Wikipedia:PC2012/WaitingForConnection

When to apply pending changes
There are many plausible applications for pending changes. However, as human intervention is required, and significant delays in reviewing edits would be considered unacceptable, it needs to be used as conservatively and efficiently as possible. Pending changes should generally only be applied in one of the following circumstances:

Articles where a high proportion of recent edits are unconstructive
For articles which are subject to heavy vandalism, semi or full protection are usually the most effective tools. However, pending changes may be a better alternative if all of the following conditions are met:
 * A high proportion of edits that would be prevented by pending changes are vandalism.
 * Some recent edits were constructive, and would have been prevented by semi or full protection.
 * The article is not ordinarily edited on a daily basis.
 * The article does not have a significant history of edit-warring (reversion of vandalism should not be considered edit-warring).
 * The article should not have a template such as current on it (inappropriate implementations of such templates should be removed).

If an article meets these conditions, pending changes should be applied for no longer than the equivalent form of protection would have been applied in similar circumstances.

Egregious or consistent BLP violations, where other measures have proven ineffective or undesirable
When used effectively, pending changes can be a good way of protecting living people from harm, without preventing their articles from being updated in a timely fashion. For many articles, semi or full protection will be the most appropriate way of providing this protection.

Pending changes may be a better alternative to other forms of protection, on articles with a history of constructive contributions from editors who would be prevented from editing by full or semi protection. When weighing up whether or not pending changes would be the best tool to use in these circumstances, it's worth remembering that edits to articles with pending changes require manual review. This consideration is particularly relevant when applying pending changes for a long period of time. As a rule of thumb, the more regularly an article is ordinarily edited, the more convinced an admin should be that pending changes would be beneficial.

Low traffic BLP articles with a history of "stealth" vandalism
Subtle vandalism is often difficult to detect. While never welcome on any article, it can be particularly problematic on articles relating to living people, as it has the potential to cause harm to the subject. Long term pending changes should be considered for low traffic articles, which have suffered from undetected vandalism remaining in the article for an extended period of time.

When not to apply pending changes
Pending changes is a tool, intended to be used to the benefit of Wikipedia. As such, there are no circumstances under which pending changes may never be applied. However, its use in the following situations should be considered particularly carefully:

Current events
Consider whether it is realistic for reviewers to keep up with the pace of good-faith editing on the article. If they cannot keep pace, there is a considerable risk of vandalism being unwittingly approved, or of constructive contributions being accidentally rejected. Sometimes protection is not necessary for high-traffic pages – the high volume of editors may be able to remove vandalism quickly.

In response to edit wars
When an edit war breaks out, it is preferable that those involved stop editing and start discussing the problem. Consider whether pending changes would be the best way to achieve this, or whether an alternative form of protection would be better.

Controversial articles
Some editors fear that pending changes is, or could lead to, a form of censorship. That fear alone should not prevent the use of pending changes on any article for which it is well suited. In articles which have seen contentious editing or discussion, admins should be particularly confident that pending changes is the appropriate measure, and be prepared to explain their reasoning.

Where the primary contributors are against its use
Pending changes should only be applied if it is considered a bigger net positive than the alternative actions. Primary contributors to an article do not own it, and thus they should not assume that they can demand or veto the use of pending changes. However, a primary contributor's input may well be relevant in determining whether applying pending changes to an article will be a net benefit to Wikipedia.

The reviewer right
Disclaimer: this section is not intended as a coherent policy, merely as the principles I believe should be reflected in the eventual policy.

Granting

 * The method and standards for granting the reviewer right should be similar to those for rollback. The article feedback tool already equates the two permissions: you have access to the "monitor" tools if you hold either of those userrights.
 * To prevent gaming such as this approach to autoconfirmed status, the right should be granted manually.

Removal

 * The right must only ever be removed in response to a breach of reviewing policy.
 * In particular, the right should not be removed merely because the user has been blocked for something else.
 * It must never be acceptable for an admin to unilaterally remove the right from a user with whom they could be considered involved. If there is the slightest suggestion of involvement, the admin should start a discussion at WP:ANI.
 * If the right is inappropriately removed for reasons other than an obvious accident, the user who had the right removed would have the right to go to Arbcom. If Arbcom believe there is a chance that the admin acted inappropriately, they should accept the case.
 * Suitable sanctions for admins who have improperly removed might range from a simple admonishment, to a warning not to take future admin actions in relation to the other user, to a strict instruction not to remove the reviewer right from any user in future. Desysopping, as always, would be a theoretical last resort.