User:Brynosaurus~metawiki: Difference between revisions

Here is a draft write-up of some thoughts of mine on how WikiMedia (and perhaps other wiki systems) might be improved to deal with the problem of controversial pages and "edit wars" more gracefully and democratically. For background, see also the branch-related discussion in A Better Wikipedia.

(Note: incomplete; work in progress)

Wiki systems work extremely well most of the time, but (especially in popular wikis such as wikipedia.org) there are always a few pages that attract substantial controversy, which end up having to be protected by sysops often or even most of the time. Not surprisingly, these controversial pages tend to be those related to controversial people or ideas. As wikis continue to grow, this trend is likely to continue, presenting the danger that only relatively uncontroversial wiki content will ultimately retain the freedom and cooperative editing properties that are so fundamental to "wikiness", whereas all content surrounded by any controversy will by necessity fall more or less continuously under the exclusive control of top-down authorities ultimately appointed by the site owners. (And what happens the first time two sysops get into an edit war? Has this ever happened?)

Which is not to say that this "bi-modal" management regime will not work; only that it does not seem ideal in terms of wiki's cooperative editing and management principles. It would be nice if the freedom and cooperative editing could be reliably provided for all wiki content all of the time, and not just most of the time for the less controversial majority of wiki pages.

The obvious solution (and I'm far from the first to propose it) is to implement some kind of voting mechanism, so that controversial pages can still be cooperatively managed according to democratic principles instead of just having to be protected by specially-privileged sysops. But any such voting system should not create undue complexity or impede the freeform Wiki writing and editing process in the normal case, since the simplicity and freedom of the wiki system is obviously one of its greatest attractions. Also, a wiki voting system should ideally ensure that the "definitive" version of a page reflects majority opinion without completely suppressing alternative, minority opinions. Finally, any voting mechanism should encourage meaningful discussion and group evolution toward consensus, rather than merely facilitating continual ideological warfare. In other words, the voting system should work towards making itself unnecessary.

Over in A Better Wikipedia, User:Marc Girod already suggested introducing branches into WikiMedia's revision system for the purpose of democratic Wiki-collaboration, allowing users to choose the "official" branch democratically while still allowing alternative branches to co-exist as alternative, "minority opinions". I like this idea, and my goal here is to flesh it out further and try to come up with good solutions to some of the problems that were brought up in the follow-up debate.

My proposal: Instead of being a page's history being a strict linear order, each stored revision of a page (already "labeled" by timestamp and author) can be marked as being "derived from" any previous revision (or perhaps multiple previous versions, in the event of a merge?), forming a directed acyclic graph in the obvious way. At a given time one or more of these revisions are also marked with a "head" flag, representing the current head of a branch.

The main content page for a given wiki page always shows the head of the "official" or "most popular" branch according to users' votes, as described later. The corresponding "history" page, however, lists:

1. the head revisions of the most popular (say) 5 branches, each with a link to select that branch
2. the actual revision history of the currently selected branch (the "official" branch by default), reconstructed by following the "derived-from" dependencies from the branch's head revision.
3. a link (or a separate tab) allowing users to view all the head revisions in the page's history.

For example, a "history page" in the branching scheme might look something like this:

Recent Branches

1. (5 votes - vote for this branch) 11:02, 7 Aug 2004 User:Patrick (See also -*Parser testing)
2. (2 votes - vote for this branch) 07:45, 30 Jul 2004 User:AaronPeterson M (HelpTOC at bottom)
3. (1 vote - vote for this branch) 20:35, 13 Dec 2003 User:Mxn M (Fixed interwiki link)

Revisions of Branch 1

• (cur) (last) (O) (O) 11:02, 7 Aug 2004 User:Patrick (See also -*Parser testing)
• (cur) (last) (O) (O) 02:18, 7 Aug 2004 User:61.94.148.42 (remove excessive ...)
• (cur) (last) (O) (O) 11:43, 6 Aug 2004 User:Patrick M (Sections, paragraphs, lists and lines)
• (cur) (last) (O) (O) 11:38, 6 Aug 2004 User:Patrick M
• ...

To extend the current "official" branch, a user just clicks "edit" on the main content page, just like they do now. To extend a different branch, a user just goes to the head revision of that branch on the history page and then clicks edit. In the normal (non-edit-war) case, the new revision is saved and the "head" flag is transferred from the old revision to the new one, causing the existing branch to be continued in the usual linear fashion.

A new branch can be created simply by editing any non-head revision of an existing branch. Thus, branch creation effectively replaces the old rollback behavior.

Of course, if the user clicks "edit" on a revision that was a branch head as of the time the user's page was generated, but the branch is subsequently extended by someone else while the user is editing the page, then when the user saves the page the Wiki system should go into conflict resolution mode instead of just creating a new branch that the user probably wasn't expecting.

Whenever any user saves a new revision (either by extending an existing branch or creating a new branch), the wiki system automatically counts the user as having "voted for" the new revision, and removes any other vote the user may have previously attached to a different revision on that page.

Other users who are not actively checking in new revisions can nevertheless cast votes for a particular branch simply by calling up that branch on the page's history tab and clicking the "vote for this branch" link on that branch (see the example above).

All votes expire after some time period (e.g., a few weeks) if not explicitly refreshed, to ensure that the accumulated "weight" of past votes cast by users who are no longer paying attention does not outweigh the votes of currently active users.

Although votes are initially "attached" to specific revisions within a branch, by default these votes "propagate forward" within that branch as it is extended with new revisions. Thus, in the common case in which several users "get along" reasonably well, repeatedly extending a given branch in linear fashion, then their (implicit or explicit) votes will automatically be "collected" and attached to that branch without them having to take any special action. For example, in the "main branch" shown in the example above as having 5 votes, those five votes might simply reflect the fact that five different users have recently extended that branch (instead of creating new ones). If there are several groups of users that disagree with each other, but "get along" internally, then each group can work on its own branch independently, and their votes automatically collect on their respective branches.

Suppose there is a "split" at a given revision: i.e., a new branch was created starting at that revision, so there are two or more "next revisions" emerging from the split point. In this case, any outstanding votes attached to the split point itself, or to prior revisions "below" the split point, are propagated forward using the following precedence rule:

• If at least one of the alternative "next revisions" was checked in by a user who has previously checked in edits on this branch (at or before the split point), then the next revision whose author most recently checked in such a prior revision has precedence, for purposes of vote propagation.
• Otherwise, if none of the alternative "next revisions" were checked in by "established authors", then votes do not propagate beyond the split point.

This propagation rule ensures that the continuity of a branch can be preserved even in the presence of trolls or vandals who might come along and try to "hijack" the main branch. For example, suppose the main branch of a page is suddenly vandalized by an anonymous user:

Recent Branches

1. (4 votes - vote for this branch) 02:18, 7 Aug 2004 User:61.94.148.42 Heeheehee! Yer page is TR4$HED!!!

Revisions of Branch 1

• (cur) (last) (O) (O) 02:18, 7 Aug 2004 User:61.94.148.42 Heeheehee! Yer page is TR4$HED!!!
• (cur) (last) (O) (O) 11:43, 6 Aug 2004 User:Patrick M (Sections, paragraphs, lists and lines)
• (cur) (last) (O) (O) 11:38, 6 Aug 2004 User:TLong M
• (cur) (last) (O) (O) 08:49, 31 Jul 2004 User:Patrick M (See also)
• (cur) (last) (O) (O) 11:11, 18 Jul 2004] User:WTKatz M

