>>No-one has yet explained why the review/super-review structure applies >>to documentation. I don't believe it does at all. > > The very same reason why there are editors and even multiple levels of > editors at publishing firms. Mozilla.org is a virtual publishing house, > with the sole product the Moz documentation.
Let me put it the other way round. Why do we have two levels of review for code? - Checking in bad code inconveniences many people (tree bustage) - Code cannot be checked in half-finished, or "cleaned up later." - Code is complex, and cannot be skim-read - Code is best changed by the original author, who is familiar with its quirks - Code is best changed near the time it was written, while it's still fresh in the mind Contrast with documentation: - it can be improved and fixed incrementally - it can be proof-read by many people quite quickly - bad documentation (while it's still in development) hurts no-one - Docs can be changed at any time by anyone who sees a mistake I think the best approach for a document is for one person or a group to write it, and post it. Then, anyone can review it and send feedback, and the document gets better and better organically. Release early, release often. We don't need formal review and super-review which you have to get before it's posted. This just raises the barrier unnecessarily. Gerv
