Was Jimmy Wales born on the 7th or 8th of August? Which source is the most reliable and how many do we need to support one or the other? Of course, the subject of the article could end the birthdate controversy himself... but that would be original research! -- Wikipedia's Lamest Edit-Wars

Analyze the interface

edit

MediaWiki features tools to view the revisions of contributions. These tools can be found on several web pages. On Wikipedia, every editable page has a revision history. Of course, that history page is not editable in the way one would edit an article. The context of that page, with all the click-able links and displayed content, is an interface to the MediaWiki software. The history page is only one example of the many interfaces that MediaWiki provides.

In order to edit how the history interface works, one would have to edit the source code of the MediaWiki software. At this time, the active source code is not available in wiki style to edit. There are many reasons for this, one is security of the code. If you consider what edit wars could do to an article, consider what an edit war in the source code of the history interface could do to when you try to access Wikipedia's articles. One minute a link might be to the right of another link, and another minute it might be on top, and another minute it might be back on the left, and... you get the idea. The interface, the history page, would not be stable enough for people to use if it was editable by everyone at any time.

The history interface may not be in the best form, or have all the right tools, in order to easily resolve edit wars on articles. For example, when editor looks at the history page and notices edit wars, then that editor might manually pull up each user's talk page and give a notice that an edit war exists. Notice the editor manually pulls up each user page. Now, if you could edit the history interface you might make a button to quickly give notice to everybody in the edit war. Another editor might find it useful in further edit wars to quickly select the editors that need notices on their talk page. People might like the feature because it saves time over the many manual steps to edit everybody's talk page. More features like that could be edited into the history interface, but there is a problem with more and more additions: feature creep. The number of additional tools or lack of tools, and the best form for them, the web page, need broad consideration.

The feedback that the engineers need is that kind of well thought-out consideration. As of this time (see also: Wikimedia's bugzilla), there may be hundreds of feature suggestions, known as wish-lists, of how to change MediaWiki software, but most of them probably do not have any justification for the change. The engineers hesitate to implement a new feature that could create havoc, like MediaWiki's active source code that anybody can edit.

Automated detection

edit

Set aside Wikipedia's 'bots' for the time being, as we don't want to encourage Wikipedia's Lamest Mech-Wars being actively logged.

Another consideration is the amount of information being presented in the context of the history interface. Entries of revisions may be highlighted in order to indicate potential occurrences of an edit war. The editors involved in the edit war would see the visual warning of an edit war when they look at the history page. The actual methods of how such detection is done is a separate issue from the consideration being discussed here, as it is a matter of the engineers to change the source code. The feedback to the engineers still need the consider to be in-depth enough about the potential or abstract methods of detection.

One example of detection is being developed now, and that is the WikiTrust Coloring project. With the features of WikiTrust, one could consider a new feature that would detect when two edits change a single word marked by WikiTrust. In that case, the revision history could show a revision as highlighted for potential edit wars. This is the kind of depth the engineers need in order for them to avoid too much time in research of how to accomplish wanted features.

Events and ethical considerations

edit

With automated detection in place, the next step is to consider more automation steps that MediaWiki can do to handle common events of edit wars. With the color features noted above, if the revision history looks like a massive strobe of indicators found at nuclear reactor meltdown, then it is possible for such events to trigger page protection to the degree of the edit war. If it is only for the past hour, then MediaWiki could issue a 3 hour auto page-protection. If it was just from unregistered users, it could auto page-protect to only allow registered users for so many hours. It could just auto page-protect until an admin has time to review the edit war and decide when to un-protect the page.

The elements of ethics may be found in hidden ways when steps are automated. In the given examples above, the triggers help save the administrator's time to manually discover that a page needs to be protected. Other manual steps may be eliminated such as the need to manually edit a page to make a report of an edit war. Consider that AN/I typically shows between 100kb to 500kb of data being stored for each single edit made to the page, that is a perpetuated amount of data flow everyday. That history page shows about 50 revisions that average more than 150kb each, so that is over 7 megabytes worth of space needed just for those 50 edits alone.

Suggested essay

edit
  1. Write a short essay to recommend a new feature for the revision history web page.
  2. Research the Internet for developments that would help automate detection of edit wars or other such events, and source it in your essay.
  3. Include in your essay how the new feature may affect ethical issues.
  4. Estimate the total amount of space required to store every revision of AN/I since it was created.

Resources

edit
edit