Wikipedia:Pending changes

"WP:PC" redirects here. For establishing context in articles, see WP:PCR. For press coverage, see WP:PRESS. For the Pokémon Collaborative, see Wikipedia:WikiProject Pokémon. For the Page Curation tool, see WP:PAGCUR.

"WP:PEND" redirects here. For pending AFC submissions, see CAT:PEND.

For a list of articles with pending changes needing review, see Special:PendingChanges.

Pending changes protection is a tool used to suppress vandalism and certain other recurrent nuisances on Wikipedia while allowing a good-faith user to submit an edit for review. Intended for infrequently edited articles that are experiencing high levels of such troublesome edits from new or unregistered users, pending changes protection can be used as an alternative to semi-protection and full protection to allow unregistered and new users to edit pages, while keeping the edits hidden to most readers until they are accepted by a reviewer. There are relatively few articles on Wikipedia with this type of protection.

When a page under pending changes protection is edited by an unregistered (also called IP) editor or a new user, the edit is not directly visible to the majority of Wikipedia readers, until it is reviewed and accepted by an editor with the reviewer right.

Pending changes are visible in the page history, where they are marked as pending review. The latest accepted revision is displayed to the general public, while logged-in users see the latest revision of the page, with all changes applied. When editors who are not reviewers make changes to an article with unreviewed pending changes, their edits are also marked as pending and are not visible to most readers.

Both logged-in users and anonymous users who click the "edit this page" tab edit the latest version as usual. If there are pending changes awaiting review, there will be a dropdown box next to the article title, pointing to the pending changes.

Pending changes may be used to protect articles against persistent vandalism, violations of the biographies of living persons policy, and copyright violations.

Applying pending changes protection

Administrators may apply pending changes protection to pages that are subject to heavy and persistent vandalism, violations of the biographies of living persons policy, or insertion of content that violates copyright. Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred, nor should it be used to privilege registered users over unregistered users in content disputes. Pending changes protection should not be used on articles with a very high edit rate, even if they meet the aforementioned criteria. Instead semi-protection should be considered.

In addition, administrators may apply temporary pending changes protection on pages that are subject to significant but temporary vandalism or disruption (for example, due to media attention) when blocking individual users is not a feasible option. As with other forms of protection, the time frame of the protection should be proportional to the problem. Indefinite PC protection should only be used in cases of severe long-term disruption.

Like semi-protection, PC protection should never be used in genuine content disputes, where there is a risk of placing a particular group of editors at a disadvantage.

Editors without administrator privileges can request page protection if the above criteria are met. Removal of pending changes protection can be requested of any administrator, or at requests for unprotection.

Reviewing pending edits

The process of reviewing is intended as a quick check to ensure edits don't contain vandalism, violations of the policy on living people, copyright violations, or other obviously inappropriate content. Reviewers are users sufficiently experienced who are granted the ability to accept other users' edits. Reviewers have a similar level of trust to rollbackers; all administrators have the reviewer right. Potential reviewers should recognize vandalism, be familiar with basic content policies such as the policy on living people, and have a reasonable level of experience editing Wikipedia. Reading the reviewing guideline, where the reviewing process and expectations for a reviewer are detailed, is recommended.

Acceptance of an edit by a reviewer is not an endorsement of the correctness of the edit. It merely indicates that the edit has been checked for obvious problems as listed above.

Reviewer rights are granted upon request at Wikipedia:Requests for permissions. While any administrator has the technical ability to remove the reviewer permission, removal should occur only as the result of consensus from a discussion or when an editor requests the removal of their own permission. Discussion regarding removal of the reviewer permission should normally occur at the Administrators' noticeboard. Discussion with the involved editor and/or a request for a second opinion at the Pending changes talk page is recommended before formally requesting removal.

Reviewing of pending changes should be resolved within reasonable time limits (at most a few hours). Backlog management should be coordinated at a community level. The backlog can be viewed at Special:PendingChanges. As of January 2013, edits are rarely unreviewed for more than two to three hours and the backlog is frequently empty.

Effect of various protection levels

Wikipedia users, page protections, and page edits

	Unregistered, New	Autoconfirmed, Confirmed	Extended confirmed	Template editor	Pending changes reviewer	Administrator	Appropriate for*
No protection	can edit; changes go live** immediately; no acceptance required						The vast majority of pages
Pending changes level 1 protection	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
Extended confirmed protection	cannot edit		can edit; changes go live immediately; no acceptance required	can only edit if also Extended confirmed		can edit; changes go live immediately; no acceptance required	Specific topic areas authorized by the Arbitration Committee or persistent disruption that semi-protection has failed to stop
Pending changes level 2 protection	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:PCRFC
Pending changes level 2 with Semi-protection	cannot edit	can edit; changes will go live after being accepted by a reviewer
	Unregistered, New	Autoconfirmed, Confirmed	Extended Confirmed	Template Editor	Pending changes reviewer	Administrator	Appropriate for*
Template protection	cannot edit			can edit; changes go live immediately; no acceptance required	can only edit if also template editor	can edit; changes go live immediately; no acceptance required	High-risk templates and modules
Full protection	cannot edit						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 pending changes that are not yet reviewed, Administrators and Reviewers are prompted to review the pending changes before saving their edit.

