wiki choice: moinmoin vs confluence

[Paul Okstad <po...@gmail.com>]

Hello dev team,

I'm following up on a brief discussion I had with the CouchDB twitter
account (my handle: @pokstad) regarding the official ASF wiki for CouchDB.

I'm a CouchDB evangelist in both my personal projects and at my full time
job at a large engineering company (not Atlassian, lol). When I advocate
CouchDB, the main thing that becomes frustrating is the lack of quality
documentation. The CouchDB Guide by J. Chris Anderson was a great
introductory resource, but the current draft version is so out of date that
it's not a great resource to introduce new users to couch IMO.

I believe part of the reason for the lack of documentation is the lack
luster moinmoin wiki.  Obviously, being a huge fan of CouchDB I am a big
proponent for OSS, but I feel that the moinmoin wiki is hurting the CouchDB
community. It's a very unattractive interface and it is difficult to
navigate the wiki. While these concerns may not be huge issues for the
person(s) who chose this wiki, I believe it raises a barrier to entry for
less-technical potential contributors (e.g. myself).

CouchDB is also about a community of developers and users, and Atlassian
has been working very hard on making the current Confluence release more
and more social. I know this sounds like a tired buzzword, but consider
this: Atlassian supports blog entries for users of a wiki space. Right now,
there are many couchdb blog entries scattered about the web on many
different managed sites. What if members of the CouchDB wiki space were
permitted to write blog entries about anything they want? Not just
structured documentation, but also a well designed hub for anything couch
related. This could really unify couchdb articles. Also, the newest
confluence has support for twitter like #hashtags and @mentions that can be
used for tagging articles/pages and alerting users.

Also consider this: Confluence has a Flash/HTML5 plugin that would allow
users to collaborate on architectural drawings to illustrate CouchDB use
cases better.

Anyway, I'm really excited about CouchDB and I really want to contribute to
the global documentation out there, but MoinMoin ain't making it easy. I
really think that a move to a better documentation tool could be a huge
push to CouchDB's adoption. Thanks for listening.

-- 
Paul Okstad

Re: wiki choice: moinmoin vs confluence

[Filippo Fadda <fi...@programmazione.it>]

The documentation in the source is a great idea, and it's great having it in Futon. In my opinion the wiki is superfluous and should be removed.

My 2 cents.

-Filippo

Re: wiki choice: moinmoin vs confluence

[Dave Cottlehuber <dc...@jsonified.com>]

On 1 May 2013 20:50, Paul Okstad <po...@gmail.com> wrote:

> Hello dev team,
>
> I'm following up on a brief discussion I had with the CouchDB twitter
> account (my handle: @pokstad) regarding the official ASF wiki for CouchDB.
>
> I'm a CouchDB evangelist in both my personal projects and at my full time
> job at a large engineering company (not Atlassian, lol). When I advocate
> CouchDB, the main thing that becomes frustrating is the lack of quality
> documentation. The CouchDB Guide by J. Chris Anderson was a great
> introductory resource, but the current draft version is so out of date that
> it's not a great resource to introduce new users to couch IMO.
>
> I believe part of the reason for the lack of documentation is the lack
> luster moinmoin wiki.  Obviously, being a huge fan of CouchDB I am a big
> proponent for OSS, but I feel that the moinmoin wiki is hurting the CouchDB
> community. It's a very unattractive interface and it is difficult to
> navigate the wiki. While these concerns may not be huge issues for the
> person(s) who chose this wiki, I believe it raises a barrier to entry for
> less-technical potential contributors (e.g. myself).
>
> CouchDB is also about a community of developers and users, and Atlassian
> has been working very hard on making the current Confluence release more
> and more social. I know this sounds like a tired buzzword, but consider
> this: Atlassian supports blog entries for users of a wiki space. Right now,
> there are many couchdb blog entries scattered about the web on many
> different managed sites. What if members of the CouchDB wiki space were
> permitted to write blog entries about anything they want? Not just
> structured documentation, but also a well designed hub for anything couch
> related. This could really unify couchdb articles. Also, the newest
> confluence has support for twitter like #hashtags and @mentions that can be
> used for tagging articles/pages and alerting users.
>
>
Thanks Paul, <3 this discussion!

I'm neither for nor against it, but here's my woolly thinking:

## Real Docs

