Wikipedia:PC2012/RfC 2

May PC be applied to pages to protect against vandalism?

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

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

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

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

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: . 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)

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)

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

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)

Should this be added to the current provisional policy?

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)