See also WikiVandalism.

----> Laugh it off... if you don't find it funny then just edit out the offending material. Life goes on...

- being unknown/uninteresting to the less mature posters ?

----> We LMP's will find ways to make your board entertaining for ourselves.

- an active user community who maintain the tone of the site through vigilance and pro-active editing ?

----> Correct! If you don't like something edit it out.

- restricting permissions on key pages ?

----> This defeats the whole purpose of wikiweb

- requiring a login for all edits ?

----> Lame.

Perhaps some variation of "To assume an above-average IQ for the average reader, simplifies writing." would express this aspect of the beauty and pivotal dilemma of the Wiki experience. --JohnDeBruyn (July 30, 2000)

An interesting phenomenon related to real-life vandalism is that if the vandalism is immediately cleaned up, eventually the vandals give up. E.g. if a wall has lots of graffiti on it, paint it one solid colour. The vandals will go "cool, virgin wall!" and wreck it again. That's fine, paint it over immediately to on solid colour. A couple vandals may try again. That's fine, paint it over. Eventually, they'll give up and you'll only have to paint it once a month or so, and only small patches. --RobHarwood?

I hearby apologize for modifying other people's signed words and I promise to no longer take part in this particular aspect of trolling. --the less mature user Thanks :) --SM

Hrrmm.. Well, several things. With RecentChanges?, you maintain an adequate level of peer review (MeatBall:PeerReview) to protect things. Also, with an open server, you can suffer from pestilent users who won't leave you alone ala eBay (See relevant link on MeatBall:EbayDotCom). Also, you don't need to move to absolute moderatorship ala Usenet. You can do like rusty on (the late) kuro5hin (MeatBall:KuroShin) who just deleted trolls and crap as he saw them. Sure, you run the risk of creating a GodKing? (MeatBall:GodKing) but who cares? Online if you don't like somewhere, you can leave. --SunirShah, who has probably exceeded his InterWiki limit with this post.

I liked the summary of techniques by SunirShah, and I started thinking about a synthesis of these techniques that would work well for most wikis. My primary goal is to ensure that the wiki culture can survive the evils of popularity and the inevitable POST-bots.


  1. PeerReview? for scientific publications works remarkably well.
  2. PeerReview? is incredibly slow.

For the purpose of these axioms, I am assuming the peer review model that is in common use for print journals. Rapid peer review methods have been developed for use on the web. Ebay and Slashdot are good examples of these methods.

Here are the rules:

  1. The wiki is open to all, but registered participants (RPs) have priveleges that anonymous participants (APs) do not have.
  2. RPs can earn reputations. A reputation is a dynamic rating that reflects the value of the contributions that an individual has made to the wiki.
  3. APs cannot earn reputations. They are always assumed to be disreputable.
  4. After a page is edited, it goes into a queue awaiting approval or moderation (or whatever you want to call it).
  5. The approval queue can be viewed by everyone. RPs with some minimum reputation can approve a page edit, and then the page update actually occurs.
  6. Approval criteria should be limited to whether or not the edits or additions are constructive to the wiki.
  7. An approval automatically provides positive feedback (in the Ebay sense) on the page editor. This is how one earns one's reputation. Of course, APs cannot earn a reputation, so this step is only meaningful for RPs.
  8. RPs with the minimum reputation to do approvals cannot approve their own edits.
  9. RPs with a very high reputation can effectively approve their own edits, meaning that their edits can bypass the approval queue.
  10. Some number of reviews per some interval is required to maintain one's reputation.

The main problem with this scheme is that the delay in the review process (the approval queue) still causes a number of problems. Edits can easily become out of synch with the latest copy of the page, for example.

-- JeffEbert (August 26, 2000)

Thanks for the compliment. Your scheme sounds much like kuro5hin, but that is more appropriate for a temporal MeatBall:WebLog, not an atemporal wiki, I think. By the way, you should note that Rusty has abandoned the manual moderating of kuro5hin in favour of "mojo" which is a better karma system than Slashdot karma. More details on MeatBall:KuroShin. --SunirShah

There's just a tad too much friction with this; the growth of the Wiki would be limited by the spare time of registered approvers. If you shifted the model to reactive, I think you'd be just a tad better off: approve changes by default, but give approvers a "this sucks" button to press to undo "bad" changes. A really simple twist on ManagedMode might be an ability to select whether a page was approve-before-display or reject-after-display.

Hmmm. I'm not convinced I like the social effect of either. I'll have to ponder this one.

-- GTK (August 28, 2000)

Seeing as the FrontPage was just wiped out (September 20, 2000), I think it's about time to implement WikiWikiWeb:EditCopy also known as the MeatBall:ReversibleChange. You might also want to see MeatBall:SoftSecurity, a little pattern language of non-restrictive security measures. --SunirShah

Restored from zope undo history; I think that's our first front page wipe (FrontPageWipe20000920?). It seems the first DestructiveEdit? blanked the page; later edits may have been someone else. Thanks for the links, I will take a look. --SM

Actually, we've been discussing versioning systems lately on MeatballWiki?. You should grab a peek at MeatBall:KeptPages while you're at it. I'm glad you had a back up! (By the way, one of Cliff's goals was to maintain the site, even in the event of his absence, by relying on the community.) --SunirShah

(moved this old stuff off HelpPage)

very annoyingly, has the help page been replaced by a crude ad - the wiki equivalent of spam, but more destructive? Simon, could you please undo this?

Done . As a quick fix I could remove anonymous edit permission on important pages like this one ? But this would damage the communal wiki feeling... -SM

It's cheaper just to implement versioning. Let the community fix itself. MeatBall:CommunitySolution vs. MeatBall:TechnologySolution. --SunirShah

2000/10/03: after a brief mention on SlashDot we attracted another (more) PersistentVandal? and I put the ShieldsUp --SM

My condolences and moral support. I thought that being almost Slashdotted Sunday night was bad enough for us on MeatballWiki?. This is sad. I can only suggest a few things in response:

SoftSecurity? does work, but it's nice to have a few tools. ;) Good luck. I'll keep an eye on this place when I have a chance. --SunirShah

Thanks for your kind words Sunir. I have the feeling this site has reached the point where more defensive technology is needed - the ability to block certain hosts, for example. WikiWikiWeb did this - for robots - we'll find out if it's effective in a case like this.

what happened on meatball ? --SimonMichael

I posted a comment on a kuro5hin article which was linked to from Slashdot. The traffic from Slashdot acted like a skipping stone hitting us. We only got malicious edits as far as I could tell. Being SlashDotted is no fun.

h2g2 has a policy of allowing open edits, but reviewing all edits within an hour, max. Do they have staff online around the clock? See This relates to RobHarwood?'s idea above, which is effective on the NewYork? subway. --RickLeir?

A fun thread: WikiWikiWeb:SocialAcceptabilityOfWikiVandalism


Moderating comments for mail-out --davidm, Fri, 16 Sep 2005 01:34:25 -0700 reply
Comments get mailed out within minutes of posting - how can they be edited before being mailed??? david..

Moderating comments for mail-out --simon, Fri, 16 Sep 2005 16:26:25 -0700 reply
Customize the subscribeform so that people will subscribe to a moderated mailing list instead of directly to the wiki. WikiMail has more on this.