Last modified: 2011-03-13 18:06:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4397 - Time based anti-vandalism feature
Time based anti-vandalism feature
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: Lowest enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 11770 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2005-12-27 12:04 UTC by Ian Woollard
Modified: 2011-03-13 18:06 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

time outs shut downs (deleted)
2007-12-12 19:41 UTC, sharon

Description Ian Woollard 2005-12-27 12:04:17 UTC
Vandalism is currently encouraged by the wikipedia- vandalisations go 'live'
immediately and the vandals get immediate positive feedback, encouraging their

The proposal is for edits by anonymous editors and new editors to be delayed
from being the current generally displayed version for a period of time; for the
sake of argument, for 1 day after the article has ceased being edited.

Experienced editors would get their edits shown immediately as now.

This mechanism would give the experienced users a chance to see the change and
remove inappropriate edits; via the existing watchlist mechanism. It also
discourages the vandals, and permits the first time editors to tidy up their own
edits (i.e. "can I really edit this??" edits).

The implementation of the idea would require having a list of recently edited
pages that have been edited by 'newbies' and rendering them differently. Since
this only applies to pages that have been edited within the period of time, the
list would be reasonably short and is unlikely to impact performance of the wiki

Differences from similar ideas:

- semiprotection forbids new users from editing entirely; this idea allows it,
but in a controlled way
- unlike semiprotection this idea scales to the entire wikipedia, and minimises
the amount of work the admins would need to do.
- voting is much more complex way to do similar things, but in a wiki voting has
many pathologies; cabals can form and the concept of quorate is not well
defined; in addition, requiring voting can stop articles going live entirely if
nobody ever votes etc. etc.
Comment 1 Rob Church 2005-12-27 16:04:47 UTC
This would rapidly break the article histories if we were to implement them.
What happens if Joe Anon edits revision A of an article, and saves revision B.
Revision B isn't visible right away however. Meanwhile, Joe User edits revision
A and saves what will be revision C.

At this point, we have an edit conflict which we can't easily resolve. After a
period of time, if I follow your suggestion, revision B would become the current
one; out of sequence with the rest.

There are too many niggles we'd have to work out.
Comment 2 Ian Woollard 2005-12-27 17:22:35 UTC
Sorry if I wasn't clear.

The version history and editing would work *exactly* as it does now. Edits
necessarily have to work with the absolute latest version (even if that wasn't
the displayed version); and the version list would show all versions, including
newbie edits, all exactly as now.

Only the 'current' version of the article that is served if you go to the
article would hide anything.

In your example 'Joe User' (I prefer 'Joe Editor') would get an edit conflict,
*exactly* as now. The idea is not that of trying to hide Joe Anon's edits from
editors- only from the *users* of the wikipedia.
Comment 3 Ian Woollard 2005-12-27 18:04:59 UTC
If you meant that Joe User hits edit ''after'' Joe Anon hits 'save page', then
he would be editing Joe Anon's version. That's the way it works in the wikipedia
now- you edit the latest version, even if that isn't the version you are viewing
(say, because somebody has submitted an edit since you started viewing.)
Comment 4 Rob Church 2005-12-27 22:54:42 UTC
Hmm. That makes it sound a little more...I'm not sure what the word is;
feasible/plausible. Wouldn't this be more or less superceded by the various bits
of reviewing functionality coming into play soon?
Comment 5 Ian Woollard 2005-12-28 01:19:02 UTC
Which? The only ones I am aware of would complement it nicely.
Comment 6 Brion Vibber 2005-12-28 15:33:47 UTC
This is probably a dupe as it's been discussed since 2002, but I can't turn up a prior for it in bugzilla at the moment. Mark as dupe if you find it.

This will be implemented with upcoming version-display work.

Comment 7 Ian Woollard 2005-12-28 16:05:54 UTC
The only one I've found is 568, but 568 seems unworkable because it doesn't have
the timeout idea where things get automatically published after 24 hours.
Comment 8 Catherine Woodgold 2007-06-10 16:28:45 UTC
Suggestion: "stabler version" button to display relatively vandalism-free version of page:

Have one more button at the top of an article page, called "stabler version".  When a user clicks it, they would see a recent version of the page (usually not the most recent version), chosen by an algorithm designed to try to lower the probability of seeing vandalism.

The algorithm would try to find the most recent version which seems to have been implicitly approved of by at least 3 editors and not disapproved of by any.  (In the following, any consecutive series of edits by the same editor is treated as a single edit.)

