MeatballWiki | RecentChanges | Random Page | Indices | Categories

This page is an attempt to tie together modern low-tech wiki consensus mechanisms, and look at a recent extension that applies equally to them all.

Consensus for PeerReview

Several wiki technologies require consensus to be reached before an action can be taken. Deleting a page, removing history, replacing an important file on the server, presenting a spam-free view of a site: all require PeerReview to avoid abuse. The original approach is, of course, not to provide such an option, relying on a GodKing to get them done if at all. This is rather against the Open design principle (see Wiki:WikiDesignPrinciples), and tends to allow more and more detritus of various forms as the site grows.

One solution is to assume a single consenting opinion (a second) implies consensus: this was used, for instance, by EditCopy. This approach is very vulnerable to abuse such as use of a SockPuppet, and potentially biased against minorities - not to mention heavily in favor of RecentChangesJunkies.

Various strong consensus protocols have been mooted over the years, such as attempting to achieve democracy on the web. In many cases, however, this is likely inappropriate: wikis are not shared and ubiquitous resources like transport systems or unions, and need neither guaranteed progress nor representation. Problems of SockPuppets also apply to any system that gives greater weight to opinions with much backing. However, some concrete "low-tech" implementations have arisen: PageDeletion, KeptPages, FileReplacement and StableView. All are based on a simple consensus protocol: veto.

Once an action is suggested, perhaps by marking a DeletedPage, or altering text, a fixed period of PeerReview begins. If there are no dissenting voices within that period, the action is taken. Since multiple voices have no more effect than one, a SockPuppet is of no use; since the action can be reviewed for a long period of time, RecentChangesJunkies have no more power than periodic visitors. However, this system prevents rapid progress in new systems, which can be frustrating and even cause a new group to lose momentum waiting for non-existent vetos.

Veto within groups

ConsensusGroup establishes a group of participants and allows each to give explicit approval of a decision (rather than relying solely on SilentAgreement as the veto system does). This loses none of the benefits of simpler silence/veto systems: since a single dissent stops the consensus, SockPuppetry gives no advantage; since pre-registration is all that is needed to become a peer, each participant has the full PeerReview time at their disposal and RecentChangesJunkies get no advantage.

How can we initially extend the veto systems described above to use a ConsensusGroup? The simplest approach would be a single consensus group for the whole wiki, used for every decision. (Mild protection of accounts would now be indicated to prevent someone faking explicit consent across the group.) This is in line with the traditional thought that a single wiki represents a single community.

Unanswered questions

Can efforts to exclude antisocial elements (spammers and others) focus on maintenance of the consensus group?

A Wiki (WhatIsaWiki) is open — anything important can be edited by anyone in TheAudience. Can we find a way to restrict the ConsensusGroup to TheAudience, and if so, can that also found ways of filtering out non-audience edits?

Can one usefully fragment the ConsensusGroup within a wiki to preserve GlobalResources?

Several questions need to be answered:

limited to existing pages - quite a restriction.

See also PeerGroups.

Can one fragment consensus by EditCategories — which are currently at their strongest when simply supporting PeerReview?

A small group could register to review CopyEditing, for instance, and once a copy edit has been confirmed by the group, any mention of it could be truncated from the digest. One problem would be reaching consensus across orthogonal edits of the page, especially on a hot page: it may simplest to give up on such consensus on any page that also has major edits.


I found several of these ideas quite intriguing. Thinking about them a bit, it seemed to me that the 'group' reviews you are describing could be akin to a review by a number of Editors (either a single Editor or a small group of them with interest in the subject of a page). This inevitably made me think of WikiPedia and realize that they have probably struggled most with these types of issues. Personally, I don't know enough about WikiPedia to do more than wonder how their experience might help flesh out these ideas. Perhaps someone that does will comment?

-- HansWobbe

Just thought of an amusing title for the traditional degenerate model of wiki behaviour: he who changes last changes loudest. Thought I'd share.

I've also come to the conclusion that a consensus group is probably the wrong model for simple PeerReview of categorized edits, as it prevents people sharing the workload: instead, effort has to be duplicated. The simplest approach is a single consenting opinion from an established cabal confirms (and retires) the categorized digest, so subsequent edits get a fresh new digest. A ConsensusGroup would perhaps make sense for admission into the cabal, as it prevents abuse (accidental or otherwise) whilst allowing a cabal to remain dynamic even if someone's modem catches fire (and prevents them voting, for instance).

Though perhaps this is over-thinking things. -- ChrisPurcell

Does this replicate AcademicPeerReview; i.e. for AcademicJournal?s. Some person or committee says a paper is good or bad, and that is enough to direct thousands or hundreds of thousands of dollars from one project to another? -- SunirShah

No, this is just peer-review of minor edits. (Ah, the irony. The entire peer-review system delegated to the writing equivalent of cleaning dishes.) -- ChrisPurcell


MeatballWiki | RecentChanges | Random Page | Indices | Categories
This page is read-only | View other revisions | Search MetaWiki