Wikipedia:PC2012/RfC 2

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

This is the second informal Request for Comment on various ideas for changes to the provisional policy on Pending Changes (PC).

It includes questions on when to apply Pending Changes, criteria for rejecting edits, whether to automatically accept old changes or reverts, and whether to specify in the policy how frequently it should be used in the early days. 12:00, 01 October 2012 (UTC)

Procedural note: Because several questions beyond the scope of this RfC remain to be settled (preferably before PC use formally begins on December 1st), an additional RfC may be required. After a minimum discussion period of one week, this RfC may closed. The mechanism for deciding when to close the RfC is a simple majority vote.

"...it is clear that though the community supports the adoption of Pending Changes, the community is also well aware that both the Pending Changes Trial of 2010 and the draft policy as presented in this RfC suffer(ed) from weaknesses. Therefore...the community should dedicate itself to determining the implementation of Pending Changes that it wishes to be turned on. Many opinions have been presented in the various areas of this RfC as to what works and doesn’t work in Pending Changes as implemented/proposed; the community must now focus its energy on optimizing the implementation of Pending Changes that it wishes to see go live."

— Closing admins of the 2012 Pending changes RfC

Current provisional 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.

When to apply Pending Changes (PC)

The provisional policy currently says,

"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."

May PC be applied to pages to protect against vandalism?

Yes (vandalism)

1. Obviously. This was, is, and should continue to be its primary purpose. Beeblebrox (talk) 19:17, 30 September 2012 (UTC)
2. Yes. I see PC as being primarily a tool that gives us a time window in which to revert obvious vandalism before it goes live and embarrasses us. ~Adjwilley (talk) 19:27, 30 September 2012 (UTC)
3. Of course. WhatamIdoing (talk) 20:07, 30 September 2012 (UTC)
4. Yes. While I am opposed to PC in general, I believe its problems can be fixed, so that it can be implemented to stop vandals. RedSoxFan2434 (talk) 21:25, 30 September 2012 (UTC)
5. Yes. PC would be a valuable addition to the anti-vandalism toolkit. It needn't be applied in every case, any more than we apply blocks or semiprotection &c in every case, but it would be very helpful to have this tool. bobrayner (talk) 22:24, 30 September 2012 (UTC)
6. Yes of course. There are many heavily watched pages that are subject to lots of vandalism, and as well as making sure that readers didn't see the vandalism this would ensure that when there is a good edit to that page the first person to check it can mark it as such - so others watchers don't need to waste their time. And for less well watched pages this should greatly reduce the amount of vandalism that sneaks into the pedia via the occasional gaps at recent changes patrol. ϢereSpielChequers 07:41, 1 October 2012 (UTC)
7. This is the situation in which it would be most useful by a large margin. Hut 8.5 11:52, 1 October 2012 (UTC)
8. Obviously. A fluffernutter is a sandwich! (talk) 13:27, 1 October 2012 (UTC)
9. Doi. If we weren't able to agree on this much it wouldn't have gotten this far.--The Devil's Advocate (talk) 18:00, 1 October 2012 (UTC)
10. In cases where there are many positive IP edits in addition to vandalistic ones, this seems like a good choice. elektrikSHOOS (talk) 19:28, 1 October 2012 (UTC)
11. Close per per WP:SNOW - Of course! Isn't that the main point of page protection? Michaelzeng7 (talk) 21:53, 1 October 2012 (UTC)
12. No brainer.—cyberpower ^Chat_Absent 18:59, 2 October 2012 (UTC)
13. Isn't this the raison d'etre of PC? Alanl (talk) 19:13, 2 October 2012 (UTC)
14. Anthonyhcole (talk) 03:26, 3 October 2012 (UTC)
15. Kilopi (talk) 11:04, 3 October 2012 (UTC)
16. Yes, but only if a more severe form of protection would be used if Pending Changes was not available, i.e. only if such vandalism would result in semi- or full-protection today. davidwr/(talk)/(contribs)/(e-mail) 22:32, 3 October 2012 (UTC)
17. Yes, if it is used when there is an obvious need for it, and when other forms of protection would not be satisfactory. Thegreatgrabber (talk) 04:06, 4 October 2012 (UTC)
18. Of course! --v/r Electric Catfish (talk) 15:37, 4 October 2012 (UTC)
19. A rather obvious function of PC. CT Cooper · talk 10:50, 5 October 2012 (UTC)
20. Only where semi-protection would normally be used. Davewild (talk) 11:16, 5 October 2012 (UTC)
21. Is the Pope a Catholic? Of course. —Tom Morris (talk) 12:26, 5 October 2012 (UTC)
22. — Dmitrij D. Czarkoff (talk•track) 00:29, 7 October 2012 (UTC)
23. Replacing semi-protection against vandalism is the primary use case where PC is superior. Think of opening up Barack Obama or Dog one day, by using PC instead of indefinite semi! Steven Walling • talk 02:30, 7 October 2012 (UTC)
24. Yes. — ΛΧΣ21™ 03:25, 10 October 2012 (UTC)
25. Slam dunk support. Magog the Ogre (t • c) 00:58, 11 October 2012 (UTC)
26. --JN466 08:35, 11 October 2012 (UTC)
27. Yes. --xensyria^T 21:22, 11 October 2012 (UTC)
28. May or may not be possible to be applied to pages to protect against vandalism. --EleoTager (talk) 16:21, 15 October 2012 (UTC)
29. Of course. One of its primary purposes. Identifying vandalism (and pages that are frequently vandalised) is also very objective so PC is not an issue here.--Mark91it's my world 21:20, 15 October 2012 (UTC)
30. This would make the vandalism less visible (and therefore more discouraged) while allowing good-faith anons would be able to do good edits. עוד מישהו Od Mishehu 15:18, 17 October 2012 (UTC)
31. That's what it is for. Carrite (talk) 21:10, 17 October 2012 (UTC)
32. Without this, PC is completely useless. As one of the most active admins at WP:RPP, I come across plenty of times where semi-protection for a short period would be ineffective because vandalim is sporadic, but where it doesn't get picked up immediately; the subtle vandalism. There's other circumstances where PC would be effective against accounts that have been rushed autocoonfirmed specifically to vandalise a semi-protected page. GedUK  11:21, 19 October 2012 (UTC)

No (vandalism)

1. Without Pending Changes, users can spot and revert vandalism immediately, then make their own live changes. Or make their own live changes, notice the vandalism while they're double-checking their submitted page, and fix it. This system puts vandals in charge of the regular editors rather than the other way around - because many editors will be put off by the inability to make live changes and collaborate, it allows a persistent vandal to in fact stop most editing of a page for as long as he can keep changing his IP to evade any blocks, which in case of high-profile, timely pages featured on the Main Page or relevant to recent news stories will actually greatly increase the vandals' power. Wnt (talk) 03:54, 1 October 2012 (UTC)
2. Conscience !vote (with qualification). I think PC will be a greater liability than an asset to the project. The problems it poses are manifold, both in theory and in practice, and the harm that may come from its implementation, even with its worst attributes ameliorated, has the potential to be permanent. Nevertheless, implementation is going forward, so let's make the best of it. PC should not be applied to deter vandalism unless certain conditions are met: (1) semi-protection is unfeasible because of a significant number of recent, constructive IP edits, and the page (2) has few watchers and (3) is currently beset with repeated instances of vandalism from multiple unregistered or non-autoconfirmed users. Rivertorch (talk) 08:57, 2 October 2012 (UTC)

   As with Rivertourch. I consider it useless altogether, but here is where it is least useless. As with him, I can think of a few special situations where it might work. But as with Wnt, I can also think of cases where it would be harmful. DGG ( talk ) 12:30, 10 October 2012 (UTC)

May PC be applied to pages to protect against violations of one or more core content policies (WP:NPOV, WP:V, WP:NOR)?

Yes (NPOV/V/OR)

1. Yes, for truly serious problems, including WP:HOAXes and rumors (both WP:V/WP:NOR violations). I'd also consider it for NPOV disputes, e.g., if someone persistently tries to re-write medical articles to oppose mainstream scientific consensus and support quackery (Mercury in vaccines, anyone?). I don't believe this should be the typical response, but it should be allowed when we have someone who is obviously working against a valid, established consensus to violate our core content policies. WhatamIdoing (talk) 20:09, 30 September 2012 (UTC)
2. Yes, for serious problems, usually where the first line of defence (ie. semiprotection or blocking one or two problematic editors) has failed. It would not be appropriate to use it for routine disputes but we are capable of using common sense... bobrayner (talk) 22:26, 30 September 2012 (UTC)
3. Yes, for very serious problems, though it should be very clear that PC (like any protection scheme on the site) is not an endorsement of the current revision, nor is it a tool to end discussion and enforce a version that's against consensus. elektrikSHOOS (talk) 19:29, 1 October 2012 (UTC)
4. Taking into consideration the below opposes, these policies are subjective and this should only be enforced if violating the policies is a massive disruption to the project. It should be considered that parties that are involved in the dispute have reviewer rights or not and whether protection will stop it or turn it into a one sided argument. This method is obviously useless if they already have the ability to edit through protection. It can be used but the administrators trying to calm the dispute should all of this into consideration before deciding this is an appropriate action to take. PC2 would be more effective in this case but since it's not being used, I have nothing more to say.—cyberpower ^Chat_Absent 19:06, 2 October 2012 (UTC)
5. For subtler violations, this won't be the best remedy, but should be an available option in cases where the reviewers will almost unanimously agree that the edit is a serious enough violation to warrant immediate reversion. Kilopi (talk) 11:04, 3 October 2012 (UTC)
6. Yes, but it should be used sparingly in this situation, as not to burden the reviewers. --v/r Electric Catfish (talk) 15:38, 4 October 2012 (UTC)
7. Per WhatamIdoing. JN466 08:34, 11 October 2012 (UTC)

No (NPOV/V/OR)