Frequently asked questions

If an established user edits an article with unreviewed pending changes, is the new version automatically accepted?

No. If the user is a reviewer (that is, the user has been granted the "reviewer" permission), they will be prompted to review and accept any unreviewed pending changes. If the user is not a reviewer, the edit will also be marked as "pending review". (Reviewers can test this by unaccepting the current version of a page under pending changes and then trying to edit.) An exception to this is when a user reverts a pending edit to the latest accepted revision: in this case the revert is automatically accepted.

What happens if several IP edits to an article under pending changes result in a null edit? (For example, an IP makes an edit, then another IP undoes it.)

If they were all made by a single IP, the new version is automatically accepted. If different users edited, the new version is not accepted (to prevent potential abuse).

On which kinds of pages can pending changes be used?

At first, it was determined by consensus that pending changes could be used only on articles, subject to the protection policy, and on test pages in project space. A later request for comment found it permissible to use pending changes beyond articles; however, it is restricted by the software to the main and project namespaces, and no request to allow other namespaces was made. It is not technically possible for talk pages to be placed on pending changes.

Wasn't pending changes protection dropped?

Yes and no. Pending changes protection was deployed on a trial basis in 2010. In 2011, pending changes protection was dropped as a mechanism for protecting pages, until a consensus agreement on its deployment was reached. There have been a series of discussions on using the feature and it was put back into service on December 1, 2012. Since then only pending changes level 1, affecting the edits of new and unregistered users, is being used. The use of level 2 may be proposed for truly exceptional cases, but is rarely accepted.

How can you tell if a page has pending changes protection?

Protected pages are normally marked with a small white-colored or orange-colored padlock symbol in the top corner depending on its level of protection. Also, there will be a drop-down box next to the article title, pointing to the pending changes, if there are any.

Timeline

See also: Template:Pending changes discussions

Below is a list of past discussions and polls relating to the Pending Changes feature:

• March 2009: First poll 4 to 1 approving original trial
• May 2010: RFC on some pre-trial issues
• June 2010 – August 2010: Pending changes trial
• August 2010: Straw poll 2 to 1 in favor of continuing PC in some form
• September 2010: Straw poll on interim usage
• September 2010 – May 2011: Continuation of pending changes without clear mandate
• February 2011 – May 2011: PC RfC 2011 Ended the original PC trial.
• March 2012 – June 2012: PC RfC 2012 established consensus to enable PC before the end of 2012.
  • September 2012: WP:PC2012/RfC 1 discussed whether to use Level 2 pending changes.
  • October 2012: WP:PC2012/RfC 2 discussed when to apply pending changes, the criteria for rejecting edits, and various ideas for reducing backlog.
  • November 2012: WP:PC2012/RfC 3 discussed deployment and usage of the pending changes feature.
• December 2012 – : Pending changes re-enabled on a permanent basis
• May 2013: PC RfC 2013 is closed as requiring further discussion for implementation. It reopened the question of whether to use Level 2 pending changes.
• January 2014: PC RFC 2014 opened to determine if there is consensus on how to implement pending changes level 2. By the time it was closed in June, there was no longer a consensus to use pending changes level 2 at all, but if and when such a consensus does develop, there is some consensus on when to apply it.
• October 2016 DC RFC 2016 opened to determine if the edit filter, bots and ORES should be allowed to defer suspicious edits for review using deferred changes. The RfC passed in its entirety.
• November 2016 PC RFC 2016 #1 opened to propose lowering the auto-accept threshold for PC2 and establish usage criteria.
• November 2016 PC RFC 2016 #2 opened to propose several things, including implementing pending changes for all articles, implementing it for certain types of articles (including good articles, featured articles, vital articles, and biography of living persons articles), auto-granting the reviewer right for those meeting certain criteria, and creating a semi-automated tool for reviewing. The portion for creating a semi-automated review tool was withdrawn from the RfC as not needing consensus, and the RfC was later snow-closed with consensus against all remaining proposed changes.

See also

• Wikipedia:Flagged protection and patrolled revisions, the original trial proposal.
• Wikipedia:Deferred changes, proposal to allow bots, the edit filter, and/or ORES to defer suspect edits for review (originally Wikipedia:Deferred revisions).
• Wikipedia:Patrolled revisions, a request for a passive reviewing system, part of the original proposal.
• Wikipedia:Pending changes blocks, proposal for a form of user specific editing restriction that is to a classic block what pending changes protection is to classic protection.
• Wikipedia:PC2012, an overview of the 2012 implementation of pending changes.
• Wikipedia:Pending changes caveats, an essay on why the use of pending changes was severely limited.

Interface

• Special:PendingChanges, pages with pending edits.
• Special:StablePages, pages under pending changes.
• Special:ValidationStatistics, various statistics pertaining to the Pending Changes feature.
• Template:Pending Changes backlog, a display of the current backlog, which can be added to user pages.

Logs

• Special:Log/stable, actions to enable or disable pending changes.
• Special:AdvancedReviewLog, actions to review edits.