This is draft for a new Pending changes RFC. It is not an active proposal at this time, please do not add comments, endorsements, etc to this page. To discuss this idea please go to the talk page. Thanks.
Current status - Pending changes (level 1) was re-enabled on December 1st, 2012 by community consensus according to the 2012 RFC.
Logged in users – Logged in users (or users choosing to view pending changes) will see all edits as usual (unless the relevant setting has been changed in their preferences). All edits will still be added to the wiki and inappropriate edits must still be reverted or fixed as usual.
Logged out users – Until checked for obvious vandalism or superseded by appropriate editing, edits by new and unregistered users to "pending changes protected" pages will not be seen by users who are not logged in until approved. Edits by autoconfirmed users are approved automatically at level 1 when the prior revision is approved.
All users can edit Edits by unregistered or newly registered editors (and any subsequent edits by anyone) are hidden from readers who are not logged in until reviewed by a pending changes reviewer or administrator. Logged-in editors see all edits, whether accepted or not.
Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users.
Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive.
Scripts, stylesheets, and similar objects fundamental to operation of the site or that are in other editors' user spaces.
★ The table assumes a template editor also has extended confirmed privileges, which is almost always the case in practice. ♦ Administrators are only authorized to perform non-controversial edits without obtaining consensus on the talk page.
The purpose of this request for comment is to determine what the future of pending changes on the English Wikipedia will be. Due to problems with the previous discussions this request for comment will be restricted in its scope. All participants are asked to respect these limitations. A group of volunteer coordinators will be administrating this process, their task will be to keep the discussion focussed on the relevant issues and at the conclusion of this process to perform a close which reflects the community's desires.
Three positions are presented. They are designed to be mutually exclusive of one another. Therefore, each participant will choose one position only to endorse. If you change your mind and decide to switch positions, please strike out your previous endorsement but do not remove it entirely. Users may participate in the discussion section regardless of whether they have endorsed one of the three positions, but are asked not to make alternate proposals. Unregistered users may participate in the discussion section but may not endorse a position due to the risk of sockpuppetry.
Rationale
The official pending changes trial ended some time ago. For a period of time after the trial the tool was used without any clear policy regarding how it was to be used, or even if it was supposed to be used at all. This RFC aims to resolve these issues.
The policy presented below is based on the provisional policy used during the trial period, with modifications based on input at the previous RFC in 2011 that ended with the tool being temporarily taken out of service. That action was taken more or less to "clear the air" for further debate, but at the time interest in further discussion of these issues was on the decline and the matter has remained more or less unresolved for most of a year.
The format will be similar to other RFCs, however users are asked not to add additional positions. This may seem overly restrictive but it is necessary in order to arrive at a clear result. The three positions presented are designed to be mutually exclusive of one another, and to only address the very core issues involved as the smaller details will change over time anyway, as with all Wikipedia policies. Users may add a brief comment to their endorsement, but all threaded discussions should take place in the discussion section. Any overly long comments or replies to endorsements will be moved to the discussion section. Discussion not related to these core issues will be removed, in order to avoid expanding the scope of the discussion away from its intended purpose. Any discussion of the RFC itself should be posted to the talk page, not the discussion section.
A note on the "improve it first" position
The option of the tool itself (as opposed to the policy on its use) being improved or altered before considering re-deployment is deliberately absent from the positions. Pending changes is a specialized version of the more restrictive "flagged revision" system. It was developed by the Wikimedia Foundation specifically to be used on en.Wikipedia and is not used on other projects. For that reason the Foundation made it clear that it would not expend any more resources to develop pending changes until this project had determined that they would actually use it. Therefore the option of improving it first before deciding is not viable at this time.
Position #1
The negative aspects of pending changes outweigh the positive. Therefore the tool should not be used at all on the English Wikipedia.
users who endorse this position
Position #2
Despite the flaws of the trial period pending changes has proven to be a useful tool for combatting vandalism and other types of problematic edits. The tool should be used in accordance with the following draft policy. This policy is intended to reflect the community input in discussions. It is not set in stone and after use of the tool is resumed there may be unanticipated problems which can be corrected through normal consensus gathering processes.
Click "show" to view the draft policy
Pending changes protection (level 1)
When a page with Pending Changes (PC) protection is edited by an unregistered user or new user, that edit and all following edits by any user are not included in the article displayed to the general public (that is, for readers who are not logged in), until the edits are approved by someone with the "reviewer" user right. PC protection is intended to quash inappropriate editing while allowing good faith users to submit their edits for review.
Reviewers are users with a similar level of trust to rollbackers (including all administrators) and the right can be granted and removed by any administrator. Reviewer rights are granted upon request at Wikipedia:Requests for permissions. 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.
Pending changes should be used on pages where the disruption to good-faith editing caused by existing protection tools would be disproportionate to the problem the protection seeks to resolve. Suitable issues for pending changes protection include persistent:
Vandalism;
Re-insertion of rumor, error, and NPOV/V/OR violations;
Edit warring by large groups of unregistered users;
Disruption by users on highly variable IPs.
These standards are to be interpreted more liberally on biographies of living persons, or in any situation involving content related to living persons. As with other forms of protection, PC protection should not be used preemptively.
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.
users who endorse this position
Position #3
Pending changes should be kept in the long term, but the draft policy is insufficient and/or out of step with what the community wants from the tool. Pending changes should not be rejected entirely but should remain unused until such time as there is a more complete policy in place that has been explicitly approved by the community.