A simple algorithm would work like this:  each edit is classified as being a revert or not.  (In the simplest implementation, it's classified as a revert only if it is identical to the second-last version before it.  More advanced algorithms could be developed.)  A revert, of course, indicates disapproval of the version being reverted from and approval of the version reverted to.  An edit which is not a revert is assumed to implicitly approve of the preceding edit.  (The logic here is that if someone edits something in one paragraph, and then someone else edits something in a different paragraph, the second one is implying that the first one was not vandalism.)

If the algorithm can't find, with a reasonable amount of effort, e.g. analysing the last 10 edits, a most recent version which was implicitly approved of by at least 3 editors and disapproved of by none (first try: 3 approving editors), then it tries to find the most recent version implicitly approved of by at least 2 editors and disapproved of by none (second try: 2 approving editors).  If that also fails, then it simply returns the most recent version. (third try:  1 approving editor.)

(Note that vandalism is usually not a revert, therefore vandalism is taken by the algorithm to implicitly approve of the preceding version, so in such a case the preceding version seems to be approved of by 2 editors, including the vandal, so the algorithm will not fail its second try and the most recent (vandalised) version will not be returned as the "stabler version".  Also, after vandalism, usually the next edit is a revert, so the vandalised version will usually not be returned later on, either.)

I believe that a simple implementation of this algorithm will display vandalism-free versions of the vast majority of vandalised pages given the current rates of vandalism and anti-vandalism vigilence.

Edit history issues:  Perhaps by default the most recent version is displayed.  Any user can view the stabler version by clicking on the tab.  If they click on edit while viewing the stabler version, they will see a warning that they are editing an older version of the article, and everything will proceed the way edits to older versions happen now. 

Unlike the time-based anti-vandalism feature suggested in the original bug report, this "stabler version tab" feature would allow any reader to see the most current version if they choose to.  For pages edited more rarely, the most recent version might contain a lot more information, and the reader would be able to access it.

Variations:  the default could be to see the stabler version, with the most current version available with a "most recent version" tab.  Or, users could choose the default in their skin.  
Comment 9 sharon 2007-12-12 19:41:50 UTC
Created attachment 4436 [details]
time outs shut downs

stack walk error ,stops computer,watchdog shuts computer down,
Comment 10 Brion Vibber 2007-12-18 01:15:49 UTC
The content of attachment 4436 [details] has been deleted by
    Brion Vibber <>
who provided the following reason:


The token used to delete this attachment was generated at 2007-12-18 01:15:42 UTC.
Comment 11 Aaron Schulz 2008-01-13 19:01:05 UTC
*** Bug 11770 has been marked as a duplicate of this bug. ***
Comment 12 Aaron Schulz 2008-01-13 19:07:59 UTC
Catherine, that is a whole different idea, being working on as ArticleTrust.
The plan is to make ArticleTrust and FlaggedRevs compatible so that the newest
"likely unvandalized" version can show by default if there is no "sighted"
(manually done) version.
Comment 13 Aaron Schulz 2008-09-11 06:36:48 UTC
Pretty much done by ArticleTrust extension.
Comment 14 Ian Woollard 2008-12-14 04:02:41 UTC
Feature does not appear to have been implemented in any recognizable form on English wikipedia, so reopening.
Comment 15 Mike.lifeguard 2008-12-14 04:10:13 UTC
(In reply to comment #14)
> Feature does not appear to have been implemented in any recognizable form on
> English wikipedia, so reopening.

The software exists - English Wikipedia needs to gather consensus to enable it, then make a shell request in Bugzilla.
Comment 16 Ian Woollard 2008-12-14 06:33:32 UTC
I tried searching in several places and was unable to confirm this has been completed. Unless you give me a usable reference to the documentation of the feature so I can evaluate the claim that it has been satisfactorily fixed, as the originator I am forced to reopen it as not fixed.

Comment 17 Brett Hillebrand 2008-12-14 14:26:44 UTC
Per comment #15: The software exists - English Wikipedia needs to gather consensus to enable it,
then make a shell request in Bugzilla.

This does not belong here yet, please go to the Village Pump on wikipedia and when you gain a consensus that it should be implemented, than make a request here.
Comment 18 Ian Woollard 2008-12-14 14:43:11 UTC
If it exists you can tell me the name of the feature or other details on it so we can check that it implements the feature as requested (or near enough), and then I can actually put a shell request in on all appropriate wikis, and then *I* will close this. Right now I can't do any of that, and I'm not convinced you have the slightest clue whether this feature has been implemented, so for all purposes this is not fixed.
Comment 19 Max Semenik 2008-12-14 14:45:48 UTC
Comment 20 Aaron Schulz 2008-12-14 19:01:53 UTC
(In reply to comment #19)
> [[mw:Extension:FlaggedRevs]]

That is incorrect. Said extension does not include a feature to auto-review or mark things "live" just due to time passage.
Comment 21 Ian Woollard 2008-12-14 21:28:16 UTC
I understand that the FlaggedRevs extension does however permit listing of the versions that have remained unsighted, so it looks like the feature could be implemented with a bot that checks this list and sights them as needed. I do have some concerns about performance though, but we could reopen the feature request if the performance turned out to be too poor, and use it only on tagged articles. The usability would be higher with this scheme than with conventional FlaggedRevs.

However, it also seems from data from the German trial that no reduction in vandalism was observed from FlaggedRevs, so the theory that this feature is based on may be based on flawed analysis of vandalism psychology.
Comment 22 Thomas Bertels 2009-11-19 10:28:22 UTC
(In reply to comment #21)

> However, it also seems from data from the German trial that no reduction in
> vandalism was observed from FlaggedRevs

I'd be interested to read the full study, if you have the link handy. Or if you remember somewhat where you read it.

Note You need to log in before you can comment on or make changes to this bug.