Automatic edit war squashing

Here's an idea for a replacement/addition for protection as an ameliorating factor in edit/revert wars:

Proposal

Pages with more than X edits in the last seven days, get a "frequently edited" status flag set. Such pages have the following additional behaviour:

1. Edits to them do not appear on recent changes, related changes, or watchlists.
2. When the current version is replaced, the old version does not enter the edit history.
3. An automatic message is placed at the top of the page, something like This page is being edited very frequently, and certain technical features are disabled. Please see the last stable version. (but that'd be MediaWiki:, anyway).
4. When the page loses "excessively edited" status, the current version is written into the history with the edit summary (flurry of X edits by Y users). This change appears on recent changes, watchlists, related changes.

Pages that are edited that frequently in the normal course of events (main page, recent changes, ...) get put in a (community-edited) exemption list.

Heuristics

The "more than 5 edits in the last seven days" heuristic is a simple one to detect the difference between normal editing (which is good) and highly frequent editing (which is probably an edit war and thus bad). More complex heuristics are possible.

A sensible improvement would be to consider multiple consecutive edits by the same person to be the same edit, solely for the purposes of gaining the "frequently edited".

You could also consider making "straight reverts" count for 5x a single non-reverting edit. A "partial revert" (where a prior version is edited, but some changes are made to it) would count for 2x normal.

Benefits

Reduced visibility (and hence annoyance and inconvenience) of edit wars to third parties

Harder for edit warriors to carry on their war (They must keep manually refreshing each page, rather than using their watchlists to keep track of wartorn pages.)

Discourages edits to warred pages until the matter has calmed down

Reduced sysop involvement (in fact, no involvement); So, the whole question of who is a sysop, The Wrong Version etc., becomes moot.

Reduces clutter of page histories; A protracted revert war doesn't wreck the usefulness of the page history for everyone else.

Ties up revert warriors in thankless revert wars where they can slowly exhaust each other until one or the other (or both) keels over from lack of sleep, which seems like an effective way of "resolving" some apparently unresolvable disputes; At best, the sheer monotony of a continual revert war will get people to make the odd compromise.

Drawbacks

Reduces the opportunity for users of operating systems that spontaneously combust every now and then, people behind shaky Internet access or living in the Third World and therefore subject to frequent power outages to actually make nontrivial contributions.

Comments

I can see merging consecutive edits by the same user as being a very good thing, especially if they are within a very small delta of each other. Perhaps in addition to the "minor edit" button there could be a "merge with my previous edit" button to make this happen on any page. This would also be good because a spelling fix edit summary would not cover up the real reason for the main edit.

Similarly, revert wars could instead of saving the edit history, just revert back to the previous version, as long as both versions are saved in the edit history somewhere. This perhaps would be harder to implement. Perhaps the third revert would just roll back the second revert? How often does this happen anyway? --Ssd 06:08, 17 Apr 2004 (UTC)

As an observation...I saw a revert war between a vandal and two registered users. The vandal reverted twice, the registered users each reverted once. The history of reversion probably needs to be saved at least short term, even though the end result of four reversions is no actual changes in the page. If the history is collapsed, should it be done immediately, or perhaps it would be better to do it weeks later, deleting or combining inbetween steps? --Ssd 05:00, 19 Apr 2004 (UTC)

The history could be collapsed but have an option to show all edits as they were made. This would solve the problem of history clutter and make edit wars much less harmful, but still discourage excessive reversion by keeping the entire history. Guanaco 03:23, 18 Aug 2004 (UTC)

That's an idea worth pursuing: collapsible sections of the history; although exactly how the software would choose what to collpase, I'm not sure. - IMSoP 23:12, 23 Nov 2004 (UTC)

What if rather than a single linear history, there was a branched history a little like what you get in CVS and similar systems. When a revert is done, any previous edits would be collapsed into a "branch", so that tracing back from the current tip would not be interrupted by any intermediate vandalism or non-canonical changes (in the default visualisation). Any amount of history could then be "undone" simply by creating a new branch from a last known good version, with edit wars vandalism etc. tidied away into an obsolete branch. 62.173.111.114 10:42, 5 May 2005 (UTC)

I'm not sure an automated heuristic of edit frequency would detect revert wars very reliably at all. A page that is being "excessively" edited could just be one that is in the process of collabourative improvement. And I certainly don't think 5 edits in 7 days would be "excessive": some pages regularly get 5 edits within 7 hours! I wondered briefly if a formula could be created based on X editors over the last Y hours have edited this page Z times - such as setting the flag if X=2, Y=24 and Z=5; but even that could be perfectly innocent, for instance two users alternately adding information and improving each other's formatting, grammar, etc. And even then, I think what we really want to do is persuade people to stop the war, whereas this proposal seems to simply hide their edits from everyone else unless/until they calm down. So, really, I can't see this working. - IMSoP 23:12, 23 Nov 2004 (UTC)

So what about a Panic Button that either user (or maybe a third party) could press in the course of an edit war to actually trigger the protection mechanism. I think a good way to differentiate between collaborative improvements and edit wars is the repeated presence of reverts to previous versions (although that would be too easy to get around if the user wanted to carry on fighting). 80.58.43.42 03:15, 6 Feb 2005 (UTC)

Another idea similar to the X/Y-formula above would be to include the lenght of the page in characters: If the same 2 authors have edited the same page 5 times the last 24 hours and the page hasn't gained more than 5 words per edit, then an edit war is detected. Only the words added by the 2 authors in question should be counted, of course.

Will this still work if the users are merely collaboratively revising / rewriting / tidying up, rather than adding new material? There could be innocent cases of this, too... though I suppose it would be rather rare.

If you have the wartorn pages not show up on watch lists or recent changes then spammers could just create their own editwar over pages to prevent the good guys from seeing that they changed and then fixing them.

The best thing to do would be to check for edit summaries containing "revert", "rollback", or "rv". 66.193.5.99 16:11, 12 January 2006 (UTC)

A large number of edits, each adding to the article, is probably not an edit war. Perhaps a heuristic should involve an amount or percentage of data changed/removed per week would be better. 24.46.145.152 02:04, 20 January 2006 (UTC)

Such an idea seems very dumb to me. Often I link Wikipedia articles on various topics to a forum (topics that need expansion) and a bunch of people help expand it quickly. This may result in hundreds of edits in a few hours. The same thing happens in current-event articles. The one good idea is to merge consecutive edits by the same user: I'm surprised that isn't implemented already. 132.250.190.57 19:05, 13 July 2006 (UTC)

Making reverts more difficult to perform is technologically backward.

Difficulty of reverts (a) is designed out of a naive concept of safety of obscurity, (b) gives a false perception of safety to the users, (c) gives an advantage to technology-savvy users over NPOV-oriented users. Ilgiz 09:00, 16 March 2007 (UTC)