This page is for describing and expounding on why you should / would want to use the ApacheWiki. Its points and virtues should be detracted on this page WhyNotUseWiki.
Because mailing lists are basically in-sight/in-mind, out-of-sight/out-of-mind. Basically, mailing lists are great for discussion, but awful for presenting current status.
The Wiki provides an excellent mechanism for capturing the current status of an evolving topic of interest, and is more convenient (and accessible to non-Committers) than the CVS.
The Wiki provides an excellent mechanism for collaborative editing, and the participation of users for whom CVS rights are not warranted.
In practice, attacks on wikis rarely occur and when they do they are corrected within a very short period of time. Just try spamming or vandalizing WardsWiki or WikiPedia and see how quickly it gets reverted. Because the RecentChangesJunkies FixBrokenWindows, vandals have no incentive to keep vandalizing.
- The more popular a wiki gets, the more consistent its content becomes. Misleading or wrong information is corrected or segregated (into a discussion page for example) quickly. You get just as much misleading information from mailing lists as wikis (if not more). Besides, you wouldn't publish a wiki as the 'official' version of documentation, it's more like a development snapshot including all those tests and experiments.
Those interested parties should scan RecentChanges periodically, if they aren't already RecentChangesJunkies. If they're not 'keeping up' on their reading, they probably aren't 'keeping up' on their mailing list reading either. Besides, the discussions on wikis tend not to be the kind that are time-sensitive. Interested parties can come back to a topic 6 months later and add their contributions then. Some of the best wiki pages are 'grown' this way.
These points were originally regarding three points on WhyNotUseWiki. They seem out of context now that they've been moved to a separate page.
StefanoMazzocchi provides some excellent points for why one should use wikis.
(in response to how the ApacheWiki can be moderated).
It doesn't have to be a one-person job, just like CVS commits oversight is parallelized by sending email on the mail list. What if Wiki commits were sent to the project-docs mail list? It might be a second step, a step that will provide oversight.
My point is: just because the first step of a particular new service being asked to be offered by the ASF doesn't look right, it doesn't mean that it should not be allowed for people to experiment.
Think about it: many people used to closed development see the open source development model as *chaotic* at the very least. The fact that *every* committer is allowed to write something somewhere without telling anybody would scare the crap out of any commercial project manager. In fact, they tend to do the opposite: careful access control, top-bottom design and all that.
XP (eXtreme Programming) was the first stone thrown against that wall. Interesting enough, an open development model and XP have a lot in common.
Now: we have applied the same development model to both code *and* documentation. IMHO, it doesn't work.
I can't tell you exactly *why* (even if I do have a few key pieces in mind), but the system doesn't scale.
What we've tried to do to fix this was to give commit access very easily to people that sent patches for the cocoon documentation. This created a 'documentation team' inside the cocoon dev community and they soon figured out that the problem the users were experiencing was this very steep learning curve to be able to submit anything to them.
Thus the CocoonWiki and its amazing growth.
Now, let me draw a parallel here: imagine to do software development on a wiki and imagine you didn't know anything better. No CVS and no mail list.
I would clearly not work. But what would be your estimation of *why* that doesn't work?
The first comment about people used to hierarchical models would be: "because everybody is allowed to touch it, so it becomes a mess".
What if we are doing that mistake here? what if the wiki doesn't really work well in creating good and coherent documentation because it's just a first technological step instead of a inherently-messy medium?
In fact, evolution is inherently messy... it can be considered as an auto-organizing way of filtering the most amount of mess as possible, because there is an amazing amount of signal into a mess, the hard part is to filter it out and to shape it.
But allow me to go wilder (I've been researching on this topic of publishing/editing for the last few years now!): what if the problem is in the media itself? what if we have to rethink how to represent information in order to obtain a system that socially scales in its editing process? are we absolutely sure that directly-linked hypertext is good enough?
Example: the first television commercials were visually ineffective because they were used to make radio commercials so they didn't know how to use the other 'dimension' (the visual one) that the new media provided. So they ended up taking posters (the only visual components in commercials they knew) and people talking like they were on the radio. It was a visual radio commercial.
To me, after 10 years of hypertext, we have barely scratched the surface of what it really can be.
If we don't allow our incredible pool of users to be used to experiment new trends in that direction, we will never improve the poor 'visual radio' that we have today.
But understand that it might take several years for a new pattern to emerge, so, prepare to be patient. But let me stress that IMHO, there is much more to gain than to loose in being open to alternative ways of interacting with our communities.
To this effect, AndrewCOliver (aka Andy) has upgraded this to allow RSS feeds. You just do http://nagoya.apache.org/wiki/apachewiki.cgi?action=rss and you get an RSS feed of recent changes. You can easily keep up using BloggingTechnologies.
I just have to say that this wiki is already proving itself. It's growing pretty fast for a new wiki.
Related: Wiki:WhyWikiWorks | Wiki:WhyWikiWorksNot | Wiki:TheWikiWay