1. NPOV and OR are often subjective, and using PC to protect against these could very well give one "side" an unfair advantage. NPOV/OR/V issues should be dealt with as what they are: content disputes. ~Adjwilley (talk) 19:30, 30 September 2012 (UTC)
2. I would support adding PC to the toolbox for dealing with articles subject to community sanctions where NPOV/V/OR is a problem, but not for dealing with regular NPOV/V/OR problems. Standard BRD response is more then adequate for most articles with this sort of problem. Monty₈₄₅ 19:42, 30 September 2012 (UTC)
3. PC should not be used for issues of verifiability or seemingly original research. As Adjwilley said, whether or not something is OR or is verifiable is often debatable, and should be handled as a content dispute. The handling of content disputes that we currently have does not need to be limited by PC. As for NPOV issues, that depends on how obviously opinionated it is: there is no fine line between NPOV and Vandalism, but an overlap between the two, so anything that is Vandalism should be protected by PC. Other NPOV, if its non-neutrality is debatable, should not be protected by PC. RedSoxFan2434 (talk) 21:37, 30 September 2012 (UTC)
4. Per Adjwilley and RedSoxFan, these are not issues that will be amicably solved by all-or-nothing rejections where your edits drop silently into the bit bucket rather than being hashed out on the talk page. Wnt (talk) 03:56, 1 October 2012 (UTC)
5. Agree with Adjwilley and RedSoxFan. These are points for discussion, not for arbitrary assessment and dispensation by an individual reviewer. Risker (talk) 05:36, 1 October 2012 (UTC)
6. Agreed with the above, whether or not something is a violation of these policies is very much debatable and not something that should be decided by individual reviewers. In any case if the nature of the violation is not obvious to a previously uninvolved editor then PC won't even succeed in keeping these edits out. Hut 8.5 11:52, 1 October 2012 (UTC)
7. No, but the severity of the "no" depends on circumstances. In a perfect world, violations of these policies would be unambiguous and enforceable by a single admin. In reality, they're often contentious. That means that a single admin probably ought not have the ability to impose PC because they perceive NPOV, etc violations. However, at a community level, PC could still be a useful tool for this. I would be ok with PC being deployed for policy violations following discussion and consensus by multiple users that these violations really are taking place and cannot be halted by other means. But I remain not-ok with a single admin being allowed to deploy PC in a circumstance like this. A fluffernutter is a sandwich! (talk) 13:43, 1 October 2012 (UTC)
8. I would support it for very severe violations, but the wording above seems too broad.--The Devil's Advocate (talk) 18:00, 1 October 2012 (UTC)
9. These types of conflicts can only be settled by discussion. PC is (perhaps intentionally, perhaps not) designed to circumvent discussion by creating a delay between when a "bad" edit is made and when the maker of the "bad" edit becomes aware that the edit was rejected. In other words, PC stifles discussion. Sven Manguard Wha? 06:11, 2 October 2012 (UTC)
10. While experienced editors usually can correctly identify blatant core-content policy violations, we all make mistakes from time to time. Add to that the uncertainty that the reviewer flag will be available only to experienced editors, and you have a recipe for inadvertently thwarting the constructive edits of IPs and newbies—and doing so in a way that lacks the transparency of the edit request process on semi'd pages. That is unacceptable. It's also worth noting that these policies frequently lend themselves to nuanced interpretations, and sometimes the newbie is right and the experienced editor is wrong. On pages subject to persistent policy violations of this type, it's best to keep a level playing field and deal with disruptive editors one by one instead of condemning an entire class of editors to second-class status. Rivertorch (talk) 09:21, 2 October 2012 (UTC)
11. Too subjective - such disputes should be resolved through discussion where possible. CT Cooper · talk 10:54, 5 October 2012 (UTC)
12. Davewild (talk) 11:16, 5 October 2012 (UTC)
13. No. The line between violation of core policies and WP:INCOMPLETE is too vague to allow such usage of PC, whatever effective it could turn out. Unlike permanent semi-protection of main namespace this change will indeed impact Wikipedia badly pretty reliably. — Dmitrij D. Czarkoff (talk•track) 00:39, 7 October 2012 (UTC)
14. Waaay too subjective. Steven Walling • talk 02:28, 7 October 2012 (UTC)
15. The actual problems is applying them are much too subjective. NPOV is particular normally implies a complicated content discussions, nit simple ation. DGG ( talk ) 12:27, 10 October 2012 (UTC)
16. No, this leaves the system too open to abuse. --xensyria^T 21:22, 11 October 2012 (UTC)
17. No. This is much too broad a range of possibilities, for problems which very often are fixable. And it is quite routine for people to claim these things about whatever edit they disagree with. DGG ( talk ) 01:17, 15 October 2012 (UTC)
18. Is that even possible? I would use other things. --EleoTager (talk) 16:21, 15 October 2012 (UTC)
19. Strongly no. This PC seems to be heading down a slippery slope turning wikipedia into a form of moderated or editorially controlled encyclopedia- it is one thing to use it to block unambiguous vandalism, but quite another to have changes only allowed under the judgement of an editor. Remember that most contributions to wikipedia are by unregistered IPs and it won't take much to discourage such participation (incidentally, I note that most comments here are by registered editors-- IP editors seem under-represented). 121.45.215.186 (talk)
20. Current procedures are sufficient. Carrite (talk) 21:11, 17 October 2012 (UTC)
21. No I don't think so. As others have said, current procedures work reasonably well, and I'm struggling to see how PC would help. If anything it's more likely to enflame a situation where reviewers are approving some edits when consensus isn't clear. GedUK  11:23, 19 October 2012 (UTC)

May PC be applied to pages to protect against abusive IP sock puppetry?

Yes (abusive sock puppetry)

1. Yes, but only after alternative methods for dealing with the socking have been tried, including at least a few weeks of semi-protection. PC should be used in this context only for very persistent and long term sock abuse. Monty₈₄₅ 19:49, 30 September 2012 (UTC)
2. Yes, I believe this should be permitted in some instances. Usually, however, I suspect that semi-protection will be more practical. The situations I have in mind involve pages that have some good-faith IP traffic that we want to encourage, and occasional, easy-to-spot abuse. We don't really want to deploy semi-protection for a year, just because someone spends a few days each month adding "That is so gay" to a page. WhatamIdoing (talk) 20:02, 30 September 2012 (UTC)
3. Yes, but only if an editor previously unfamiliar with the sockmaster can see that their edits are blatantly disruptive. Otherwise they may be accepted by an unwary reviewer and the tool is useless. I remember during the trial that one article which was the target of a long-term sockmaster was put under PC. While the sockmaster's edits were not approved by reviewers, they were denied on verifiability grounds rather than the fact that the edit was being made by a sock. Hut 8.5 11:52, 1 October 2012 (UTC)
4. Depends on the circumstances as noted above.--The Devil's Advocate (talk) 18:00, 1 October 2012 (UTC)
5. Yes, per the reasons labeled above. Hut raises a valid point, as does Monty845. elektrikSHOOS (talk) 19:31, 1 October 2012 (UTC)
6. Yes only if socks can't be dealt with any other way.—cyberpower ^Chat_Absent 19:08, 2 October 2012 (UTC)
7. Yes, but only in obvious cases of WP: DUCK. --v/r Electric Catfish (talk) 15:40, 4 October 2012 (UTC)
8. Simple answer: suck it and see. Pending changes is a tool, just like semi-protection or full protection is a tool. In the cases of long term abuse, it might be sensible to apply pending changes indefinitely as an alternative to semi-protection to prevent sockpuppets who come back on a regular basis to vandalise articles. Because the relative cost of pending changes to good-faith editors is lower than the cost of semi-protection, being able to apply it to prevent abusive edits from long-term abusers/sockers seems like a reasonable plan. —Tom Morris (talk) 12:25, 5 October 2012 (UTC)
9. per Tom. --JN466 08:33, 11 October 2012 (UTC)
10. Yes, after the only after alternative methods for dealing with the socking have been tried. --EleoTager (talk) 16:21, 15 October 2012 (UTC)
11. Yes. Whilst semi-protection is usually perfectly effective where IPs are being used as socks, it is ineffective against confirmed accounts created and confirmed (through 'good' edits to other pages) specifically for block evasion. PC would be a better tool in these circumstances. GedUK  11:25, 19 October 2012 (UTC)

No (abusive sock puppetry)

