[voltagex_]

>But I bet people will welcome documentation contributions with little hesitation.

People should treat documentation issues the same way as critical bugs IMO. Can anyone point me to projects where this is done? e.g. documentation category on a bug tracker, open issues requesting additional documentation.

[orderlyoctopus]

I remember noticing Vuejs using the issue tracker for documentation in the lead up to their release of 2.0.

FreeBSD also does this, which will surprise no one who has ever read the FreeBSD docs.

Also, one of the reasons I asked this question in response to antirez is because the Redis docs are excellent and have been since I first set eyes on the project three or four years ago. I don't know what he's doing or how he does it, but whatever it is, it's working.

[antirez]

Hello, I write the doc myself for the most part, since I believe the docs should be only written by persons that wrote the code they are documenting, or that fully understand it in the subtle parts. I happen to also love to write, so it's quite fun for me to do documentation, while I understand there are a seizable amount of programmers that don't like to write documentation a lot.

However to return to your original question of what is possible to do to help, issues verification/triage is a HUGE thing because the issues are of hugely mixed quality. Moreover Github does not help by making users not able to label the issues in order to make them into categories: only the collaborators can label issues.

Another problem I face is high quality QA, that is, a person that explores certain parts of Redis to understand where there is a quality problem and how it is possible to fix it.

Code reviews are also crucial. For a few months I had a contributor, Sun He, that prevented a number of bugs in Redis by reading each commit and by understanding non trivial bugs just reading the code. Impressive. Eventually he got a job after the university and now contributes only from time to time, but I'll be thankful forever ;-)

[merb]

well not treating them as critical, but there are many projects that do so. One scala Project for example: https://github.com/playframework/playframework/labels/docume...

Unfortunatly once they are there not many PRs will address, these, only if their are actually critical. (Well the problem with play is actually that you need to read the README.md of the documentation carefully to make documentation and to understand a little bit of sbt and scala.)

Also it's actually not easy to write understandable documentation for many users. Some people are just too different, so that some actually need a way more detailed view, while for others this would be disturbing and useless noise, the golden middle is hard, especially if you contribute documentation to a framework which includes different libraries, it's really hard to keep the documentation simple.

P.S.: gitlab also treats documentation very seriously. (just to have at least two examples)