Wikipedia:Pending changes blocks

This Wikipedia page has been superseded by Wikipedia:Deferred changes and is retained primarily for historical reference.

This page in a nutshell: A 'pending changes block' prevents the user's edits to articles from going live immediately. It is intended to be used more liberally than the more stringent traditional blocks and would be available to non-administrator users and automated processes. The objective is to reduce the overall visibility of damaging edits to the general public.

A pending changes block is a proposed technical editing restriction imposed on a user, that is to traditional blocking what pending changes protection is to traditional protection. Any edit by a pending changes blocked user would not be visible to readers, it would be pending until reverted or reviewed, as if the edited pages were on pending changes protection but such protection would disappear after the revert or review is done. This permission would be assigned to administrators as well as users in a new usergroup, and may be made available to the edit filter.

Pending changes blocks may be imposed on new or unregistered users performing edits that are vandalism, spam or BLP violations, provided the criteria for a traditional last warning are met, at minimum. This means that pending changes blocks can be used one step ahead of traditional blocks by a larger group of users, improving our reactivity and our mitigation of vandalism. For dissuasive effect, the pending changes blocked user would be warned that their edits are now reviewed before being published, and that further inappropriate edits will result in a full block. Any edit by a pending changes blocked user would be reported at AIV by a bot.

Rationale

The rationale for introducing this new technical tool is twofold. First, the excessive amount of time it takes for administrators to block the users reported for performing those unacceptable edits, a concern that is only amplified by the widely held view of a shortage in administrators. Second, the criteria for blocking are quite strict, with a requirement of several warnings in most cases, in the meantime the damaging edits cannot be mitigated preemptively, except when picked up by edit filters set to disallow, but those are often evaded.^[1] In addition, since the edits are not saved, they are not apparent to recent changes patrollers, and so users can be unhindered in their attempts for long periods.^[2] Among users reported at WP:AIV, both the total number of edits performed between last warning and AIV report, and performed between AIV report and block, are significant. The noticeboard is chronically backlogged, some users have enough time to makes dozens of edits,^[3] and sometimes are blocked only hours later when they are no longer active.^[4] Some of their edits remain visible for several minutes, up to an hour or more on occasion.^[5] Had those users been pending changes blocked by non-admins, their edits would not have been visible to the public. In addition, recurrent sockpuppeting vandals and spam bots could be immediately pending changes blocked. The edit filter cuts a substantial portion of vandalism, but most of the flagged edits are allowed due to significant false positive rates. They are tagged, but many can still be missed, sometimes for days.^[6] Deferring those suspicious edits for review would ensure that they are taken care of. In addition, it may reduce the number of edits allowed per minute (8 for new or unregistered users). The situation would therefore be much improved by providing this mild form of blocking to non-administrators, anti-vandalism bots and the edit filter.

Impact analysis

The impact on the backlog of unreviewed edits should be small. The simple fact that the user's edits are no longer published without review should be quite dissuasive on its own. If a pending changes blocked user persists, any edit would be listed at Special:PendingChanges and tagged, and the user would be immediately reported at WP:AIV by a bot. In contrast, on pending changes protected articles, despite being among the articles most subjected to this type of edits, a very large portion of all edits are still acceptable, and they end up forming the bulk of the backlog. The pending edits that are vandalism, spam or BLP violations are dealt with quickly. At the moment, most pending changes are reviewed within one hour, and it takes very rarely more than a few hours, this small increase can be managed.

The impact on general editors should be minimal. Unlike pending changes protection which remains on articles continuously for significant periods of time, and thus is visible and potentially interfering during that time, the ephemeral nature of the disruption caused by pending changes blocked users ensures a very limited distraction.

The impact on the workload of administrators should be positive due to the dissuasive effect of pending changes blocks, meaning less need for traditional blocks. While administrators would also be involved in the occasional promotions (or demotions) of users to the new usergroup, those would form a very small part of their burden compared to their regular duties.

The impact on user participation should be negligible. Since the use of this feature is straightforward and restricted to obvious vandals, spammers and such, misuse or abuse potential would be small. If it does happen, the user would still be able to edit and this would come to the attention of an administrator due to the AIV report. Further, the vast majority of contested admin blocks are of established editors, but it would be technically impossible to pending changes block autoconfirmed users. Pending changes blocks of IP ranges would also be impossible.

Policy issues

