Wikipedia:Pending changes

(Redirected from Help:Pending changes)

Pending changes protection is a tool used to prevent vandalism and certain other recurrent nuisances on Wikipedia from being viewable to the general public[1] while allowing good-faith users to make constructive changes. This protection level can be used as an alternative to semi-protection or full protection, which fully restricts and disallow these users from being able to make any changes.

Pending change protection is intended for – and best used on – articles and pages that are experiencing a sudden high level of disruptive edits from new or unregistered users, but are rarely or infrequently edited otherwise. It may be used to protect articles against persistent vandalism, violations of the biographies of living persons policy, and copyright violations.

Any pages currently under pending changes protection that are edited by unregistered users or new user accounts are saved, but are marked as pending changes that are awaiting review. Articles with any pending changes will display the most recent accepted revision (or stable change) to the general public, while logged-in users will see the most recent pending change. When a pending change is reviewed and accepted by a pending changes reviewer (also called a "reviewer") or an administrator, it becomes an accepted revision and hence becomes viewable to the general public just like a normal change would.

Pending changes are visible in the page history, where they are marked as "pending review". When editors who are not reviewers make changes to an article with pending changes, their edits are also saved as a pending change and hence are not visible to the general public until they are reviewed. Unregistered and logged-in users who click the "edit this page" tab will be presented with the latest revision to modify as usual. If there are pending changes awaiting review, there will be a drop-down box next to the article title pointing to the pending changes.

While pending changes protection can be used as a first resort when handling disruptive edits to an article or page, there are relatively few articles on Wikipedia with this type of protection.

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 the insertion of content that violates Wikipedia's policy on copyrights.

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 becomes an unfeasible option. As with other forms of protection, the expiration of the protection should be set proportional to the problem at-hand, as well as proportional to the the likelihood that a high-level of disruptive edit attempts will have passed. Applying pending changes protection with an indefinite duration should only be used in cases of severe and long-term disruption.

When considering applying pending changes protection to an article or page, the following situations should be considered before doing so:

  • Just like other protection levels, 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 during content disputes.
  • Like semi-protection, pending changes protection should never be used in genuine content disputes if there is a risk of placing a particular group of editors at a disadvantage over others. Full protection should be considered in these situations instead.
  • Pending changes protection should not be used on articles with very high edit rates, even if they meet the aforementioned criteria. Semi-protection should be considered instead.

Editors without administrator privileges can request page protection if the above criteria are met. The removal of pending changes protection from a page can be performed by any administrator, or requested at requests for unprotection.

Reviewing pending changes

The process of reviewing pending changes is intended as a quick check to verify and ensure that they don't contain obviously inappropriate content, including:

Pending changes reviewers are sufficiently experienced users who are granted the ability to review and accept pending changes, which converts them into accepted revisions. Reviewers have a similar level of trust as users with the rollback permissions, and are integrated as part of the administrator toolset. Potential reviewers should be able to recognize vandalism and contrast them from edits that are not vandalism, be familiar with basic content policies such as the policy on the biographies of living people, and have a reasonable level of experience with editing Wikipedia. Proficiency with the reviewing guideline, where the reviewing process and the expectations for pending changes reviewers are detailed, is highly recommended.

Reviewers and administrators will see a yellow watchlist banner on their watchlist whenever there is a pending edit needing review. If a reviewer or administrator wishes to disable it, they can paste #mw-fr-watchlist-pending-notice {display: none} to their common.css page.

The review and acceptance of a pending change by a reviewer is not to be considered an endorsement; it merely indicates that the edit has been checked for obvious problems such as those listed above.

The pending changes reviewer rights are granted upon request at the Wikipedia requests for permissions page. While any administrator has the technical ability to revoke or remove the pending changes reviewer permission from a user account, this removal should occur only as the result of consensus from a discussion, or when an editor requests the removal of the permissions from their own account. Any discussions primarily regarding the removal of the reviewer permission should normally occur on the Administrators' noticeboard. A discussion with the involved editor and/or a request for a second opinion at the Pending changes talk page is recommended before starting a discussion to formally request a revocation or removal of the permissions from a user.

Reviewing of pending changes should be resolved within reasonable time limits (at most a few hours). The pending changes backlog can be viewed at Special:PendingChanges, and backlog management should be coordinated at a community level. As of February 2025, pending changes are rarely left unreviewed for longer than 1-2 days, and the pending changes backlog is usually empty.

Pending changes adds highlighting that is lost when disabled

In the edit history, accepted revisions are highlighted in order to improve the list's readability. Additionally, visible tags are applied to indicate why particular edits were accepted ("automatically accepted"/"accepted by [Username]"). This highlighting is still permanently lost for past changes on a given page whenever the pending changes setting is disabled or allowed to expire.[2] Because of this, when pending changes are enabled on a page again later, the highlighting will only be applied to newer changes that were made afterwards. Therefore, it is generally a good choice to leave pending changes enabled when other protection levels are applied to the same page.[3]

Effect of various protection levels

Protection levels and their impact on various Wikipedia user groups[α]
F Protection level New or unregistered editors Confirmed Extended confirmed Template editor[β] Admin Interface admin[γ] Appropriate for...
Editing
None Normal editing The vast majority of pages.[δ]
 Pending changes Can edit
