Tidal Wiki

Wiki has a lot of nice content. And a lot of horseshit. People come here to do good things. And bad things. We want to keep the former and ditch the latter.

Therefore,

We use the pattern of a DoubleCardioidFishTrap. We let all edits into wiki including spam, flames, and so on. Then we revert all edits except the ones that survive a periodic communal review process. Only the edits that survive review are actually effective in altering wiki.

But,

What if there's too many editors trying to edit for the reviewers to keep up?

Let 'em appoint more reviewers. Or put in place more cardioids.

Other objections?

What would the communal review process look like?

Wiki has a bunch of trustees called WardsWikiStewards. There's maybe a dozen of 'em. Anyone any of them dubs a reviewer is a reviewer. Anyone any of them vetoes is not a reviewer. Reviewers are IP authenticated via an email/password dialog. Ordinary editors are never asked for a password.

Reviewers read a page called RecentEdits or something like that. It's the neck of the outer cardioid if you like. It works like RecentChanges does right now.

Any reviewer can approve any new version of a wiki page. Reviewer edits are auto-approved; if a reviewer runs rogue then the stewards will soon put them right - this is unlikely to be a problem unless the stewards themselves disagree. Which in practice is very unlikely indeed. And if they do then they can go ask Ward to make his intent clearer.

Any edit that isn't approved by a reviewer within 24 hours of its review is auto-reverted. Reviewers do not have the power to cancel an edit - only to prevent its cancellation. Approved edits appear on RecentChanges - the neck of the inner cardioid. Key is there's no voting on it; if any reviewer likes something, that's all there is to the decision. This is to encourage casual users to perform corrections/deletions, etc, without fretting about The Big Cabal. The reviewers are an attention filter, not a bureaucratic decision making entity.

And that's all there is to it. No more CodeWords (except for Captcha), no more OnTopic debates, no more WikiVictimization. If your edit makes it onto RecentChanges then you're doing right and no one should hassle you about it. Otherwise it'll be available in non-googleable form in some slushpile some place in case you've lost it in the shuffle. There is no avenue of appeal - if some reviewer some place doesn't find value in it, it's just not right for here. And if you build up enough of a presence here for people to recognize the value of your contributions, you'll soon get invited to be a reviewer.

I think this will work. Or at least I think it'll work a damn sight better than what we're doing now. --Pete.

That's a great idea - sort of like SlashDot moderation, but with a selected moderation team. The steward oversight on the reviewers would work like meta-moderation. -- EarleMartin

Reminds me of moderated discussion lists and UseNet newsgroups. They almost never start out moderated, but wind up being moderated as a consequence of exactly the sort of things we've seen here. Perhaps it's an inevitable stage in the evolution of a public forum. -- DaveVoorhis

WikiIsUsenet! But where does moderation fit on the WikiLifeCycle? (See also: CommunityLifeCycle.) -- EarleMartin

It is a proposal for a kind of WikiBreathing ... or at least a kind of WikiMetabolism?. It fascinates me that the DoubleCardioidFishTrap looks a lot like a fish itself. The first cardioid is a mouth that opens to the ocean. But the only stuff that comes past that and down the gullet is stuff good to "eat". Inside the mouth are predator fish acting as teeth - reviewers/stewards driving only the tasty tiddlers down the gullet and spitting out the rest with the next tide. The tide works like ingestion/excretion of water by a fish too. And the little people lounging on the beach inside the stomach look like its ... well, that place the tiddlers go after they've been digested. I'll leave my usual allusions out for the sake of focus. --Pete.

Turns out that the WikiPedia gang thought of this already, sort of (since they use logins, it'll be for new or anonymous users only). See: http://mail.wikimedia.org/pipermail/wikien-l/2006-August/053286.html

Similar. What's proposed here has no time delay on edits; anonymous edits are represented immediately. There is a time limit on how long they can live without a followup or tick by an authenticated reviewer. I can't see why anonymous editors should be time delayed - that makes it almost impossible to have a legit collaboration. I guess that fits a ContentClassificationWiki, but not a ContentCreationWiki.

If there is no time delay, how do you handle the situation where edit A is not approved, but edit B that built on top of edit A is approved? You could auto-merge edit A out, but there could be a conflict, or a loss of continuity if both edits belong to the same discussion. If you implicity approve A when B is approved, that poses problems if edits A and B are unrelated.

It's a page version you're approving; if any reviewer ticks or follows up the present version of a page, it's approved. Doesn't matter how it got that way. If a reviewer doesn't do that within 24 hours then the page auto-reverts to the last reviewer-approved version. So a reviewer can approve B's correction of A, or delve into PageHistory to approve A's edit but not B's edit, no merging necessary on their part. Unless they wish to merge in their followup, which they may certainly do. It would be nice if reviewers agreed in principle to try to be GoodWikiCitizens before getting their authentication.

There are advantages moderated lists/groups don't enjoy.

Reviewers don't need to review every article in a thread; just use RecentEdits as you presently do RecentChanges and don't change your behaviour except for using a tick box on the edit page when you like something.
Reviewer status will be highly regarded and desirable; folk won't want to lose it by being hasty or arbitrary in their reviews.
If the stewards are careful in their decisions then a very high trust high signal core group will self-assemble without further WikiOnWiki.
And casual wiki users will notice nothing except that the signal rate goes exponential.

Well ... and the problems of rapid growth ... but right now those look like good problems to have ...

I think this is a good idea, and I'd like to see it in action. That said, history leads me to doubt that it will ever be put into action on this site. There are probably a hundred other good WikiWikiSuggestions written up here that would improve wiki in one way or another. The only constant among them is that they haven't been implemented at this site. I'll refrain from making wild guesses at why that has been the case. -- MichaelSparks

A thought: if a reviewer disapproves of an edit by a UserName-identified individual, it would certainly be good form to tell them why on their WikiHomePage. -- EarleMartin

SeptemberZeroSix