As with the previous RfC, some sections are much clearer-cut than others. There was very strong consensus to enable the use of Pending Changes throughout all namespaces, though it's worth noting that its use on transcluded templates would need extra attention because, as was pointed out, transclusions will only show the latest revision regardless of whether it's been approved. There was unanimous agreement that the best venue for requesting PC would be the current Requests for Page Protection board, and nearly unanimous agreement that a new noticeboard dedicated to PC was unnecessary. In addition, the initial removal policy of the reviewer right met with no objections; as it's an initial policy, this is something we will have to review after a few months to see if it's actually effective. Then there's the question of whether we need specific eligibility criteria for PC. The consensus on this was fairly clearly against having any specific criteria, but a significant minority expressed concern that its use is less well-defined than is the use for conventional protection methods; if enormous inconsistencies with application are seen upon implementation, this may be a topic worth revisiting. As to where the policy on use of Pending Changes should be located, the consensus seems to be that it belongs as a section on the current protection policy page, and there was no objection to using the page WP:Pending changes as an information page on the tool itself, similar to WP:Rollback. Finally, the draft guide for reviewers underwent some changes during the course of the RfC, and there didn't seem to be any significant opposition to said changes; like all guidelines, it should evolve as PC is rolled out and we're dealing with real scenarios. As with the previous RfC, assessing the usefulness of what gained consensus here will require some monitoring. The same time frames (1 month for obvious problems, more for subtler issues) seem to fit with everything in this discussion as well. It appears that after this and the previous RfCs, we have the necessary framework to roll out Pending Changes, and we know what aspects of its use will require the most monitoring and later attention. The Blade of the Northern Lights (話して下さい) 22:22, 28 November 2012 (UTC)[reply]

This RfC is the third in a series of RfCs on Pending Changes. Based on prior feedback, a draft policy is located at WP:Pending Changes. A draft guideline for reviewers is at WP:Reviewers. General comments or concerns regarding the drafts that are not addressed by questions below may be discussed in the appropriate section near the bottom.

• Note: This RfC will likely not run a full 30 days. Pending changes is planned to go live on December 1, so this will close, at the latest, several days prior to that. Plan accordingly.

Should PC only be used on articles that meet specific, firm criteria (e.g., the number of users watching a page or the frequency of unregistered users editing the page; please specify), or should it be up to administrator discretion? RfC 2 determined that pages eligible for PC must have persistent vandalism, copyright, or BLP problems.

Comments[edit]

• No. We don't have hard requirements for conventional protection, and I see no reason why we should impose requirements on PC. Let the admin use his/her judgement. David1217 ^{What I've done} 16:13, 28 October 2012 (UTC)[reply]
• It should be a case-by-case judgment call left to administrative discretion. Carrite (talk) 16:19, 28 October 2012 (UTC)[reply]
• General guidelines are sufficient, admins are expected to use their discretion and to treat any policy with common sense. hard requirements would be obstructive instead of helpful. Beeblebrox (talk) 20:59, 28 October 2012 (UTC)[reply]
• No requirement is hard, per WP:IGNORE. There is obviously some room for discussion about how amazingly good your reason has to be before you can ignore these rules. However, I think that can be worked out as we go along. If an admin applies PC to a page and then another admin quickly removes it its not the end of the world. If it is removed after a day of discussion it is not the end of the world... that sort of situation may even help us to improve the guidelines. Obviously it would be nice if people were civil in any such discussions but the important thing is that we will get to the answer in the end. That is the strength of wikis. We don't need to decide everything in advance. Yaris678 (talk) 16:54, 29 October 2012 (UTC)[reply]
• No, it should just be case-by-case; administrators should be allowed to use their own judgement. This might lead to some contradictions at first, but a consensus will form pretty quickly about what is generally accepted. If necessary after this it may be helpful to identify some guidelines. GedUK  14:19, 7 November 2012 (UTC)[reply]
• Yes and no. There should be an obvious need for protection, but not enough of a need to disallow editors from editing the page alltogether. gwickwire | Leave a message 00:26, 8 November 2012 (UTC)[reply]
• Solutions should evolve rather than being written in stone before we even get started. - Dank (push to talk) 00:55, 8 November 2012 (UTC)[reply]
• I agree with Dank. We should wait for a solid background in Pending Changes before we decide the criteria. Even after that, I would say Administrator discretion, as with existing Semi- and full protection. Vacation⁹ 02:37, 8 November 2012 (UTC)[reply]
• Admin discretion, as per standard.--Tznkai (talk) 18:00, 8 November 2012 (UTC)[reply]
• Agree with most of what was said by others, Admin discretion like most things. IRWolfie- (talk) 23:38, 9 November 2012 (UTC)[reply]
• No - same thing with regular protection; if someone has a complaint about it, work it out on the basis of that particular page. ⁓ Hello71 15:11, 10 November 2012 (UTC)[reply]
• No - though I trust that anyone asking for PC on a page will, in fact, monitor changes. Collect (talk) 22:29, 10 November 2012 (UTC)[reply]
• Weak yes. I dislike the idea of PC's being available as an open-ended alternative to semi-protection and would prefer to see its officially sanctioned use limited to specific contexts where semi doesn't work well. Then again, we don't really know how (or indeed if) PC is going to work out, and my position is evolving to acknowledge that it may be better remain as flexible as possible at the outset. Based on what we learn, I'd imagine that after several weeks or perhaps months it may be advisable to set some limits. Rivertorch (talk) 08:04, 12 November 2012 (UTC)[reply]
• I have an idea: don't use PC at all! OK, seriously, I guess it's a done deal, so I agree with many editors above that we ought to play it by ear, and allow some flexibility. As with most things Wiki, experience will show what does and doesn't work. --Tryptofish (talk) 23:24, 12 November 2012 (UTC)[reply]
• It should mirror the current protection policy for full and semi-protection. There should be guidelines that give general instruction on what types of events should occur before PC protection is applied, but it should not be overly specific, and should allow admins to use some amount of discretion and common sense. ‑Scottywong| talk _ 23:54, 12 November 2012 (UTC)[reply]
• Using your best judgement == good. Let's get away from bot-level rules, which might lead to overuse on all articles that "qualify" rather than only where it's most needed. WhatamIdoing (talk) 00:49, 13 November 2012 (UTC)[reply]
• Yes to admin discretion and common sense. First Light (talk) 01:56, 14 November 2012 (UTC)[reply]
• It would be downright bizarre to rely on administrative discretion for harsher measures (like deletion) yet restrict their ability to use lesser means of protection. — Coren ^(talk) 13:58, 15 November 2012 (UTC)[reply]
• Yes. We have so little agreement among the admins for when to do this that without some specific guidance, there will be grossly inconsistent decisions. For the conventional methods we have worked out rough agreement, so the analogy does not apply. DGG ( talk ) 21:54, 15 November 2012 (UTC)[reply]
• No, I don't think we need a hard requirement. I think PC can be used effectively when considering its value on a page-by-page basis. Canuck^{89 (talk to me)} 05:33, November 16, 2012 (UTC)
• No, avoid adding any other bureaucracy such as counting frequency of vandalism. Admin discretion is more than enough.--Mark91it's my world 00:13, 17 November 2012 (UTC)[reply]
• No. Use admin discretion, as for other forms of protection. Begoon ^talk 13:46, 17 November 2012 (UTC)[reply]
• No. Like with regular page protection, any criteria would have to be ridiculously complicated and would never be viable. Admin discretion is necessary for such cases. CT Cooper · talk 16:57, 17 November 2012 (UTC)[reply]
• No, as per Beggon. Buckshot06 (talk) 22:21, 17 November 2012 (UTC)[reply]
• It should be left to administrator discretion (no "specific criteria"); however there should be a guideline for administrators saying that it should be avoided on articles with a high edit rate and lots of watchers. — Preceding unsigned comment added by Adjwilley (talk • contribs) 22:26, November 19, 2012‎
• Should be left on admin discretion. Harsh (talk) 16:02, 21 November 2012 (UTC)[reply]

