Wikipedia:PC2012/Monty845

In order to implement Pending Changes in an orderly fashion, and with as little drama as possible, we should adopt a time table that implements pending changes in a serious of phases.

During phases 1-3 admins should not unilaterally apply pending changes to an article that is not already protected. If during phases 2-3 there is a pressing need for protection pending the outcome of a discussion, semi-protection should be used.

Phase 1

Duration: 30 Days

Pending changes level 1 will be available for articles that are already under long term semi-protection. Articles that are currently semi-protected, and have been protected for at least the last 30 days, may be downgraded to level 1 pending changes protection. In no case should the pending changes protection extend for longer then the protection it is replacing.

Phase 2

Begins at the end of Phase 1

Duration: 60 days

In addition to eligibility under phase 1, articles may have pending changes level 1 applied as an outcome of a discussion at a community noticeboard. Eligible noticeboards are

WP:SPI

.

Phase 3

After Phase 2

Duration: At least 60 days and until consensus for additional implementation is reached

In addition to eligibility under phase 2, requests may be made to

WP:BLP

policy. Level 1 protection may be applied 48 hours after the request is made if there is no objection, or when consensus becomes clear, whichever is later. Notification should be made to the article talk page of the request for pending changes protection. Admins may, if consistent with regular semi-protection practice, apply semi-protection while the discussion is ongoing.

Followup RFC

60 days after Phase 3 begins, an RFC should be conducted to evaluate the the operation of pending changes level 1, decide if the process for applying it should be relaxed, and consider whether implementation of Pending changes level 2, and level 2 + semi-protection should begin.

Requesting the Permission

Requests for the Reviewer permission may be made at

policy, and have a functional understanding of copyright policy.

Removal of Permission

The reviewer permission may be unilaterally removed by an admin only if the reviewer is committing obvious vandalism. If the reviewer is making poor review decisions, they should first be counseled on what they should be doing differently, and if the problem is not resolved, reported to an administrative notice board for a consensus decision on removing the permission. Remember that reviewers cannot be expected to catch all edits that violate policy, they are only expected to catch obvious cases. Administrators can help by making sure that protection log entries clearly identify the reason for protection so reviewers will have a better idea of what to look out for.

Standards for Reviewing

When reviewing an edit:

• Look up the reason for protection. Pay particular attention to that reason when reviewing the pending edit.
• Is the edit obvious vandalism?
• Does the edit violate
  WP:BLP
  policy?
• Is there any reason to believe the edit may have been copied from somewhere?
• If there is not strong policy reason for disallowing the edit it should be approved. Approving and edit does not mean you like the change, or think that it helps the article, it only means there is no reason to disallow it. After allowing the edit, you are free to act as a regular editor to fix any problems with it, or even revert it. While allowing and then reverting is functionally identical to denying the pending edit, best practice is to seperate your action as a reviewer from your action as a regular editor, approve, then revert.