An outline of what we should cover in the source documentation.
The source documentation will be available via Futon, and will eventually be published on the web.
We want to cover the basic aspects of CouchDB. Every option, every feature, every parameter.
After we have compiled an initial table of contents, we can start to flesh them out.
Eventually, these will be moved to the source in HTML format, where they will be maintained.
"For me, the goal would be for docs/ to contain at least a brief description of every couchdb feature. I specifically don't expect to see introductory text, example views, tutorials, etc, except where needed to describe core features. One thing we've missed for a long time, and Couchbase had to step in and fill this gap for us, is a genuinely comprehensive list of everything couchdb can do (all those funny corners like ?batch=ok, all_or_nothing, etc)." — Robert Newson
"However we ship the documentation in the source, it'd be cool to install it at /_docs or something. This would be straightforward. It'd be easy for futon to embed that (but it wouldn't be tied to futon). I'd love if the startup message had a link to the "Getting Started" guide or something. That makes it a lot friendlier for someone to browse the docs after installing CouchDB on a remote server." — Randall Leeds
We'd like to use the Couchbase documentation as a starting point, but need confirmation from Couchbase before we proceed.
"As part of the coursework I'm planning for January, I can start contributing back class notes and information as well. This would be the start of documentation about how the code is laid out, formatting, etc. I see this as complementary, and whoever signs up for the course can also contribute at least 30-60 minutes of documentation cleanup as well." - JoanTouzet
Table of Contents
Please list things here that you think we should cover in the source documentation, like a table of contents.