Either commit to keeping documentation rigorously up to date, or save yourself the effort to write it. With code it's easy: keep the documentation in the same repository as your code and make documentation an integral part of the review process.
-
Final point: if by policy you delay docs release, how are your users incentivized to keep up to date about your project (including it's bugs) with those.
It wouldn't be the policy to delay, so much as to avoid putting the pressure on having perfect docs at the point of release. It's trying to reduce the friction in writing documentation at any time.
-
-
You raised very good points. My concern, at the beginning, was finding a way to minimize the effort in enforcing the update of docs, as I believe they're a fantastic medium to minimize the friction to adoption and contribution. How would you deal with that?
-
Enforcing is harder (and hints at a need for a policy, as you suggest...) My goal is to make it easier to make contributions. For an OSS project, a separate docs repo can lower the barriers to contributing (think, closer to a wiki).
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.