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