The main branch lists "4 votes" because, in addition to the 1 vote cast by the vandal, the votes of Patrick, TLong, and WTKatz have been propagated forward so that they apply to the head of the branch. The Wiki system still remembers exactly which prior revisions each of these votes were originally attached to, however.

Now suppose User:TLong notices the vandalism first, and responds by going back to the second-to-the-last revision by Patrick, clicking "edit", then clicking "save" to create a new "rollback" branch without the vandalism. Then not only is TLong's own vote transferred to this new branch automatically, but because TLong already checked in a revision on that branch earlier on Aug 6, TLong has "prior authorship precedence" on the branch with respect to User:61.94.148.42, so Patrick's and WTKatz's votes also transfer over to TLong's new branch as well, producing the following configuration:

Recent Branches

1. (3 votes - vote for this branch) 10:50, 9 Aug 2004 User:TLong M Rollback vandalism
2. (1 vote - vote for this branch) 02:18, 7 Aug 2004 User:61.94.148.42 Heeheehee! Yer page is TR4$HED!!!

Revisions of Branch 1

• (cur) (last) (O) (O) 10:50, 9 Aug 2004 User:TLong M Rollback vandalism
• (cur) (last) (O) (O) 11:43, 6 Aug 2004 User:Patrick M (Sections, paragraphs, lists and lines)
• (cur) (last) (O) (O) 11:38, 6 Aug 2004 User:TLong M
• (cur) (last) (O) (O) 08:49, 31 Jul 2004 User:Patrick M (See also)
• (cur) (last) (O) (O) 11:11, 18 Jul 2004] User:WTKatz M

The vandal's revision is still available on the list of alternative branches, but has effectively been removed from the revision history of the main branch, and will probably disappear entirely before too long as other new branches come and go.

Of course, this simple "prior authorship precedence" rule will not necessarily be sufficient if two "established authors" get into an edit war, or if a vandal persists. But it should handle most of the less extreme cases gracefully, without introducing any significant new procedural complications.

The mechanisms described above should be sufficient to deal with "edit war" situations in which the competing authors (or groups of authors) are at least civil enough to "agree to disagree", work on their own branches independently, let users' votes decide which version should be the "official" one for the time being, and hopefully work toward eventually reaching a consensus and merging back together in support of a single branch. In the presence of downright antisocial behavior, however, in which a user for example repeatedly attempts to "hijack" the main branch, slightly tougher security measures are needed.

For this purpose I propose a set of simple set of "include/exclude" tags that can simply be written into the wikitext of any page by anyone editing that page. These measures are still much less "heavy-handed" and more democratic than the current page protection mechanism.

• If the wikitext of the head revision of a given branch contains a special "exclude-user" flag naming a particular user, then that user is disallowed from extending that branch. An "exclude-anonymous" flag similarly prevents all anonymous users from extending the branch. Excluded users are not prevented from working on other branches, however, or even from creating a new branch starting from the existing head revision from which they are excluded. If a user clicks "edit" on a revision from which they are excluded, the Wiki system allows them to edit the page as usual, but simply displays a warning that saving the edits will not extend the existing branch but will create a new branch instead. Votes of other users never propagate from the existing branch to a new branch created by an excluded user, of course.

• To deal with cases of extreme incivility in which someone repeatedly signs up for new accounts just to get around such exclusions, "include-user" flags can be used instead to prevent everyone except the named users from extending the branch. Even this security mechanism, however, is still much less onerous than outright page protection. For example, if a user who isn't already on the include list wants to work on the page, he simply edits the page starting from the head revision, inserts himself into the page's include list in the process, and saves the new revision (which of course creates a new branch since he isn't yet allowed to extend the existing mainline branch). Since he is now on the include list of the new branch, he (and the other included users) can continue working on it freely. And if the existing users on the include list like the new user's work, they can "endorse" the new user simply by switching their outstanding votes over to the head of the new branch.

to be written

to be written

• MediaWiki feature request and bug report discussion
• A Better Wikipedia