On Tue, Jan 07, 2003 at 11:53:52AM -0500, Ben Hyde wrote:
...
It turns out if you build a event driven mail based notification system you shortly there after discover that it's too painful to use. The Wiki model results in editors writing changes so they can preview; and in tangles of nodes going thru periods of total chaos[1] as an editor attempts to make any changes that involve more than one node. Both these make the change stream very hard to read. I suspect that much of that could be resolved by sending mail with changes "when the dust settles".
Bah. Use SubWiki, check out the Wiki pages into a working copy, make all your changes, then commit them. Regular commit email sends the full bunch of changes.
Simple as that :-)
You are stating that:
0) download a working copy [this is done only once] 1) go to a page 2) edit it 3) save it 4) commit the page
is comparably simple with
1) go to a page 2) edit it 3) save it
and I disagree.
The (only?) beauty of a wiki is its dead-simple editing cycle.
It can hardly be simpler than what it already is. Introducing an explicit version control cycle (because commits are exactly that) might seem relatively simple (or even totally natural) for somebody (all of us if we are committers) that is used to it but might not be for users that simply want to give some help.
As Jeff brilliantly put it on the forrest-dev list: users don't rant, they quietly leave.
Here, you could say: users don't complain about how hard the documentation system is, simply they don't use it to contribute.
Between having a smarter diff-sending algorithm transparently do the job on the users behalf and an explicit commit cycle, I'd go for the first even if it removes only *one* step, it might be a difference between 100 people using the wiki and 150, 50 of which are scared by the concept of 'committing'.
Paint me PITA, but I think it's worth playing devil's advocate on this muddy ground.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> --------------------------------------------------------------------
