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).
I hope this answers your secondary questions, but I'd add that I'd expect to see the docs/ folder used to seed the wiki and other documentation efforts. It would become part of our procedure to insist that a commit that adds a feature also adds documentation for that feature (the way it ought to include verifying tests). B. On 26 November 2011 18:23, Noah Slater <[email protected]> wrote: > Let's forget about the format or the toolchain for now, they're bikesheds. > > What is the goal of this effort? > > We want documentation in the source, sure. But why? What kind of > documentation is it going to be? What topics will it cover? Can anyone come > up with a suggested outline for it? i.e. Table of Contents > > Secondly, who's going to be use it, and in what situation? Typical > use scenarios please! > > Thirdly, who's going to write it? > > Once we have that nailed down, we can move forward sensibly. >
