This is a rough outline of the kind of content that could appear in a Wiki "Documentation" area, if we had such an area. Conceptually I see it as the opposite of the Jungle area. It would be relatively polished for Wiki information and sometimes peoples' tasks (particularly at the end of a release) would be to add documentation here. We considered whether to put documentation in source control but the Wiki seems adequate with its versioning support and would be more encouraging to occasional contributors.

The audience for the Documentation area would fall into these types:

• Tourists
• Users
• Administrators
• Parcel Developers

Note that some documentation is for more than one audience (e.g. the Vision and Guided Tour are both for Users as well as Tourists; administrators may frequently want to refer to user guide info). Also individuals might combine their interest: e.g. a tourist today might be a user shortly, and a parcel developer is very likely also a user.

There's one characteristic that all these audiences share. They do want finished and accurate information. They hardly ever want project status, project task lists; musings or proposals about what we might implement; bug numbers or bug counts, or to know who's assigned to what; Chandler coding practices or developer community chatter; or even how our build system works (beyond downloading a build that they install or can use to write a parcel).

We can also argue that sometimes a parcel developer shades into a contributor and those people will be interested in both Documentation and Projects areas. That's fair enough, but I think that type of person can easily navigate both areas -- there's still going to be a type of developer that doesn't want the firehose of OSAF project info but just wants to try writing a parcel based on clear documentation.

"Tourist" information

People who are interested in high-level information about Chandler aren't users, so I call them tourists -- anybody got a better word? CSG partners are sometimes tourists, for example.

This is the information we currently have up-to-date:

Information that is out-of-date but we should update:

• Vision
• ProductRoadmapNov2004
• Guided tour
• Westwood agreements/plans

Information we need to create short-term:

• Cosmo Intro
• Scooby Intro
• Network Architecture

End-user documentation

Content we already have:

• EndUserDocumentation
• GettingChandler

Content we should get someday, possibly even in 0.6 but definitely by Kibble:

• Setting up an Email account
• Setting up a Sharing account
• Sharing with other Chandler users
• Sharing somebody's iCal calendar...

Administrator documentation

We have none of this yet, but with Cosmo and Scooby, we will. E.g. for starters...

• Installing Cosmo and Scooby
• Installing just Cosmo
• Managing users

Parcel Developer Documentation

This is where we have the most documentation so far, where we explain parts of Chandler so that people can understand how to extend it with their own works. Right now we tend not to distinguish different kinds of developers. The DeveloperDocumentation sub-area is for contributors to Chandler as well as parcel writers. It mixes information about Chandler's coding style (only for contributors) together with information about writing parcels and the ZaoBao^? example parcel.

Anyway, pulling from that the information that I think is of interest to parcel developers:

• Pycon tutorial paper -- can be broken out into individual pages, possibly
• ZaoBaoTutorial
• ZeroPointFourArchitectureDiagram
• Busy Developer's guide to the repository
• CpiaZeroPointFourStatus
• Queries
• ParcelManager
• ItemClouds
• StampingModel
• ZeroPointFourSharingSummary
• ZeroPointFourItemCollectionSummary

Some of this does need updating but it's a start.