[wordup] Wiki Wiki Wiki!

[Adam Shand]

From: http://www.corante.com/many/20030801.shtml#50187

Wikis, Grafitti, and Process

Every time I show a wiki to someone who has never seen one, I invariably 
see the same two reactions: "That's pretty cool", followed seconds later 
by "It'll never work." This second reaction is understandable, as wikis 
take a radically different attitude towards process than almost any 
other piece of group software.

Process is an embedded reaction to prior stupidity. When I was CTO of a 
web design firm, I noticed in staff meetings that we only ever talked 
about process when we were avoiding talking about people. "We need a 
process to ensure that the client does not get half-finished design 
sketches" is code for "Greg fucked up." The problem, of course, is that 
much of this process nevertheless gets put in place, meaning that an 
organization slowly forms around avoiding the dumbest behaviors of its 
mediocre employees, resulting in layers of gunk that keep its best 
employees from doing interesting work, because they too have to sign The 
Form Designed to Keep You From Doing The Stupid Thing That One Guy Did 
Three Years Ago.

Wikis dispense with all that -- all of it. A wiki in the hands of a 
healthy community works. A wiki in the hands of an indifferent community 
fails. The software makes no attempt to add 'process' in order to keep 
people from doing stupid things. Instead, it provides more flexibility, 
a crazy amount of flexibility, and intoxicating amount of flexibility, 
allowing massive amounts of stupidity and intentional damage to be done, 
at will, by roving and anonymous posters. And it provides rollback.

Bad things happen on wikis. All the time. As historyflow shows (w00t!), 
pages frequently get deleted outright. But, as historyflow also shows, 
in a healthy community they also get restored, quickly.

Programmers have known for decades that a version control system covers 
a multitude of sins, and wikis embrace versioning as the cardinal 
virtue. With versioning, there's no need to try to prevent bad things 
from happening, so long as they can be quickly undone. "Detect badness? 
Get back to the last good version, then start out again from there."

I was recently reminded of this marvelous property when checking out 
wikitravel.org. I noticed a page for my city, and checking it out, I saw 
that it was an entirely fake review, making reference to places and 
events that never happened. It looked like an attempt at humor writing 
(though a fairly lame one), but of course the side effect (or perhaps 
intentional effect) was to undermine the goal of the site.

Seeing this, I simply deleted the current content and put an "Add 
content here" stub on the page, then went to Recent Changes to see if 
there had been other such grafitti entries. The same IP address came up 
in two other places, both also fake entries, and I deleted them as well.

Looking at the timestamps in recent changes, I saw that our budding 
satirist had spent an hour and three-quarters working on his trio of 
masterpieces. They were on the site less than two hours when I came 
along, and I undid everything he had done in two minutes.

And this, mirabile dictu is why wikis can have so little protective 
armor and yet be so resistant to damage. It takes longer to set fire to 
the building than put it out, it takes longer to grafitti the wall than 
clean it, it takes longer to damage the page than restore it. If nearly 
two hours of work spent trying to subtly undermine a site can be erased 
in minutes, that's a lousy place to hang out, if your goal is to get 
people's goat. Better to go back to posting Microsoft trolls on slashdot.

The freedom from process is quite remarkable, and is also the hardest 
thing to explain about why wikis don't just fall apart with the first 
attack.