Changes are only visible to logged-in users until reviewed by a pending changes reviewer or administrator.[ε]
Can edit
Changes are visible to everyone if there aren't any unreviewed pending changes. Otherwise, they are only visible to logged-in users until reviewed by a pending changes reviewer or administrator.[ε]
Can edit
If there are any unreviewed pending changes, the administrators will be required to review them before they can edit the page.[ε]
Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users.
  Semi Cannot edit Normal editing Pages that have been persistently vandalized by anonymous and newly registered users. Some highly visible templates and modules.
 Extended confirmed Cannot edit Can edit[ζ] Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive.
  Template Cannot edit Normal editing High-risk or very-frequently used templates and modules. Some high-risk pages outside of template space.
  Full Cannot edit Can edit[η] Pages with persistent disruption from extended confirmed accounts.
  Office Cannot edit Can edit[θ] Pages that the Foundation has determined to be exceptionally sensitive.
  Cascade[ι] Cannot edit Normal editing Particularly visible pages, such as the Main Page, to prevent vandalism to pages that are transcluded onto them.
  Interface[κ] Cannot edit Normal editing Scripts, stylesheets, and similar objects fundamental to operation of the site or that are in other editors' user spaces.
Creating pages
None Cannot create[λ][μ] Can create The vast majority of page titles.[δ]
  Create Cannot create[μ] Adjustable
Protection may be applied to neither, either, or both groups.
Can create Pages that have been repeatedly and problematically re-created. This form of protection is often called "salting".
Moving pages
None Cannot move Can move The vast majority of pages.[δ]
  Move Cannot move Adjustable
Protection may be applied to neither, either, or both groups.
Can move Pages that have been the subject of move wars.[ν]
Uploading files
None Cannot upload Can upload The vast majority of file names.[δ]
  Upload Cannot upload Adjustable
Protection may be applied to neither, either, or both groups
Can upload Files that have been repeatedly uploaded after deletion

Notes:

  1. ^ Details about historical protection levels and user groups no longer in use are available at Wikipedia:Protection policy § Retired protections.
  2. ^ This table assumes that template editors are also extended confirmed, which is almost always the case for non-bot accounts.
  3. ^ This table assumes that an interface administrator is also a "regular" administrator, which is almost always the case in practice.
  4. ^ a b c d This is the default protection level.
  5. ^ a b c However, if any editors (including unregistered editors) revert all unreviewed pending changes back to the latest accepted version, that revision is automatically accepted and pending changes reviewers and administrators aren't prompted or notified.
  6. ^ typically with restrictions as spelled out in edit notices
  7. ^ Only noncontroversial changes or requested changes following an achieved consensus should be performed.
  8. ^ Only with the approval from the Wikimedia Foundation.
  9. ^ Cascade protection extends to all pages that are transcluded onto the protected page, unless the transcluded page is at the same protection level or higher. Cascade protection can only be applied to pages that are fully or office-protected because otherwise it creates a workflow flaw.
  10. ^ The interface protection level is automatically set by the MediaWiki software to a specific set of pages, such as pages in the MediaWiki namespace, system-wide CSS and JavaScript pages, and personal CSS and JavaScript pages of other users. It is not a protection level that an administrator can manually apply to any page, nor is it a protection level that can be modified on pages currently under interface protection. Because of this, administrators also cannot cascade-protect pages that are Interface-protected.
  11. ^ This has been in effect for unregistered users since 5 December 2005. The restriction was extended to newly registered users on a six month trial basis starting on 14 September 2017. The extension became permanent on 18 April 2018.
  12. ^ a b Under the default no protection, unregistered and newly registered users can create talk pages in all namespaces and draft articles in the Draft namespace. For these namespaces, it would therefore be possible for the creation protection to only apply to unregistered and newly registered users
  13. ^ Any page that is edit protected is usually also move protected at the same level.

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 pending changes reviewer, 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.) However, if any editors (including unregistered editors) revert all unreviewed pending changes back to the latest accepted version, that revision is automatically accepted and pending changes reviewers and administrators aren't prompted or notified.
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. There has been consensus to drop pending changes level 2, and as a result only level 1 is now used.
How can you tell if a page has pending changes protection?
Protected pages are normally marked with a small 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.
How can I see the details of review?
On a page with pending page protection, hover the mouse over the arrow in the box
  Accepted (latest)  
(for logged in users) or
   
for logged out users. You'll see a popup with text:
This is the latest accepted revision, reviewed on 25 August 2025.
. The link "reviewed" leads to the log of the review.

Timeline

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.
  • January 2017: RFC to remove pending changes level 2, after all RFCs on the subject failed to achieve consensus for using it.
  • November 2017: The proposal for implementing deferred changes was marked as dormant, following a lack of work on its technical implementation.

See also

Interface

Logs

Footnotes

  1. ^ On this page, the term "general public" refers to readers who are not logged into an account.
  2. ^ "⚓ T189422 Disabling pending changes removes visual highlighting and labelling of reverts and accepts". phabricator.wikimedia.org. Retrieved 26 April 2019.
  3. ^ There are no edit protection levels that exist that are at a weaker level than pending changes protection. Therefore, it will not cause any kind of interference when any other protection levels are applied.