Initial Rollout
editIn 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
edit- 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
edit- 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:AN, WP:AN/I, WP:BLP/N and WP:SPI.
Phase 3
edit- 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:RFPP to request protection of articles covered by 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
edit60 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.
Reviewing
editRequesting the Permission
editRequests for the Reviewer permission may be made at WP:PERM or to an individual administrator. Reviewers should generally have at least 500 edits, have experience dealing with Vandalism, WP:BLP policy, and have a functional understanding of copyright policy.
Removal of Permission
editThe 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
editWhen 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.