Pending changes blocks may only be used for vandalism, spam or BLP violations, provided the user meets the requirements for a traditional last warning before a traditional block, or for a traditional block as determined by the blocking policy. Pending changes blocking thus serves both as :

a preventive and dissuasive measure that can be applied before the requirements for a traditional block are met,
in case of persistence of the disruption, or if the criteria for a full block were already met, as a temporary measure until an administrator can intervene.

The new usergroup would have in addition to this new userright those of rollbackers and pending changes reviewers.^[7] The community should agree on a name for the new usergroup; suggestions include moderator and pending changes blocker. Administrators would possess all of the userrights afforded to this new usergroup, and could grant it or remove it. The criteria and process for adding users to this usergroup would be discussed later by the community. A good anti-vandalism experience would be expected. It may involve a short community discussion with consensus determination by an administrator.^[8] The modalities of removal of this usergroup should also be discussed. A new noticeboard for reports for pending changes block may be created. Pending changes blocked users may appeal on their user talk page, with only administrators allowed to review appeals.

Bots may be assigned to this new usergroup based on a successful BRFA. For example, regular anti-vandalism bots may use it every time they give a last warning or report a user at AIV. The only active anti-vandalism bot at the moment is ClueBot NG (talk · contribs). A new type of anti-vandalism bot may directly pending changes block any user committing a specific pattern of serious abuse, as a complement to the edit filter.

Edit filter

Currently, numerous filters target vandalism, spam or BLP violations, the user is usually either prevented from performing the edit or warned, in the later case they can still confirm and save the edit, which is simply tagged. Those edits are often not reverted in a timely manner, in addition the users often find ways to get around filters set to disallow. In order to correct those deficiencies, it may pending changes block a user tripping the filters three times, so that edits not picked up by the edit filter are also deferred.^[9] It may do so at second hit, or first hit for certain filters targeting serious patterns of abuse, such as those of sockpuppeting vandals or spam bots.

Those filters tag the edit, and for most of them, warn the user, they could possibly be set to pending changes block after three hits :

List of filters

3 (hist · log) New user blanking articles
11 (hist · log) You/He/She/It sucks
30 (hist · log) School libel and vandalism
50 (hist · log) Shouting
79 (hist · log) New user removing reference grouping tags
80 (hist · log) Link spamming
132 (hist · log) Removal of all categories
135 (hist · log) Repeating characters
149 (hist · log) User adds link containing username
189 (hist · log) BLP vandalism or libel
231 (hist · log) No spaces
345 (hist · log) Extraneous formatting
346 (hist · log) Large non-English contributions
351 (hist · log) Text added after categories and interwiki
432 (hist · log) Starting new line with lowercase letters
491 (hist · log) Edits ending with feeling expression

Those filters prevent the action, but users often find ways to get around the edit filter, so they could pending changes block after three hits or less :

List of filters

11 (hist · log) Replacing a page with obscenities
31 (hist · log) ASCII art
46 (hist · log) "Poop" vandalism
139 (hist · log) Fixed position vandalism
225 (hist · log) Vandalism in all caps
260 (hist · log) Common vandal phrases
285 (hist · log) Common Vandalism
294 (hist · log) Personal attacks
294 (hist · log) "Your mom" Vandalism
365 (hist · log) Unusual changes to featured content
380 (hist · log) Multiple obscenities
384 (hist · log) Addition of bad words
614 (hist · log) Yolo swag and other vandalism trends

Schematic table

Wikipedia users, user blocks, page protections, and page edits
	Traditionally blocked users	Pending changes blocked users	Unregistered, New	Autoconfirmed, Confirmed		Reviewer	Administrator	Appropriate for*
No protection	cannot edit	can edit; on an article, changes will go live after being accepted by a reviewer	can edit; changes go live** immediately; no acceptance required					The vast majority of pages

Pending changes level 1 protection	cannot edit	can edit; changes will go live after being accepted by a reviewer		can edit; changes go live immediately (if no previous pending changes remain to be accepted)		can edit; changes go live immediately;*** can accept pending changes		Infrequently edited articles that are experiencing high levels of vandalism or BLP violations from unregistered and new users
Semi-protection	cannot edit			can edit; changes go live immediately; no acceptance required				Articles experiencing high levels of vandalism or edit warring from unregistered and new users, and for some highly visible templates and modules

