Diana Shannon wrote: > How will new docs, authored by Cocoon users, come to life? Here's my > current idea, along with some questions.
Here is my proposed process. I hope that it helps to arrive at a combined solution. 1. Author gets urge to start a new doc on a topic that is not yet addressed. 2. Author follows "How-To Start a new doc". 3. Author consults topic status list (a web page on cocoon web site) to make sure no other draft on this topic is in process. Author sends patch via bugzilla to topic-status.xml to claim the topic. 4. Following the guidelines, author decides on type (how-to, tutorial, faq, full xdoc). Author copies an appropriate document shell. They add sufficient content for a basic outline. 5. Submit patch to Bugzilla to get new outline added to scratchpad. When it is finally into CVS, then send email announcement calling for a "[REVIEW] this-document-name". 6. The overseeing editor, a Topic Group, and anyone else who is interested, looks at the scratchpad build on their own local system and sends review comments to the open list as Reply-To. There is no need to "approve" topics ... either they grow wings or they languish in the scratchpad. 7. Author takes comments and revises the outline. Sends as many patches via Bugzilla as they need. 8. When author gets the go-ahead, they expand the outline to become the first draft. They send patches via Bugzilla as before and commits still go into CVS scratchpad. 9. Author reaches a stage where they are happy to have others add input and flesh out any holes. They have flagged any known deficiencies using the <note>FIXME: ... </note> convention. Send announcement to list. 10. Now let CVS do its real work. Anyone can dive in and add their own patches. Now it is all working the same as CVS for Java code. There is a working base and various people address various lacks. CVS protects from clashing edits on the same section of the docs. Commit often. 11. After a certain period from the announcement at 9, we enter a formal QA testing phase. No matter if there were no changes during 10, just go ahead with QA. 12. Author revises as necessary. Hopefully the QA process already directly made any obvious changes. 13. After vote, document can move out of scratchpad and into the distribution proper. 14. Community/author submits patches as appropriate via the normal Bugzilla process. --------- This all hinges on the need to have the Cocoon website updated very often (so as to get the "topic list" out in the open). At the moment the website is just updated after every code release which is not often. It also hinges on the responsiveness of committers to the Patch Queue generated by Ken's automation. The power of CVS combined with an email list will facilitate this. If people are frightened to make diffs, then they can send comments to the email list and some other enthusiast will turn it into an xdoc. If people are concerned about doing CVS checkout and the like, then they can always get the current documents via ViewCVS http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/documentation/xdocs/contrib.xml One other key point is that there cannot be any single-person bottleneck. Opensource is all about a community working together where no particular person is responsible, yet everyone is responsible. --David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