I'd prefer to have quality docs in the source code / .rst files if
possible. Wikis are ok for evolving stuff but if it's actually usage of
CouchDB proper, in the source is the way to go. You get history directly
tied to source code / release versions for free too.

The ASF comments plugin works when hooked up to our docs system but I've
failed to get it to appear in a usable form in the right place on the page
just yet.

I love markdown, am OK with rst, and hate wiki format,and loathe crappy web
IDEs.

## Blog

Anybody can contribute to the ASF CouchDB blog by simply sending an
attached markdown file along, jira ticket, to the dev@ mailing list, or via
git. I've found a simple way to pre-process these including with
source-code highlighting, so it gets processed, and then manually uploaded,
and with a little bit more effort this can likely be done by anybody with
ASF commit privs via a single script + sanity checking.

## the Guide

The rewrite and inclusion of the book into CouchDB source itself is a big
task, but if Noah etc are ok for us to take the ball & run with it (IP
clearance etc notwithstanding) then people can get on with it as we did for
the ex-Couchbase docs.

## The wiki

Suffers from the same fate as all wikis, maintainability. Same as our
released .rst docs for that matter. They need tender love.



> Also consider this: Confluence has a Flash/HTML5 plugin that would allow
> users to collaborate on architectural drawings to illustrate CouchDB use
> cases better.
>
> Anyway, I'm really excited about CouchDB and I really want to contribute to
> the global documentation out there, but MoinMoin ain't making it easy. I
> really think that a move to a better documentation tool could be a huge
> push to CouchDB's adoption. Thanks for listening.
>
> --
> Paul Okstad
>

And thanks again for writing.

If you (and any others) want to fix this, I'm all for assisting you to make
it happen.

We probably need some kind of "document strategy" which sounds overkill,
but probably boils down to 3 things.

- where we store official content vs evolving stuff
- how can we make it as easy to add/edit stuff as possible (blog, wiki,
source docs, whatever)
- keeping in simple and up to date

Oh I've just seen Wohali's comments so, yeah, +1 to that too.

Please let me know if & how can help.

A+
Dave

Re: wiki choice: moinmoin vs confluence

[Joan Touzet <wo...@apache.org>]

On Wed, May 01, 2013 at 12:58:44PM -0700, Jens Alfke wrote:
> I agree; it's pretty unpleasant to use. I've been contributing to it intermittently for over a year but it's always a chore.

+1

[snip]

> We use Confluence internally at Couchbase, but in practice people don't seem very happy with it — informally, it looks to me like people here use private Github wikis and Google Docs a lot more for internal docs. The usual complaint I hear is that it's too complicated, and too hard to find things in.
> 
> But it's better than MoinMoin, and it integrates with Jira, so I'd be in favor of switching. (Not that I have any sway around here.)

Basically, I agree with this. GH wiki is a very low barrier to entry,
but only when GH is the version control system of default. With ASF's
web git infrastructure not rendering Markdown/Textile/whatever, using
text-based wiki conversion is not as motivational.

I've used Confluence on and off for about 8 years. Recently, they've
removed the "wikitext editor" which is a step backwards for coders like
us, but makes contribution by non-technical people a lot simpler.

I'd be +1 on moving to Confluence and could probably spare a Saturday to
help migrate content. The trick to making a good Confluence wiki is the
information architecture, and clear guidelines on where to put content.

There are some add-on macros that will build a dynamic index of pages
with a given tag, for instance, and some that provide improved
formatting.  There's even some workflow stuff if we wanted to show that
a page was +1'ed by a committer. It'd be good to get a sense from ASF
Infra all the plugins currently available, and their openness to new
plugins.

-- 
Joan Touzet | joant@atypical.net | wohali everywhere else

Re: wiki choice: moinmoin vs confluence

[Jens Alfke <je...@couchbase.com>]

On May 1, 2013, at 11:50 AM, Paul Okstad <po...@gmail.com>> wrote:

I believe part of the reason for the lack of documentation is the lack
luster moinmoin wiki.

I agree; it's pretty unpleasant to use. I've been contributing to it intermittently for over a year but it's always a chore.

CouchDB is also about a community of developers and users, and Atlassian
has been working very hard on making the current Confluence release more
and more social.

We use Confluence internally at Couchbase, but in practice people don't seem very happy with it — informally, it looks to me like people here use private Github wikis and Google Docs a lot more for internal docs. The usual complaint I hear is that it's too complicated, and too hard to find things in.

