I'd like to start converting documentation to svn / DocBook as follows:

1. Create a DocBook document that corresponds to this page and the pages it references:

http://qpid.apache.org/documentation.html

At least initially, this can be a single document, composed of multiple entities. External links are referenced via URLs, Wiki content is incorporated into the sections of this document. To enable links to specific versions of generated API documentation, generated HTML will also be checked in for each release, in the documentation subtree.

I will create a subdirectory under trunk for the XML source:

    trunk/qpid/documentation/src

The initial check-in corresponds exactly to the current content, so that source code control reflects the changes made to this content.

2. Enhance existing sections with existing text, where available.

In some cases, there is existing text that can be used to enhance existing sections of the documentation. For instance, I've written some things on federation and clustering that could be added, and there is text in some existing vendor documentation that could probably be used for some existing sections.

3. Improve the overall organization

This should especially focus on a few simple goals:

- Make sure the documentation shows people how to easily install, configure, and run the brokers, in an obvious place - Make sure the documentation shows people how to easily run the examples, in an obvious place

4. Add missing material, improve existing sections with new work.

I think steps 1-3 can be done by mostly one person in a week, though it's possible that I'm being optimistic. I plan to do this next week, but my father is gravely ill, so my time is somewhat unpredictable this month. Rafi and Rajith have both offered to help, and I may well take them up on that even in the first week.

Once that is done, we'll have a template that other people can easily add to. We need to figure out how to divide up the work on this. I'll be dividing up the document into XML entities that individuals can be responsible for, so we can have someone primarily responsible for the WCF, the Java broker, the new API, etc.

Jonathan

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to