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) 11:02, 7 Aug 2004 User:Patrick (See also -*Parser testing)
2. (2 votes - vote) 07:45, 30 Jul 2004 User:AaronPeterson M (HelpTOC at bottom)
3. (1 vote - vote) 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" link on that branch (see the example above).

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.

When there is a "split" at a given revision (i.e., a new branch was created starting at that revision), any outstanding votes "below" that revision are propagated forward using the following precedence rule:

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.

However, if the wikitext of the existing revision being edited contains a special "exclude-user" flag naming the author of the new revision (or if the author is anonymous and the page contains an "exclude-anonymous-users" flag), then instead of extending the existing branch, the wiki system just creates a new one: i.e., the new revision is marked as a "head" revision without removing the "head" flag from the old revision. Thus, in this scheme users are never barred from editing whole pages, but only from extending particular branches.

In edit war situations for which exclude flags are not sufficient, e.g., in the presence of a vandal who changes accounts repeatedly to evade the exclude flags, a stronger set of "include-user" flags might be used instead, which would allow only the named users to extend that branch.

This system is obviously vulnerable to the problem that after a period of relative calm, a branch as-yet-unprotected by exclude or include flags might suddenly be "hijacked" by a vandal who (for example) adds an include flag to the page that only allows himself to edit it. XXX answer...

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