> 2. To say that documentation can be improved and fixed incrementally is to > mis-understand matters a bit, I'm afraid.
It's not, though. To be useful to anyone, code must always compile and run. Bad grammar or missing paragraphs do not invalidate the rest of the documentation, or prevent anyone from working on it. > Working on the assumption that the > major concern is developer and technical documentation, r= needs to be there to > ensure the accuracy of and currency of the documentation. In a sense, sr= is a > misnomer, it's more of a meta-review -- proof-reading, sanity checking, editing > (for clarity and understandability). I am not saying that documentation should not have peer review. That would be silly. I'm saying we don't need a r=/sr= system like code, where documentation goes through a process before it gets checked in. > 5. If we're going to have CVS blame -- and, in fact, even if we're /not/ going > to have CVS blame -- , I'd say we need to be careful as to who can make changes. > I'm beginning to think that we need a little editorial cartel for these kinds of > purposes. Surely the whole point of a version control system is you have accountability and can roll back? If there was no version control, you'd have to exercise very tight control over who could change documents. Version control widens, not narrows, the field. Again, beware of making it hard for contributors. > editor). Person X comes along and says, 'Hmm . . . this is wrong', and changes > something. This does not strike me as a desirable state of affairs. If person > X comes along and sees something and get hold of me, I can either make the > change myself or contact Alex or the doc's owner for clarification. More > cumbersome, perhaps, but a /much/ more sane state of affairs. It depends who person X is. I don't think anyone's suggesting we should open up our docs to be edited by J. Random Web-User, but there is plenty of space between that scenario and the other extreme of having to pass all changes through one or two people. Gerv
