User:Brynosaurus~metawiki
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 democracy?
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.
Branches
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.
Branches as seen by the user
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:
- the head revisions of the most popular (say) 5 branches, each with a link to select that branch
- 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.
- 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
- (5 votes - vote for this branch) 11:02, 7 Aug 2004 User:Patrick (See also -*Parser testing)
- (2 votes - vote for this branch) 07:45, 30 Jul 2004 User:AaronPeterson M (HelpTOC at bottom)
- (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
- ...
Extending branches
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.
Creating branches
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.
Voting for revisions and branches
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).
Vote expiration
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.
Vote propagation
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.
Prior authorship precedence
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
- (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
- (3 votes - vote for this branch) 10:50, 9 Aug 2004 User:TLong M Rollback vandalism
- (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.
Exclude-user and include-user tags
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.
Conclusion
The proposed branch management and voting scheme should provide a viable "soft security" alternative to the existing "hard security" mechanism of sysop-controlled page protection, which will hopefully allow almost all the current edit war and vandalism situations to be dealt with by the participants themselves without requiring special privilege. The system also allows different individuals or groups to work on their own versions of a page independently for a while if they so desire, merely for the purpose of exploring different possibilities in order to work toward a better eventual consensus.
Finally, the proposal provides these capabilities while introducing as little additional complexity or procedural red-tape as possible. In particular, workflow in the common case of editing an uncontroversial page is left essentially unchanged.
Proxy voting
In any large and diverse, cooperatively managed system such as Wikipedia, any given user will naturally only be able to actively participate in a limited number of topic areas, and contribute to or vote on a limited number of pages. This limitation introduces the danger of the classic "vocal minority" effect, in which a small number of users with extreme viewpoints who are highly active in a particular topic area (e.g., due to their ideological convictions) are effectively able to drown out or at least tip the balance of the discussion toward themselves and away from the more moderate viewpoint of the "silent majority". This situation can easily develop into what appears to be a flame war between two or more extremes with no one in the middle. The problem in this case is simply that the moderate "silent majority" viewpoint does not have the voting weight it deserves, because most members of this "silent majority" are busy participating in other topic areas in which they have more direct knowledge and interest. Simply because of human time and energy limitations, participatory democracy can effectively disenfranchises the moderate middle in favor of the radical extremes.
A solution to this problem (and again I'm far from the first to propose it) is to allow proxy voting. In short, a user registers a list of proxies on a special page, who are then automatically given the power to vote on the user's behalf on issues or pages for which the user does not cast a vote directly. A user can always override his proxy's vote on a particular page simply by casting a vote directly, and can choose different proxies for different pages. A user can choose a proxy to vote for him on all the pages within a given "topic area", which might be based on the existing WikiMedia category system. Proxies can have proxy lists too, so if neither a user himself nor the user's "primary" proxy casts a vote on a particular page, then the user's vote can be delegated forther to his proxy's proxy, and so on. Proxy voting is completely optional: any user can simply leave his proxy list empty, in which case his vote will only apply when and where he casts it directly.
The upshot is that, by delegating their votes in topic areas outside their immediate focus to other users whom they know and trust to represent them (or at to least maintain a sensible, balanced viewpoint), users can participate at least indirectly in a much larger number of areas. Collectively, useers can thereby give more voting weight to the direct participants in each area who represent the more widely trusted, "silent majority" viewpoints. Nevertheless, since proxy voting is optional and users can always override their proxies' votes and vote directly, the system never takes away the user's power to participate directly in whatever areas he so desires.
Accountability
In order to ensure that proxies remain accountable to the users on whose behalf they vote, any user who wants to act as a proxy must explicitly choose an option to indicate as such (e.g., on their proxy list page), and by doing so they give up their right to have their votes counted anonymously. On the branch/revision history tab of any wiki page, any user can view a breakdown of all the proxies who voted for a particular branch, and how much voting weight they wield in the currently tally. For example:
- Recent Branches
- (10 votes - vote for this branch) 11:02, 7 Aug 2004 User:Patrick (See also -*Parser testing)
- (3 votes - vote for this branch) 07:45, 30 Jul 2004 User:AaronPeterson M (HelpTOC at bottom)
- (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
- ...
- Votes for Branch 1
- 4: Proxy User:Patrick, voting for self plus:
- 2: Proxy User:Kim
- 1: Private users
- 3: Proxy User:TLong, voting for self plus 2 private votes
- 3: Private users
- 4: Proxy User:Patrick, voting for self plus:
In this case, there are currently 10 votes for branch 1, seven of which are public proxy votes and three of which are private votes cast by direct participants on this page. Of the 4 votes wielded by Patrick, one is Patrick's own vote, one is a private vote delegated directly to Patrick by a "single-indirect" participant, and two are private votes from "double-indirect" participants, which were originally delegated to Kim, but who in turn delegated those votes on this page to Patrick.
Distributing proxy votes
to be written
The multiple account problem
to be written
Technical challenges
to be written
Stable branches
to be written