Wikimedia Meta-Wiki

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.

There are two main ideas discussed on this page:

  1. A mecanism for managing multiple alternative branches per wiki page, and allowing users to vote on branches.
  2. A proxy voting mechanism allowing users to participate indirectly in topic areas for which they do not have the time or expertise to particpate directly.

Both of these ideas are technically ambitious, the second even more so than the first. The goal here is to try to find the right long-term solutions to some of the basic problems of wiki systems (and public collaboration systems in general), rather than to come up with immediate, easy-to-implement half-solutions.

Wiki democracy?

edit

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

edit

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

edit

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

Extending branches

edit

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

edit

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

edit

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

edit

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

edit

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

edit

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

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

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

edit

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

edit

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. The branch system will hopefully allow almost all 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

edit

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 further 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 least to maintain a sensible, balanced viewpoint), users can participate at least indirectly in a much larger number of areas. Collectively, users 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.

Proxy Lists

edit

A user defines his proxy list by editing a special per-user "proxy list" page. This page is essentially a normal WikiMedia page, except that it can only be edited by the user who owns it, and it can only be viewed by other users if the user has chosen to be a proxy (see "Accountability" below). Any "User:" links present on the proxy page indicate the user's chosen proxies, and any ":Category:" links on the page control the domain of applicability of those proxies, as follows:

  • If a given paragraph contains one or more "User:" links but no ":Category:" links, then the users listed in that paragraph are general proxies, who are given the power to wield the user's vote on any page in the system.
  • If a given paragraph contains one or more "User:" links and one or more ":Category:" links, then the listed users are given proxy power only within (all of) the categories listed in the paragraph.

Other types of text and links on the page, as well as any "User:" links naming the owner of the proxy page, are ignored by the system, allowing the user to annotate his proxy list page freely. A user's proxy list might look as follows, for example:

Hi, I'm User:James.
My general proxies are User:Bob and User:Alice, because they're my close friends and I trust them to represent me on any topic.
In addition, my chosen category-specific proxies are as follows:

Accountability

edit

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 preferences page), and by doing so they give up their right to have their votes counted anonymously or to keep their proxy lists private. 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 current tally. For example:

Recent Branches
  1. (10 votes - vote for this branch) 11:02, 7 Aug 2004 User:Patrick (See also -*Parser testing)
  2. (3 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
Votes for Branch 1
  • 4: Proxy User:Patrick, voting for self plus:
  • 3: Proxy User:TLong, voting for self plus 2 private votes
  • 3: Private users

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

edit

When a user checks in a new revision on a page or explicitly votes for a given branch, he casts a direct vote as described earlier in the section on branches. We therefore call such a user a direct participant on the page. In addition, any user who is not a direct participant on the page, but from whom a vote delegation chain exists leading to some direct participant, is considered an indirect participant. When only one delegation chain exists from an indirect participant to a direct participant, the behavior is relatively obvious: the direct participant's voting weight simply increases by one vote to include the vote of the indirect participant.

What if there are multiple delegation chains leading from a single indirect participant to two or more direct participants - i.e., when a user has more than one applicable proxy? And particularly, what happens when those direct participants vote differently? For example, suppose Bob includes Alice on his proxy list as a proxy for "all categories", and Bob lists Jim as a proxy only for the category "mathematics". Further, Alice lists both Jules and Jim as her proxies for mathematics. If neither Bob nor Alice casts a vote on some page in "mathematics", but both Jules and Jim cast votes, then there are three different delegation chains from Bob to the direct participants on the page (Jules and Jim):

  • Bob → Alice → Jules
  • Bob → Alice → Jim
  • Bob → Jim

In such a situation, the indirect participant's vote is split into fractions and evenly divided among each of the indirect participant's immediate proxies. This process is then repeated as necessary to propagate the fractional votes along the delegation chains to the direct participants on the page. In this example, Bob's vote is split into two halves, with half a vote going to Alice and half a vote going (directly) to Jim. Alice's half of Bob's vote is in turn split evenly, with a quarter vote going to Jules and a quarter going to Jim. Effectively, then, 75% of Bob's vote goes to Jim while the other 25% goes to Jules.

Of course, we only considered Bob's vote so far. Since Alice, Jules, and Jim are also participants in this scenario, however, and wield individual votes of her own, the overall situation is as follows. Bob wields 1 vote, split evenly between Alice and Jim. Alice effectively wields 1.5 votes (her one vote plus Bob's half vote), which is split evenly between Jules and Jim. Jules then ultimately wields 1.75 votes (one for himself plus 0.75 from Alice), while Jim ultimately wields 2.25 votes (one for himself, 0.75 from Alice, and 0.5 directly from Bob).

The multiple account problem

edit

One serious problem that such a proxy voting could unfortunately cause is to make a wiki system much more vulnerable to abuse by users who sign up for multiple accounts. With proxy voting, a user might create several fake accounts that do nothing but delegate all of their voting power to the user's single "real" working account, unfairly magnifying the user's voting power. Because of this abuse potential, proxy voting should not be enabled in a wiki system unless the system also has some form of protection against this kind of abuse.

One possible form of multiple-account abuse protection might be only to allow users to vote once their account has been "validated" in some way. There might be multiple possible ways for a user to be "validated", such as the following:

  • Being explicitly marked as such by a sysop who has interacted with the user and believes the user is legitimate.
  • By having contributed a certain minimum amount of content that has remained on "main-line" branches for a minimum length of time.
  • By being "endorsed" or "voted in" in some way by a sufficient number of existing validated users.
  • By passing some form of more traditional identity check, such as a credit card-based name and address verification, or by mailing or faxing in a utility bill as proof of residency.

The security mechanisms most appropriate in a given case will obviously depend on the wiki system in question and the policies of the organization running it.

edit

Stable branches

edit

to be written

Personal bookmarks

edit
edit
Retrieved from "https://meta.wikimedia.org/w/index.php?title=User:Brynosaurus~metawiki&oldid=11859296"