In the previous team call, Weekly Team Call (March 12th, 2020) there was a suggestion that updating documentation becomes a requirement for a release. With the validation process for now being, maintainers sign off on a release.
I’m looking to make more specific what “the bar” is for documentation. Now and going forward.
Two things I would like to point out starting the discussion is:
- We’re in a Beta stage, so I believe the target audience to aim for currently would be (potential) contributors to SourceCred and/or Beta pilot partners.
- Since contributors’ time is one of our main bottlenecks, I believe low-hanging fruit suggestions are better than painting ideal scenarios right now.
With that said, here’s what I would propose for Release v0.5.0 #1679.
In this release there’s a list of new features:
I think it would be good to have a (blog-like) introduction of new features / major changes.
These would have an outline of: What is it? Why is it useful? How do I (technically) use this?
I believe, by doing this only for major features/changes and in a blog-like introduction only (rather than maintaining a full technical documentation of all features across versions). We keep the administrative burden low. While still putting some pressure to document these major changes in a format that we could share more broadly with the target audience.