You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/01/28 21:12:05 UTC

Wiki Benefits

> People can do the same with patches on mailing list; and seem less likely
> to abuse that. Perhaps the simple validation (and display) of a valid
> email address may do the trick.

You are concerned about abuse.  I don't disagree, but the mailing lists are
also capable of being abused.  I would not complain if in order to edit the
Wiki, a user had to subscribe similarly to how they subscribe to mailing
lists.  I've already raised the notion of SubWiki adding access controls,
and that could be part of the model.  But right now I am not seeing abuse
(glancing around for some wood to knock on), and the benefits are real.

IMO, restricting the publishing medium to either a mailing list or the
Committer published web site creates a tremendous more amount of work for
Committers to apply patches, removes the self-empowerment element from the
users, and thus a psychological incentive for them to help, and delays the
availability of the content.

An e-mail message is static.  Once published, it lives as-is.  It cannot be
edited.  It cannot be refined.  It cannot be corrected if it is in error, or
if the situation changes.  It exists in an unstructured archive.

A Wiki page is a malleable part of structurable content.  The Wiki enables
users who have worked out solutions to a problem to post those solutions in
a user helping user mode.  Publishing the solution once to the mailing list
means that users have to search the archives, rather than have a more
structured organization to helpful content.  We're more likely to harvest
e-mail content and refine it on the Wiki.

Even for committers with CVS access, the Wiki is much, *much* faster for
collaborative editing of documents that are works in progress before
committing them, again through the whole process.  It isn't even close to
being only one order of magnitude easier.  I can edit a page in seconds
without having to edit the xdoc, commit the xdoc change, build the web site,
commit the web site changes, log into daedalus and update the site.  I can't
get away with less than 5 minutes per change.  The web site build takes that
long, by itself.  I am absolutely convinced that we have a lot more
collaboration on documents because of the Wiki.

I do agree that the Wiki isn't a discussion medium.  Our Wiki area has the
following notation: "Please use the James mailing lists to discuss the
content of these pages. The purpose of the Wiki is to record and edit
plans/proposals/notions that are discussed on the mailing lists."  And
periodically, we could harvest suitable Wiki content, and move it into the
xdocs->HTML publishing process.  Right now I am taking a check list of
changes that was maintained quickly on the Wiki, and moving it into xdocs
for the next Release.

	--- Noel


Re: Wiki Benefits

Posted by Dirk-Willem van Gulik <di...@webweaving.org>.

On Tue, 28 Jan 2003, Noel J. Bergman wrote:

> > People can do the same with patches on mailing list; and seem less likely
> > to abuse that.

> You are concerned about abuse.  I don't disagree, but the mailing lists are
> also capable of being abused.

No sorry; I am _NOT_ worried by abuse at all. In fact I am almost amused
by the irony of a Wiki Hater using the Wiki as its platform for fame :-)

What I wanted to offer was an observation; and that is that certain (and
fairly simple, easy to forge) feedback loops seem to be just enough to
keep a certain level of abuse in check.

It is just the observation that (even while one can abuse mailing lists)
it somehow happens less there than on WiKi's.

I note that it is not just ours - we have similar issues on
www.wirelessleiden.nl its associated wiki's with warez and license keys.

And I postulate/guess that is because:

> > Perhaps the simple validation (and display) of a valid
> > email address may do the trick.

As this means people have a certain amount of skin in the game; an
identity of sorts to preserve (no matter how virtual it is).

Dw