Pending changes level 2 protection	cannot edit	can edit; changes will go live after being accepted by a reviewer				can edit; changes go live immediately; can accept pending changes		No consensus for use on the English Wikipedia per WP:PC2012/RfC 1
Pending changes level 2 with Semi-protection	cannot edit			can edit; changes will go live after being accepted by a reviewer		can edit; changes go live immediately; can accept pending changes		No consensus for use on the English Wikipedia per WP:PC2012/RfC 1

	Traditionally blocked users	Pending changes blocked users	Unregistered, New	Auto/Confirmed	Reviewer	Template editor	Administrator	Appropriate for*
Template protection	cannot edit					can edit; changes go live immediately; no acceptance required		High-risk templates and modules
Full protection	cannot edit						can edit; changes go live immediately; no acceptance required	Articles experiencing persistent vandalism or edit warring from (auto)confirmed accounts, and for critically important templates and modules
* See also: Wikipedia:Protection policy "Go live" means the edits will be visible to readers who are not logged in. In all cases, edits are always visible to readers logged into Wikipedia. * When editing articles with un-reviewed pending changes, Administrators and Reviewers are prompted to review the pending changes before saving their edit.

Technical details

The naive implementation would be for MediaWiki to place any article that gets edited by the pending changes blocked user under pending changes protection, put the new edit in an unaccepted state, as well as edits by the same user immediately preceding it (only the last revision by another user would be accepted, so a sort of pending changes rollback), then remove the protection as soon as a new revision is accepted (when the user gets reverted for example). The new revision would thus appear at Special:PendingChanges along with unreviewed revisions from pending changes protected articles. They should also be tagged with a wording such as "deferred for review".

The pending changes block interface would be integrated in the block interface, and pending changes blocks logged with the block log. 'Moderators' would have block links like admins, but would have the 'pending changes block' option checked by default and grayed out (on the other hand, admins would have it unchecked by default), and possibly the option to disallow account creation for registered users only (enabled by default). There would also be a notification in the user contribs similar to the block notification, with another color to differentiate it (maybe yellowish).

If a pending changes blocked user edits an article, a notice similar to MediaWiki:Revreview-locked, but more prominent, would be shown but instead would read something like :"Note: Your edits are subject to review (help) for the following reason : <log for the pending changes block>." If the edit gets saved, and thus pending changes protection intermittently enabled, users neither autoconfirmed or confirmed who may edit the article in the meantime would be shown the standard MediaWiki:Revreview-locked with a generic log in details.

Since the pending changes block would no longer have any effect if the account becomes autoconfirmed, it may have to prevent autoconfirmation. Rate limits may be made stricter (for example, 4 edits per minute instead of 8).

The following limits would apply to pending changes blocks by 'moderators', but not by administrators :

IP ranges cannot be blocked
autoconfirmed or confirmed users cannot be blocked
maximum block duration is limited for IPs.

It should be discussed whether to extend the effect to all namespaces, as much as technically possible.

The edit filter already has the ability to block users, it wasn't implemented on the English Wikipedia because of too great a risk of false positives. The extension could be tweaked to support pending changes blocking.

Notes

^ Examples of typical patterns : Kaonalpha (contribs | filter log), Iphone repairs (contribs | filter log), Qwertybubbles (contribs | filter log), Gsjfe (contribs | filter log), Brazilfifa (contribs | filter log). These show the limits of the edit filter, which is repeatedly evaded, and of anti-vandalism bots, which restrain themselves to avoid false positives.
^ They are often eventually caught by a bot, Mr.Z-bot (talk · contribs), which reports them to AIV after several triggers of some specific filters, or a unique trigger of some others. See User:Mr.Z-bot/filters.js.
^ Example: Winedmoves (contribs | filter log), 174 vandalism edits to egg for half an hour
^ Examples : 82.215.225.196 (contribs | filter log), Lokolkok (contribs | filter log), 201.242.44.46 (contribs | filter log), 190.207.207.70 (contribs | filter log), Azbycx100 (contribs | filter log)
^ Example : last warning at 18:44, subsequent vandalism remains for one hour, blocked one hour after last edit.
^ From 189 (hist · log) : Special:Diff/634457313, Special:Diff/634455682, Special:Diff/634454854, Special:Diff/634455208, Special:Diff/634456024, Special:Diff/633671390
^ Some low-level userrights may also be granted, to be determined later.
^ To ensure a sufficient number of users in this new usergroup at the beginning of the implementation, candidatures should be accepted at least a week before implementation.
^ The users are warned before saving the edit, so one less warning is needed.