Is it permissible to protect pages in any namespace or only certain namespaces? (It doesn't work on talk pages.) Please comment in a subsection below.

Yes, anywhere.[edit]

PC may be applied in any namespace (e.g., project, category, portal, user) at the protecting administrator's discretion.

• Why not? We use semi-protection in all namespaces. David1217 ^{What I've done} 16:13, 28 October 2012 (UTC)[reply]
• PC should just be considered another tool on the shelf and used wherever appropriate. Beeblebrox (talk) 21:00, 28 October 2012 (UTC)[reply]
• I can't imagine why anybody would want to use it in another namespace (Userspace, for instance) but I don't think we need to write a rule saying that you can't. ~Adjwilley (talk) 17:23, 29 October 2012 (UTC) Upon further reflection I can see an argument for using this in the template namespace, so 'Yes'. ~Adjwilley (talk) 22:22, 19 November 2012 (UTC)[reply]
• Yes, should be able to be applied anywhere. It's highly unlikely to be used I'd have thought, but even so, portals do get vandalised from time to time. GedUK  14:20, 7 November 2012 (UTC)[reply]
• Yes. Any page can be semi-protected, I think that any page should be able to be PC protected. That way, new editors can edit without having to make an edit request (and that category is usually backlogged with about 5-10 all the time anyway). gwickwire | Leave a message 00:26, 8 November 2012 (UTC)[reply]
• Sure, the comments so far make sense. - Dank (push to talk) 00:57, 8 November 2012 (UTC)[reply]
• Yes. I agree with the other comments, semi protection can apply on any page and the same should apply for PC. Vacation⁹ 02:39, 8 November 2012 (UTC)[reply]
• As an additional anti-vandalism tool, this should be used in the same manner and in the same range of places where page protection is currently used. Carrite (talk) 17:07, 8 November 2012 (UTC)[reply]
• Yes. Of course. — ΛΧΣ21™ 22:11, 11 November 2012 (UTC)[reply]
• Per Adjwilley; I don't see why we would need PC in another namespace, although a rule preventing such isn't necessary. RedSoxFan2434 (talk) 17:28, 12 November 2012 (UTC)[reply]
• Using your best judgement == good. WhatamIdoing (talk) 00:48, 13 November 2012 (UTC)[reply]
• I don't just use a hammer on a nail, sometimes other things need a wack. Why limit this tool? --Nouniquenames 18:34, 13 November 2012 (UTC)[reply]
• The main point of Pending Changes is to prevent vandalism and BLP problems in article space. But if it can be sensibly used elsewhere, why not? First Light (talk) 01:57, 14 November 2012 (UTC)[reply]
• Absolutely. Just like deletion and protection, stupid decisions can always be reversed. Someguy1221 (talk) 01:20, 15 November 2012 (UTC)[reply]
• Support except for the user talk namespace I think it's imperative that we don't use PC on user talk pages, as many new users won't understand PC, and PC would cause confusing, frustrating hampering of communication for the users where good communication has the greatest impact. I'm also weary of PC on any talk namespace, because those are rarely vandalized, and again, we need to keep the lines of communication open, however user talk is the only one I'd expressly prohibit PC on. Sven Manguard Wha? 06:17, 15 November 2012 (UTC)[reply]
• PC is a "gentler" tool, it makes sense to allow it anywhere protection is allowed. — Coren ^(talk) 13:59, 15 November 2012 (UTC)[reply]
• Although I can imagine PC will largely be used in article-space, I don't think we need a rule that states it can't be used elsewhere if needed. Canuck^{89 (converse with me)} 05:31, November 16, 2012 (UTC)
• Per Coren - no sense in different rules. Begoon ^talk 13:48, 17 November 2012 (UTC)[reply]
• I don't see any need for a limit, though naturally the main area of use will be in the mainspace. CT Cooper · talk 16:58, 17 November 2012 (UTC)[reply]
• I'd hate to make too hard-line a restriction--if we had something like "new admin school" for reviewers, the test page would presumably be in the Wikipedia namespace. *shrug*. Of course there will be namespaces it's ill-suited for (user talk, as Sven rightly points out), and a note in the discussion area leaves me wondering if there will be any use for it at all in Template space. That having been said, I think experience will likely be an excellent guide, once we have it. --j⚛e decker^talk 06:58, 15 November 2012 (UTC)[reply]

No. PC may only be applied to articles.[edit]

There's no case to apply PC to anything other than articles; that is its purpose, to allow otherwise "disenfranchised" non-registered and new users to edit articles. Seriously, we're going to apply it to user talk pages? Noticeboards that can get hundreds of edits a day? I don't buy the template argument either; high use templates should at least be semi-protected explicitly because we don't want new or unregistered users editing them without being able to demonstrate that they understand the effects of doing so. (Indeed, the main reason they're semi- or fully protected is because we have enough unregistered and "new" users who understand full well what the effect is, and are very happy to contribute their penis vandalism.) Risker (talk) 22:35, 12 November 2012 (UTC)[reply]

• Preventing the common vandalism while keeping constructive edits is PC's big idea. Semi-protection (or full protection) should still be used for anything other than an article, per Risker. I don't think there is any need for PC out of the article space, and we've already seen some problems with PC in the article space. Michaelzeng7 (talk) 01:39, 14 November 2012 (UTC)[reply]
• I personally see PC as a useful tool for BLPs and highly vandalized articles; I do not see much use in other namespaces. In any case, I do not think it will be used a lot in other namespaces anyway. --Mark91it's my world 00:16, 17 November 2012 (UTC)[reply]

No. PC may only be applied to articles or templates.[edit]

• Weak preference. PC should be about protecting article integrity, not policing garden variety nonsense.--Tznkai (talk) 17:39, 8 November 2012 (UTC)[reply]
• Can't see any reason that PC protection would ever need to be used on pages in the User, Wikipedia, File, Help, Category, Portal, Book, or any of the Talk namespaces. ‑Scottywong| gab _ 23:56, 12 November 2012 (UTC)[reply]
• Yeah, it doesn't seem to make sense to use PCs outside of the article or template space. I think having it on WP space would be particularly difficult to maintain and will probably cause more trouble than benefit. I, Jethrobot ^{drop me a line} (note: not a bot!) 05:29, 14 November 2012 (UTC)[reply]

Discussion (namespaces)[edit]

• We should be careful when applying PC to templates. It may potentially be a good idea because it will draw the attention of reviewers to any edits to the template. However, when transcluded, a template will just appear in its latest version, irrespective of whether that version is approved or "pending". i.e. PC on templates isn't completely pointless but it doesn't achieve what PC usually achieves. Yaris678 (talk) 12:59, 15 November 2012 (UTC)[reply]
  • Thanks, I had not known this. --j⚛e decker^talk 19:51, 18 November 2012 (UTC)[reply]

The pending changes policy could be located at WP:PC or be incorporated into the existing page protection policy or at a completely new page. Where should the pending changes policy reside? Please comment in a subsection below.

On its own page at WP:Pending changes[edit]

• For the first few months, we need WP:PC to put as a link in edit summaries and protection logs so that people who have no clue what it is can find out the whole story, instead of a snippet paragraph on the Page protection page. gwickwire | Leave a message 00:26, 8 November 2012 (UTC)[reply]

As part of WP:Page protection[edit]

Merge the PC policy into the regular protection policy at Wikipedia:Page protection. Other advice or how-to information could go in WP:PC or other pages.

• Same place. Keeps it simpler. The only time I would support spinning PC out is if it had so many rules on when it can be used (such as the ones above) that it makes the protection policy very long. David1217 ^{What I've done} 16:13, 28 October 2012 (UTC)[reply]
• Should be integrated with the protection policy. Despite how some have characterized PC it really is just a different way of protecting a page and it should not be made out to be some big deal that is somehow segregated from other forms of protection. Also, having all protection policies in one place is more helpful for those unfamiliar with how protection works. Beeblebrox (talk) 21:02, 28 October 2012 (UTC)[reply]
• Should be explained here in detail and summarized at WP:Protection policy. Basically the way it is now. ~Adjwilley (talk) 17:25, 29 October 2012 (UTC)[reply]
  • So would you make this page our 55th official ((policy)) page, or would you make it an informational page or guideline, with the formal policy at WP:PP? WhatamIdoing (talk) 19:13, 29 October 2012 (UTC)[reply]
    • Point taken, and thanks for helping me understand the real question. I would make this an informational/guideline page, leaving the official policy at WP:PP. (I think PC should basically be treated the same as Semi-protection.) ~Adjwilley (talk) 19:18, 29 October 2012 (UTC)[reply]
• (Supplement to my comment above in "own page"). Should also be listed as a paragraph under the protection policy page. gwickwire | Leave a message 00:26, 8 November 2012 (UTC)[reply]
• Same place. As David1217 said, it makes it simpler and gives a feeling of integration. As Beeblebrox said, it is just a different way of protecting a page. It is not segregated from other methods. Vacation⁹ 02:41, 8 November 2012 (UTC)[reply]
• This should be made another aspect of current page protection policy. Carrite (talk) 17:08, 8 November 2012 (UTC)[reply]
• Something needs to be at WP:Protection policy. We could also have a guideline page, although it's too early to say whether that will be needed. - Dank (push to talk) 02:22, 9 November 2012 (UTC)[reply]
• Per Dank, with the caveat that it will need to be moved if it makes WP:PP too long and/or confusing. I'd very much like to see a separate guideline page. Rivertorch (talk) 08:09, 12 November 2012 (UTC)[reply]
• It should certainly exist at WP:PP in a form similar to what it is now, even if given its own page as well. RedSoxFan2434 (talk) 17:38, 12 November 2012 (UTC)[reply]
• The policy should be explained concisely at WP:PP. If there are other non-essential nitty-gritty details, perhaps they can live at WP:PC. ‑Scottywong| soliloquize _ 23:58, 12 November 2012 (UTC)[reply]
• Let's not have an ever-multiplying list of official policies. We should integrate the actual policy into WP:Page protection, and put any practical advice/how-to/descriptions/history/guidelines/whatever at WP:PC. WhatamIdoing (talk) 00:48, 13 November 2012 (UTC)[reply]
• Yes, make it part of the page protection policy to give it some context. But if it gets too long, then just summarize it there. First Light (talk) 02:00, 14 November 2012 (UTC)[reply]
• Might also consider putting a hatnote for WP:PC on WP:PP and/or adding it to the "See Also" section. I, Jethrobot ^{drop me a line} (note: not a bot!) 05:30, 14 November 2012 (UTC)[reply]
• The criteria are similar enough, and the applicability is much of the same. I view PC as a gradated step to and from the other kinds of protection, and it should be handled accordingly. — Coren ^(talk) 14:01, 15 November 2012 (UTC)[reply]
• Agree: avoid adding more confusion and fragmentation: use WP:PC only as a practical how-to guide.--Mark91it's my world 00:18, 17 November 2012 (UTC)[reply]
• Yes. It's just another form of protection. Begoon ^talk 13:50, 17 November 2012 (UTC)[reply]
• Pending changes is ultimately just an extension of page protection, so it makes sense to integrate the two together. CT Cooper · talk 16:59, 17 November 2012 (UTC)[reply]

As part of WP:PP with a separate page to explain PC[edit]

• Idea: Put specifics about how PC specifically works on WP:PC (a page similar to WP:ROLLBACK wrt interface etc) and have policy on WP:PP. ⁓ Hello71 15:15, 10 November 2012 (UTC) (edited 17:57, 12 November 2012 (UTC))[reply]
• I suggest creating a WP:Rough guide to pending-changes protection guideline page or similar to accompany WP:PCPP, which is the section of WP:Protection policy devoted to Pending Changes. This is in line with WP:Rough guide to semi-protection, which expands upon WP:SEMI at the Protection policy page. RedSoxFan2434 (talk) 17:38, 12 November 2012 (UTC)[reply]
• I agree with RedSoxFan2434. Part of the problem at the moment is the uncertain status of the page WP:Pending changes. It is a "proposed Wikipedia policy, guideline, or process". Meaning that we don't know whether to put stuff in there if it has only a vague consensus. If we create WP:Rough guide to semi-protection, we can describe the nature of the consensus around things where it might still be an issue. I'm not sure but maybe WP:Pending changes could become something of a disambiguation page. Yaris678 (talk) 13:08, 15 November 2012 (UTC)[reply]

At some other page[edit]

Put the PC policy somewhere else (specify).

Discussion (where should policy reside?)[edit]

When people want to request that an article be placed under PC protection, should the request be made at Wikipedia:Requests for page protection?

Responses (venue for protection requests)[edit]

• I think we should use the existing board so that the administrators can choose the most appropriate option. Gigs (talk) 08:05, 28 October 2012 (UTC)[reply]
• Use RPP. That way, we don't have confusion if a page with request for PC protection is instead semi-protected, and vice versa. David1217 ^{What I've done} 16:13, 28 October 2012 (UTC)[reply]
• Admins should be expected to consider every option when evaluating any request for protection and to chose whichever is appropriate for the situation. There is no need and no logical reason to create a separate forum just for discussing PC requests, doing so would only be pointless beuracracy serving no good purpose. Beeblebrox (talk) 20:57, 28 October 2012 (UTC)[reply]
• Use RPP. We need a centralized location. No need to make it any more confusing. ~Adjwilley (talk) 17:21, 29 October 2012 (UTC)[reply]
• Yes, use RPP. People currently request different forms of protection there, and the admin will make the decision on what the appropriate one should be. PC is just another form of protection. GedUK  14:21, 7 November 2012 (UTC)[reply]
• Yes, use WP:RPP for requests. All other protection is requested there for now (mostly), and this shouldn't be any different. gwickwire | Leave a message 00:26, 8 November 2012 (UTC)[reply]
• Yes. Makes it simpler and non-segregated. Shouldn't be any different from existing methods. Vacation⁹ 02:42, 8 November 2012 (UTC)[reply]
• Use existing RPP. Centralization and simplification of WP's backstage structure is good. Carrite (talk) 17:11, 8 November 2012 (UTC)[reply]
• Per Ged and others. - Dank (push to talk) 02:24, 9 November 2012 (UTC)[reply]
• Yes per all. ⁓ Hello71 15:16, 10 November 2012 (UTC)[reply]
• I find WP:RPP a frustrating page because of how quickly its entries come and go, but I guess we can give it a try. I rather wish that RPP reports could be somehow transcluded to the talk page (or maybe the log page) of the protected article, but I suppose that's neither here nor there vis-à-vis this RfC. Rivertorch (talk) 08:17, 12 November 2012 (UTC)[reply]
• I support keeping Page Protection requests centralized at RPP; continue that with Pending Changes requests. RedSoxFan2434 (talk) 17:48, 12 November 2012 (UTC)[reply]
• Use RPP. PC should always be regarded as an alternative to the other kinds of protection, not as something in a category by itself. --Tryptofish (talk) 23:28, 12 November 2012 (UTC)[reply]
• RPP is already set up for this purpose, so no sense in making a new place for requests. ‑Scottywong| prattle _ 23:59, 12 November 2012 (UTC)[reply]
• Support per most of the above.--SPhilbrick(Talk) 20:43, 13 November 2012 (UTC)[reply]
• Naturally. If any problems, of which I can't think of any now, arise, we can discuss the issue then. Michaelzeng7 (talk) 01:41, 14 November 2012 (UTC)[reply]
• Yes, use RPP so it is in context with other options, and so that admins have discretion. First Light (talk) 02:02, 14 November 2012 (UTC)[reply]
• Support putting it at RPP, but I think it needs a separate section. I anticipate RPP will be inundated with such requests when Pending Changes reboots, and they shouldn't overshadow the other requests for protection. I, Jethrobot ^{drop me a line} (note: not a bot!) 05:35, 14 November 2012 (UTC)[reply]
• Single venue, please. A large fraction of protection requests, even those that end up getting some form of protection, ask for the wrong kind. Segregating them isn't going to actually segregate the work that needs to be done. --j⚛e decker^talk 07:03, 15 November 2012 (UTC)[reply]
• RPP. Admins examining the request may well find protection is more appropriate while looking at a PC request or, conversely, might find PC would be better where protection had been requested. Flexibility is key. — Coren ^(talk)
• RPP. Again, avoid adding extra fragmentation/bureaucracy. Keep it simple, one page for one kind of requests.--Mark91it's my world 00:19, 17 November 2012 (UTC)[reply]
• RPP. As is now the case, admins may use their discretion to use a different form of protection than that requested. Having them in separate places makes no sense. Begoon ^talk 13:53, 17 November 2012 (UTC)[reply]
• Yes for RFPP per comments in previous section - pending changes is closely related to page protection, so a separate page seems pointless. CT Cooper · talk 17:01, 17 November 2012 (UTC)[reply]

Discussion (venue for protection requests)[edit]

While discussions related to pending changes policy will continue to take place at WT:PC, WT:PP, or another dedicated page and requests for pending changes will be made at WP:RPP or another page (see previous question), a dedicated Pending Changes Noticeboard would serve functions clearly beyond the scope of any of those pages. Such a noticeboard would provide a centralized place to discuss the merits of certain pending edits, raise concerns about backlogs, and conduct extended discussions about PC's use on specific pages.

Should a Pending Changes Noticeboard be established?

Responses (noticeboard)[edit]

• I'd say play it by ear at this stage. If the need for one becomes apparant, then it's useful, otherwise it's unnecessary. GedUK  14:23, 7 November 2012 (UTC)[reply]
• No. Let's not make up nonexistent problems and then try and solve them. If this should become needs it can be created easily enough but at the moment I don't see the point at all. Beeblebrox (talk) 00:22, 8 November 2012 (UTC)[reply]
• Yes, a noticeboard should be established. But it should only be used for editors who are wishing to post some edits that they would like to generate discussion from other Reviewers over. That way, the policy can be refined as necessary by the Reviewers and all of them can agree on the types of edits acceptable. I know this is in the policy, but a noticeboard would be good. gwickwire | Leave a message 00:26, 8 November 2012 (UTC)[reply]
• Yes. I agree with gwickwire. There should be a place where editors could receive discussion from Reviewers over changes. Vacation⁹ 02:44, 8 November 2012 (UTC)[reply]

Changing my mind. I think there should not be a noticeboard. I agree with other users, and it would make it more complicated. It is also unneccesary. Vacation^nine 17:13, 10 November 2012 (UTC)[reply]

• No. Too many damned noticeboards already. Integrate the new tool into an existing complaint structure. Carrite (talk) 17:10, 8 November 2012 (UTC)[reply]
• Not now. If we really need such a thing, then we can create it later. If we don't really need such a thing, then let's not have an endless multiplication of noticeboards. WhatamIdoing (talk) 01:14, 9 November 2012 (UTC)[reply]
• I'm happy to leave this question up to the active reviewers. - Dank (push to talk) 02:29, 9 November 2012 (UTC)[reply]
• Not now, and probably not ever. We already have such things as talk pages to discuss article content on, and RfC if that isn't enough. ⁓ Hello71 18:20, 9 November 2012 (UTC)[reply]
• Yes. Among its other advantages, such a board would foster collaboration by facilitating focused discussions between reviewers who otherwise would be "flying solo" when deciding what edits to accept, what accepted edits need subsequent undoing, and so on. Try thinking of it not as a Pending Changes Noticeboard but as a Reviewers' Noticeboard, a place where reviewers can go to get second opinions from their peers. Or don't call it a noticeboard at all, if that's the hangup. But despite some of the comments above, the proposal is not for a noticeboard for problems (nonexistent or otherwise), complaints, or solely article content; it could be for all of those things, but it would mostly be for something that no other venue would accommodate. Rivertorch (talk) 08:35, 12 November 2012 (UTC)[reply]
• No. No justification for having a separate noticeboard for this, and the proliferation of single-issue noticeboards has resulted in users with specific points of view gatekeeping on those boards. Risker (talk) 22:38, 12 November 2012 (UTC)[reply]
• No. It's better to enable an administrator to evaluate whether PC, or semi, or something else is the best choice. --Tryptofish (talk) 23:29, 12 November 2012 (UTC)[reply]
• No, existing noticeboards and policy talk pages will suffice. ‑Scottywong| express _ 00:00, 13 November 2012 (UTC)[reply]
• No, as long as there is a page where reviewers can see a listing of all articles with Pending Changes that need reviewing. Maybe this has been discussed elsewhere? First Light (talk) 02:05, 14 November 2012 (UTC)[reply]
• No. But I think on WP:PP, requests for PC and other protection requests should be separated, at least a first because we may get a lot of requests right away. I, Jethrobot ^{drop me a line} (note: not a bot!) 05:38, 14 November 2012 (UTC)[reply]
• No. The last thing we need is additional noticeboards. We should be moving in the opposite direction. DGG ( talk ) 21:50, 15 November 2012 (UTC)[reply]
• No. Let's use talk pages!! --Mark91it's my world 00:20, 17 November 2012 (UTC)[reply]
• No. I think existing talk pages should be sufficient. Assuming WP:PP becomes the pending changes policy page, WT:PP should be the default starting location for any policy changes (problems with policy such as backlogs e.t.c. naturally should also be discussed on policy talk pages, so whether or not any noticeboard is actually for implementing policy changes is irrelevant, since WT:PP can do it all), and after that RfC. CT Cooper · talk 17:17, 18 November 2012 (UTC)[reply]
• No. I think these issues can safely be discussed on the pages we currently have (AIV, RPP, talk pages, etc.). If problems arise we can always revisit this. ~Adjwilley (talk) 22:31, 19 November 2012 (UTC)[reply]

Discussion (noticeboard)[edit]

• If the noticeboard is created, would someone be able to create a bot or script to notify Reviewers of new posts? gwickwire | Leave a message 00:26, 8 November 2012 (UTC)[reply]
  • Great idea. I would fully support a bot nom for this if someone takes the time to create one. Vacation⁹ 02:53, 8 November 2012 (UTC)[reply]
  • Why? A noticeboard is just a page with a fancy name. Put it on your watchlist, just like people put WP:COIN and WP:ELN on their watchlists. WhatamIdoing (talk) 01:11, 9 November 2012 (UTC)[reply]
• I'm really curious about some of the responses here, many of which posit that existing pages are adequate. Where exactly would a reviewer who wants to discuss a particular pending change go to raise the issue? Not the article's talk page; there's no mechanism to point other reviewers to look there. Not WP:PC; if reviewers did ending up frequently discussing particular pending changes, that page would soon fill up and be useless for any other purpose. Certainly not WP:RPP. Admins ask for feedback on recent actions (and occasionally even ask for advice before taking actions) at AN. Can't there be somewhere comparable for reviewers who actually want to make the reviewing process a cooperative one instead of a solo endeavor? Rivertorch (talk) 14:42, 13 November 2012 (UTC)[reply]
  • Agreed. - Dank (push to talk) 15:00, 13 November 2012 (UTC)[reply]
    • I think we could use WT:PC for now. If it got to be high traffic we could fork it out into a board. Gigs (talk) 19:05, 13 November 2012 (UTC)[reply]
      • Theoretically, WT:PC is supposed to expressly for discussing changes/improvements to WP:PC, but I'm not one to stand on ceremony. If WT:PC fits the bill, I'd be fine with that. We would need to make reviewers aware of that function of the page, since it would be a nontraditional function of a talk page. Rivertorch (talk) 22:36, 13 November 2012 (UTC)[reply]
        • Also agreed. - Dank (push to talk) 02:35, 14 November 2012 (UTC)[reply]
        • That's how a lot of noticeboards get their start. WP:ELN exists because WT:EL was getting cluttered. It's also possible that people who are particularly interested in reviewing might start a WikiProject for reviewers. WhatamIdoing (talk) 07:33, 14 November 2012 (UTC)[reply]
• I want to note that many of the responses to this question seem to be responses to a different question that wasn't asked. The wording could have been clearer to facilitate comprehension for RfC participants who are in a hurry, but a careful read of the question reveals that the proposed noticeboard is not for policy discussions. Rivertorch (talk) 21:07, 17 November 2012 (UTC)[reply]
  • Policy talk pages are often used for discussions related to the application of that policy in a particular case. It's not unprecedented. Noticeboards are usually only necessary if such discussions would overwhelm the talk page. Gigs (talk) 15:50, 19 November 2012 (UTC)[reply]

It has been proposed that we go forward with this as the initial policy on removal. This is of course subject to further refinement. The idea behind this is that removal should not be unilateral.

"The reviewer permission should only be removed as the result of consensus from a discussion or where an editor requests the removal of their own permission. Discussion regarding removal of the reviewer permission should normally occur at WP:AN. Discussion with the involved editor and/or a request for a second opinion at WT:PC is recommended before formally requesting removal."

Support/Oppose[edit]

• Support It may not be perfect but it's a good starting point. To be honest I don't see this coming up a lot, but time will tell. Gigs (talk) 15:07, 14 November 2012 (UTC)[reply]
• Support. I too don't see this being a major recurring issue either, but it needs to be addressed before the 1 December implementation of Pending Changes, and I'm glad to see it being addressed here. This statement would make a good policy because it favors group consensus. Of course, I would be willing to allow for a provision allowing for an admin to remove the reviewer right before consensus is reached, as long as it is returned if consensus is not reached to revoke the reviewer right. RedSoxFan2434 (talk) 01:42, 15 November 2012 (UTC)[reply]
• Support, with the understanding that we'll be fine-tuning. - Dank (push to talk) 04:28, 15 November 2012 (UTC)[reply]
• Support, more or less. (See my comment below.) Rivertorch (talk) 15:33, 15 November 2012 (UTC)[reply]
• Support as drafter. Monty₈₄₅ 18:06, 15 November 2012 (UTC)[reply]
• Support. I do want something like this agreed to from the start, so adding this is much better than leaving it out. I like the idea of making AN the main place for decision-making. There's some discussion below about having discussion at talk pages related to PC – although of course I favor discussion with the editor in question before taking action, I'd rather keep subsequent discussion in one place, and a place where administrators broadly can be expected to be watching. I'd rather not have a sub-culture start to form, of PC specialists, because I think it's important that these kinds of decisions reflect broad community consensus. --Tryptofish (talk) 23:13, 15 November 2012 (UTC)[reply]
• Support. Simple policy, keeps discussion centralized at AN. I see no problems here.--Mark91it's my world 00:23, 17 November 2012 (UTC)[reply]
• Meh Support, I guess, although I think the discussion could also take place at WP:Requests_for_permissions#Reviewer. I agree that it shouldn't be unilateral, although there are probably exceptions that we haven't thought of. ~Adjwilley (talk) 22:40, 19 November 2012 (UTC)[reply]
• Support. This shouldn't be much of an issue, and this should be defined before implementation. Vacation^nine 20:58, 22 November 2012 (UTC)[reply]

Discussion on initial removal policy[edit]

I see it more or less this way:

• If disruption from misuse of the reviewer right is blatant, current, and ongoing, and if the reviewer is not responding to concerns on his or her talk page—i.e., if it's an emergency—then the appropriate remedy is a block, not a demotion, just as a block is appropriate for any such disruption.
• An attempt to discuss repeated misuse that isn't blatant, current, and ongoing with the reviewer in question shouldn't be recommended; it should be required. (This is a no-brainer. Ignorance can be corrected—usually—and even horribly disruptive vandals usually get at least one warning. Reviewers deserve no less.)
• Discussion at WT:PC should be recommended. A note left at WT:Reviewing (or WT:PERM) would also be a good idea if there is reason to think the regulars at WP:PERM aren't watching WT:PC.
• If the reviewer has quit making problem edits and is discussing the alleged problem, no administrative action is advisable—just a continued watch on the situation.
• Demotion at WP:AN should be a slam-dunk when the above steps have been followed to no avail.
• DIscussion and consensus at WP:AN should be required for reviewer demotions. Unilateral decisions to demote are completely unnecessary if the above steps are followed, and expressly prohibiting them up front would obviate great dramatic ANI showdowns resulting from lack of adherence to mere recommendations rather than rules. (If I've gotten any of this wrong, WP:IAR would still be an option.) Rivertorch (talk) 16:01, 15 November 2012 (UTC)[reply]
  • We can talk about all this more after the RfC, but I don't think WP:IAR should be viewed as a license to require bureaucracy, and then say "Well, you could have just ignored it". Anyway, lets just get through this first pass first, and we can talk about changes to it later. Gigs (talk) 17:16, 15 November 2012 (UTC)[reply]
    • Sure. Just to clarify, I meant that there may be some situation that no one has conceived of where unilateral demotion would be advisable, and if so, WP:IAR would provide a policy-based justification for it. That's why I mentioned WP:IAR; it had nothing to do with writing PC policy per se. Rivertorch (talk) 20:15, 15 November 2012 (UTC)[reply]
• ANI should also be a legitimate location for such a discussion --Nouniquenames 05:01, 17 November 2012 (UTC)[reply]
  • Legitimate, yes, but far from ideal. Rivertorch (talk) 21:08, 17 November 2012 (UTC)[reply]

Please provide your feedback on the draft PC policy:

• I disagree with this statement: "Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred..." I believe Pending Changes is a great tool for this situation. Consider this: the page Hurricane Sandy is created as a result of reports about the hurricane. Obviously it is semi-protected due to visibility. But, users want to report about the hurricane during the event, and add useful information. This would be perfect for Pending Changes, but violation would not yet have occured. I think PC should have the same criteria and applications as Semi-Protection. Vacation⁹ 02:52, 8 November 2012 (UTC)[reply]
  • Semi-protection is not used preemptively either. Gigs (talk) 03:28, 8 November 2012 (UTC)[reply]
    • Ah, yes. I still think preemptive protection would work great for PC though. Vacation⁹ 12:36, 8 November 2012 (UTC)[reply]
      • There was very significant opposition to pre-emptive use at Wikipedia:PC2012/RfC_2. I don't think we should rehash that here. I would say it would be best to wait until after everything is settled and in place, and then raise it again as a new proposal and RfC to see if consensus has changed after a few months of PC use. Gigs (talk) 14:55, 8 November 2012 (UTC)[reply]
        • Yes, I saw that. Sounds good for the moment. Vacation⁹ 17:07, 8 November 2012 (UTC)[reply]

Removal of Reviewer[edit]

• I continue to think that we need to provide more guidance then is currently in the draft regarding when the reviewer right may be removed (Its more relevant here then in the next section, as that is more about instructing reviewers then the main policy). If recent controversial removals of the rollback right have shown us anything, it is that summary removals of rights, based only on the discretion of a single admin, should be avoided when possible. Obviously there may be times when it is necessary, but I think it should be explicit that absent bad faith use or a clear need to stop ongoing disruption, it should only be removed after a discussion at AN or AN/I, or with consent of the editor. Specifically, this would mean that the right should not be summarily removed because an editor did something bad not involving the right, made several bad judgement calls, or mistakes. Monty₈₄₅ 20:16, 9 November 2012 (UTC)[reply]
  • The question on granting and removal of reviewer was eliminated from this RfC at great expense and at the last minute. Those responsible have been sacked. Seriously though, it was discussed a little on the talk page and we (for some small value of we) agreed that it would be better to have a discussion on it with more involved stakeholders first instead of just tossing it out in the voting format with little prior discussion. Those discussions do need to start very quickly, IMO, and shouldn't wait for this RfC to complete, since PC will be live December 1, and this RfC is not likely to wrap up for another two weeks at least. Gigs (talk) 20:39, 9 November 2012 (UTC)[reply]
    • What Gigs said. - Dank (push to talk) 02:44, 10 November 2012 (UTC)[reply]
      • I stated my opinion on the talk page pre-RfC and would have preferred that the question remain, but others disagreed and I am trying to keep an open mind. Of course, stakeholders should always be consulted (and of course they should be diligent about responding to RfCs that affect their work), but I'm not entirely clear on who precisely the stakeholders are when it comes to removal of the reviewer right. Rivertorch (talk) 08:44, 12 November 2012 (UTC)[reply]
  • If the discussions must start very quickly, then why not start here and now? I agree with Monty's position, since it favors community consensus. Simply giving an individual admin power to strip another user of his/her right, especially for reasons unrelated to reviewing, should not occur. RedSoxFan2434 (talk) 18:54, 12 November 2012 (UTC)[reply]
    • The goal in removing the question wasn't to support the admins, it was to support the reviewers. We all bitch about RfA ... and rightly so ... but we forget that it does serve some purposes, one of which is to close the feedback loop. If what it means to be a reviewer is decided by RfC voters and isn't allowed to evolve, that means that reviewers won't have a say in how to be a reviewer or what it takes to get promoted, and if that happens, I don't think there will be many reviewers. The trick of course is how to be open to feedback in the promotion and demotion process without allowing the nastiness of RfA. I actually think we've all learned a lot over the years about what not to do from RfA ... it's just that we never could apply those lessons to RfA; the thinking has been that RfA has to be tough because some bad promotions have had nasty repercussions. - Dank (push to talk) 20:15, 12 November 2012 (UTC)[reply]
      • Do you want to put a straw poll here on whether demotions should require AN/I consensus first, unless it's an emergency? That's pretty open ended to me in that the criteria for that consensus is open to change, while still making it clear that we don't expect unilateral demotion to happen. Gigs (talk) 21:04, 12 November 2012 (UTC)[reply]
        • I get that ANI may succeed in scaring admins who want to demote against consensus, but the ANI environment is not the place I'd want to be discussing the supposed deficiencies of reviewers. I'd be in favor of experimenting with different demotion discussion formats at RFPERM, where reviewers and people involved in promotion will be most likely to participate; we can probably find something that doesn't wear down the soul like RfA does. If admins are behaving badly, let's take them them to ANI, but let's focus on the admins' conduct, not the reviewers'; ANI is geared toward crime-and-punishment, and I think it would be exactly the wrong place to fine-tune reviewer standards. - Dank (push to talk) 21:25, 12 November 2012 (UTC)[reply]
          • I didn't suggest removing the question was done "to support the admins", Dank. As for ANI, the fact that it "is geared toward crime-and-punishment", as you stated, is why it should be used to discuss demotion of reviewers, since that is typically a "punishment" being done because of a "crime". RedSoxFan2434 (talk) 22:01, 12 November 2012 (UTC)[reply]

• It should be at the Administrator's Noticeboard (widely viewed but not as drama-fraught as ANI). There should be no other noticeboard; none of the others have anywhere near enough disinterested readers to come to a decision that could be considered community-supported. It should require a strong consensus after a discussion of not less than 48 hours. And there's no such thing as an emergency with this; if people are misusing it that badly (i.e., okaying clear vandalism - a blockable offense in itself) or refusing good edits (which can be fixed easily), then they should be instructed to refrain from using the tool for the duration of the discussion, and that can be built into the "removal" process.

  Now, the more important question is whether or not we will consider abuse of this tool by an administrator to be grounds for a request for desysop. Risker (talk) 23:10, 12 November 2012 (UTC)[reply]

• Monty was right to raise this question, as it is an important one. I guess we can discuss cases one-by-one at AN, but we really need to have a community consensus on what the criteria are, and we don't have it. It certainly was raised, by me and others, numerous times in previous discussions, so everyone paying attention knows that it's a matter of concern. I feel like the decision to punt on it for this RfC was a decision to go ahead and implement PC without dealing with reality. The reviewer right was given out way too freely before, and the draft guideline sets the bar awfully low. I fear we're headed for unnecessary drama. --Tryptofish (talk) 23:36, 12 November 2012 (UTC)[reply]
  • It's an important question, but considering that we are only doing pending changes level 1, I don't think it matters if we hand this out freely. This level of protection is somewhere less than semi-protection. We need to keep that in mind before we go too crazy worrying about a right that is somewhere on par with "autoconfirmed". Gigs (talk) 23:43, 12 November 2012 (UTC)[reply]

Well, I don't see it that way at all. What happens when someone reviews and allows an edit that violates WP:BLP? What happens when someone selectively disallows only those edits with which they disagree in a POV dispute? It's nothing like autoconfirmed, in my opinion. --Tryptofish (talk) 23:56, 12 November 2012 (UTC)[reply]

To back up Tryptofish's point, WP:Reviewing itself says that the level of trust in a reviewer is on par with rollback and autopatrolled rights. This is because autoconfirmation (relative to semi-protection) is the ability to edit, whereas reviewing (relative to PC) is the ability to both edit and accept edits. Meanwhile, I agree that we go case-by-case at AN, ANI, or another Noticeboard, although we should also have a general guideline of criteria, which, if a reviewer undisputably is not meeting, he/she loses his/her reviewer right. However, if it is disputable, than a Noticeboard consensus is needed. RedSoxFan2434 (talk) 01:38, 13 November 2012 (UTC)[reply]

There's no user right at all in order to patrol pages (except autoconfirmed I guess), and all rollback does is make undoing an edit take one less click. Those rights are not a particularly big deal either. PC level 1 is a way to allow an article that might have been semi-protected to still accept edits from IPs and non-autoconfirmed. That's pretty much it. These edits would have never happened at all if the article were semiprotected, which is what it would be today. It's just a fancy UI for people to respond to ((Edit_semi-protected)) from IPs, without the IPs needing to know how to use a template. We don't have any "level of trust" required to respond to semiprotected editprotected requests, do we? Anyway I'm not convinced this is going to be a big deal. If this were PC level 2, then it would be a bigger deal, but it's not. Gigs (talk) 03:35, 13 November 2012 (UTC)[reply]

To clarify: Autopatrolled rights (formerly known as "Autoreviewer" rights) refers to the ability to create an article which is then automatically marked as patrolled. Now that's a pretty high level of trust. RedSoxFan2434 (talk) 23:39, 13 November 2012 (UTC)[reply]

Unlike most of the other questions, I don't think that we need to have this particular issue settled before 01 December. It's unlikely that we're going to have people clamoring for userrights to be removed on Day #1, or even during Month #1. So hold those thoughts, please, and even give the issue more thought, but let's not try start mixing the concrete for right removals this week.

(My personal opinion, BTW, is that it ought to be treated like Rollbacker: any admin can act (in either direction), and you can appeal to the community if you disagree with the admin's action. I don't think that we benefit by adding a lot of red tape, like "can only be discussed here" or "must never be removed without a minimum of 48 hours' discussion".) WhatamIdoing (talk) 00:56, 13 November 2012 (UTC)[reply]

The problem is that we have somewhat regular removals of the rollback right for things other then the misuse of rollback, on the grounds of loss of trust. Its very hard to argue against such a removal, other then to try to reach consensus that we do trust generally trust the user. Rather then let reviewer end up in a similar morass, we would be much better advised to limit unilateral removals. I'm not saying we need a specific period of discussion or anything, just that it should be a consensus decision in most cases. Monty₈₄₅ 02:52, 13 November 2012 (UTC)[reply]

Volunteers with difficult jobs need to know that they're working on a team that has a shared, or at least overlapping, vision, and that will have some degree of autonomy. Admins who actually wind up investing time in promotion and demotion, such as the ones who have been doing it so far, generally want to do it right, and I expect they'll gain the trust of the reviewing community. It doesn't matter if random commenters at AN or ANI do a good job with demotions ... if reviewers don't perceive the people making the decisions as being involved with and responsive to reviewers and reviewing, then reviewers will get a sense that the process isn't their process, and they'll stop reviewing. - Dank (push to talk) 03:13, 13 November 2012 (UTC)[reply]

My sense is that those at WP:PERM are not typically the ones removing permissions, instead a random admin sees something they don't like, and does it themselves, sometimes not even understanding how the right works. I think the regulars at PERM do a fine job, at least for me, they are not who I am concerned with. But without any guidance at all on when an admin may remove the right, we fall back on the admin's unbridled discretion, which should be avoided when practical. Monty₈₄₅ 03:26, 13 November 2012 (UTC)[reply]

Right. My sense of it is that removal of the permission is quite different from deciding to hand out the permission in the first place. It might be helpful if the regulars who have been dealing with requests would provide some input on this. @ Gigs re "This level of protection [PC level 1] is somewhere less than semi-protection": that's a valid viewpoint, but it's not the only valid viewpoint, and it was hotly debated in various past RfCs. There's no point in rehashing those old arguments, but I feel I should say that I don't accept the premise. Rivertorch (talk) 06:19, 13 November 2012 (UTC)[reply]

I think the best suggestion might be to wait a little bit to see how things start to go. It sound like we have rough consensus for bringing any issues to AN or something like it, at least for now. I get what Dank is saying, but without knowing how the chips are starting to fall, it's going to be hard to address those concerns. Gigs (talk) 16:13, 13 November 2012 (UTC)[reply]

If "Do it at WP:AN" is going to be added to the RfC, I'd prefer we include something about trying to get consensus among reviewers first before heading to WP:AN. But if that seems premature to you guys, it will be enough for me if the people likely to vote on demotions at WP:AN get the pros and cons of different approaches. I'll go ask. - Dank (push to talk) 17:55, 13 November 2012 (UTC)[reply]

There's nothing wrong, exactly, with any of the suggestions so far, but there's an inattention to what's needed that could get us to "awful". In the long run, there's not going to be any demand for a job where someone pretends to newbies to have some authority ... which is what the PC interface suggests, that an edit is being rejected by someone who has the authority to do that ... and then, as soon as they're asked a question by a newbie or challenged by any authority, it becomes clear that they were just pretending to have authority, they actually have no say in anything. Jobs that are all responsibility and no authority tend to fail even when there's a paycheck as incentive to make them work. What I suggest is, if anyone wants to give feedback about a promotion or demotion, before or after, then something should be said at RFPERM (or somewhere else, if you guys want this to happen somewhere else) along the lines of: I have concerns that this person may be too bitey, or may lean too much one way or another on accepting or rejecting edits. Then one or more of the admins who generally do promotions and are trusted by the reviewing community can do a quick investigation, and solicit public comments or emails on just those points that they think might be decisive to the question. A thorough discussion of all possible faults the reviewer or reviewer-candidate might have would be irrelevant, and hurt our ability to retain reviewers, as we know from RfA: no volunteer actually likes a public airing of all their dirty laundry, even if the charges are true, especially if they're true. Then the admin(s) could present what they think is the decisive issue to the reviewing community, sketch the problem, possibly offer a recommendation, and see if people in general, and especially reviewers, are on board with the recommendation ... for better or worse, promotion and demotion decisions will help to define what it means to be a reviewer, which means that reviewers need to be involved, and need to know that they're being heard. For demotions, when a consensus has been reached at RFPERM (or wherever) that someone should be demoted, or that someone who was demoted shouldn't have been, that consensus could be presented at WP:AN for review. This is a little messier than some people were hoping for, but if you're asking people to volunteer large amounts of time to an admin or reviewer job, then it shouldn't be a surprise that sometimes they're going to need to be taken seriously and reasoned with. - Dank (push to talk) 13:10, 13 November 2012 (UTC)[reply]

Quick analogy: the students in the after-school math club are trying to put together a competitive team ... so performance is important, but the club is also a social activity. One option is for the adviser, who the club knows and trusts, to do most of the promotions and demotions to the competitive team, particularly if the adviser has the good sense to involve the students in discussions of standards. If all the promotions and demotions were made and announced to the school by vice-principals unknown to the club, that would be publicly advertising that the club has no autonomy, no voice in its own affairs, and it's unlikely the club would survive that lack of respect. - Dank (push to talk) 14:47, 13 November 2012 (UTC)[reply]

Above, I asked two questions. I'm going to ask them again, because I think that it would be constructive here to actually attempt to get consensus on the answers, or alternatively to discover that we need to do more work on that consensus:

1. What happens when someone reviews and allows an edit that violates WP:BLP?
2. What happens when someone selectively disallows only those edits with which they disagree in a POV dispute?

Thoughts? --Tryptofish (talk) 21:47, 13 November 2012 (UTC)[reply]

I've got a longer answer if you're asking something fine-grained. If your question is mainly about flagrant, knowing abuse of the tool, then if I were in on the discussion, I'd recommend demotion at WP:RFPERM (or wherever) and again at WP:AN. - Dank (push to talk) 23:06, 13 November 2012 (UTC)[reply]

Yes, I'm really just asking about knowing abuse, not an isolated error made in good faith, and maybe also chronic incompetence, so that answer is what I'm looking for. But what I'm not clear on is whether other users will agree with you. Why not put it in the draft that there is a venue for recommending demotion? Why not put it in the draft that such demotion is appropriate when reviewing is repeatedly misused? --Tryptofish (talk) 23:16, 13 November 2012 (UTC)[reply]

It appears from the votes so far that there won't be a special noticeboard, and that maybe WT:PC will be used for notifications. If so, more reviewers will be looking at WT:PC than at WP:RFPERM, so if we want to get the advice of reviewers on demotions, that would probably be the place for it. It sounds like most people here would like to see a demotion question in the current RfC. I suggest: "If clear abuse of the reviewer tool is discovered, links showing the abuse should be provided at WT:Pending changes (WT:PC). Any admin [but I'm hoping it will be admins active in promotion and reviewing generally] can then ask for input from the [reviewing] community if there are open questions about what constitutes abuse and whether there was abuse, and if the admin determines there was abuse, the admin should recommend demotion at the Administrators' noticeboard. Out-of-process demotions should also be reported at WT:PC when discovered. - Dank (push to talk) 03:10, 14 November 2012 (UTC)[reply]

What if we say: "The reviewer permission should only be removed as the result of consensus from a discussion or where an editor requests the removal of their own permission. Discussion regarding removal of the reviewer permission should normally occur at WP:AN. Discussion with the involved editor and/or a request for a second opinion at WT:PC is recommended before formally requesting removal." This would provide clear guidance regarding what admins may do without discussion, and suggest alternatives to dragging someone to AN without necessarily requiring they be used. This also leaves open other potential venues, such as RFC/U or ARBCOM where removals would also be the result of a sufficiently public process. Monty₈₄₅ 03:43, 14 November 2012 (UTC)[reply]

Just to be clear on the difference, your language seems to invite open-ended discussion; mine asks people to provide links to the problem they're trying to point out, and leaves it up to admin discretion whether there are gray areas that need discussion before a trip to WP:AN. - Dank (push to talk) 04:29, 14 November 2012 (UTC)[reply]

I think a diff is a good idea, but as this is for the policy page, I don't think it should be required in every case. The main focus of the change is I want to avoid a mandatory trip through WT:PC before a requested removal can be discussed on a notice board, which would turn WT:PC into a notice board itself. Certainly questions can be raised, advice asked, or help in dealing with a problematic reviewer requested there, and both those should be encouraged, but I think instituting a mandatory pre-screening before a matter can be brought to AN is overly bureaucratic. Really the only part that would be really be policy in my version would be the first part, "The reviewer permission should only be removed as the result of consensus from a discussion or where an editor requests the removal of their own permission. Discussion regarding removal of the reviewer permission should normally occur at WP:AN." the remainder being more of an associated guideline. Monty₈₄₅ 05:51, 14 November 2012 (UTC)[reply]

I like Monty's proposal and thing we should add it for straw polling. Gigs (talk) 14:32, 14 November 2012 (UTC)[reply]

I don't object; I've made my argument. Time will tell whether reviewers wind up being disenfranchised from their own process, and if so, we'll deal with that. - Dank (push to talk) 15:36, 14 November 2012 (UTC)[reply]

Please provide your feedback on the draft reviewers guideline:

• I agree with the policy in full. It completely covers the neccesary instructions. Vacation⁹ 02:55, 8 November 2012 (UTC)[reply]
  • After further assessment, I have changed my mind. I think that WP:IGNOREALLRULES should apply in the reviewing process. I agree from RfC 2 that Reviewers should accept edits they don't agree with, however if the content would worsen Wikipedia (anything you would normally revert for AGF) then you should not accept it. Vacation⁹ 12:39, 8 November 2012 (UTC)[reply]
    • I think the idea there is that they should accept the revision and then use rollback. Gigs (talk) 15:05, 8 November 2012 (UTC)[reply]
      • But that is just an extra step isn't it? Why more work for the reviewer when they could simply decline the change? Vacation⁹ 17:06, 8 November 2012 (UTC)[reply]
        • No, the way I understand it, PC only shows you a rolled up diff of every unapproved change which you have to give a simple "yes" or "no" on without the ability to leave any comments. This stuff was discussed heavily at previous RfCs, and the rough consensus was that PC rejection should not be used unless every part of the unapproved changes is uncontroversially unsuitable, which eventually was refined at later RfCs to the specific classes of vandalism, BLP, and blatant copyright only. If you just reject the unapproved changes, it's entirely possible to throw out good edits with the bad, without noticing it (I think, it's been a long time since the trial).
          • I believe as stated on the reviewers guideline that you can undo specific requested changes, then approve the rest all at once. Vacation⁹ 00:37, 9 November 2012 (UTC)[reply]
        • As well, there was concerns about reviewers being held to an impossible standard of taking full responsibility for the content of every edit they approved, which would eventually entangle them in pretty much every edit war on Wikipedia. Reviewers being instructed to accept everything that isn't a clear violation of our most basic policies is an attempt to keep them from becoming involved all over the place. Gigs (talk) 17:24, 8 November 2012 (UTC)[reply]
          • I agree. Maybe a later revert would be better. Vacation⁹ 00:37, 9 November 2012 (UTC)[reply]
• "Occasionally, even a lack of reasonable command over English is one of the reasons why a rollbacker or an autopatroller might not qualify for the reviewer flag." — This supplementary note, which describes a criterion that is not otherwise defined or substantiated by the proposal, has far too much negative potential to warrant inclusion.   — C M B J   11:02, 9 November 2012 (UTC)[reply]
  • I just removed the footnote entirely. Rollback requires a similar level of competence in recognizing cases of blatant vandalism. Gigs (talk) 15:48, 9 November 2012 (UTC)[reply]
    • Agreed. Even more so with autopatrolled. Vacation⁹ 20:38, 9 November 2012 (UTC)[reply]
• Thinking maybe that it would be better to put the "how to be a reviewer" at the end or at least halfway down the page. Comments? ⁓ Hello71 15:20, 10 November 2012 (UTC)[reply]
  • What do you mean? Gigs (talk) 21:02, 12 November 2012 (UTC)[reply]

• From my experience reviewing in other wikis (mostly mediawiki.org and wikibooks) I believe it's important to clarify that accepting a revision does not require endorsing the correctness of the changes, but merely ensuring that it contains no obvious vandalism or policy violations. There's a little of this in the passage "Reviewers are not expected to be subject experts and their review is not a guarantee in any way of an error-free article", but I think it is important to highlight this and make it very clear, otherwise we might risk the formation of backlogs in complex edits (as in length, or dealing with hard/obscure topics, etc.) --Waldir ^talk 15:33, 14 November 2012 (UTC)[reply]
  • Yeah, I think we should further emphasize there is some level of "immunity" for reviewers, when it comes to things other than BLP violations, copyright, and clear vandalism. Gigs (talk) 20:39, 14 November 2012 (UTC)[reply]
    • I have boldly added "Acceptance of an edit by a reviewer is not an endorsement of the correctness of the edit. It merely indicates that the edit has been checked for obvious problems as listed above." to the policy, and tweaked the guideline in a similar way. Gigs (talk) 20:48, 14 November 2012 (UTC)[reply]
      • I for one never intend to become responsible for clearing others' edits of all potential policy violations which may be rather hard to detect (can you check if an off-line source is being plagiarized if you don't have access to it?) I don't plan to ever review a single edit under this scheme. It's even more amusing that random admins will be able to grant and ungrant this bit when many admins are rather incompetent about detecting such things; witness the fall from grace of some former ArbCom members etc. Tijfo098 (talk) 09:02, 23 November 2012 (UTC)[reply]

        At this point it appears that it will be left to future discussions (possibly at the removal of permission stage) how far reviewers are expected to go in checking for policy violations. I advocate for a standard where there is a high level of care regarding the specific reason for protection, then a quick look for obvious policy violations (Blatant indicia of copy pasting, blatant negative blp violations, etc), and if none are found, the reviewer is in the clear. Monty₈₄₅ 01:19, 25 November 2012 (UTC)[reply]

• The main problem with the policy is and always has been whether reviewers can reject changes they simply disagree with as "obviously inappropriate". Of course there's not much difference between rejecting and simply reverting. Are accepts & unaccepts subject to 3RR etc.? Tijfo098 (talk) 08:52, 23 November 2012 (UTC)[reply]
  • You should accept and then revert if it's not in the obviously problematic classes. If it is in those classes, 3RR probably doesn't apply anyway. Gigs (talk) 18:56, 28 November 2012 (UTC)[reply]