FAIR and interactive data graphics from a scientific knowledge graph
Contents
It is proposed that a new edit filter 'defer' action be created enabling intermittent pending changes protection or a technical equivalent in response to flagged edits on any article. Before the suspicious edit is saved, pending changes is enabled so that the suspect edit does not appear to readers and is instead checked by reviewers like usual pending edits, who can then revert it, overwrite it or accept it. However unlike typical pending changes, once any revision becomes accepted, either by a reviewer or automatically, pending changes is automatically removed from the page. An implementation minimizing the amount of technical changes required is sought after, so that the software request can be acted upon.
Background and objective
Pending changes (using the FlaggedRevs extension) works on pages 'protected' by pending changes by displaying to unregistered users only revisions that have been marked as accepted automatically or by a reviewer. At level 1, edits by autoconfirmed users are automatically accepted when the previous revision was accepted, while at level 2, such is the case only for reviewers.
The edit filter (formerly AbuseFilter) works by monitoring edits made to all pages, testing them against filters to identify suspicious behavior, and then taking action based on the likely nature of the edit. The filter can disallow edits, warn the editor, tag the new revision, or remove the editor's autoconfirmed status.
The intent of deferred revisions is to provide a way to delay the visibility of edits that have been flagged for deferral by the edit filter until they have been accepted or reverted by a reviewer. This implementation proposal attempts to use the FlaggedRevs and AbuseFilter features together in order to achieve that goal in an integrated way and without need for a new extension.
Description
This proposal involves modifying the edit filter to create a new available action: the ability to enable pending changes protection, however in a time-limited manner: as soon as (or soon after that) any revision becomes accepted (automatically or manually), the added pending changes protection is removed automatically. As such, on pages without prior pending changes protection, only edits flagged as suspect will not be visible immediately; and they will await review in the same manner as other edits to pages protected by pending changes. Edit filters are limited by MediaWiki so that they can only catch a small percentage of edits and edit filter managers ensure that the false positives rate is minimized.
The action to enable and disable intermittent pending changes protection is noted in the pending changes protection log, but not in the history of the affected page. The last edit prior to the suspect edit is automatically accepted when pending changes is enabled, reviewers cannot have their edits deferred for review. An edit filter using this action can at first warn the user before deferring the edit.
Pending changes protection can either be set at level 1 or level 2. At level 1, only edits by unregistered or new users can be deferred, across all pages without pending changes protection. At level 2, edits by autoconfirmed users can also be deferred. However, on pages already under pending changes at level 1, after a new revision is accepted, the edit filter should downgrade protection back to level 1 (and not altogether remove it), with the prior expiry, and cite the prior protection summary. Generally, deferrals should be of level 1 type. The feasibility and desirability of setting a level 2 deferral is to be discussed.
Deferred revisions are listed at Special:PendingChanges with other pending edits. In order to inform reviewers of the specific situation, the pending changes protection log which can be displayed optionally when reviewing revisions could be always displayed by default, and the log summary given by the edit filter could display the name and reference of the filter responsible for deferring the edit. A cooldown period for the automatic removal of pending changes after a new revision is accepted may be instituted to fend off repeated vandalism attempts, this may be a variable that can be set per filter, with an upper limit of a few minutes to be fixed. The bot adding pending changes protection templates should not add those in this case.
Due to the way pending changes work, subsequent edits by non-reviewers before pending changes is automatically disabled will also be 'deferred', but unless a page is frequently edited by different users, this shouldn't happen often, based on the occurrence of such events in the current pending changes implementation. If this still happens too often for a filter, the cooldown period can be reduced.
Examples of filters
Several existing edit filters with the action to warn or tag could be set to defer. Numerous vandalism edits detected and tagged by those filters still persist for minutes or hours, yet the rate of false positives is too high so the edits can't be altogether disallowed. This includes:
- 172 : Section blanking
- 135 : Repeating characters
- 39 : School libel and vandalism
- 189 : BLP vandalism or libel
- 3 : New user blanking articles
- 132 : Removal of all categories
- 432 : Starting new line with lowercase letters
- and many others.
See also
- Old proposal
- Related feature request: T3189