1. Semi-protection is a better tool for abusive sock-puppetry. PC would still allow the IP to edit, and their edits would be disruptive to the normal editing process. An unreviewed pending change prevents subsequent edits (even by autoconfirmed users) from going live until a Reviewer comes along to sort things out (accept the good edits, reject the bad). Things would get messy really fast once the socks learn to game the system. ~Adjwilley (talk) 19:39, 30 September 2012 (UTC)
2. Per adjwilley (actually I was predicting something about the same thing in my answer above) Wnt (talk) 03:58, 1 October 2012 (UTC)
3. As I understand it, nothing is recorded if a revision is rejected. That will make it much harder to actually track the socks, which will make fighting sockpuppetry very hard. Sven Manguard Wha? 06:21, 2 October 2012 (UTC)
4. The way PC works (or doesn't work, as the case may be), it seems as if persistent socks would have the ability to be more disruptive on PC-enabled articles than they would on unprotected articles because they could overwhelm the reviewing system by flooding PC's slow, shaky interface with pending edits needing to be reviewed. If we must have PC, let it be applied to protect against certain edits, not certain editors. Rivertorch (talk) 09:33, 2 October 2012 (UTC)
5. Sockpuppet edits won't generally be identifiable as such in isolation. If sockpuppets are being used to vandalize or clearly violate policy, then PC can be applied under that reason, but it won't work if socking is the only reason to reject. Kilopi (talk) 11:04, 3 October 2012 (UTC)
6. It should not be prohibited but Pending Changes may not be the best way to handle a particular case of sockpuppetry. I think we can trust administrators to choose between PC, various forms of protection, blocks, or other actions in sock-puppet cases. Not allowing them to use PC will force them to use another method in cases where PC is in fact the best method to handle the situation. davidwr/(talk)/(contribs)/(e-mail) 22:38, 3 October 2012 (UTC)
7. May be appropriate in some situations, but semi-protection and blocking are generally better, so as a general principle but not a hard line rule, I would say "no". CT Cooper · talk 10:56, 5 October 2012 (UTC)
8. per many above. Davewild (talk) 11:17, 5 October 2012 (UTC)
9. Pending changes is not the path to follow to deal with sockpuppetry. Sockpuppeteers and their puppets are blocked, and the pages in which the user substantially vandalises can be semi-protected. Semi-protection is probably the best way to deal with sockpuppetry. Sure, anonymous editors cannot make good faith contributions, but then again, the trolls are separated from their favorite targets. There is no reason why a sockpuppet can be allowed to flood the reviewer backlog and halt all development of the page by autoconfirmed users, it's just too big of a hassle for PC to handle. Michaelzeng7 (talk) 17:39, 6 October 2012 (UTC)
10. Semi-protection should be applied in such cases. — Dmitrij D. Czarkoff (talk•track) 00:32, 7 October 2012 (UTC)
11. Just use the normal functions for investigating and fighting sockmasters. Steven Walling • talk 02:27, 7 October 2012 (UTC)
12. We have good methods for this already. DGG ( talk ) 12:26, 10 October 2012 (UTC)
13. Having a cue of edits to reject doesn't seem the best way to deal with sockpuppetry. --xensyria^T 21:22, 11 October 2012 (UTC)
14. My objection to PC is based primarily on how bad it is at dealing with sockpuppetry. Reviewers are conditioned to evaluating whether or not the edit is vandalism or not, and sock puppets generally are not committing obvious vandalism. The subsequent acceptance of the edit by the reviewer does nothing but make reverting all the sockpuppet's edits more difficult.—Kww(talk) 03:14, 16 October 2012 (UTC)
15. Current procedures are sufficient. Carrite (talk) 21:12, 17 October 2012 (UTC)

May PC be applied to pages to protect against edit warring by unregistered users?

Yes (IP edit warring)

1. May it be done? Yes. Should this be done very often? No. Most significant IP edit wars involve serious content violations. I think semi-protection would be my first choice, and if the group of editors is small enough, blocking the IPs (that's why the provisional policy says "large groups"), but in a few instances (e.g., both a slow-motion edit war and some very good work being done), I'd want to use this as an intermediate step. It might also be a valuable step down in protection, to see whether the edit warring is going to resume. (For example: start with semi-protection to drive the IPs to the talk page. When they seem to have worked things out, switch to PC for a week or two, rather than complete unprotection, to see whether their nice words on the talk page are followed by cooperative editing, or if they fall back into their bad behavior immediately.) WhatamIdoing (talk) 20:18, 30 September 2012 (UTC)
2. Yes, PC should be used to stop edit wars. Monty845 claims it is no better than Semiprotection but this is not true, because with PC, unconfirmed and anonymous users making non-disruptive edits are still allowed to edit the article; it is simply up to the reviewer to make those edits viewable (which he/she will, if they are truly non-disruptive and backlog is not a problem). RedSoxFan2434 (talk) 21:59, 30 September 2012 (UTC)
3. Yes, where appropriate (I recognise the downsides suggested by the honourable oppose !voters below). In a rapid-fire IP edit war, PC may not be the best solution, but I think it could be a good solution for (say) a more slow-burning edit war involving one or two editors, especially if they create disposable accounts to get round semiprotection (cf the history of John Craven). bobrayner (talk) 22:30, 30 September 2012 (UTC)
4. I think too many people are saying "this won't resolve the edit war", which is kind of missing the point. Chances are that an article subject to edit-warring has other, less controversial, issues in need of addressing and our current protection methods insure that an edit-war prevents those improvements.--The Devil's Advocate (talk) 18:00, 1 October 2012 (UTC)
5. Anthonyhcole (talk) 03:36, 3 October 2012 (UTC)
6. Yes, but only rarely will this be the best solution. davidwr/(talk)/(contribs)/(e-mail) 22:40, 3 October 2012 (UTC)
7. Per WhatamIdoing. JN466 08:33, 11 October 2012 (UTC)
8. Yes, if needed. --xensyria^T 21:22, 11 October 2012 (UTC)
9. Absolutely. This can stop the edit warring and the edit requests which can tend to get pretty disgusting when being answered.—cyberpower ^Chat_{Limited Access} 12:32, 12 October 2012 (UTC)

No (IP edit warring)

1. No. Using PC in the middle of an edit war would be incredibly disruptive and confusing. It wouldn't stop the IPs from editing, but would cause a lot of confusion with the "current revision" and the "latest accepted revision" etc. It would also disrupt normal editing for normal users. For edit warring between to IPs/new users, Semi-protection should be applied (as full protection is applied for edit wars between auto-confirmed users). ~Adjwilley (talk) 19:35, 30 September 2012 (UTC)
2. I don't think PC is a good tool for dealing with edit warring. Better that the page be protected to the necessary level, and that dispute related changes be discussed on the talk page first. PC wont facilitate that discussion any better then semiprotection, and will tie up noncontroversial edits made by non-reviewers if they are made subsequently to a potentially disputed edit from an IP. Monty₈₄₅ 19:39, 30 September 2012 (UTC)
3. So far as I understand, PC doesn't stop an edit war. It does, however, make an easy tactic to "win" an edit war in practice - you watch the article carefully, and when a change gets accepted, you revert your enemy, log out, and quickly make a typographic edit. The visible article is thus almost always your version. (Of course, gaming for your own reviewer account offers other possibilities...) Wnt (talk) 04:00, 1 October 2012 (UTC)
4. Semi-protect for IP edit wars; there's no reason that reviewers should have to wade through all that stuff. Risker (talk) 05:34, 1 October 2012 (UTC)
5. PC isn't very good against edit warring because it doesn't actually stop the parties from edit warring. If would likely make the article history a mess though. Hut 8.5 11:52, 1 October 2012 (UTC)
6. Other forms of protection are better suited for handling edit warring. Beeblebrox (talk) 19:13, 1 October 2012 (UTC)
7. At least in this case, pending changes is not a good solution for an edit war. The current implementation of pending changes doesn't actually stop editing; it just makes it temporarily invisible. This would confuse and complicate disputes, especially those involving new editors who are unfamiliar with the system, and would exacerbate them. elektrikSHOOS (talk) 19:35, 1 October 2012 (UTC)
8. Exactly what Adjwilley said above. Sven Manguard Wha? 06:12, 2 October 2012 (UTC)
9. Per all of the above. This is a very bad idea. Rivertorch (talk) 09:36, 2 October 2012 (UTC)
10. Not a good use. Submitting a PC draft is not a discussion and it forces the reviewer to pick a winner. Kilopi (talk) 11:04, 3 October 2012 (UTC)
11. Absolutely not. Protection or page banning/blocking the users are far better options and disrupt others less. ⁓ Hello71 00:50, 4 October 2012 (UTC)
12. No. Users should be encouraged to discuss their changes and follow WP: BRD. There is no need for PC by edit warring. --v/r Electric Catfish (talk) 15:42, 4 October 2012 (UTC)
13. Wouldn't really stop an edit war, and would still interrupt editing unrelated to it, so has no real advantage over page protection. In any case, talk page discussion is always the best method. CT Cooper · talk 11:00, 5 October 2012 (UTC)
14. Per Adjwilley. Davewild (talk) 11:17, 5 October 2012 (UTC)
15. Our policy is to move edit wars to talk pages and fight it out there, enforcing with real protection if necessary. Steven Walling • talk 02:26, 7 October 2012 (UTC)
16. We deal withthis already. PC would add to edit warring, preventing discussion of changes properly. DGG ( talk ) 12:24, 10 October 2012 (UTC)
17. Bad idea. Magog the Ogre (t • c) 00:59, 11 October 2012 (UTC)
18. Definitely not, it would just flood the backlog. Just semi-protect or even fully protect the page. Michaelzeng7 (talk) 23:06, 14 October 2012 (UTC)
19. This would be confusing as per Adjwilley's words. --EleoTager (talk) 16:21, 15 October 2012 (UTC)
20. No. Use semi-protection instead.--Mark91it's my world 21:26, 15 October 2012 (UTC)
21. Current procedures are sufficient. Carrite (talk) 21:13, 17 October 2012 (UTC)

May PC be applied to pages to protect against violations of the policy on biographies of living persons (WP:BLP)?

Yes, for all BLPs (BLP)

1. Ideally we should follow the German example and protect the whole of the pedia, this would be a useful step towards that. ϢereSpielChequers 07:45, 1 October 2012 (UTC)
2. This always felt like the primary purpose of any sort of flagged revisions idea in the first place. By enabling this, we'd create a needed shield on BLPs to prevent against libel or vandalism from appearing on the page. It's good for both Wikipedia as a site, and for the subjects of the articles themselves. elektrikSHOOS (talk) 19:33, 1 October 2012 (UTC)
3. Support per WereSpielChequers. I'd like to see this applied to all BLPs, certainly the little-watched ones. JN466 23:24, 1 October 2012 (UTC)

   Of course, I would also support PC for any individual BLP where there is an identified need to keep policy-violating changes out of the public's sight, even though semi-protection is not called for. JN466 22:06, 2 October 2012 (UTC)

4. Combined with permanent semi- or full protection of troublesome BLPs, to take care of the problem identified by Risker below at No (BLP) #2. The present policy of shutting the barn door after the horse has bolted is simply disrespectful to our subjects. The non-existent right to edit does not trump a person's actual right not to be defamed, even for the five minutes – 6 months it takes for someone to notice. --Anthonyhcole (talk) 03:14, 3 October 2012 (UTC)
5. Yes, the vulnerability of most BLPs to libellous additions and the extent of the BLP problem on Wikipedia justify giving some kind of protection to all such articles. Wouldn't solve everything, but at the very least this would make problematic changes that go unnoticed unviewable for most readers. Failing this, the level of disruption required to apply pending changes to a BLP should be lower than a regular articles, as it is in practice occurs with semi-protection at the moment. In any case, the application of pending changes should not usually result in the downgrading of existing page protection. CT Cooper · talk 11:08, 5 October 2012 (UTC)
6. Given the current BLP policy this makes sense. — Dmitrij D. Czarkoff (talk•track) 00:34, 7 October 2012 (UTC)
7. Second choice, almost first choice. Magog the Ogre (t • c) 01:00, 11 October 2012 (UTC)
8. Absolutely. It won't fix everything, but will go a long way. Kevin (talk) 07:14, 11 October 2012 (UTC)

Yes, but only when there are problems (BLP)

1. Weak, qualified support. Only if the violations are serious and persistent. In general, I don't want PC to become standard practice (or preemptive) for BLPs. ~Adjwilley (talk) 19:45, 30 September 2012 (UTC)
2. Oppose preemptive use but as a general proposition, I think dealing with BLP problems is the best use of PC. Monty₈₄₅ 19:50, 30 September 2012 (UTC)
3. Support for serious and persistent violations of the BLP policy, whether the article is primarily a biography or primarily about another subject but happens to have some BLP content. However, I oppose its routine use for all BLPs. I would also support a systematic effort to downgrade protection on low-traffic, long-term semi'd BLPs from semi to PC1. WhatamIdoing (talk) 20:21, 30 September 2012 (UTC)
4. Yes, BUT it should be used only when BLP policies have already been persistently violated on an article. Preemptive use should not be done, and even more important is that we will need to limit the number of articles on PC based on the fact that reviewers can not be constantly reviewing. Therefore, BLP violations should have PC protection only in very necessary circumstances. RedSoxFan2434 (talk) 22:08, 30 September 2012 (UTC)
5. Yes. I agree with the other !voters above that this should be done in order to respond to specific BLP problems rather than applying PC preemptively to large swathes of BLPs. I am open to preemptive use of PC in the sense that BLP problems sometimes spread across multiple pages - for instance if there were some hypothetical serious BLP problem on Liu Yongqing and it seemed likely to spill over, I'd happily apply PC to Hu Jintao. bobrayner (talk) 22:36, 30 September 2012 (UTC)
6. Support use where there are persistent violations or a high likelihood of persistent violations as Bob mentions above.--The Devil's Advocate (talk) 18:00, 1 October 2012 (UTC)
7. PC should not be applied preemptively, ever, for any reason, because it sends the wrong message about how established editors and the community at large interact. If we're going to lock down a page, we need something recent and substantial to point to as a justification, and we need that for every case. Sven Manguard Wha? 16:21, 2 October 2012 (UTC)
8. Kilopi (talk) 11:04, 3 October 2012 (UTC)
9. It should be allowed if there are problems where PC is the best solution to the particular current problems in a given article. From other comments in this question, I see that in many cases PC is not the best solution to BLP problems. davidwr/(talk)/(contribs)/(e-mail) 22:42, 3 October 2012 (UTC)
10. For articles that have a history of BLP violations. --v/r Electric Catfish (talk) 15:43, 4 October 2012 (UTC)
11. I think this is currently the best solution. I'm very tempted by pending-changes-for-all-BLPs, but I fear the workload would be unnecessarily high while we are still getting pending changes going. I would be strongly in favour of having a discussion about activating it for all BLPs once we have PC established and working well. Six months time, say. In the meantime, having pending changes available in addition to full or semi protection is a useful addition to the admin toolbox for those dealing with contentious BLPs. So, not now, but not never. —Tom Morris (talk) 12:21, 5 October 2012 (UTC)
12. Preemptive protection of any kind is undesirable. Steven Walling • talk 02:25, 7 October 2012 (UTC)
13. First choice. Magog the Ogre (t • c) 01:00, 11 October 2012 (UTC)
14. If the protection is applied to all BLPs, even problem less ones, it would defeat the purpose of anybody being able to edit it. Sure they can still edit, but it won't be visible. This can cause ownership issues. It also adds unneeded strain and work to reviewers. Only apply the need to review if the BLP has a history of problems.—cyberpower ^Chat_{Limited Access} 12:37, 12 October 2012 (UTC)
15. I think that BLPs are probably one of the biggest points of Wikipedia's scrutiny, and protecting those when there are problems should be the best PC use. Restricting IP edits for all BLPs goes against the tradition of Wikipedia, I think. Michaelzeng7 (talk) 23:09, 14 October 2012 (UTC)
16. Per C678. --EleoTager (talk) 16:21, 15 October 2012 (UTC)
17. Yes. I think this is the area where PC will help the most.--Mark91it's my world 21:22, 15 October 2012 (UTC)
18. Problematic BLPs and ongoing vandalism are the reasons for this tool. Carrite (talk) 21:14, 17 October 2012 (UTC)
19. Certainly shouldn't be pre-emptive as I don't believe any protection should be, BLP or not, but it is a useful tool in certain circumstances, which the protecting admin would have to take into account. GedUK  11:28, 19 October 2012 (UTC)

No (BLP)

1. The interpretation of BLP policy is anything but obvious or uncontroversial. The existence of things like the Middleton topless photos or the Dan Savage definition of "santorum" is anathema to the dogged, hard-line, well-placed POV pushers who use BLP to explain their actions. The purpose of using PC for "BLP" is to allow whichever cabal of admins gets the upper hand to control who gets the reviewer bit based on their loyalty in keeping relevant information out of articles. It will be used to prevent certain people who are wealthy, white, and from Western countries from having anything bad about them mentioned, while others who do not fulfill these requirements can still be described as harshly as the users desire. Wnt (talk) 14:50, 1 October 2012 (UTC)
2. Speaking as an oversighter, I can say honestly that we wound up having to suppress far more edits to BLPs during the PC trial, because BLP violations that were being held for review remained in the page history, often with inappropriate edit summaries. Those edits would not have existed when the page was semi-protected instead. Note that PC should only be applied if there is a history of a problem, and not just to an article because it's a BLP. Simply put, if there is an ongoing BLP problem, the page should be semi-protected. Risker (talk) 05:31, 1 October 2012 (UTC)
3. I have several problems with the use of PC in this manner. It would allow more BLP violations to persist in edit histories and hence create an increased workload for admins/oversighters. I am concerned that it may be applied pre-emptively, or at least that it may be applied more liberally than we currently use protection. Exactly what constitutes a BLP violation can be debatable, and the types of BLP violations we should be most concerned about are the types which are least likely to be prevented by PC. And of course we need to keep the system as simple as possible in order to keep backlogs down. Hut 8.5 11:52, 1 October 2012 (UTC)

   Forbidding pre-emptive use is certainly better then otherwise, but it doesn't address all of my concerns. Hut 8.5 19:39, 2 October 2012 (UTC)

   Oppose as written. PC should not be applied preemptively, ever, for any reason, because it sends the wrong message about how established editors and the community at large interact. If we're going to lock down a page, we need something recent and substantial to point to as a justification, and we need that for every case. As written, this proposal would allow for applying PC preemptively, so I will not support it. Sven Manguard Wha? 06:16, 2 October 2012 (UTC)

   Moved to support non-preemptively. Sven Manguard Wha? 16:20, 2 October 2012 (UTC)

4. Articles with significant BLP components often require special care, and PC won't provide it. What it may well do is lull many of us into a false sense of security while allowing bad edits that would have been caught by other protection schemes to slip through. To say that WP:BLP, like other policies, is subject to interpretation is putting it mildly; it's probably the only policy where one group of editors regularly sees black where the other sees white. Certainly no other policy has created such bitter, lasting divisions among Wikipedians. If we're unfazed at the prospect of broadening those divisions, then sure—let's give admins who interpret the policy one way the green light to use a clumsy technical tool to marginalize a sizable group of editors who disagree with them. Otherwise, let's recognize that close watching, traditional protection methods, and honest discussion are the only feasible way to manage WP:BLP violations and maintain WP:NPOV-compliant articles. Rivertorch (talk) 10:10, 2 October 2012 (UTC)
5. Per Wnt. Davewild (talk) 11:19, 5 October 2012 (UTC)
6. Per Risker. BLP violations ar best removed quickly, as spotted by RC patrol and the bots and edit filters. Anything more complicated will be slower. DGG ( talk ) 12:23, 10 October 2012 (UTC)
7. Like allowing it for other content policies this isn't an ideal solution, leaving PC open to abuse. --xensyria^T 21:22, 11 October 2012 (UTC)

Discussion about when to apply PC

Discussion about "Yes, for all BLPs (BLP)"

• Why is this option even here? This isn't derived from the initial RFC and most certainly didn't receive consensus support in that RFC. Once again we see the desire to use an anti-vandalism tool for content control. If the community RFC had given this as an option, it would have failed miserably, and it is remarkably disappointing to see the desire to impose this through the backdoor. (And note below, BLP violations requiring suppression actually increased during the PC trial, so there is no basis to believe this will have a positive effect.) Risker (talk) 16:19, 2 October 2012 (UTC)
  • I don't know, but the division between people that supported it for all cases and the people that supported it for only problem cases was so stark that I split the sections so that there could be no doubt as to what people wanted. Sven Manguard Wha? 16:25, 2 October 2012 (UTC)
  • There is no back door. A small number of editors have said that they want it for that purpose so they have been given their own section. Their opinion is unlikely to ever get consensus but that doesn't change the fact that they stated it. Yaris678 (talk) 17:25, 2 October 2012 (UTC)
  • This isn't about using an anti vandalism tool for content control. This is a proposal to use an antivandalism tool to give extra protection against vandalism to a group of articles where the content merits extra protection against vandalism. ϢereSpielChequers 18:41, 2 October 2012 (UTC)
    • The "where does it end" arguement comes into play though. Why are BLPs (which, when wrong, just piss off people that could make our lives miserable) treated differently from medical articles (which, when wrong, can put people in danger)? What about businesses (who also have lawyers and who, according to SCOTUS, are people too)? The argument that we should lock down every article in a specific topic because it's in that topic, and with no thought as to whether individual pages warrant that locking down, is a bad idea. Sven Manguard Wha? 18:58, 2 October 2012 (UTC)
    • I am with WSC here. Just look at the press Wikipedia got for this incident. Vandalism, pure and simple. If we had had PC on that page, no one would ever have seen it, and the thing would have been a complete non-event. Moreover, most of the incentive to engage in vandalism of this kind would evaporate in an instant, because it is only the English Wikipedia's present state of being wide open to any silliness that encourages it. JN466 22:14, 2 October 2012 (UTC)

Jayen, is there any other link that says the same thing? I ask because that website is being blocked by my net nanny here, and it usually only does that when there's some kind of malware at the other end of the link. Alternately, could you please link to the article it refers to? (Also, don't forget that any edit that is made, regardless of whether or not it's accepted, remains in the article history, and the diff can still be used to spread that info. We've also not figured out what happens when web crawlers hit a PC article - do they get the "public version" or the "unreviewed" one? They're running off the API, I believe, so I'm thinking it's the unreviewed one.) Risker (talk) 22:21, 2 October 2012 (UTC)

Ah, never mind, Jayen; I finally worked out that it was a link to the blog of the article subject. I confess I'm rather liberal in my semi-protection of BLPs: almost never less than a month, and normally 6 or 12 months is my practice. Indeed I extended the SP on that article to a full year. Meanwhile, I've asked a bit more about web crawlers and GoogleBot in particular to see if we can work out what version of a PC article gets pushed out in the API and/or would normally be picked up by a web crawler, and I will report back here when I get the information. It will probably be a couple of days. Risker (talk) 23:44, 2 October 2012 (UTC)

As others might have the same problem as you, here is a link to the New Statesman http://www.newstatesman.com/blogs/internet/2012/06/dear-internet-why-you-cant-have-anything-nice – although given that the word porn is mentioned, it may not remedy the problem. Here is a Google search for Anita Sarkeesian Wikipedia that should do the trick for everyone: [1]. The biography was Anita Sarkeesian. My impression from de:WP is that oversighters there are not too concerned about poor edits that were never approved remaining in the edit history. It is also my impression (and that has been confirmed by German admins) that fewer such edits are made, simply because there is no point making them if no one but logged-in Wikipedians can see them. The key thing is that the public never has seen them and never will see them by calling up the article. JN466 09:29, 3 October 2012 (UTC)

This here sounds like another example of malicious BLP vandalism having a far greater effect than it need have had: http://www.haaretz.com/print-edition/opinion/a-web-of-lies.premium-1.469273 JN466 02:35, 11 October 2012 (UTC)

Here is another news report that would not have happened with flagged revisions on biographies: Valverde’s Wikipedia Page Vandalized. AndreasKolbe JN466 13:52, 15 October 2012 (UTC)

• Risker, the inclusion of this option was discussed here, here, here, here, and here. The back door was already standing wide open and flapping in the wind; by including this quesion, my hope was to shut it. @WSC: in a perfect world, or on a perfect wiki, that might be true. The reality at en.wp is that disputes over interpretation and application of WP:BLP frequently center on the attempted exclusion of content that some editors believe must be included in order to have a credible, NPOV article. (Btw, would you please respond to my query here?) Rivertorch (talk) 19:30, 2 October 2012 (UTC)

For the record, there is a discussion on the talk page concerning the split of this section. (Well, it would be a discussion if someone else joined in. At the moment, it's rather like one hand clapping.) Rivertorch (talk) 22:10, 2 October 2012 (UTC)

• I support Risker. This possibility is totally outside the parameters of the original Rfc. Ity was never approved, and if this had been the question asked there, the whole thing would not have been accepted. DGG ( talk ) 03:07, 10 October 2012 (UTC)
• I support Risker as well. --EleoTager (talk) 16:21, 15 October 2012 (UTC)

Criteria for rejecting edits

This is related to the questions above. The provisional policy is ambiguous regarding the criteria for accepting or rejecting edits because it defers these details to Wikipedia:Reviewing. For instance, should reviewers reject good-faith edits that are unhelpful and would probably be reverted anyway?

Please endorse one of the following three statements:

1. Reviewers may reject only those edits that violate the criteria governing when to apply PC to pages.

For example, if consensus in the previous section is to apply PC only to protect pages from vandalism, reviewers may reject a pending edit only if it constitutes vandalism. Reviewers may not use PC to reject an edit for any other reason. Example1 Example 2

1. Clarifying the reviewer's role is important not just for preventing ugly rejection wars, but for the reviewer's legal protection as well. I'm not a lawyer, but the ECPA offers a safe harbor for censors at online services who enforce some set of criteria but miss other things; but if the reviewer has unlimited discretion to support or oppose anything in an edit as his own work, I think this may be compromised. Wnt (talk) 04:07, 1 October 2012 (UTC)
2. Strongly Support. Any other option means that wikipedia has become a publication under the control of a select board of editors/reviewers. 121.45.215.186 (talk)

• Oppose There are other problematic edits that can't be considered vandalism, but can't be accepted either.—cyberpower ^Chat_{Limited Access} 12:43, 12 October 2012 (UTC)

2. Reviewers may reject any edit that clearly violates any Wikipedia policy or guideline.

Reviewers should use the edit summary to cite the applicable policy or guideline they are enforcing. Example 1 Example 2

• Neutral it should be recommended and emphasized, but not required. It can also be told to the user directly what policy it violates.—cyberpower ^Chat_{Limited Access} 12:46, 12 October 2012 (UTC)

3. Reviewers may use their judgment to reject any edit that would significantly harm the page's quality if approved.

Reviewers use a clear edit summary explaining precisely how each edit they reject would harm the page. Example

1. Support. This is the quick way of doing things and anything else smells of bureaucracy. Insisting on the edit summary helps the WP:BRD cycle. I would say that you don't need an edit summary if it is a clear cut case of vandalism. In other cases, giving a reason stops it from seeming arbitrary. It is also important that reviewers should be willing to discuss their decisions on the talk page. In some cases it may even be a good idea for them to initiate the conversation. In most cases they just need to be prepared to answer questions if someone queries their reasoning. Yaris678 (talk) 13:32, 1 October 2012 (UTC)

   anything else may be more complicated, but this is way too broad. it amounts to saying, Reviewers may reject any edit they disagree with. DGG ( talk ) 01:21, 15 October 2012 (UTC)

   Replied at #"Reviewers may use their judgment to reject any edit that would significantly harm the page's quality if approved." Yaris678 (talk) 12:33, 16 October 2012 (UTC)

2. Support. I like much of WhatamIdoing's alternative below (and disagree with it on a couple of points) but consider it unwieldy. Short and simple is best, for starters. There will be ample opportunity to add to the policy later on, close the loopholes, reduce the ambiguities, and so on. Let's begin the PC era by keeping the policy bare-bones and flexible, allowing reviewers to use their judgment and rescinding that privilege only if it proves problematic. I should say that I'm also really leery of the accept-then-undo approach, especially given the page load times I'm seeing on PC-enabled pages. Rivertorch (talk) 06:12, 3 October 2012 (UTC)
3. Support Don't go overboard on details.—cyberpower ^Chat_{Limited Access} 12:47, 12 October 2012 (UTC)
4. Support - I thought the point of these RfCs was to eliminate the loopholes and decide the policy beforehand. Nevertheless, this is my first choice. Michaelzeng7 (talk) 23:15, 14 October 2012 (UTC)
5. Support - Let common sense prevail rather than a massive set of new rules and standards. Carrite (talk) 21:16, 17 October 2012 (UTC)

4. Same rules apply as for Rollback v Undo

If a reviewer disagrees with an edit so strongly as to want to revert it entirely then they should bear in mind the rules for Rollback, and if in doubt use undo instead. Example

1. ϢereSpielChequers 07:51, 1 October 2012 (UTC)
2. This is the most common-sense, succinct way of doing it. If the edit doesn't warrant a rollback or even an undo, accept it then edit the article to make it better even if the net effect is the same as an undo or rollback. If nothing else, this will be less WP:BITEY to new editors who, in ignorance, put in things that would be edited out quickly but not undone or rolled back if they were done today. davidwr/(talk)/(contribs)/(e-mail) 22:49, 3 October 2012 (UTC)
3. Gigs (talk) 17:29, 11 October 2012 (UTC)
4. Rollback is rollback and is to be used in clear cut vandalism only—cyberpower ^Chat_{Limited Access} 12:49, 12 October 2012 (UTC)

5. WhatamIdoing's five point proposal

• Reviewers must (using the definition at RFC 2119, but having some compassion because we all make occasional mistakes) reject serious policy violations such as libel, blatant copyvio, and vandalism.
• Reviewers should (see RFC 2119 again) reject any obvious policy violation.
• Reviewers may reject any change that substantially harms the page, although the "best practice" is to accept and then undo most such changes.
• Reviewers should not reject changes that are borderline or personal preference issues, e.g., the addition of material that is probably verifiable but doesn't happen to have been supplied with an inline citation yet. Those should always be accepted, even if the reviewer (in his/her capacity as a normal editor) then immediately heads for the undo button or {{fact}}-tags it or whatever.
• There should be no requirement to use edit summaries. Or, rather, the requirement to use edit summaries in PC should be exactly the same as the requirements in all other editing, which is "recommended but not required". WhatamIdoing (talk) 19:47, 30 September 2012 (UTC)

1. Support though I disagree with the last point. If you're undoing someone's edit for any other reason than blatant vandalism you should use an edit summary. (Note: when you use PC to reject a change the software specifically prompts you for an edit summary, so it shouldn't be that hard.) ~Adjwilley (talk) 20:00, 2 October 2012 (UTC)
2. Support The above approach with the caveat that further discuss needs to occur regarding the implications of must. Must if you notice it, with a higher expectation of noticing it when it is the type of violation that resulted in protection as provided in the protection log entry. Monty₈₄₅ 19:55, 30 September 2012 (UTC)
3. Support but I think edit summaries should be mandatory. Sven Manguard Wha? 20:58, 2 October 2012 (UTC)
4. Support except for point 4. Approving and then reverting is a bit too messy: just revert, and the last edit will then be auto-approved. Comes to the same thing, and doesn't have the article flip-flopping. JN466 22:19, 2 October 2012 (UTC)
5. Support as this wholeheartedly describes my opinion on when reviewers should reject edits. RedSoxFan2434 (talk) 22:36, 2 October 2012 (UTC)
6. Support - I think the use of edit summaries should be more like the requirements for deletion or other administrative action. You have to describe why you are deleting the article, or in this case, why you are rejecting the edit. Otherwise, yes, this is a good summary of what should be dealt with using PC. Michaelzeng7 (talk) 00:00, 3 October 2012 (UTC)
7. Kilopi (talk) 11:04, 3 October 2012 (UTC)
8. Support Seem like decent ground rules.--The Devil's Advocate (talk) 17:59, 3 October 2012 (UTC)
9. Support, though I would replace the last point with "Reviewers should (see RFC 2119 again) use edit summaries – unless the declined material is a blatant violation of policy, explanation in edit summary must be supplied. — Dmitrij D. Czarkoff (talk•track) 00:18, 7 October 2012 (UTC)
10. Oppose This is way too complicated. Five point, multiple-paragraph policies about how and when to reject or accept edits is the kind of stupid bureaucracy that makes Wikipedia too hard and no fun. Steven Walling • talk 02:24, 7 October 2012 (UTC)
11. Support. Good editing is a hard craft. If you want easy, you're in the wrong place. --Anthonyhcole (talk) 16:38, 10 October 2012 (UTC)
12. Support. Seems the best set of guidelines for its use. --xensyria^T 21:22, 11 October 2012 (UTC)
13. Support This is common sense. Why people can't exercise it is beyond me.—cyberpower ^Chat_{Limited Access} 12:41, 12 October 2012 (UTC)
14. Strongly oppose. WhatamIdoing is proposing a comprehensive content control package. "Should" remove policy violations—ignores the fact that we often have long and complex discussions about whether or not a particular edit is a policy violation. Those go to the talk page and are discussed, they should not be removed using the "power" of pending changes. "May" reject changes that substantially harm the page — except that this is highly subjective and is one of the primary causes of edit warring. Ask 10 editors what constitutes "harm" to a page, and the answer will range from "removing any content" to "penis vandalism". Nobody's going to complain about the latter, but "removing any content" also encompasses logical and appropriate editing of an article — unless someone else really wants that content there. Risker (talk) 13:04, 12 October 2012 (UTC)
15. Support - Risker, if you look closely at the should clause, you'll see it says obvious policy violations. עוד מישהו Od Mishehu 15:25, 17 October 2012 (UTC)
16. Oppose this sort of micromanagement. Instead: case by case, common sense. Carrite (talk) 21:17, 17 October 2012 (UTC)

Discussion about criteria for rejecting edits

• None of these really reflect my POV (my fault; I should have followed the development of this section more closely). So here's what I want:
  • Reviewers must (using the definition at RFC 2119, but having some compassion because we all make occasional mistakes) reject serious policy violations such as libel, blatant copyvio, and vandalism.
  • Reviewers should (see RFC 2119 again) reject any obvious policy violation.
  • Reviewers may reject any change that substantially harms the page, although the "best practice" is to accept and then undo most such changes.
  • Reviewers should not reject changes that are borderline or personal preference issues, e.g., the addition of material that is probably verifiable but doesn't happen to have been supplied with an inline citation yet. Those should always be accepted, even if the reviewer (in his/her capacity as a normal editor) then immediately heads for the undo button or {{fact}}-tags it or whatever.
  • There should be no requirement to use edit summaries. Or, rather, the requirement to use edit summaries in PC should be exactly the same as the requirements in all other editing, which is "recommended but not required". WhatamIdoing (talk) 19:47, 30 September 2012 (UTC)

Support Moved to the newly created section above Monty₈₄₅ 20:05, 2 October 2012 (UTC)

I think this is going to be one of the most important issues to clarify. At this point if I have to pick one it is option two, with option three as another reasonable approach. Option one is way to restrictive and could actually discourage reviewers. Beeblebrox (talk) 19:59, 30 September 2012 (UTC)

• I think WhatamIdoing puts it best. bobrayner (talk) 22:39, 30 September 2012 (UTC)
  • I agree. WhatamIdoing's proposal is what I would like to have done. It is significantly better IMO than any of the 3 given proposals. — Preceding unsigned comment added by RedSoxFan2434 (talk • contribs) 23:15, 30 September 2012 (UTC)
• This goes against many of the points above that have significant discussion. It turns PC into a content control tool instead of an anti-vandalism tool. Risker (talk) 05:39, 1 October 2012 (UTC)
• I kinda agree with WhatamIdoing. However: (1) He says "Reviewers may reject any change that substantially harms the page, although the "best practice" is to accept and then undo most such changes." and "the requirement to use edit summaries in PC should be exactly the same as the requirements in all other editing, which is 'recommended but not required'." Under this it would be seen as being super good in one way and just about acceptable in another if a reviewer rejected an edit for quality reasons and included an explanatory edit summary with the rejection. That is the most efficient and communicative way of doing things so I would prefer it if it were just standard practice. See also this comment. (2) While I can kinda see what he's getting at with the distinction between "must", "should" and "may", it feels a bit bureaucratic. I'm of no fixed opinion on that and would be interested to know what others think. Yaris678 (talk) 13:53, 1 October 2012 (UTC)
  • Since this proposal has attracted more support and more attention than any of the other four, I've moved it up as an official option. I will not however, move any votes up myself. Sven Manguard Wha? 16:04, 2 October 2012 (UTC)

"Reviewers may use their judgment to reject any edit that would significantly harm the page's quality if approved."

Comment from #3. Reviewers may use their judgment to reject any edit that would significantly harm the page's quality if approved.:

anything else may be more complicated, but this is way too broad. it amounts to saying, Reviewers may reject any edit they disagree with. DGG ( talk ) 01:21, 15 October 2012 (UTC)

Well... reject any edits they believe they have a good reason to reject... Which is what ANY editor can do anyway using the undo feature. The differences are that no unregistered users will have seen the other version in the interim and that the article history will record that the edit was rejected (as opposed to recording that it was undone). I think this is compensated for by:

1. Reviewers being more used to the consensus ways of Wikipedia than new users and more familiar with policies etc. so they will be better able to explain why they are rejecting the edit.
2. Reviewers being strongly encouraged to add the reason in the edit summary.

Its not like the rejected edit disappears from the article history.

Yaris678 (talk) 12:31, 16 October 2012 (UTC)

Automatically accept old changes

Currently pending changes remain in a queue until they are accepted or rejected by reviewers. Should changes that have been in queue for a given time period (eg. 24 hours) be automatically accepted?

Further information

This is intended to address a number of concerns with Pending Changes. Specifically, concerns that: Pending Changes queue would become severely backlogged Pending Changes would contribute to a lack of openness, scaring away new users who don't know whether or when their changes would ever be "accepted" Reviewers might become legally vulnerable when they mistakenly or negligently approve an edit that contains a copyright violation or subtle defamatory falsehood. In practice, it is unlikely that that changes will remain in the queue long enough to be automatically accepted, since the vast majority of edits should be accepted or reverted long before the 24 hour mark. In your answer feel free to make recommendations for the length of the time period. 24 hours was chosen because this would give sufficient time for reviewers in all time zones to see the edit. A much shorter time period (1 hour, for instance) would be sufficiently long to revert most obvious vandalism, while a longer time period would ensure that no edits would be automatically accepted without review. There is also the option of letting the protecting admin choose the time period on a case-by-case basis.

Yes, automatically accept old, unreviewed changes

1. Weak yes. Sort of. I'd accept a very long timer on this, like a week or a month, just in case no one is willing to decide one way or the other on a given edit. If we can't get something reviewed, we should default to normal. WhatamIdoing (talk) 19:34, 30 September 2012 (UTC)
2. Yes. I think this would be a good way for PC supporters to meet opposers halfway. (Many opposes were based on the fear of long backlogs like they have in the Russian Wikipeida.) I'm not particularly concerned about inappropriate edits slipping through the cracks, since most vandalism is reverted within the first 30 minutes, either by ClueBot, vandal fighters, or watchers. The potential damage of borderline inappropriate edits slipping through the cracks is outweighed by the disruption of interrupting normal editing for more than 24 hours. (When an article has a pending change awaiting review, all subsequent edits to the article are also marked as pending.) I see Pending Changes as a tool that gives us a time window in which to revert vandalism before it goes live to the general public. We should add safeguards to ensure that it doesn't become more than that. ~Adjwilley (talk) 19:54, 30 September 2012 (UTC)
3. 24 hours seems like a reasonable middle ground. If no one can come up with a reason to justify rejection within 24 hours the edit is either acceptable, or the system is overwhelmed and in need of a safety valve. I expect the latter case is unlikely to occur, and that mostly it will be edits that reviewers don't like, or are uncomfortable with, but that there is no clear policy reason for rejecting. Monty₈₄₅ 19:59, 30 September 2012 (UTC)
4. Yes. 24 hours seems good since it gives everyone in each time zone an opportunity to see it. I would also like the creation of a bot to deal with this. The backlog is easily the biggest problem PC has and this is the ideal way to deal with it because it keeps things up-to-date (especially BLPs) whereas a longer time limit could cause things to fall out of date. RedSoxFan2434 (talk) 23:34, 30 September 2012 (UTC)
5. It isn't much, but it's a partial remedy to this fiasco. Wnt (talk) 04:09, 1 October 2012 (UTC)
6. Weak support, with the understanding that if the limit gets hit with any significant frequency admins should either remove PC protection from some pages or make some more reviewers. Kilopi (talk) 11:04, 3 October 2012 (UTC)
7. I hate waiting, and so does every other human being on the planet. If we can't get our act together enough to review pending changes in 24 hours, then we don't deserve to make other people wait. Treating people with an assumption of bad faith, namely that their edits must be reviewed before appearing, is bad enough already. Steven Walling • talk 02:23, 7 October 2012 (UTC)
8. After waffling internally for a week, I'll endorse this. If nothing else, it should somewhat reduce the disruption to editing caused by PC. I'd be more comfortable with, say, 48 hours, instead of 24, but without automatic acceptance there will either be stuff sitting there for weeks, with subsequent edits in limbo, or there will be problems with improper accepts or rejects. I think 48 hours should give ample opportunity to weed out any blatant vandalism, etc. PC should be removed from any article where it turns out the pending edits are too esoteric or complex for reviewers to assess in a reasonable length of time. Rivertorch (talk) 09:47, 7 October 2012 (UTC)
9. After a week, automatically accept old, unreviewed changes. --EleoTager (talk) 16:23, 15 October 2012 (UTC)

No, don't automatically accept old, unreviewed changes

1. No. Defeats the whole purpose. under the current system users can submit edits on the talk page of a protected page. If their proposed edit is inappropriate we don't automatically add it if the request is not dealt with fast enough. This idea attempts to manage a backlog that at this time does not actually exist. Beeblebrox (talk) 19:21, 30 September 2012 (UTC)
2. Per Beeblebrox. Simply put, if the backlog is determined to be unacceptable or unmanageable, then the use of PC should be revisited. Significantly more edits were rejected than accepted during the trial. Risker (talk) 05:41, 1 October 2012 (UTC)

   I am going to expand here. There is no point in turning on pending changes if we are going to accept unreviewed edits of any age. The entire *point* of pending changes is that *every* addition is reviewed before it goes to the public-facing view. That is the "product" that was supported by the community, not one that puts timeliness of insertion of information over actual reviewing. I am gobsmacked that this question was even asked or considered. Risker (talk) 14:30, 1 October 2012 (UTC)

3. If we have backlogs it would be better to respond by recruiting reviewers and whitelisting more goodfaith editors. But we shouldn't allow unchecked vandalism onto the pedia. ϢereSpielChequers 07:57, 1 October 2012 (UTC)
4. Depending on how PC is to be used then this could be extremely dangerous by (e.g.) allowing BLP violations into the encyclopedia in a way that semi-protection would not have. If we can't handle the workload of pending changes - something which is a strong possibility - then we should either reduce the number of protected pages, increase the number of reviewers, simplify the reviewing process, or get rid of the tool altogether. Hut 8.5 12:10, 1 October 2012 (UTC)
5. This sort of timeline might make sense on articles with high activity, but plenty of articles get little attention from editors for weeks so a 24-hour period would basically negate the whole purpose of Pending Changes protection in those cases.--The Devil's Advocate (talk) 19:08, 1 October 2012 (UTC)
6. Potential backlogs are a problem that is better solved by liberally giving out the reviewer right rather than automatically accepting potentially problematic revisions. In my view, this would defeat the purpose of the system in the first place. If it is determined that a backlog is too severe, we can revisit it. elektrikSHOOS (talk) 19:36, 1 October 2012 (UTC)
7. If the primary purpose for pending changes is to ensure changes to a given article are reviewed, then it defeats the purpose to automatically accept changes after a period of time. To ensure the backlog remains manageable, it would be best to gradually scale up the deployment of pending changes to match the pool of active reviewers. As there will presumably be an initial burst of enthusiasm, I suggest a conservative approach be taken as the numbers of regular reviewers stabilize. isaacl (talk) 00:47, 2 October 2012 (UTC)
8. As was said above, this defeats the purpose. If we can't control the stream of changes in need of checking, we need to rethink how PC is applied or rethink PC itself. Sven Manguard Wha? 06:08, 2 October 2012 (UTC)
9. JN466 22:20, 2 October 2012 (UTC)
10. Anthonyhcole (talk) 03:56, 3 October 2012 (UTC)
11. Yes, far better to let some unreviewed material through than to have it languish for want of reviewing. Hopefully there will be an automated way of tagging articles whose last edit was the automatic-reviewer so humans will know to double-check for edits that would have been rejected. davidwr/(talk)/(contribs)/(e-mail) 22:51, 3 October 2012 (UTC)
12. Absolutely not. The whole problem we have now is that with recent changes (and Huggle etc.) we can have a situation where five people look at one diff and nobody looks at another diff. This problem is exactly why FlaggedRevs was built (and is used on some other wikis), and a major benefit that Pending Changes offers. In addition, the fact that unlike the shooting gallery that is Recent Changes/Huggle, patrollers can take a few minutes longer to think about a PC edit because they know that it isn't live... the whole point of PC goes out the window if old edits get auto-approved. Scaling up slowly seems to be the best approach. Take the proposal to apply it to all BLPs (I admire the reasoning behind it), that's a fine idea, but do that last. Start PC off, and scale it up slowly over the course of, say, six months. If PC changes aren't being handled quickly enough, delay further rollout. —Tom Morris (talk) 11:06, 5 October 2012 (UTC)
13. Does defeat the purpose, per above. Issues with the backlog are best resolved through encouraging more people to do reviewing, giving more people the reviewer right, and as a last resort, scrapping pending changes. If an auto-approve mechanism must be added then I would push for a time period of much longer than 24 hours e.g. a week. CT Cooper · talk 11:16, 5 October 2012 (UTC)
14. Though it may be used as a tool of last resort, it shouldn't be used unless the process becomes stable and some data gets collected so that an inform decision could be made. In other words, I don't have enough information to even consider a possibility to support this proposal. Let the horses go first. — Dmitrij D. Czarkoff (talk•track) 00:24, 7 October 2012 (UTC)
15. Defeats the whole point. Magog the Ogre (t • c) 01:02, 11 October 2012 (UTC)
16. No, definitely not. --xensyria^T 21:22, 11 October 2012 (UTC)
17. If anything, after a week of being unreviewed.—cyberpower ^Chat_{Limited Access} 12:50, 12 October 2012 (UTC)
18. No. Defeats the purpose. Leave them until someone knowledgeable about the topic comes along.--Mark91it's my world 21:24, 15 October 2012 (UTC)
19. No - 24 hours would not necessarily mean that all admins would have a chance. Weekdays and weekends are inherrently different in terms of editing patterns. עוד מישהו Od Mishehu 15:30, 17 October 2012 (UTC)
20. No. Completely avoids the point. There's plenty of circumstances where vandalism sits on a page for some time, days, weeks, months even years because they're low traffic. Just becuase no-one has it on their watchlist doesn't mean that it's any less important to the encylopedia. GedUK  11:34, 19 October 2012 (UTC)

Discussion about what to do with old, unreviewed changes

• As I understand it, this idea requires either Mediawiki developer time (a very scarce resource) or someone to create a new bot, with the reviewer flag, to "review" old items. As such, this question should be considered a way of deciding whether or not to ask someone technical to please provide us with a new feature. Even if everyone likes the idea, it is not something that we can guarantee would happen at all, much less any time soon. WhatamIdoing (talk) 20:26, 30 September 2012 (UTC)

It should be very straightforward to get a bot to do it if there is consensus. Monty₈₄₅ 20:35, 30 September 2012 (UTC)

• I think a discussion needs to be had (if not now, then at some point) about how long until a hypothetical PC reviewer bot would step in and automatically insert unreviewed changes; of course, if consensus is against automatically inserting unreviewed changes, than this is moot, but it would save time to have that discussions sooner rather than later. I think the proposed 24 hours is good, whereas waiting a week is too long since a BLP or other article can easily fall out of date. RedSoxFan2434 (talk) 23:45, 30 September 2012 (UTC)
• What to "do" with old unreviewed changes is to review them. There should be no exceptions. Even if it's decided it's necessary to remove PC from an article, the changes should be reviewed before doing so to ensure that the public-facing article version does not contain vandalism or BLP violations.

  The more important question here is what metric we're going to use to determine whether or not PC is working properly. We should have a bright line, such as >500 edits older than 24 hours or >0.5% of articles on PC have edits awaiting review after 24 hours, that brings PC to a halt. We have no "success/failure" metrics at all for something that is changing our culture. Risker (talk) 14:39, 1 October 2012 (UTC)

  @Risker: "The entire *point* of pending changes is that *every* addition is reviewed before it goes to the public-facing view." I disagree. In my view the point of pending changes is to give us a brief time window in which to revert vandalism and policy violations before they go live to the public. Putting the normal editing process on hold to ensure *every* change is reviewed before it goes live would be a dramatic change to our culture, and a negative one in my view. One of the main reasons for this proposal is to minimize the effect on our culture.

  I would also disagree with the view that auto-accepted changes should be considered un-reviewed. By the 24 hour mark the changes will have been reviewed by vandal bots, page watchers, STiki/Huggle users, and perhaps even Reviewers who don't like the change enough to hit "accept" but can't find anything specifically wrong with it. These kinds of changes should be automatically accepted so as to not disrupt the normal editing process for other users. ~Adjwilley (talk) 15:33, 1 October 2012 (UTC)

See now, here's where your reading and my reading of what the community considered during the RFC on pending changes is radically different. If the RFC had asked "do you want to set up a structure where some changes will be reviewed and some won't if people are too busy, and we'll still make the changes go live in a few hours/a day/whatever even if they're not reviewed", then I doubt there would have been nearly as much support. You're changing the goalposts from what the community supported, which is that pending changes go through a review process. Period. Either all pending changes are reviewed, or the page comes off pending changes. And if it keeps happening, and more and more pages are removed from PC, then we have to re-examine whether or not it's worth it at all. You're making enormous assumptions in your statement without any supporting evidence. Risker (talk) 15:44, 1 October 2012 (UTC)

Ah. I think I see where you're coming from. I actually agree with your reading of what the community considered. As of this moment, you are correct pending changes is a process where every single edit must be reviewed by a reviewer. My view is that this is not how it should be and since this RfC is a chance to modify the policy, that's what I'd like to see happen here. I can't say whether or not the community would have accepted this proposal several months ago in the big RfC. I did notice that many PC opposers had concerns about backlogs, censorship, and lack of openness (the encyclopedia that anybody can edit after their edits are reviewed). Perhaps they would have been more inclined to support if this were a part of the policy, since this deals directly with backlogs and the lack of openness. I guess we'll have to see how this RfC turns out before we can gauge what the community thinks. ~Adjwilley (talk) 17:13, 1 October 2012 (UTC)

Risker has it exactly right. It was only after the big RFC closed that any mention of automatically accepting edits came up. This idea is apparently an attempt to deal with a backlog that has never existed. That some people are convinced that there will be massive backlogs does not make it so. We've already got one user above saying that this will help with this "disaster" when we aren't even using the tool and it has never been deployed full-scale. The alarmists, who failed to sink PC with such statements in previous discussions, need to come up with some factual basis to support their claims or join the rest of us in admitting the fact that we don't actually have the slightest idea what kind of backlogs PC may produce. My personal feeling is that it won't be a big deal because there will probably be a lot of new page patrollers who do reviewing as well and there are lots of them, but I can't say the definitely will happen because we just don't know. Instead of building backlogs in our imagination and then constructing a mechanism for clearing them I think a more common-sense approach, such as the one suggested by Risker, is much more sensible. If users in the previous discussions had the slightest inkling that we might turn around and give vandals a back door that no other form of protection has I doubt it would have been supported as strongly as it has been. Beeblebrox (talk) 19:25, 1 October 2012 (UTC)

It is not at all alarmist to suggest that there will be backlogs. Take Special:Newpages, which is probably the closest thing we have to pending changes at the moment and which according to you is very well staffed. Yes, it has a backlog - there's over 100 pages from 4 September (four weeks ago) awaiting review, and the same is true for 5, 6 etc September. This particular backlog fluctuates, but usually there's several weeks' worth of pages there, a timespan that would be unacceptable for pending changes. The German Wikipedia's version of the pending changes tool, which admittedly has a different configuration, has plenty of unreviewed edits which have been sitting there for almost three weeks.[2] Hut 8.5 20:04, 1 October 2012 (UTC)

Ironically, I'd disagree with you about using Special:Newpages as an example. The new page curation tools took the backlog from almost 30,000 unreviewed pages to just over 15,000 in just a week, which is very striking. I do, however, think that the comparison with the German Wikipedia's flagged revisions is on target. That project bills its flagged revisions specifically as an anti-vandalism tool, which is what we hypothetically are doing as well, and it is concerning that their large community is having difficulty keeping up. Risker (talk) 22:12, 1 October 2012 (UTC)

@Beelbebrox: Actually the idea of automatically accepting old changes came up during the RfC [3] and was specifically mentioned in the close. Backlogs were also a huge concern in the RfC (just go there and do a search for the word Backlog). I take your point about having no evidence that there will be a backlog. I personally am not so optimistic, but in the case that there were no backlogs, the auto-accept bot would do nothing, and we'd be no worse off than we are now. This proposal is just a safety release valve.

Also, on the topic of alarmism, I'm having a hard time understanding the concern about vandalism and BLP violations slipping through the cracks and getting auto-accepted. To do so, the vandal's edit would have to escape detection by Cluebot, escape detection by the algorithms and users behind STiki and Huggle, escape detection by users who have the pages on their watchlist, escape detection by reviewers on the lookout for vandalism, and who have unreviewed PC edits highlighted in orange on their watchlists. If the vandalism is really that subtle it probably won't do that much damage if it goes live after 24 hours, and it can be reverted a couple days later when somebody finally does notice. Would it be bad to have this hypothetical subtle vandalism go live? Yes. Would it be as bad as disrupting normal editing for longer than 24 hours? I argue no. ~Adjwilley (talk) 22:43, 1 October 2012 (UTC)

Well, there were people who said all kinds of wild things in tht RFC (I believe there were several supporters who thought it should automatically be applied to just about every BLP), but the closers did not find a consensus on this point, or they would have posted it in their actual decision rather than as a passing mention in the summary. More importantly, you're making an argument that pending changes isn't even needed. Now, that's fine, and I wouldn't object to a complete reconsideration of the use of bad software, but I'm not going to bet the ranch it's going to happen. Risker (talk) 22:55, 1 October 2012 (UTC)

Yes, I do think some such edits could slip through the cracks. The vast majority of vandal edits are quickly reverted by RC patrollers, of course, but a handful escape detection, and if an edit is missed by the RC patrollers then it will probably last for weeks or months as the only people who could revert it are people who have the page watchlisted or readers who feel bold enough to edit the page to remove the vandalism. Bear in mind that PC may be applied to obscure pages where it is unlikely that the page is being watched or that whoever watches it logs in every day. BLP violations are even worse in that they're not necessarily obvious and we have a lot of quite experienced editors who don't properly understand the BLP policy. Hut 8.5 23:06, 1 October 2012 (UTC)

@Risker: My argument is that most vandalism gets reverted within 24 hours. PC just saves us the embarrassment of having it having it "live" for the half hour or so before it's reverted.

@Hut: Your assessment is correct, I believe. Some vandalism will always get through. It always has, and it always will. We do our best to eliminate it, but if we go too far we will, at some point, destroy the openness of the project. ~Adjwilley (talk) 23:17, 1 October 2012 (UTC)

• @Risker: A metric such as what you're describing is a good idea, but wouldn't that work better in conjunction with a bot that automatically accept unreviewed changes? And also, couldn't this bot automatically remove vandlaism from the unreviewed changes? I think the reason these changes need to go live automatically after a certain amount of time is because Wikipedia prides itself on being constantly up-to-date, and (with the following applying especially to BLPs) events in the real world can change in less than 24 hours. If a page on PC requires editing to stay up-to-date, but is being neglected by reviewers, will these unreviewed changes remain uninserted into the article indefinitely? RedSoxFan2434 (talk) 22:50, 2 October 2012 (UTC)

No. A bot inserting unreviewed changes defeats the purpose of pending changes. The community clearly didn't agree to having bots insert changes if people couldn't get around to reviewing them. Risker (talk) 23:30, 2 October 2012 (UTC)

• If there are any significant number of old unreviewed changes , PC will have failed, at least in the way we have implemented it. One key question has always been whether we could keep up with the flow of edits--in arguing for this proposal, the proponents always have said we would be able, and those who thought we wouldn't were being unduly skeptical. Well, let's find out. RTo avoid failure, we can adopt this for a very small number of pages at first; if we cannot even do that, regardless of any argument in its favor, we are not able to do it. If it works at a very small number but not at larger, we will have found out our limits. DGG ( talk ) 17:22, 2 October 2012 (UTC)
• This is just a crazy idea, and I don't know how hard it would be to write something like this, but it would be cool if the hypothetical bot that would accept the unreviewed changes were intelligent. For instance, ClueBot gives each and every edit on Wikipedia a score: the higher the score, the more likely the edit is to be vandalism. If it were a ClueBot-like bot that were accepting old changes, the bot could be programmed to accept only the changes that score below a certain number on the ClueBot scale. In this way the only changes that would get automatically accepted are those that are very unlikely to be vandalism, and the questionable edits would be more concentrated so that reviewers could be more efficient with their time. ~Adjwilley (talk) 23:03, 2 October 2012 (UTC)

Wow... that doesn't sound so crazy to me, as long as, of course, this isn't impossible or highly difficult to write (I don't know anything about how bots are created and written). RedSoxFan2434 (talk) 23:08, 2 October 2012 (UTC)

If the edits in question can be identified as vandalism and reverted by ClueBot, then is there a need to enable pending changes on the article? isaacl (talk) 00:09, 3 October 2012 (UTC)

If that's the only problem with that article, then probably no. But you might put a BLP under PC to keep a lid on potentially libelous statements, and still have an occasional instance of plain old vandalism. WhatamIdoing (talk) 00:31, 3 October 2012 (UTC)

The same could be asked about Semiprotection; however, we use it for the same reasons when vandalism is excessive (especially on BLPs). With PC, though, anons can still edit, their edits must just be reviewed first. However, in my opinion, PC only works if we have a good solution to this backlog issue, which Adjwilley's "crazy idea" is. RedSoxFan2434 (talk) 01:24, 3 October 2012 (UTC)

If article A is being vandalized but the problematic edits can be identified by a bot, then I'm not clear on the advantages of placing the article under pending changes protection and allowing the vandalism to be rejected by a bot, versus just letting the bot revert the changes on the article (protected or not). isaacl (talk) 01:44, 3 October 2012 (UTC)

Here's the long answer about ClueBot. ClueBot is smart enough that it can correctly identify about 90% of vandalism. However, if it were to revert all that vandalism it would revert an unacceptable of non-vandalism edits (false positives). Currently ClueBot is throttled so that it has a false positive rate of about 0.1%, or 1 revert of non-vandalism per 1,000 reverts, and at this rate it catches about 40% of vandalism. If the community decided that a higher false positive rate was acceptable (say, 0.25%) it could get about 55% of vandalism. The point is ClueBot can't and won't catch all vandalism: thus the argument for Pending Changes. My idea would involve basically running ClueBot backwards...In addition to reverting edits it's sure are vandalism, it could accept edits that it's sure aren't vandalism. ~Adjwilley (talk) 16:12, 3 October 2012 (UTC)

Thanks for the info; is statistics available on what percentages of edits can ClueBot identify as being non-vandalism, with, say, a false positive rate of 0.1%? isaacl (talk) 17:27, 3 October 2012 (UTC)

I doubt anybody's crunched those numbers because there's never been a demand or mechanism for ClueBot to "accpet" non-vandalism edits. Without pending changes edits are just accepted immediately by default. Everything I know I got from User:ClueBot NG#Statistics. ~Adjwilley (talk) 17:47, 3 October 2012 (UTC)

That page answers Isaacl's question pretty well: "Selecting a threshold to hold false positives at a maximal rate of 0.1% (current setting), the bot catches approximately 40% of all vandalism." Yaris678 (talk) 16:24, 4 October 2012 (UTC)

Actually, since Adjwilley is looking to use the ClueBot score in the opposite direction, I'm trying to determine the reverse situation: how many non-vandalism edits can ClueBot identify, with what false positive rate? If the percentage of edits reverted by ClueBot out of all of the edits it examines is known, then the current percentage of identified non-vandalism edits and the current false positive rate can be calculated, I believe, but more data/study would be required to determine how many non-vandalism edits could be identified with a specific false positive rate. isaacl (talk) 16:34, 4 October 2012 (UTC)

I see. How about a precision-recall graph? That lets you slice it any way you like.

This paper has some nice ones at the end of section 4. Unfortunately ClueBot NG doesn't get a mention. What we can see is that if you aim to get a decent proportion of vandalism with a low false positive rate then you want a language based system. This explains why CBNG is mostly language based. If you want to get a decent proportion of non-vandalism edits with a low false positive rate then meta-data and reputation are most important. Therefore CBNG is probably not what you are after. Of course, CBNG is probably better than the language based algorithm tested here but I suspect the general thrust of these results still holds. Yaris678 (talk) 17:32, 4 October 2012 (UTC)

I don't think the ClueBot idea is going to work. Even if the article is under PC solely to deal with persistent poop vandalism (which ClueBot is very skilled at recognizing), you still shouldn't accept edits that involve libel or copyvios, which ClueBot can't identify. WhatamIdoing (talk) 17:28, 5 October 2012 (UTC)

Automatically accept reverts

Currently, if an IP editor vandalizes an article protected by PC, and an autoconfirmed user reverts the vandalism, both edits will remain "pending" until a Reviewer accepts them. (The Reviewer would basically accept a "null" diff.) Furthermore, if another editor makes changes to the article before the reviewer accepts the latest revision, that user's edits will be "pending" as well. When the latest revision of the article is the same as the latest accepted revision, should the latest revision be automatically accepted?

Further information

This would have the benefit of being less disruptive to normal editing and saving Reviewers the hassle of accepting a bunch of "null" edits. It could be accomplished either by the software or by a bot that would monitor reverts in articles with pending changes. On the other hand, it would essentially give autoconfirmed editors the same power as reviewers when it came to reverting, and could be seen as an unfair advantage over IP editors.

Yes, automatically accept reverts

1. If an IP vandalizes an article and somebody who is not a reviewer reverts the vandalism, the story should end there. We shouldn't require that another editor come in to accept the revert before normal editing can resume. Reviewers have more valuable things to do with their time than pushing the "Accept" button for null edits. A bot can do the job just as well as a reviewer, and faster. ~Adjwilley (talk) 20:00, 30 September 2012 (UTC)
2. Accepting a null edit simply because it has to be accepted just feels like a bit of pointless bureaucracy. Anything that can make a reviewer's job easier should happen. elektrikSHOOS (talk) 19:38, 1 October 2012 (UTC)
3. Though preferential treatment for reverts is alarming, Monty's argument has persuaded me. Besides, the philosophical explanation for PC is that the version is being reviewed for vandalism, etc. - if the version has already been reviewed, why review it again? Wnt (talk) 00:07, 2 October 2012 (UTC)
4. If and only if the revert is back to the last accepted version (this alleviates problems mentioned below). Magog the Ogre (t • c) 01:04, 11 October 2012 (UTC)
5. Works fine in de:WP. JN466 08:41, 11 October 2012 (UTC)
6. If the version had been accepted earlier, then there is no reason not to accept it again. עוד מישהו Od Mishehu 15:34, 17 October 2012 (UTC)
7. I think JN is the one with the right idea — this idea is tested on German Wikipedia, don't reinvent the wheel, follow their lead here. Carrite (talk) 21:20, 17 October 2012 (UTC)
8. Yep. Makes sense on the face of it and, per JN, is born out in practice on de.WP. --Anthonyhcole (talk) 22:01, 17 October 2012 (UTC)
9. Yes, assuming that it doesn't do what some in the no section below think it might; ie be gameable. GedUK  11:36, 19 October 2012 (UTC)

No, don't automatically accept reverts

1. I think liberally handing out the reviewer flag is a better (and less technically complicated and expensive) solution. Beeblebrox (talk) 19:23, 30 September 2012 (UTC)
2. As I understand it (and I may be wrong), "rejected" versions aren't displayed to readers, but it's kind of a temporary thing. The software only keeps track of what the latest accepted revision is. So imagine an edit war: We begin with a perfectly good revision A. I vandalize it, which creates revision B. You revert to revision A. We all would like to have revision A automatically accepted. But I believe that if I then reverted to the vandalized revision B, that the software would automatically accept that, too, because revision B is a "prior version" and older than the latest accepted version. Additionally, you could use this to blank years' worth of improvements, because it's just a reversion to a prior version. WhatamIdoing (talk) 20:31, 30 September 2012 (UTC)
3. WhatamIdoing has seen exactly the problems I was going to ask about. This is still so untested that we would do much better to not automatically do anything, and I would oppose any bot having anything to do with the process, at least initially. We are in too much danger of setting up something that will run away with itself. DGG ( talk ) 00:16, 2 October 2012 (UTC)
4. The green box makes this look harmless, but per discussion below, I'm unconvinced it truly is. Kilopi (talk) 11:04, 3 October 2012 (UTC)
5. No, all items in the PC queue should be reviewed in the same way. --xensyria^T 21:22, 11 October 2012 (UTC)
6. What if the vandalism doesn't turn out to be vandalism? I can't get myself to support.—cyberpower ^Chat_{Limited Access} 12:56, 12 October 2012 (UTC)

Bots can accept their own reverts, if reverting to an accepted version, but not automatic for humans

1. Based on the discussion below I have added this option. I support it. Bots should be given the reviewer right. If, for example, ClueBot NG or 28bot revert an edit then we know that they are doing it for defined reasons that have been approved by the Bot Approvals Group. If a human reverts an unapproved edit and the revert is approved it could look like taking sides in an edit war. (Tangential issue, but bots that don't revert, such as TypoBot, should accept their own edit if and only if the version prior to it was accepted.) Yaris678 (talk) 17:51, 2 October 2012 (UTC)
2. I foresee problems with ClueBot NG and other vandal bots. The bots should ONLY approve revisions if there is only 1 prior unaccepted revision (logically that revision being vandalism). If there are more revisions, the bot should revert but not accept revisions. This is to prevent the other unapproved edits that could be problematic from being made visible.—cyberpower ^Chat_Online 13:03, 12 October 2012 (UTC)

Discussion about reverts

• One concern I have with auto-accept of reverts, is that it could result in an editor reverting an IP just so that there next edit could be made without getting caught by PC. I think a better approach would be to hand out enough reviewer permissions per Beeblebrox's position, that the queue stays small and this isn't a big issue, but I also sort of like the idea of letting logged in editors revert to minimize the impact of PC on them. I'll just stay down here with my comment as I'm torn on the issue. Monty₈₄₅ 20:05, 30 September 2012 (UTC)
• Can we give the Reviewer flag to Cluebot? Would that deal with a sufficient proportion of simple reversions that the rest wouldn't matter so much? WhatamIdoing (talk) 20:12, 30 September 2012 (UTC)

• User:ClueBot NG is a reviewer, and that will hopefully deal with a lot of simple reversions, but still a far cry from a sufficient proportion in my opinion. Cluebot only reverts the stuff it's 99.9% sure is vandalism, and only reverts once per day per article AFAIK. (If the vandal reverts Cluebot, Cluebot won't edit war.) Speaking of which, I should go ask Cluebot's masters if Cluebot is ready to deal with PC articles. ~Adjwilley (talk) 20:35, 30 September 2012 (UTC)

• Do we need a separate question to gauge the community's feeling on granting the reviewer bit to bots? Personally, I think it would be uncontroversial, but since we have an RfC this is a perfect place for people to disagree bobrayner (talk) 22:52, 30 September 2012 (UTC)

• @WhatamIdoing: I understand where you're coming from, but there's a flaw in your logic. The software would never revert to the vandalized version B, because B was never the "latest accepted revision". The software (or bot) would only automatically accept when the current revision is exactly the same as the last accepted revision. In other words, for your scenario to work, the vandalized version B would have to have been accepted by someone in the first place. ~Adjwilley (talk) 00:05, 1 October 2012 (UTC)

  Does the PC software actually keep a full, permanent list of every single version and whether or not it was accepted? I am under the impression that it only stores the current accepted version (one version per article) and treats all prior-to-accepted versions equally. It sounds like we need to find out how it actually works. WhatamIdoing (talk) 00:55, 1 October 2012 (UTC)

  The versions that are important are the "latest accepted revision" and the "current revision". All edits after the "latest accepted revision" are pending, and all revision before that are accepted. If somebody reverts from the "current revision" to the "latest accepted revision" then the reviewer will get a null diff to accept. This is the case where the bot would come in and automatically accept. If somebody reverts to a revision that is different than the latest accepted revision (accepted or no) it will not be a null-diff and the bot would wait for a reviewer to sort things out. You can check it out here if you like. ~Adjwilley (talk) 01:08, 1 October 2012 (UTC)

  So this would only process a fraction of the reversions, not all of them. WhatamIdoing (talk) 15:07, 1 October 2012 (UTC)

  Correct. It would only process reverts to the "last accepted revision". Reverts to other revisions would still have to be accepted/rejected manually. ~Adjwilley (talk) 15:10, 1 October 2012 (UTC)

  But then nobody would actually be likely to check the possibly good edits in the middle. No bots should be doing anything in this process, at least until the humans can figure out what is going to happen and get some experience with it DGG ( talk ) 00:18, 2 October 2012 (UTC)

  You do have an issue here, that if both the automatic acceptance of old edits and the automatic acceptance of reversions pass, you could end up in a situation where a vandalized version is auto-accepted. However, even if both pass, you could set the bot that accepts the reversions not to accept reversions to a version that has been accepted by a bot that looks at the length of time; I don't think that should be hard. Wnt (talk) 21:09, 2 October 2012 (UTC)

  Thinking about this further, this illustrates the difference in intent with the PC system. Is the purpose simply to check whether a revision is bad? Or is it to pick and choose among revisions to see which you like best? Because if you are only looking to exclude a bad revision, it doesn't matter what you miss in the middle - you wouldn't have looked at it if you didn't have PC. Wnt (talk) 23:40, 3 October 2012 (UTC)

• I think the logic here isn't sound. From editing de:WP the only thing that matters is whether the editor performing the action has reviewing rights or not, not what version was last marked reviewed. Whatever the reviewer does results in a reviewed article version. That works fine. JN466 08:40, 11 October 2012 (UTC)

Implementation: Ramp up slowly, watch backlog

The current provisional policy says little about how Pending Changes will be implemented. It is proposed that the following be added:

Pending changes protection should be ramped up slowly, and administrators should try to keep the number of pending changes-protected pages to a level that is manageable by the active reviewers. As a rule of thumb, if edits are frequently waiting longer than an hour to be reviewed, administrators should not apply PC protection to new pages and should instead look to reduce the number of pages under this type of protection.

Should this be added to the current provisional policy?

Yes (add it)

1. Qualified yes. One hour is too much to ask of volunteer reviewers. Should be longer than that, say four hours. Many requests for action wait at least that long without it being considered excessive. Beeblebrox (talk) 19:25, 30 September 2012 (UTC)
2. Yes, the ramp it up slowly part seems like common sense to me, but I don't like the part about looking to reduce the number of protected pages. ~Adjwilley (talk) 20:04, 30 September 2012 (UTC)
3. Another insufficient but nonetheless useful restriction. Wnt (talk) 04:13, 1 October 2012 (UTC)
4. Yes, because I predict that without such a statement, PC will be applied rapidly and somewhat carelessly by some of its staunchest supporters. Sven Manguard Wha? 15:42, 2 October 2012 (UTC)
5. Yes, this is an important safeguard to prevent the reviewers from being swamped from overeager PC application. Alanl (talk) 11:15, 3 October 2012 (UTC)
6. Definitely.—S Marshall T/C 00:12, 6 October 2012 (UTC)
7. This is an experimental feature, and should be treated as such. If we start using this in an uncontrolled way it can easily spread beyond the community's ability to handle the workload. Steven Walling • talk 02:21, 7 October 2012 (UTC)
8. Yes, but a longer delay than 1 hour (4 hours is not a bad suggestion) should be put into place if and when the 1 hour delay prevents widespread use of PC. --xensyria^T 21:22, 11 October 2012 (UTC)
9. This all depends on the availability of reviewers, which depends on who wants to volunteer to do so. There isn't any "recruiting" system on Wikipedia for reviewers or any other permission for that matter. Sure, you can "invite" them over to the job, but definitely make a slow start with this and if there are problems with backlogging, administrators should refrain from putting more pages on PC. If there isn't a big problem, great! Michaelzeng7 (talk) 23:21, 14 October 2012 (UTC)
10. Given my general view of PC, I'm temped to say "No", because if we let this accumulate the whole process will certainly fail. But taking a more constructive position, Yes, because for those who do want this to succeed, we should do it as slowly and carefully as possible to have the best chance of it working at all. DGG ( talk ) 01:32, 15 October 2012 (UTC)
11. Do add this to the policy. --EleoTager (talk) 16:27, 15 October 2012 (UTC)
12. The period of time is open to discussion; however, I think that the basic idea is good. עוד מישהו Od Mishehu 15:36, 17 October 2012 (UTC)

No (don't add it)

1. We should be sensible, and we should avoid mass-adds (especially during the first week or so), but adding the text to the policy itself seems like WP:CREEP, and the one-hour rule is too restrictive, especially since the length of time to review will likely depend on the time of day (so the same day, with the same number of articles, could normally see "60 minutes" and "20 minutes", depending on the percentage of our editors are asleep at that time). WhatamIdoing (talk) 19:31, 30 September 2012 (UTC)
2. It looks like a reasonable enough idea, but I do not think it should be set in stone; this kind of micromanagement is unhelpful. We don't have such rules for other forms of protection. (And if RfPP gets backlogged so it takes a day to get an article semi- or fully-protected, stepping back and letting the edit-warriors have their way is not an ideal solution). bobrayner (talk) 22:44, 30 September 2012 (UTC)
3. YES to ramping up slowly, NO to putting this in policy. davidwr/(talk)/(contribs)/(e-mail) 22:54, 3 October 2012 (UTC)
4. As others have said: all in favour of ramping it up slowly, but we don't need policy to say this. And one hour is far too restrictive. —Tom Morris (talk) 12:32, 5 October 2012 (UTC)
5. This is unenforceable, as assessing the current backlog is a difficult task. I envision waves of PC protections corresponding to the backlog state, which would mean that the decision process will fail to follow the necessity of protection as a primary principle. — Dmitrij D. Czarkoff (talk•track) 00:28, 7 October 2012 (UTC)
6. This sounds like reasonable wording for something with essay or perhaps guideline status, but it doesn't sound like policy wording to me. It's more or less common sense but it's unenforceable as written. Rivertorch (talk) 09:52, 7 October 2012 (UTC)
7. I oppose one hour as much too short, I'd support twelve hours; and an implementation guideline belongs here, as a strongly-supported resolution, rather than in policy. --Anthonyhcole (talk) 06:22, 10 October 2012 (UTC)
8. Per Anthony. --JN466 08:43, 11 October 2012 (UTC)
9. If it is beginning to get out of hand, it's time to recruit more reviewers.—cyberpower ^Chat_Online 13:06, 12 October 2012 (UTC)
10. One hour is too short in my opinion. CT Cooper · talk 18:28, 16 October 2012 (UTC)

Discussion about implementation

• Yaris678 and I discussed this somewhat at my talk page. I like the idea in principle but I won't vote under "yes (add it)" because a 1-hour time limit is itself unmanageable. I'd rather we go with a 24-hour time limit to give all reviewers an opportunity to be on Wikipedia. At the end of this time limit, I think a bot should automatically accept unreviewed changes, as I said in that section. As WhatamIdoing said, a 1-hour limit is a problem if, say, most reviewers are unavailable during that hour (due to sleep or work). Another idea that I had would be to replace this "rule of thumb" with a firm rule that defines the maximum ratio of PC pages to reviewers, perhaps at 10:1 or 15:1. RedSoxFan2434 (talk) 00:04, 1 October 2012 (UTC)
• I can definitely seem there is room for discussion on the 1 hour. Maybe 3 hours would make more sense, maybe not. However, I would remind people that (1) it is a rule of thumb and (2) it needs to be exceeded frequently to indicate we have a problem. Yaris678 (talk) 14:03, 1 October 2012 (UTC)
• Delay in reviewing is not desirable, but just what degree of delay is acceptable will depend on so many other things, particularly on the nature and prominence of the articles that are subject to PC , that this will have to be looked at as we go along. Even if we did a very loose rule, like 24 h, this would discourage adopting a shorter times if it appeared moresuitable once we actually get started. DGG ( talk ) 00:14, 2 October 2012 (UTC)
• My recollection from my limited time reviewing during the trial was that when edits were pending for more then an hour or so it was often not due to a lack of reviewers, but due to a lack of reviewers willing to make the call on that particular edit. How would the above standard work if that was the sort of edit in the queue for the time period chosen? Monty₈₄₅ 00:29, 2 October 2012 (UTC)
  • An interesting observation that fits with my own recollection. Presumably such edits, where reviewers didn't want to make the call, were not frequent, otherwise PC would just grind to a halt. This makes me feel the rule of thumb is about right. Yaris678 (talk) 09:46, 2 October 2012 (UTC)
• I don't know what level of delay will be considered acceptable and it probably shouldn't be written into policy anyway. I do suggest that average wait times (and if implemented, the number of auto-accepts) be logged and a common-sense recommendation that admins check that log before applying PC. Kilopi (talk) 11:04, 3 October 2012 (UTC)
• It seems like almost everyone thinks that this is a good idea but roughly 50% of people don't think it should be written into policy. It is interesting that this is the only issue where the proposal was specific about writing something into policy. Does something on this idea need writing somewhere like a guideline or essay? Or are we happy that we can just point to this RfC if there is any issue about this in future? I guess if we can't decide then we have an interesting situation. Consensus on what to do but no consensus on how to document that it needs to be done. Yaris678 (talk) 12:07, 8 October 2012 (UTC)

• I'm finding myself beginning to balk at the number, complexity, and verbiage of the policies on WP. Much of what is currently laid down as law is nothing more than common sense or the wisdom gained from experience. When it comes to PC, there's general disagreement about nearly every aspect of what it is, what it does, and what it may do to the project. There's clearly not much support for crafting a really comprehensive policy that forestalls most of the anticipated problems, so it's probably best to keep the wording short and malleable. That way, it should be easier to build on and modify as necessary. Rivertorch (talk) 19:26, 8 October 2012 (UTC)
  • Here's an idea. Create Wikipedia:Rough guide to pending-changes protection, which would be an equivalent of Wikipedia:Rough guide to semi-protection. That says "This is an information page that describes communal consensus on some aspect of Wikipedia norms and practices. While it is not a policy or guideline itself, it is intended to supplement or clarify other Wikipedia practices and policies. Please defer to the relevant policy or guideline in case of inconsistency between that page and this one." Possibly this could be expanded with the sentence "The way that the community uses PC will develop over time so don't take this page as hard and fast rules rules. Rather, use this page to document practice as it develops." Yaris678 (talk) 15:59, 11 October 2012 (UTC)

• We also have a number of people saying that it needs to be easier to assess the backlog and no one objecting to that. I think this should go forward as a request to the devs. I don't think we need to wait for it to be implemented before rolling PC out, so long as we do roll out PC slowly and do try to watch the backlog by whatever means we have. Yaris678 (talk) 12:12, 8 October 2012 (UTC)

Motion to close

Pursuant to the procedural note at the top of this page, a motion to close this RfC has been offered. Please vote at the talk page.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.