But it's better than MoinMoin, and it integrates with Jira, so I'd be in favor of switching. (Not that I have any sway around here.)

Another alternative would be a wiki CouchApp. (Mm, dog food!) Are there any good ones?

—Jens

Re: wiki choice: moinmoin vs confluence

[Noah Slater <ns...@apache.org>]

On 19 May 2013 08:57, Dirkjan Ochtman <di...@ochtman.nl> wrote:

>
> On Sat, May 18, 2013 at 5:40 PM, Noah Slater <ns...@apache.org> wrote:
> > 1) Yes! Let's get the docs/ sorted out! Moving NEWS/CHANGES into them.
> > Moving CouchDB: The Definitive Guide into them. Incorporating the docs
> into
> > our merge and release procedure. Drumming up a docs team! (Dave! Dirkjan!
> > Alexander! All the exclamation points!)
>
> Yes, I expect to spend a bunch of time on this.
>

Great news!

-- 
NS

Re: wiki choice: moinmoin vs confluence

[Dirkjan Ochtman <di...@ochtman.nl>]

On Thu, May 9, 2013 at 12:53 PM, Robert Newson <rn...@apache.org> wrote:
> I'm -0.9 (see http://www.apache.org/foundation/voting.html) on
> switching to Confluence. The choice of wiki technology is a tiny
> factor, in my opinion. No wiki is useful without active maintenance.
> Unless there's a horde of editors just waiting for the switch before
> they'll help out, I think it's a distraction from the real issue.

I couldn't agree more.

On Fri, May 17, 2013 at 8:48 PM, Paul Okstad <po...@gmail.com> wrote:
> Sphinx is a great tool, but it still doesn't have the user friendliness or
> social features of Confluence. What I'm suggesting is a way to get more
> involvement from less-technical members of the CouchDB community. Sphinx
> could be a great way to host official "strict" docs, but Confluence would
> be a great way for non-couch-devs to provide use cases and higher level
> documentation to total noobs. While I miss the markup removed in
> Confluence, it has lowered the barrier to people who don't know the mark up
> differences from wiki system to wiki system. It might be useful to have a
> dual-wiki approach: one for strict API docs tied to source code and one for
> casual and end user provided articles. I'm really surprised that the
> current source code hosted documentation isn't linked to from the wiki.
> Also, maybe I'm just talking too much :D

I think you're underestimating the user-friendliness of Sphinx and
probably also the level of technical knowledge of the average CouchDB
user. As pretty much all CouchDB users are actually software
developers, most of them should be able to handle reStructuredText in
their editor (and even if they don't, just writing some text into
Notepad is pretty easy).

On Sat, May 18, 2013 at 5:40 PM, Noah Slater <ns...@apache.org> wrote:
> 1) Yes! Let's get the docs/ sorted out! Moving NEWS/CHANGES into them.
> Moving CouchDB: The Definitive Guide into them. Incorporating the docs into
> our merge and release procedure. Drumming up a docs team! (Dave! Dirkjan!
> Alexander! All the exclamation points!)

Yes, I expect to spend a bunch of time on this.

Cheers,

Dirkjan

Re: wiki choice: moinmoin vs confluence

[Noah Slater <ns...@apache.org>]

Quick response:

1) Yes! Let's get the docs/ sorted out! Moving NEWS/CHANGES into them.
Moving CouchDB: The Definitive Guide into them. Incorporating the docs into
our merge and release procedure. Drumming up a docs team! (Dave! Dirkjan!
Alexander! All the exclamation points!)

2) We will always need a wiki. The wiki is a cool space to hash out
cookbooks, recipes  "this is what I had to do to get this working" stuff.
But also, our homepage is a marketing site. Which means that our wiki is
our website. It has page on where our source code lives, on how to
contribute, on how our releases work, how our community works, etc.

3) MoinMoin is a POS. I would be +1 on a migration to Confluence. As much
as Confluence is also a POS, it's a lesser of two evils, and it presumably
has better integration with JIRA. Having said that, I don't think this is
critical. That is, we have bigger problems/ideas to tackle. But also, I can
see that this is a "nice to have".

On that note, if somebody wants to step forward and say "I think Confluence
is a good idea, and I am prepared to move all of our content to it" then I
would be in support of that.

I would hope for the following:

* The migration is also a "pass" over the content to tidy it up and
restructure it a bit.
* The migration identifies anything that should be in the docs (i.e.
CouchDB documentation vs. project documentation) and better yet, actually
moves that content over the to docs, even if it's only to a scratch pad or
in a "wiki-docs" branch or something.
* That this effort, or rather, the person or people involved in this
effort, form our inaugural "wiki team". That is. We've had the concept of
teams for a while now, and I think Jason is going to make a proposal on
this topic soon. But a "team" in this context could simply be a group of
folks who say "I care about the wiki and I will tend to it semi-regularly".


On 17 May 2013 19:48, Paul Okstad <po...@gmail.com> wrote:

> >
> > I'd prefer to have quality docs in the source code / .rst files if
> > possible. Wikis are ok for evolving stuff but if it's actually usage of
> > CouchDB proper, in the source is the way to go. You get history directly
> > tied to source code / release versions for free too.
> >
>
> I love having the manual acessible from Futon in 1.3. Definitely a good
> idea for official API documentation to be stored with source. Confluence
> would be better for hosting end user written informal docs (e.g. stuff
> currently covered by the CouchDB Guide).
>
> Anybody can contribute to the ASF CouchDB blog by simply sending an
> > attached markdown file along, jira ticket, to the dev@ mailing list, or
> > via
> > git.
> >
>
> Sounds like a good way to submit immutable content for ASF members, but
> what about "living" blog entries that can be easily updated as time goes
> forward? Confluence allows you to easily maintain a chronological listing
> of blog entries parallel to structured wiki content and each entry can be
> tagged with labels so that you can cross reference blogs automatically from
> structured wiki content (e.g. I can add a "changes_feed" label to my blog
> entry on how to create a chat room CouchApp, and then back in the HTTP API
> section for the _changes feed you can automatically list articles related
> to the "changes_feed" label).
>
> Also, just listening to the whole process of submitting a blog entry makes
> it really clear that this is a process very specific to ASF and not known
> to your typical CouchDB community person. There's a lot of valuable
> documentation out there written by end users of CouchDB that would benefit
> from being hosted centrally and in a user friendly way.
>
> There's even some workflow stuff if we wanted to show that
> > a page was +1'ed by a committer. It'd be good to get a sense from ASF
> > Infra all the plugins currently available, and their openness to new
> > plugins.
> >
>
> The +1 ability is a good example of how the social aspects of Atlassian can
> help a collaborative project like this. Also, a good plugin to check on
> would be Gliffy, which is great for illustrative purposes. It lowers the
> barrier to creating diagrams that are also version controlled.
>
> Have you seen the new Sphinx-based docs?
> >
>
> Sphinx is a great tool, but it still doesn't have the user friendliness or
> social features of Confluence. What I'm suggesting is a way to get more
> involvement from less-technical members of the CouchDB community. Sphinx
> could be a great way to host official "strict" docs, but Confluence would
> be a great way for non-couch-devs to provide use cases and higher level
> documentation to total noobs. While I miss the markup removed in
> Confluence, it has lowered the barrier to people who don't know the mark up
> differences from wiki system to wiki system. It might be useful to have a
> dual-wiki approach: one for strict API docs tied to source code and one for
> casual and end user provided articles. I'm really surprised that the
> current source code hosted documentation isn't linked to from the wiki.
> Also, maybe I'm just talking too much :D
>
> On Thu, May 9, 2013 at 3:53 AM, Robert Newson <rn...@apache.org> wrote:
>
> > I'm definitely in favour of building up the docs/ effort to replace
> > the wiki as *the* place to find out how couchdb works. I can't quite
> > picture what will be left of the wiki when that's achieved. I guess
> > the pages where we list contributors and couchdb-based projects, but
> > not too much else.
> >
> > I'm -0.9 (see http://www.apache.org/foundation/voting.html) on
> > switching to Confluence. The choice of wiki technology is a tiny
> > factor, in my opinion. No wiki is useful without active maintenance.
> > Unless there's a horde of editors just waiting for the switch before
> > they'll help out, I think it's a distraction from the real issue.
> >
> > B.
> >
> > On 9 May 2013 11:46, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> > >> Anyway, I'm really excited about CouchDB and I really want to
> > contribute to
> > >> the global documentation out there, but MoinMoin ain't making it
> easy. I
> > >> really think that a move to a better documentation tool could be a
> huge
> > >> push to CouchDB's adoption. Thanks for listening.
> > >
> > > Have you seen the new Sphinx-based docs? I think they're a huge
> > > improvement over both the wiki and the book drafts. Personally, I
> > > think it would make a lot of sense to invest more time in those,
> > > rather than moving wiki content around. We could port wiki content
> > > that's missing from the docs to reST so it gets included in every
> > > CouchDB release (where it's easily accessible through Futon).
> > >
> > > I think the biggest problem with the wiki is that wikis require a lot
> > > of what I tend to think of as "gardening" to make them easy to
> > > navigate. I don't think MoinMoin is the larger problem here (though I
> > > tend to agree that it's pretty unattractive).
> > >
> > > If we want to go one step further with reST, it would even be possible
> > > to have similar handling for the blog. I use Pelican for my personal
> > > blog and it uses reST as well. We could have a directory "blog" in the
> > > tree somewhere where people can collaborate on blog entries which
> > > subsequently get published to the interwebz.
> > >
> > > Cheers,
> > >
> > > Dirkjan
> >
>
>
>
> --
> Paul Okstad
> (310) 359-0767
>



-- 
NS

Re: wiki choice: moinmoin vs confluence

[Paul Okstad <po...@gmail.com>]

>
> I'd prefer to have quality docs in the source code / .rst files if
> possible. Wikis are ok for evolving stuff but if it's actually usage of
> CouchDB proper, in the source is the way to go. You get history directly
> tied to source code / release versions for free too.
>

I love having the manual acessible from Futon in 1.3. Definitely a good
idea for official API documentation to be stored with source. Confluence
would be better for hosting end user written informal docs (e.g. stuff
currently covered by the CouchDB Guide).

Anybody can contribute to the ASF CouchDB blog by simply sending an
> attached markdown file along, jira ticket, to the dev@ mailing list, or
> via
> git.
>

Sounds like a good way to submit immutable content for ASF members, but
what about "living" blog entries that can be easily updated as time goes
forward? Confluence allows you to easily maintain a chronological listing
of blog entries parallel to structured wiki content and each entry can be
tagged with labels so that you can cross reference blogs automatically from
structured wiki content (e.g. I can add a "changes_feed" label to my blog
entry on how to create a chat room CouchApp, and then back in the HTTP API
section for the _changes feed you can automatically list articles related
to the "changes_feed" label).

Also, just listening to the whole process of submitting a blog entry makes
it really clear that this is a process very specific to ASF and not known
to your typical CouchDB community person. There's a lot of valuable
documentation out there written by end users of CouchDB that would benefit
from being hosted centrally and in a user friendly way.

There's even some workflow stuff if we wanted to show that
> a page was +1'ed by a committer. It'd be good to get a sense from ASF
> Infra all the plugins currently available, and their openness to new
> plugins.
>

The +1 ability is a good example of how the social aspects of Atlassian can
help a collaborative project like this. Also, a good plugin to check on
would be Gliffy, which is great for illustrative purposes. It lowers the
barrier to creating diagrams that are also version controlled.

Have you seen the new Sphinx-based docs?
>

Sphinx is a great tool, but it still doesn't have the user friendliness or
social features of Confluence. What I'm suggesting is a way to get more
involvement from less-technical members of the CouchDB community. Sphinx
could be a great way to host official "strict" docs, but Confluence would
be a great way for non-couch-devs to provide use cases and higher level
documentation to total noobs. While I miss the markup removed in
Confluence, it has lowered the barrier to people who don't know the mark up
differences from wiki system to wiki system. It might be useful to have a
dual-wiki approach: one for strict API docs tied to source code and one for
casual and end user provided articles. I'm really surprised that the
current source code hosted documentation isn't linked to from the wiki.
Also, maybe I'm just talking too much :D

On Thu, May 9, 2013 at 3:53 AM, Robert Newson <rn...@apache.org> wrote:

> I'm definitely in favour of building up the docs/ effort to replace
> the wiki as *the* place to find out how couchdb works. I can't quite
> picture what will be left of the wiki when that's achieved. I guess
> the pages where we list contributors and couchdb-based projects, but
> not too much else.
>
> I'm -0.9 (see http://www.apache.org/foundation/voting.html) on
> switching to Confluence. The choice of wiki technology is a tiny
> factor, in my opinion. No wiki is useful without active maintenance.
> Unless there's a horde of editors just waiting for the switch before
> they'll help out, I think it's a distraction from the real issue.
>
> B.
>
> On 9 May 2013 11:46, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> >> Anyway, I'm really excited about CouchDB and I really want to
> contribute to
> >> the global documentation out there, but MoinMoin ain't making it easy. I
> >> really think that a move to a better documentation tool could be a huge
> >> push to CouchDB's adoption. Thanks for listening.
> >
> > Have you seen the new Sphinx-based docs? I think they're a huge
> > improvement over both the wiki and the book drafts. Personally, I
> > think it would make a lot of sense to invest more time in those,
> > rather than moving wiki content around. We could port wiki content
> > that's missing from the docs to reST so it gets included in every
> > CouchDB release (where it's easily accessible through Futon).
> >
> > I think the biggest problem with the wiki is that wikis require a lot
> > of what I tend to think of as "gardening" to make them easy to
> > navigate. I don't think MoinMoin is the larger problem here (though I
> > tend to agree that it's pretty unattractive).
> >
> > If we want to go one step further with reST, it would even be possible
> > to have similar handling for the blog. I use Pelican for my personal
> > blog and it uses reST as well. We could have a directory "blog" in the
> > tree somewhere where people can collaborate on blog entries which
> > subsequently get published to the interwebz.
> >
> > Cheers,
> >
> > Dirkjan
>



-- 
Paul Okstad
(310) 359-0767

Re: wiki choice: moinmoin vs confluence

[Robert Newson <rn...@apache.org>]

I'm definitely in favour of building up the docs/ effort to replace
the wiki as *the* place to find out how couchdb works. I can't quite
picture what will be left of the wiki when that's achieved. I guess
the pages where we list contributors and couchdb-based projects, but
not too much else.

I'm -0.9 (see http://www.apache.org/foundation/voting.html) on
switching to Confluence. The choice of wiki technology is a tiny
factor, in my opinion. No wiki is useful without active maintenance.
Unless there's a horde of editors just waiting for the switch before
they'll help out, I think it's a distraction from the real issue.

B.

On 9 May 2013 11:46, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> Anyway, I'm really excited about CouchDB and I really want to contribute to
>> the global documentation out there, but MoinMoin ain't making it easy. I
>> really think that a move to a better documentation tool could be a huge
>> push to CouchDB's adoption. Thanks for listening.
>
> Have you seen the new Sphinx-based docs? I think they're a huge
> improvement over both the wiki and the book drafts. Personally, I
> think it would make a lot of sense to invest more time in those,
> rather than moving wiki content around. We could port wiki content
> that's missing from the docs to reST so it gets included in every
> CouchDB release (where it's easily accessible through Futon).
>
> I think the biggest problem with the wiki is that wikis require a lot
> of what I tend to think of as "gardening" to make them easy to
> navigate. I don't think MoinMoin is the larger problem here (though I
> tend to agree that it's pretty unattractive).
>
> If we want to go one step further with reST, it would even be possible
> to have similar handling for the blog. I use Pelican for my personal
> blog and it uses reST as well. We could have a directory "blog" in the
> tree somewhere where people can collaborate on blog entries which
> subsequently get published to the interwebz.
>
> Cheers,
>
> Dirkjan

Re: wiki choice: moinmoin vs confluence

[Dirkjan Ochtman <di...@ochtman.nl>]

> Anyway, I'm really excited about CouchDB and I really want to contribute to
> the global documentation out there, but MoinMoin ain't making it easy. I
> really think that a move to a better documentation tool could be a huge
> push to CouchDB's adoption. Thanks for listening.

Have you seen the new Sphinx-based docs? I think they're a huge
improvement over both the wiki and the book drafts. Personally, I
think it would make a lot of sense to invest more time in those,
rather than moving wiki content around. We could port wiki content
that's missing from the docs to reST so it gets included in every
CouchDB release (where it's easily accessible through Futon).

I think the biggest problem with the wiki is that wikis require a lot
of what I tend to think of as "gardening" to make them easy to
navigate. I don't think MoinMoin is the larger problem here (though I
tend to agree that it's pretty unattractive).

If we want to go one step further with reST, it would even be possible
to have similar handling for the blog. I use Pelican for my personal
blog and it uses reST as well. We could have a directory "blog" in the
tree somewhere where people can collaborate on blog entries which
subsequently get published to the interwebz.

Cheers,

Dirkjan