On 1/24/06, Dave Johnson <[EMAIL PROTECTED]> wrote: > Personally, I think the wiki is great for collaborative document > development -- things like proposals, FAQ files and up-to-the minute > docs such as release notes. But for formal documents like the user > guide and installation guide, I much prefer using a real word > processing system with a user-friendly interface and the ability to > save to PDF and HTML.
Everything we do is suppose to be a collaborative document. Source code, emails, web site, documentation, issue trackers, and wikis. Everything about a ASF project is suppose to be about collaboration. It's not about the code. It's not about features. It's about collaboration. It's about community. The code, documentation, and support that we deliver to the public is a byproduct of ASF's inner mission: Creating communites that collaborate. A binary word processing format does not promote collaboration. It promotes an environment where one or maybe two people do all the work. I realize that right now Dave is doing all or most of the work on the documentation. ** BUT THAT IS A BAD THING!!!! ** The ASF does *not* want any aspect of any project to be dependant on a sole individual. Every member of the PPMC needs to be in the loop on everything the podling project does, and every member has to be ready to step up and do what needs to be done should other people be unavailable. OK, let's have a show of hands: How many members of the PPMC have a *clue* of what changes we made to the User Guide last week? I have a clue because I submitted the "patch". But I really don't know what Dave applied and what Dave didn't apply. Only Dave knows. One person. And that is bad. Very, Very Bad. My suggestion is that we (meaning I) move the documentation to XML that can be rendered by Forrest, or Maven, or just plain Ant, which is what most other projects do. The changelog for the XML commits can be read by human beings, and then everyone is able to know exactly what changes. -Ted.
