> In the interest of public transparency and honesty, you should have > mentioned that Richard has already explicitly and unequivocally rejected > the proposal for a public, project-wide wiki. Therefore, the following > question must be emphasized:
Richard, as do you, have the right to reject anything you dislike. Do you have a public URL to Richard's statement? I think what he wrote was quite clear, so there is little use to persue the topic further. A decision was made, so please respect that. The "GNU Coding Standards" is a good example of a document that has no real official requirement to be followed, and my opinion is that it should have more liberal updates by programming language experts from the GNU Project volunteers with modern experience in the tooling used to develop such programs. I have no interest in proposing changes to the GCS unless and until it is publicly documented how the process of updates will work and who will review the changes and authorize their acceptance. That process is already documented, and it is like with any other GNU project, you talk to the maintainer, e.g, the GCS is maintained by RMS. If you wish to send improvments, or discuss changes to it you can send that to bug-standa...@gnu.org. Policy documents should absolutely live in very highly controlled repositories and go through a specifically crafted processes for change. We must follow many of the requirements in the "Information for maintainers of GNU software" and that document should be as clear as possible. You say we must follow requirements and policies, but yet you purposely rejected it when you removed text that was explcitly asked to be kept by RMS in the glibc manual. Which is it? Lastly, even small teams can make effective use of wikis. I have run a team of ~4 developers for a long time and we make effective use of wiki or wiki-like software for collaboration. My impression from the dozens of other developers I've spoken to on this topic indicates the same effective use of wikis. Most ad-hoc mechanisms boil down to using wiki-like software, either etherpad (which we could run too, and it's FOSS) or pastebin (available under CC0 for Stikked). And others have run similar, and larger projects without wikis. I agree with Brandon, in that wikis are terrible for documentation purposes, and think that the quality of the glibc/gcc/... manuals, for example, has become much worse due to the fact that a wiki is being used. Much of it is very hard to navigate, and find relevant information -- not to mention that one is required to have a network connection. And some parts might be very very wrong. A good manual takes concious effort to update, since a wiki doesn't it will always be a much worse place for writing down things. I refute your claim that wikis are bad ideas. You personally may not like them and they may not suit your own developer needs, but that is not true for all developers. The GCS, etc, are maintained by people who feel that they don't have a use for a wiki or that it would be useful for the purpose. GCC, the GNU C library, are maintained by people who feel that a wiki is useful for their purpose. Today, we have a nice balance of people being able to make things work for them, but you are trying to force everyone into your workflow.
