Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > While there are some aspects of the documentation that require a > familiarity with the source I don't think that is true in general. If > someone has a suggestion to improve part of the documentation that > they found hard to understand we should be encouraging them to > contribute a patch. There is no doubt that there are places where our > documentation could be improved and it is not necessary to be a C > programmer to contribute improvements to it. True. It is even possible to: - have a group of document nitpickers, whose charter is to improve the documentation by fixing spelling and grammar mistakes and mark-up mistakes, while making sure that what the original wanted to say is still what the updated version says. - have a gatekeeper who makes sure that the output from the above group is within the scope of its charter, before it is merged to the main tree. Then, the choice of the collaboration medium among "document nitpickers" can be delegated to the group, as long as the quality of their output is tightly controlled by the gatekeeper to meet the bar of the main tree. The resulting history should be consistent with the rest of the system when seen in "git shortlog" output, for example. The above is quite similar to how the l10n team works. There is a l10n coordinator who acts as the gatekeeper for po/ hierarchy, and l10n folks coordinate among themselves without much supervision and review of their output on the list. We can treat the documentation work that does not involve any knowledge of what the documentation describes the same way. Thanks.
