Wikipedia talk:PC2012/RfC 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

When to apply[edit]

I think that most, if not all, of the questions under "When to apply" should be removed.

Wikipedia is fundamentally a common-law system for procedural work like this. We know what "persistent" and "liberally" mean in the context of page protection: they mean exactly what they've meant for years in every single discussion of page protection so far.

The next group of questions is "You didn't really mean what you said about stopping vandalism and BLP violations and edit warring over unverifiable errors, did you?!", which is only going to irritate your potential participants by making them think this is a tendentious, back-door method of re-fighting then shall-we/shan't-we question of whether to use PC at all. WhatamIdoing (talk) 17:18, 28 August 2012 (UTC)[reply]

I cmpletely agree about not trying to define persistent etc. Admins are expected to know it when they see it. I'm not so worried about having too many questions, what I was always agraid of was having too many separate proposals dogfighting it out. If we get a lot of answers to a lot of questions, that should help us find consensus on how the community wants this to beused. By the same token though, we shouldn't get into too much detail or try to make the policy perfect simce we know it will just be changed later anyway. Beeblebrox (talk) 17:56, 28 August 2012 (UTC)[reply]

Criteria for accepting/rejecting edits[edit]

I think the suggestions at Wikipedia:PC2012/RfC 1#Criteria for accepting/rejecting edits kinda miss something... I guess I have two issues:

  1. Depending on the result of the "When to apply Pending Changes" section, PC may get used to protect against more than vandalism, e.g. "NPOV/V/OR violations". If that is the case then surely these things should be rejected too.
  2. I think the best answer involves saying something like this:
    • Reviewers should reject obvious vandalism
    • Reviewers are encouraged to investigate the possibility of other issues such as stealth vandalism and "NPOV/V/OR violations".
      • They should reject these if they find them but if reviewers fail to find something this should be politely pointed out to them rather than treated as some massive violation.
      • For "NPOV/V/OR violations", reviewers should consider opening a discussion on the talk page, as per WP:BRD.
    • Reviewers may, if they wish, reject other non-constructive edits but
      • They should give a reason in the "comment" box when they do (this ends up in the edit summary).
      • They should consider opening a discussion about it on the talk page, as per WP:BRD.

I think this deals with a number of issues, partly because of the power of WP:BRD. I have only said that reviewers should consider opening a discussion. There will be cases where the edit summary is sufficient. There will be cases of obvious bad faith where a discussion isn't going to help. But I think BRD is gonna help in a lot of cases.

Yaris678 (talk) 17:33, 28 August 2012 (UTC)[reply]

I agree with the edits in this area by WhatamIdoing. I have added one more subtopic. Yaris678 (talk) 10:18, 29 August 2012 (UTC)[reply]

My take on the first RfC: keep it short and simple[edit]

The current RfC wording looks unnecessarily complicated. I think that what needs to be decided first is very simple: what is the purpose of PC?

Everything else follows, but until this is answered, it is not going to be helpful to try to decide any of the other critical questions, such as the fate of Level 2, what articles should be eligible for PC, what reviewers should and shouldn't do, how the reviewer right should be granted and removed, and so on.

In determining the purpose of PC, it may be helpful—and is perhaps even necessary—to draw a distinction between stated purpose and acceptable use. For instance, if PC's stated purpose is limited to preventing vandalism, would it be acceptable to use PC to prevent certain other kinds of unconstructive edits (e.g., BLP violations, plagiarism or copyright violations, irremediably poor English, blatant violations of the core content policies, edit warring against consensus)?

If the answer is no, then we'll wind up with a tool that a majority of editors are competent to use but that a sizable minority of editors are likely to misuse. (Consider how often the term "vandalism" is misapplied by editors who are by no means newbies.) Solution: make the reviewer right relatively easy to get and relatively easy to remove. (I see the major pitfall here as concerning administrators. Since the reviewer right is bundled with the mop, it will be impossible to deal with an admin's repeated misuse of PC without resorting to desysopping and all that entails, and that's frankly absurd. An admin with otherwise exemplary behavior shouldn't be dragged to Arbcom and lose his or her toolbelt because of being sloppy—in a good-faith, encyclopedia-enhancing sort of way—with a tool they might not even have wanted in the first place, but neither can admins get a free pass for improperly rejecting non-vandalistic edits when a whole slew of 500-edit semi-novices are getting their reviewer bit yanked on the second offense.)

If the answer is yes, the pool of editors qualified to be reviewers will shrink significantly. (It's relatively easy to differentiate vandalism from other unconstructive edits, and far less easy sometimes to identify, say, original research. In some instances, even seasoned veteran editors are likely to screw up now and again.) Solution: make the reviewer right relatively hard to get and relatively hard to remove. (The pitfalls here are numerous, and I won't mention any of them at this point.)

It may be a good idea if the first RfC is quite simple and goes something like this:

Reviewers will use PC to prevent vandalism.

  • Preventing vandalism is the only legitimate purpose of PC, and reviewers should never use it to any other end.
  • Preventing vandalism is the fundamental purpose of PC, but reviewers may, at their discretion, also use it to:
  • prevent blatant violations of WP:BLP
  • prevent blatant violations of WP:COPYVIO
  • prevent blatant violations of WP:V, WP:NOR, and WP:NPOV
  • prevent the addition of content that is phrased so poorly that it would have to be completely rewritten for its meaning to be clear
  • prevent edit warring to add, remove or change content in a way that clearly and unequivocally defies consensus following a recent talk page discussion

That's eight short lines, but there's enough in there to spawn gigabytes of discussion. Nonetheless, it's just possible that if there's a resoundingly clear result from something like the above, the path forward might be a lot easier. If we are determined to do more than one RfC, I think we need to keep the first one really simple or we'll get bogged down and not have time for a second. Rivertorch (talk) 08:04, 30 August 2012 (UTC)[reply]

Thanks, Rivertorch; There's actually a good chance that we're going to split off the question on suspending PC/2 and treat that alone in a first RfC. There are other editors who view that as being the fundamental question. ~Adjwilley (talk) 15:25, 30 August 2012 (UTC)[reply]
I agree with Rivertorch that the purposes for the initial deployment of the pending changes feature (without prejudice against introducing more purposes later) is a more fundamental question than which variants should be deployed, and I think this would be a better starting point for the initial request for comments. I wouldsuggest that it simply list the potential uses and solicit commenters to provide a weight for each (e.g. 5 for "essential purpose" and 1 for "very minor purpose"), rather than dividing the choices into "vandalism" and "vandalism + X". isaacl (talk) 16:12, 30 August 2012 (UTC)[reply]
Hmm. That's an interesting take on it. I may have oversimplified my draft wording, but what I'm really trying to get at is not just what the "official" function(s) of PC is supposed to be but whether x, y, and z are acceptable uses of the tool. If we end up defining x as a "very minor purpose", does that mean that reviewers will be permitted to use PC for that purpose regularly? Rivertorch (talk) 18:38, 30 August 2012 (UTC)[reply]
For now, I think we want to emphasize a binary nature in our questions. The Quaker approach of "let your yes be yes, and your no be no", rather than having introducing questions of emphasis and relativity, is likely to serve us well for now. Once we have more experience under our belts, we can consider complex and nuanced situations.
Dank had wanted a series of mini-RFCs. I think that is a reasonable approach, because the smaller the question and the quicker people can respond, the more people who will actually respond. I believe that asking about just this one issue, all by itself, would make a great first mini-RFC. If people dislike "vandals" versus "vandals and other serious issues", then we could split it into a handful of tiny questions: For vandalism? For BLP problems? For copyvios? (and so on). Also, I think it would not be unreasonable to label it as a starw poll (that people can comment on), rather than a request for comments (that people will vote on, whether we like it or not). This particular question is small enough that there just isn't that much to discuss. (Unless you think comments like "I really, really, really hate vandalism" tells you more about what the community wants to use this for than "I support using it against vandalism"). WhatamIdoing (talk) 19:11, 30 August 2012 (UTC)[reply]
Makes sense to me. I'm happy to help set it up, although not just now. Rivertorch (talk) 20:32, 30 August 2012 (UTC)[reply]
I think it's just as easy to have a quick poll asking "Do you want pending changes to be used for A? B? C? D?" and respondents can enter their level of support. Again, not much need for discussion to get a quick feel of what people are thinking, and better bang for the buck. isaacl (talk) 23:50, 30 August 2012 (UTC)[reply]
The reason for some way to express the importance of a given objective is to facilitate reaching a compromise solution. With a binary yes-no, if someone says yes to A, B, and C, it's hard to tell if that person can live with a compromise of just A and B. Assuming a compromise of A and B is chosen, the resulting policy would say that pending changes can be used for A and B, and reviewers would be free to use it regularly for these purposes. isaacl (talk) 23:44, 30 August 2012 (UTC)[reply]
My thought was that if you have a yes:no ratio of 80:20 for A, 60:40 for B, 45:65 for C, and 25:75 for D, we could probably assume a compromise of A&B, and throw out C&D. ~Adjwilley (talk) 00:15, 31 August 2012 (UTC)[reply]
Having some rough indication of the importance each commenter places on the choices will make it easier to build a real consensus: something everyone can compromise on, rather than ignoring someone's strongly held preference if it falls a bit short in a straight vote. I don't think it's too much to ask for a quick gut-feel numerical weight for each option (maybe 1 to 4, to avoid a middle-of-the-road option). isaacl (talk) 00:45, 31 August 2012 (UTC)[reply]
Well, yes. I think the success of the recent RfCs on WP:V and the Muhammad image support what you're saying, but those were vast RfCs that lasted forever and a day. I'm concerned that a non-binary approach here will muddle up something that needs to go quickly and smoothly, but I could well be worrying needlessly. Rivertorch (talk) 05:26, 31 August 2012 (UTC)[reply]
The risk with a binary approach is that there may be something that the creator of the question did not foresee or imagine, and it discourages editors from proposing novel compromise solutions. To use vandalism as an example, there are many forms of vandalism, ranging from the extraordinarily obvious, such as blanking the page and replacing it with a wall of expletives, to the very subtle, such as deliberately inserting plausible sounding, but false information into an article. There is also different levels of certainty as to whether something is vandalism, or just smells fishy enough that it should be reverted pending evidence. I could imagine a compromise that allowed reviewer rejections for the first type, but regular undoing for the latter. Monty845 22:08, 7 September 2012 (UTC)[reply]
Just to clarify, I wasn't referring to questions where there can be alternative solutions proposed, but to objectives that can be weighed differently in terms of priority. isaacl (talk) 23:00, 7 September 2012 (UTC)[reply]

Header formatting[edit]

Unless anyone objects, I would like to change the sub headers for the different !vote sections so that if they leave in the automatic section edit summary information it is clear which question the person is commenting on. It makes the edit history a easier to follow. For example instead of a header of Should PC be applied more "liberally" on BLPs? followed by Yes, No and Discussion headers, it could be Should PC be applied more "liberally" on BLPs? - Yes, Should PC be applied more "liberally" on BLPs? - No, and Should PC be applied more "liberally" on BLPs? - Discussion. Monty845 19:25, 30 August 2012 (UTC)[reply]

Forgive me if I'm misinterpreting here—I'm in a rush and on my way out the door—but a question about applying PC "more liberally on BLPs" might just be putting the cart before the horse. Let's decide first what PC is to be used for (see previous thread) before we decide how to use it. Rivertorch (talk) 20:31, 30 August 2012 (UTC)[reply]
I just picked the first header from the draft RFC with the yes/no/comment sections to use as an example, I'm not trying to comment on the substantive content of the RFC, just proposing what I think would be an improvement in formatting for whatever substantive content it ends up with. Monty845 21:27, 30 August 2012 (UTC)[reply]
Your suggestion makes sense for people viewing the edit history. For people viewing the page/table of contents, it might be a detriment to have overly-long sub-headers. Perhaps a compromise such as Yes (BLP), No (BLP), and Discussion (BLP) would work better. ~Adjwilley (talk) 22:01, 30 August 2012 (UTC)[reply]
That would seem to be a good compromise, I'm mainly interested in it being identifiable which topic they are responding to, which that format would accomplish. Monty845 01:01, 31 August 2012 (UTC)[reply]

Next[edit]

We currently have eight main questions. I think it would be useful to split them up like this (numbers refer to current position on the page):

When to use PC
  • 1 When to apply Pending Changes (if we do this section at all; I recommend against it above)
  • 8 Implementation: Ramp up slowly, watch backlog
How to review
  • 2 Criteria for accepting/rejecting edits
  • 6 Automatically accept old changes
  • 7 Automatically accept reverts
Who is a reviewer
  • 3 Qualifications of Reviewers
  • 4 Removal of Reviewer right
  • 5 Reviewer right for Admins

and to have three separate mini-RFCs, each starting no sooner than one week after the previous one (so that people can give a quick answer and go back to their real work, instead of getting intimidated by the length of the RFC page and not answering). What do you think? Is this a reasonably natural division of the questions? WhatamIdoing (talk) 23:32, 7 September 2012 (UTC)[reply]

There is also the question of what is expected of reviewers when they are reviewing, in particular how far they are expected to go to make sure nothing is wrong before accepting. That could go with either the how to review, or with the removal of reviewer questions. Monty845 23:48, 7 September 2012 (UTC)[reply]
I think that would be part of "Criteria for accepting/rejecting edits", but perhaps you have something specific in mind? WhatamIdoing (talk) 00:00, 8 September 2012 (UTC)[reply]

Debundle reviewer right for admins[edit]

So we currently have a question abut debundling the reviewer right for admins. I personally think it is kind of a silly question, and is more likely to distract people from the real issues. (I think the potential for administrators abusing the reviewer right is lower than for abusing existing forms of protection.) Would there be any opposition to dropping this question from the RfC? ~Adjwilley (talk) 20:07, 13 September 2012 (UTC)[reply]

That would be okay with me.
I believe that the problem isn't worries about abuse, though, but a political question of whether some admin of either the sore-loser variety or the legally panicky variety might resign his sysop bit if being an admin "required" him to have even the ability to review an edit. WhatamIdoing (talk) 21:47, 13 September 2012 (UTC)[reply]
I already did, chummer, during the trial. —Jeremy v^_^v Bori! 21:17, 28 September 2012 (UTC)[reply]
Just cos such admins can review pending edits, it doesn't mean they have to. Yaris678 (talk) 09:22, 14 September 2012 (UTC)[reply]
Yes. And if people feel strongly about being required to see pending changes, I'm sure they'll find a way to opt out of it. (For example, you can add a little script to your common.css page to make it so the Rollback link doesn't show up on your Watchlist: very handy if you check your watchlist on a smart phone. ~Adjwilley (talk) 18:57, 14 September 2012 (UTC)[reply]
Could you point me to that script? I use an iPad and about once a week or so I accidently rollback somebody because of the clustered links on my watchlist. I don't even get why rollback links show up in watchlists at all as we are obviously expected to actually look at a diff before rolling it back in almost all cases. Beeblebrox (talk) 22:18, 15 September 2012 (UTC)[reply]
I've rollbacked based on edit summary before. --Mysterytrey 23:33, 15 September 2012 (UTC)[reply]
If you're using popups, you can (usually) check the diff from your watchlist page. Rivertorch (talk) 00:05, 16 September 2012 (UTC)[reply]
Beeble, sorry for the delay, I was out of town all yesterday. See here for how to disable the rollback links on your watchlist. ~Adjwilley (talk) 14:38, 16 September 2012 (UTC)[reply]
Well, I'm going to be bold and drop the section. If anybody objects, let me know. ~Adjwilley (talk) 19:42, 16 September 2012 (UTC)[reply]
I support your removal. I think we need to focus on more important questions. WhatamIdoing (talk) 20:40, 16 September 2012 (UTC)[reply]
Thanls for the script, seems to be working. I also support removing that topic. It is hardly the most pressing issue with the policy. Beeblebrox (talk) 20:48, 16 September 2012 (UTC)[reply]

Signpost[edit]

Jan says we can have some space in "News and Notes" in the next Signpost to talk about the recently closed RfC and to "chart the course ahead". I'm shifting my focus to developing tools and community support to help deal with some of the problems that gave rise to PC/2 in the first place, before PC/2 comes back around in six to nine months, so I'll talk about that and about the results of the RfC. If anyone wants to suggest a paragraph on the goals for the next RfC, please do, in this section. - Dank (push to talk) 20:07, 15 September 2012 (UTC)[reply]

Who is a reviewer[edit]

I have just simplified the "Removal of Reviewer right" section to make it one question instead of two. I hope that works for everyone.

I think we should have two questions in the next RFC: "Qualifications of reviewers" and "Removal of Reviewer right". Does that work for everyone else? Could we start that soon? WhatamIdoing (talk) 20:54, 16 September 2012 (UTC)[reply]

yes and yes. the sooner the better. Beeblebrox (talk) 00:21, 17 September 2012 (UTC)[reply]
Is that just those 2 questions? I think unfortunately all the questions are related in some way. If we split it up, do we want to allude to how this round could be related to later rounds? For example, if the qualifications for reviewer are low then we can't expect them to understand BLP issues, they may not even recognise some forms of vandalism, they may not be familiar with concepts like WP:BRD that help people to rub along. Maybe it would be easier to just ask all the questions at the same time. Yaris678 (talk) 10:39, 17 September 2012 (UTC)[reply]
Yes, just those two questions. I think that the more questions we ask, the fewer people who will answer them all. We're basically taking a poll, and every pollster knows that the longer the list of questions, the less willing people are to answer any of them. We can expand the click-to-show explanations, if you want. We could also add a complete copy of the draft policy for context. WhatamIdoing (talk) 00:03, 18 September 2012 (UTC)[reply]

Bass-ackwardness[edit]

At the risk of sounding like a broken record or perhaps a beater of dead horses (both similes are horribly antiquated in the 21st century, and we really need a new one), I wonder if we're not putting the cart before the horse by asking about reviewer qualifications at this stage. It seems to me that the next question really should involve the scope of PC—the extent of its official purpose(s) and the extent of its permissible use(s). If we can get consensus on that, it should be much easier to figure out the qualifications for reviewers. Without having a handle on what reviewers are supposed to do and allowed to do on PC-enabled pages, I cannot imagine how we can make an informed decision on who should be granted the reviewer right. Rivertorch (talk) 08:33, 18 September 2012 (UTC)[reply]

the RFC appears to be attempting to address both of these concerns. Beeblebrox (talk) 16:22, 18 September 2012 (UTC)[reply]
Beeblebrox, I believe Rivertorch is responding to the idea floated at #Who is a reviewer that the forthcoming RfC should concentrate on "Qualifications of reviewers" and "Removal of Reviewer right". I have changed this section to a sub-section in an attempt to make this clearer.
Rivertorch, I agree. If we have to split it up it would make sense to talk about the scope first. Specifically, we should cover the areas "When to apply Pending Changes" and "Criteria for accepting/rejecting edits". Perhaps the remaining questions should be split into an RfC3 (reviewership) and RfC4 (implementation). These questions should be linked to from RfC2 with an invite to help in the construction and an allusion to the fact that the questions are related but we have tried to split it up logically.
Yaris678 (talk) 11:17, 19 September 2012 (UTC)[reply]
I'm more concerned that something, either idea, happen sooner rather than later. For once there actually is a deadline, and it is getting closer. I suppose it has been obvious for some time now that I do not think trying to perfect the policy before implementation is possible, but if we are going to try and fix the most glaring issues we need to keep things moving here. Beeblebrox (talk) 17:05, 19 September 2012 (UTC)[reply]
Yaris, you're correct; that's what I was responding to. It looked like an idea that was gaining traction, and that worried me. Also, in looking at the RfC2 project page, I'm confronted with a wall of text that goes way beyond the basic questions. I'd like to see the next RfC focus exclusively on what you said here, except I do think it would be advisable to differentiate between what PC can be used for and what it should be used for. Clearing that up should tell us what questions to ask in the third and final RfC. I'm tempted to boldly edit the hell out of the current page, removing about half of it and rewording the rest, but I could draft it somewhere else. Thoughts? Rivertorch (talk) 18:57, 19 September 2012 (UTC)[reply]
My concerns here are similar to Beelbebrox's. It took us over two weeks to get through the first RfC, not including the time it took to write it and agree upon its content. And that was only one question. We have 5 weeks left before the November 1 deadline, and in that time we have to frame a wording for RfC_2, (a few days at least), let it run for at least a week, close it (at least a week for one so long), draft a final policy (at least a week, likely more), and then have a final RfC to accept the draft policy (another week and a half). That all adds up to more than 5 weeks. Splitting RfC 2 into two separate RfCs would tack another 2 weeks onto the process, and we just don't have time for that. In my view, the questions you are asking are critical questions, and they should be put at the top of the RfC so that everybody answers them and so people's answers to the later questions will depend on their answers to the important questions at the top. If people start the RfC and don't make it to the end, that's ok. At least we'll have answers to the most important questions. ~Adjwilley (talk) 19:27, 19 September 2012 (UTC)[reply]
I think two more RfCs are possible if we can get the first of them off the ground in the next couple of days. We don't have to wait for that one to close to see which way the wind is blowing, and that will help us formulate questions for the last one. The automatic acceptance question could be thrown in to the next one, I suppose, but asking questions about reviewer qualifications or a ramped-up implementation is premature until we get a sense of what the likely consensus will be on the other stuff. Rivertorch (talk) 22:05, 19 September 2012 (UTC)[reply]
Note, that the Nov date is to give developers time to implement any changes the RFCs may require, so the extent questions are not likely to require code implementation, the deadline isn't as critical. I don't see a reason to delay regarding the auto, accept question as I doubt the other questions will impact it. As for reviewers, I think there is a stronger case for that discussion being seperated, and as long as its completed prior to dec 1 with time to update pages, it should be ok as it will be a policy not a technical matter unless we want it to be automatically assigned, which imo is unlikely to get consensus. Monty845 22:34, 19 September 2012 (UTC)[reply]
I'd be totally fine with splitting out the Reviewer qualifications and Removal of Reviewer right sections for a later RfC, since it's entirely policy based. I have a feeling others might disagree, but it's worth a shot. It would certainly cut down the load in the current RfC. ~Adjwilley (talk) 23:27, 19 September 2012 (UTC)[reply]
Rivertorch, do you think that the "When to apply PC" should be the next question asked? Or the "Criteria for accepting/rejecting edits" section?
IMO "When to apply PC" section should be scrapped. The list is already in the draft policy, and that draft policy has already been approved. The questions about it are going to be interpreted by the average editor as being kind of silly: "Do words like persistent and liberally mean exactly the same thing that they've always meant, or would we like to confuse everyone by making up brand-new definitions?" "Do you support vandalism, or should we use this new tool to stop it?" "Do you support the addition of unverifiable garbage to BLPs and other articles, or should we use this new tool to stop it?" IMO we aren't going to learn anything by asking these questions, so I think we shouldn't bother asking them. WhatamIdoing (talk) 22:56, 19 September 2012 (UTC)[reply]
This is a point that's been discussed a bit back on the PC2012 talk page. Yes, the draft policy has outlined when PC should be used, and a lot of people have a problem with what the draft policy currently says. There is a large crowd that thinks PC should only be used for vandalism. I personally am against using it to protect against NPOV/V/OR violations and edit warring, though using PC for these cases is specifically allowed by the draft policy. (IMO using it for NPOV could give one "side" an upper hand, and temporary semi or full protection is better for stopping an edit war cold.) Anyway, that is the reason we're asking the questions...not to try and define "persistent" and "liberally". ~Adjwilley (talk) 23:21, 19 September 2012 (UTC)[reply]
  • If we aren't trying to re-define these terms, then we should scrap the whingeing about "The policy is ambiguous as to what "persistent" and "liberally" mean".
  • If nobody objects to using it for vandalism, then why should we ask about that?
  • How are you going to use PC to protect against BLP violations (which seems to have widespread support) if the addition of unverifiable and/or UNDUE garbage isn't a valid use for PC? WhatamIdoing (talk) 23:32, 19 September 2012 (UTC)[reply]
  • Absolutely. Scrap that.
  • I think there are people who still would rather not use it for anything. However many of the opposers from the original RfC might be won over if the tool's use was more limited. If nothing else, the question about PC being used only for vandalism could be a point on which there is a good consensus (something that has eluded us thus far).
  • I can't predict how the RfC will turn out, but if the result is only Vandalism and BLPs, then I suppose it will protect BLPs against vandalism. We'd have to deal with Undue garbage the way we do now. ~Adjwilley (talk) 23:41, 19 September 2012 (UTC)[reply]
  • Thanks for doing that.
  • We're not asking whether it should be used "only" for vandalism. We're asking whether vandalism is a permissible use.
  • We're not asking whether BLP protection is a permitted use. The closest we come is asking whether re-insertion of rumor, error, and unverifiable/made-up/biased/undue material is a legitimate use. An example of this kind of problem would be someone changing a BLP to say that the person is gay, or bankrupt, or a criminal, or whatever. Another way to phrase this question would be, "If someone keeps inserting a claim that Joe Famous is a child molester, should we be able to use PC to protect the article?" WhatamIdoing (talk) 00:24, 20 September 2012 (UTC)[reply]
(replying to WhatamIdoing) I think both questions should be asked in this RfC. The draft policy "has already been approved", yes, but it was approved with the proviso that it may be revised, and we have the opportunity to revise it now. I think it would be helpful to ask some really basic questions in this RfC about what patterns of problematic edits are acceptable triggers for applying PC to an article. The criteria for accepting or rejecting edits is an accompanying set of questions that's equally important, but it flows logically from the first set of questions. For instance—and this is purely hypothetical; I'm not necessarily suggesting it—if the policy on when to apply PC says that it may be applied to a given article as a response to persistent vandalism but not as a response to incessant insertion of OR-based rumors, then we need to know whether it's permissible for a reviewer to use PC to reject pending edits containing OR-based rumors. Rivertorch (talk) 09:50, 20 September 2012 (UTC)[reply]

Too many "disucssion" sections[edit]

Looking at the format of the RfC, we have two big sections at the top with five questions each. Each question has Yes, No, and Discussion sections. Instead of having 10 separate discussion sections, why not just have two: one for each big section after the block of yes-no questions? That would help clean up the RfC significantly, making things easier to find, and keeping the discussion more centralized. I'll make a bold edit to show what I mean. If anybody disagrees, feel free to revert. ~Adjwilley (talk) 19:38, 19 September 2012 (UTC)[reply]

That's one of the reasons why we need to split the remaining questions up into two or perhaps three separate RFCs. WhatamIdoing (talk) 22:51, 19 September 2012 (UTC)[reply]
The problem is that commenters will mix together many arguments on many topics, making it harder to progress forward on any one issue. isaacl (talk) 05:01, 20 September 2012 (UTC)[reply]

Relative priority in discussion[edit]

first, there is a major difficulty. Q1.1 should first ask whether protection should be only to BLPs! (many who voted for this supported only use in BLPs; this was not really settled in the discussion that led to the preliminary policy, the closers of the RfC did not specify this point, and the preliminary policy is in any case preliminary -- here is where we are deciding what we actually meant, and I do not consider us bound by the wording there in this respect.


second, there is another point to be settled: it was never decided whether this should be used only very rarely. the agreement (or apparent agreement) was only that it be used. Some who voted for it assumed we would be discussing only a few hundred articles. As we did not reach consensus there, we need to do it here.

third, there is a logical sequence in which these questions should be answered. After we decide those first two points, then sections 1 & 2 need to be settled before the others. What qualification the reviewers should have would depend on what they will be doing. Questions 3 & 4 logically go together, But questions 5 and 6 are mere details, among the minor points to clean up at the end. ; we should settle the main questions first--having these in the list simply confuses the discussion and will prevent concentration on the main issues.

question 7 comes still last of all-- until we know what we are implementing, and by whom, how can we discuss how quickly to do it? If this is to be used very rarely, by very qualified people, it gives less need for caution. If, as I will advocate, we should do only one or two hundred particularly sensitive but nonetheless not high edit frequency BLPs of public figures, where there is a known previous history of vandalism, taken at first only from those already fully or partially protected so as to ensure we are liberalizing, not restricting editing, and nothing else, we might as well do them all together. DGG ( talk ) 05:22, 20 September 2012 (UTC)[reply]

Provisional policy[edit]

At WP:Pending changes/Provisional policy, does anyone mind if I comment out the PC/2 stuff for six to nine months? One of the purposes of having the PC/2 RfC first was so that people trying to get up to speed on PC/1 wouldn't be confronted by instructions for 3 flavors of PC. The suggestion came up on the talk page of the RfC 1, and there was no objection. - Dank (push to talk) 18:48, 23 September 2012 (UTC)[reply]

Don't you dare touch my precious policy! No, just kidding, sounds like a good idea to me, and in line with my perspective of trying to keep this as simple as possible. Beeblebrox (talk) 20:21, 23 September 2012 (UTC)[reply]
Thanks, done. Instead of commenting out, I just listed (on the talk page) the parts I removed or edited. - Dank (push to talk) 12:42, 25 September 2012 (UTC)[reply]

Alternative for RfC #2[edit]

I've posted an alternative draft for the next RfC and would appreciate comments. It's still pretty rough, but if anyone likes it I'm willing to give it some time and effort in the next 24 hours. I think the current draft, while well crafted in many ways, is too long and complex and not likely to clarify things as well as we'd like. My alternative is considerably simplified and is likelier, I think, to facilitate a quicker close and produce clearer results that make it easier to construct a third and final RfC. (Much of the current draft can be used in a third round). I think we have time for this. Comments? Rivertorch (talk) 12:03, 25 September 2012 (UTC)[reply]

This is as good a place as any to offer my apologies for limiting my participation to the PC/2 stuff. My other wiki-work keeps me busy, including working on less drastic solutions to dealing with persistent socks than PC/2. Also, I think Wikipedia works best when people are allowed to do what they want to do, as long as they're not screwing things up. If it turns out that a bunch of people want to help IPs and new accounts get started editing, and they think a new tool and a new hat to wear will help them do that, then that's fine by me ... unless it turns out that there aren't enough people actually doing the work, or they don't do a good job of it, in which case it doesn't matter what the policy or the parameters are, it's not going to work. The only way to know if there's a critical mass of interested volunteers is to start it up and see. My own experience using admin tools suggests that having a cool tool and a cool hat to wear actually does make a difference ... for better or worse, new people do take what you say and what you do more seriously ... so the question for me is whether the potential advantages will materialize, and if they do, whether they're worth the drama and unintended consequences. - Dank (push to talk) 13:05, 25 September 2012 (UTC)[reply]
I appreciate your perspective and am glad you spoke up. As I understand it, however, PC/2 is off the table for the time being. I'd be grateful for your opinion on the substitute questions I've proposed for the next RfC. I suppose I could have just done the WP:BOLD thing and edited the project page directly, but I wasn't confident that there's anything approaching consensus for limiting the next RfC thus (or even for trying to do two more RfCs, for that matter). If no one comments either way within a day or so, I'll assume there are no violent objections and go ahead and change the wording on the project page, but obviously I'm not going to play Lone Ranger beyond that. With a concerted effort, I think we can get RfC #2 off and running in 2–3 days, shut it down it in a week or less, and possibly have an official close soon after that. If we don't get the ball rolling again—or, I suspect, if we try to roll these basic questions into the final RfC—we'll essentially be marching towards the cliff's edge with no parachute. (Or perhaps with no brakes, since I seem to be mixing my metaphors.) Rivertorch (talk) 19:09, 25 September 2012 (UTC)[reply]
PC/2 is off the table, but if we can't find a new procedure or new tool that helps us deal with persistent confirmed socks, it will be back on the table in 6 to 9 months ... and the search for something new may take a while. I'm sorry, I don't want to offer an opinion on RfC 2 without taking a while to study all the proposals and asking around, and I don't have the time ... it seems complicated. - Dank (push to talk) 21:37, 25 September 2012 (UTC)[reply]
@Rivertorch: Thanks for plugging along while the rest of us slacked off. Let me see if I can break down the differences between your RfC and our current one (correct me if I go astray).
  • In the first section about when to apply Pending Changes you got rid of the yes-no response format in favor of an agree-disagree-neutral format where responses are mixed into the same section. You shuffled the order a bit, and split the Vandalism-only question into two questions (endorse one). I personally liked the older yes-no format a little better, because it makes it easier to judge consensus at a glance. After the RfC has been running for a while people will want to do that, particularly if they're answering questions in section 2.1 (Reviewers may reject edits if they violate one of the criteria determined in the previous section.) It would also make it easier on the closer.
I'm fine with its having a yes-no format instead. Rivertorch (talk) 09:57, 26 September 2012 (UTC)[reply]
  • In the second section section about the criteria for rejecting edits, you basically threw out the five questions and condensed them into 3 questions that avoid repeating the same questions that were asked in the section above. Again, the yes-no format is gone, and it's an endorse one multiple choice. I like this more than what we've currently got. (I think our "Is explanation the key" question was way too much of a leading question for an RfC.)
It's not an "endorse one" multiple choice; it's an "endorse, reject, or be neutral" multiple choice, which theoretically could allow for judging level of support. Rivertorch (talk) 09:57, 26 September 2012 (UTC)[reply]
  • You dropped the rest of the questions (qualification of reviewers, removal of right, automatic acceptance, ramp up slowly) for a later RfC. You already know my feelings on trying to squeeze in even more RfCs before the deadline.
So here's what I'd propose as a compromise of sorts: Keep the current yes-no format for the 1st section. (Wording is always negotiable.) Throw out section 2 and use your questions instead. (The wording will need some tweaking...2.1 could be more concise.) Throw out sections 3 and 4 (Qualifications of reviewers and Removal of reviewer right) for a later RfC. These aren't the most pressing of issues, and how they're resolved won't affect what the developers need to do. Keep sections 5 and 6 (automatically accepting) as they are short, and may directly affect the developers' work if they pass. Keep question 7 (ramp up) because it definitely needs to be decided before PC goes live. (Otherwise we really are speeding towards the cliff without the brakes). How does this all sound to you? ~Adjwilley (talk) 22:51, 25 September 2012 (UTC)[reply]
Regarding the first section (of this, not this): some of the questions are problematic. The first one—"Should PC be used to protect against vandalism?"—is essentially useless; if we get a "no" consensus on that, it will effectively reverse the May RfC and stop PC dead in the water, and while I wouldn't be unhappy with such a result, the likelihood seems nil. The sockpuppetry question needs to have a word such as "disruptive" or "abusive" added—no big deal. The "more liberally on BLPs" is so vague as to be meaningless, and a "yes" consensus on a question worded like that is likely to open the door to some really unpleasant disputes down the road by giving those admins with extremist interpretations of WP:BLP license to be just as liberal as they please (all while acting in perfectly good faith, of course).

This is getting complicated, so tl;dr version: (1) I'm ok with your compromise if we can do something about the current questions in the first section that I objected to above. (2) Some of my wording does indeed need tweaking, and I'll see what I can do. (3) Yes, we can squeeze in a third RfC, I'm almost certain, if we work on it while the second one is running. Rivertorch (talk) 09:57, 26 September 2012 (UTC)[reply]

Sounds good. As I think I may have said elsewhere, I kinda like the "Should PC be used to protect against vandalism" question because that may be one of the few places where PC supporters/opposers could agree. In the unlikely event that it came up with no-consensus, I'd expect that we'd go ahead with what's in the provisional policy. For the rest of it, I think things will be easier to figure out if we dive in and start editing. Perhaps I'll start by dropping sections 3 and 4, replacing section 2, and trying to tweak the wording there. ~Adjwilley (talk) 15:25, 26 September 2012 (UTC)[reply]
Great! Your changes look good so far. I'll try to drop in in a couple hours and see if I can do a little polishing, but I think we're almost there. On this one, I agree that it needed to be shortened, but I wonder if we can somehow retain something in the way of examples (e.g., "poor English, broken formatting, misplaced edits inappropriate for article space"), which would provide RfC participants some concrete examples of what reviewers won't be able to do if this goes a certain way. Rivertorch (talk) 19:02, 26 September 2012 (UTC)[reply]
Sure, I was just trying to be more concise, and I had to read the sentence a couple times to understand it, so I just cut it. ~Adjwilley (talk) 20:25, 26 September 2012 (UTC)[reply]
I don't think the ramp-up question needs to be settled in advance, since it can trivially and instantly be implemented at any point. Actually, I'm not sure that it needs to be asked. (Do you honestly expect anyone to say that we should just ignore that issue?) I think we could just take that one as read and not waste people's time asking about it. WhatamIdoing (talk) 03:25, 26 September 2012 (UTC)[reply]
I agree that it's common sense, and will probably gain consensus, but it would be nice to have it set in stone (i.e. agreed upon in an RfC) so that some excited admin doesn't get too carried away and protect tons of pages right out of the gate. ~Adjwilley (talk) 04:49, 26 September 2012 (UTC)[reply]
I'm don't feel strongly about this, but I agree it would be preferable to have it "set in stone" (if only crumbly limestone or slippery shale). Rivertorch (talk) 09:20, 26 September 2012 (UTC)[reply]
Rivertorch, I can't quite figure out your section 1. Is that Pick A or B, and then (separately) answer the following questions 1, 2, 3, 4, and 5 about specific "Bs", or is that Pick A or B, and if you choose B, then please pick from among B-1, B-2, B-3, etc.? WhatamIdoing (talk) 03:26, 26 September 2012 (UTC)[reply]
Yes, I see that it's still a bit confusing. I rewrote that section about seven times, and every way I configured it, there was something fundamentally wrong. My intended meaning was to set up the part under the first bullet as an either-or choice: one must endorse one of the two statements, and if one endorses the first one ("Pending Changes may be applied only to protect pages from vandalism"), it would be logically impossible !vote "agree" on any of the four statements under the second bullet; if one endorses the second statement, then one can !vote any way (except a straight "disagree" ticket) on the four statements. If I have to explain this to someone as clueful as you, then obviously my wording needs to be retooled!

My idea was that just about the only intended function that everyone who supported PC in the May RfC agreed on was the prevention of vandalism, and we really should provide an opportunity to scuttle other proposed functions before they're implemented or we risk pissing off a larger number of editors than is strictly necessary when PC goes live. If, on the other hand, it looks like there's strong support for a multi-function PC, presenting the other possible functions cafeteria-style with agree/disagree/neutral !vote options should make it easier not only to determine the overall consensus but also to gauge the depth of feeling on these options. For instance, those !voting "neutral" on the edit-warring function probably aren't going to scramble their passwords and leave in a huff whether that function is permitted or not, and neither will they be moved to become happier, more productive Wikipedians. So, lots of neutrals on a given question should indicate that it's not something to spend any time worrying about either way, whereas a more polarized response could mean the question isn't settled and needs to be reconfigured and asked again in a couple weeks (perhaps as part of a broader question).

My longer-term goal here is determine what the community particularly wants PC used for and what we're willing to allow it to be used for. If we can figure that out soon, then we can use that information to inform the crafting of a proposed policy that is more serviceable and less divisive than the draft policy. And that just might enable us to have a simpler, shorter third RfC. Rivertorch (talk) 09:16, 26 September 2012 (UTC)[reply]

I think focusing on a Nov 1 deadline was useful in July, because we needed focus. I don't think we should try to do everything at once, regardless of the supposed deadline; I don't think anyone will stop a useful, ongoing RfC on the very day of Nov 1 ... it takes as long as it takes to find out what people want to do. - Dank (push to talk) 11:27, 26 September 2012 (UTC)[reply]
I agree. Frankly, I think we may be going overboard in attempting to conform to the timeframe preferred by the developers. We want to be as accommodating as we can, sure, but it's more important to get it right. Rivertorch (talk) 18:56, 26 September 2012 (UTC)[reply]
You might want to ask in the RfC after this one whether reviewers should be able to grant the "confirmed" user right to new accounts. - Dank (push to talk) 19:13, 26 September 2012 (UTC)[reply]

The latest version (as of 10:57 UTC)[edit]

Using the above discussion as a guide, I've implemented various changes. Among other things, in the first section, I:

  • tweaked the wording here and there. Changed "should" to "may" because the former was weaselly to the point of being meaningless; WP:IAR and WP:AGF should work in the rare instance that someone decides PC should be applied on a given page for an unofficial reason;
  • linked the policies, for convenience (and in case a newbie stumbles into the RfC);
  • took the section headings used for the each question down a level, probably violating all that is sacred, but they were just too big;
  • switched the order around, based on the order of things in the pull-out quote from the provisional policy.
  • made one highly substantive change to the BLP question. If we're going to ask if we can use PC for vandalism, we'd damn well better ask if we can use it for BLP. I realize this is a different question than the former one, and I understand what the former one is asking, but "more liberally" is too vague to mean anything even if we got a definitive answer to it.

    In the second section, I replaced the text with my draft text, with the wording significantly improved (I hope) but no substantive changes that I can see. (I did change the section title because the questions ask only about rejecting edits, not accepting them.) I also removed sections 3 and 4, to be reinstated (with revisions, if necesssary) for the third RfC. And I left everything else in place. No doubt there are various tweaks left to do, but I think it's shaping up pretty well.

    A couple things come to mind. First, I'm wondering if section 2 would benefit from some explanatory wording under each of the three options. I didn't put my examples back in because I wanted to be concise, but it occurred to me that each of the three options might benefit from a bit of explanation (perhaps as collapsed text) of what it would mean in practice. Obviously, this would need to be worded carefully and neutrally. I played around with it a bit and then thought better of the whole idea, but I wonder. Also, did we want to ask about WP:COPYVIO? (I'm sort of tempted not to, per WP:BEANS, but I think that cat is fully out of the bag already, so it might be better just to get it resolved.) Rivertorch (talk) 11:35, 27 September 2012 (UTC)[reply]

Added: Forgot to mention that I dropped the "agree/disagree/neutral" thing in section 2 in the interest of simplicity. I think it would have been a good idea a month ago but isn't likely to help much at this point. It's more important that we try to get it settled as best we can in the time that's left. Anybody want to comment on the current draft? Is it ready to go live? I keep tweaking this and that but changing my mind before clicking Save. Rivertorch (talk) 09:31, 28 September 2012 (UTC)[reply]

Just something I realized about section 2. I'm fairly certain that when you're rejecting a pending change you get a chance to enter an edit summary. This shows up in the article history as a revert. Instead of saying "Reviewers should be prepared to cite the applicable policy or guideline" we should say "Reviewers should leave a clear edit summary citing the applicable policy or guideline." Other than that, and perhaps shortening the title on 2.1.1, I think we're good to go. ~Adjwilley (talk) 16:08, 28 September 2012 (UTC)[reply]
OK. If you're sure you're right about the edit summary, please go ahead and change it. (I would try to test that now but am pressed for time.) Shortening the title . . . <shrug> I dunno.It's shorter than it was, and I don't know how to shorten it further and retain the meaning. Frankly, I've stared at the page so long now that I'm not really "seeing" it anymore. (Btw, it's 2.1, not 2.1.1. Maybe the numbering in section 2 should go, since it looks confusing in the TOC.) I'll take a last look later today/tonight and am hoping we can kick it off tomorrow. Rivertorch (talk) 18:46, 28 September 2012 (UTC)[reply]
I'm sure I'm right about the edit summary. [1] For some reason it's showing up as 2.1.1 in my browser. It's no big deal though. ~Adjwilley (talk) 19:05, 28 September 2012 (UTC)[reply]

Last-minute concerns[edit]

  • If there are to be examples in the second section, then each of the three options needs an example, to avoid introducing inadvertent bias. Can someone with an non-autoconfirmed account (or who doesn't mind flaunting their IP) do the honors for #2? I'd suggest a sentence of gobbledygook (e.g., "While a project close to lexicographers, Wiktionary is unfortunate to know that references cannot be placed within or without all etymological eschatology") on Wikipedia:Pending_changes/Testing/1 and a reject citing Wikipedia:Patent nonsense. (I'd do it myself but I don't have a second account and am not about to register for one right now.) Never mind—I did it myself. (And, wonder of wonders, clicking on my own example link crashed my browser—the second time this has ever happened to me on a WMF-hosted page. Yay, pending changes!) Rivertorch (talk) 07:11, 30 September 2012 (UTC) And I thought second examples would be helpful, so I added those. Rivertorch (talk) 08:39, 30 September 2012 (UTC)[reply]
  • Notifications: These shouldn't happen until the RfC has formally begun. I think we can make The Signpost if we post something there on Saturday (maybe Sunday)Sunday. WP:CENT is a given. Any thoughts about a watchlist notice? We'd get way more participants but it would be harder to keep it quick and streamlined.
  • Time frame. Do we want to say anything on the RfC page about how long it should run? Rivertorch (talk) 10:53, 29 September 2012 (UTC)[reply]
Unless people want something shorter, 30 days seems reasonable. The Blade of the Northern Lights (話して下さい) 18:31, 29 September 2012 (UTC)[reply]
Sure. I can well imagine this RfC running somewhat longer than the last one, given the questions being asked, and thirty days is the default. My hope, however, is that people will want something considerably shorter, and I was wondering if a suggestion along those lines might not be included somewhere in the wording (either as a question to vote on or merely in a predefined discussion section). I don't foresee an across-the-board WP:SNOW response to the questions on this RfC, but I rather thought we might have enough indicators from the responses after a week or so to inform our wording of a third RfC, which might legitimately begin while this one is still running. As far as I can see, there's no reason why that third one would absolutely have to conclude by November 1, as long as it didn't propose any do-or-die changes for the developers, although it would be nice if it wrapped up by then. Rivertorch (talk) 19:25, 29 September 2012 (UTC)[reply]
I guess we can discuss the time frame here on the talk page after the RfC begins. I'm a little wary of that, but maybe I shouldn't be. I'd really appreciate some feedback on the notifications—participation in the last RfC was quite low, and I'm thinking a watchlist notice might be a good idea. That can happen a day or two after the RfC begins, I guess, if we're going to do it. So are we ready for primetime? If no one objects in the next 8–10 hours or so, I guess I'll go ahead and get the ball rolling. Anyone else who wants to do it in the meantime, please feel free. Rivertorch (talk) 09:00, 30 September 2012 (UTC)[reply]
One last (I hope) thing: the RfC repeatedly mentions policy, even in the second section, which deals with reviewing. Wikipedia:Reviewing, however, refers in its first sentence to guidelines. Does this matter? Rivertorch (talk) 09:09, 30 September 2012 (UTC)[reply]
I just made some tweaks so that the page consistently refers to the "draft policy" or "provisional policy". I think this RfC is about the best you can do until we get broader input ... good work. One suggestion: it may be that turnout is low, and it may appear likely that you've pretty much got the input you were looking for after two weeks ... perhaps add a provision saying that after one week, a new section will be created allowing the RfC to be closed by a simple majority vote, and have Blade make a call on that section at the end of two weeks. - Dank (push to talk) 18:40, 30 September 2012 (UTC)[reply]
Added something to that effect. Thanks. Now let the wild rumpus start! (I'll begin notifications later today unless someone gets there first.) Rivertorch (talk) 19:10, 30 September 2012 (UTC)[reply]
Thanks for getting that rolling...I would have gotten the examples you asked for, but I was out of town/offline for most of yesterday and today. I agree with the changes you've made, especially the "early close" provision. (They're supposed to be "mini-RFC"s, right?) ~Adjwilley (talk) 19:16, 30 September 2012 (UTC)[reply]
I feel like yelling something corny like "may the odds be always in your favor" to kick off the RfC. That would be appropriate in more than one way, perhaps. :-) ~Adjwilley (talk) 19:19, 30 September 2012 (UTC)[reply]

Maybe one more[edit]

If we're going to ask about specific situations, should we perhaps consider adding an "IAR" question, like

Should the use of PC be absolutely restricted to the situations explicitly named in the policy, or are admins permitted to use their best judgment when choosing among protection levels? For example, if a page attracts spam, and neither blocking nor blacklisting can solve the problem, should an admin be permitted to consider using PC protection even though spam is not mentioned in the policy, or should the admin be forced to use semi-protection in that instance?

What do you think? Is it too late to add it, since the RFC started more than an hour ago? WhatamIdoing (talk) 20:44, 30 September 2012 (UTC)[reply]

I wouldn't be opposed to adding that. You'd just have to format it so it matches the rest of the RfC (think of a short title framed as a yes-no question to go in the header). ~Adjwilley (talk) 20:50, 30 September 2012 (UTC)[reply]
I think it's best not to add anything now that people have begun to respond. Save it for the next RfC. Besides, we'd need to hammer out the wording; "forced to use semi-protection" effectively turns it into a leading question. (mutters to self: why the hell does WP:VAND draw a distinction between repeated insertions of spam and vandalism? some hairs are better left unsplit. Rivertorch (talk) 21:16, 30 September 2012 (UTC)[reply]
No objection to that type of question, but I think it would be better in the next RfC ... first figure out what people think the rules are, then talk about what happens when the rules seem to fail. - Dank (push to talk) 21:19, 30 September 2012 (UTC)[reply]

Modification to BLP question response section[edit]

Hello. Because the "Yes" section was split between one group in favor of applying protection to all articles and one group in favor of applying protection to articles only when there has been a problem, I have split the section to reflect this difference. Please go back to that page and make sure that your vote is still in the section that most closely reflects your views. Sven Manguard Wha? 16:18, 2 October 2012 (UTC)[reply]

I'm not sure that split is a good idea. The wording of the BLP question is exactly the same as the wording of the other questions. As I read it, "to protect against violations of the policy" does not connote preemptive action in the absence of a documented problem, although respondents are free to specify a preference for such action. Two have clearly done so; I don't think that elektrikSHOOS's response does so categorically, although it can be read that way. I'm inclined to revert you but would prefer to discuss it first. If you completely disagree with what I'm saying, I suggest we take it to the RfC talk page. Rivertorch (talk) 18:49, 2 October 2012 (UTC)[reply]
I'd ask that you take it to the talk page without reverting, as discussion has started on one of the two items of the split, and votes have already changed (mine at least) because of the split. Sven Manguard Wha? 18:54, 2 October 2012 (UTC)[reply]

The above text is copied from my user talk page. Anyone else care to comment? Rivertorch (talk) 19:04, 2 October 2012 (UTC)[reply]

Sven, I moved this here instead of reverting, at your request, but you have given no response to the substantive concerns I raised. What we have now is an awkward situation with responses that were in one section split into two separate sections, based not on the express wishes of the individual respondents but rather on the assumptions of one of those respondents. As I said above, I think the assumption may have been wrong in one case, but that's not the main issue. The main issue is that the wording was designed to be identical to that of the other sections, thus putting the BLP question on an equal footing with the other policy questions in the section. The new wording gives unequal weight to the question and potentially carries the implication that WP:BLP is somehow deserving of special consideration not afforded to other basic policies. Now, it may be that the wording of the questions in this section was insufficiently clear—if so, I'm more to blame than anyone for it—but I don't see in the wording any suggestion of preemptive use of PC. If there is such a suggestion, then it must also be present in the other questions, since they're worded in precisely the same way. I don't know how to fix this now that there are fresh responses in the split-up section, but I'm pretty sure it needs fixing and. Whatever happens, may I suggest that no changes be made to the wording or the structure of the wording of this RfC without discussion happening first? Rivertorch (talk) 21:51, 2 October 2012 (UTC)[reply]
And I see from my watchlist that the bot is busy distributing the latest Signpost, which mentions this RfC. I really hope this can be resolved soon. Rivertorch (talk) 22:06, 2 October 2012 (UTC)[reply]
The problem is that in in response to the BLP question, some supporters were making it clear they thought there were supporting preemptive usage for either potentially problematic BLPs or all BLPs. That is a radically different proposition then the other discussions, and needed to be split out. Monty845 22:37, 2 October 2012 (UTC)[reply]
But the question didn't ask that, and I think their responses made clear that they were supporting something that wasn't being proposed. I don't know. I have RL commitments and need to disappear for several hours, so I'll just say that I'm troubled by what seems to be a shifting of the goalposts after the game is underway. Maybe someone else will iron it out, or maybe I'm seeing problems where there are none. Thanks for your input. Rivertorch (talk) 22:46, 2 October 2012 (UTC)[reply]
I don't think that it matters much, so long as the closer is smart enough to figure out that "yes, all" and "yes, some" both mean "yes". WhatamIdoing (talk) 03:24, 3 October 2012 (UTC)[reply]
I don't see what I was doing as shifting the goalposts, as much as seeing that the goalposts were shifting and updating the map accordingly (that makes sense, right?) Two different viewpoints, which are in conflict with one another, were being placed under one header. That's never a good idea. Sven Manguard Wha? 04:09, 3 October 2012 (UTC)[reply]

Thinking about the above, in particular the idea that "yes, all" and "yes, some" both mean "yes", we are going to want to address not just when an administrator may use PC, but when an administrator should use it. This manifested itself most clearly in the BLP !voting, as there are those who do advocate preemptive protection, which it appears none of the !voters on other uses even consider as a possibility. While preemptive protection is the clearest, when discussing use against socking, editing warring and NPOV, a number of support comments have wanted to permit the use for the type of problem, but also to provide restrictions/guidance on when it should be used rather then leaving it to broad administrator discretion. Are there plans to ask directly after we complete this RFC? Monty845 05:39, 3 October 2012 (UTC)[reply]

(edit conflict) All right. I don't like the inconsistent wording between that question and the previous ones, but if no one else sees it as a problem, I'll cheerfully drop the stick while the horse is still breathing. (Btw, your metaphor makes sense if it's a really, really big playing field.) Rivertorch (talk) 05:44, 3 October 2012 (UTC)[reply]
Personally, I feel that preemptive BLP protection is asking for a major issue you chummers are ill-suited to handle. I don't want to have to remind you again that 65 BLPs:1 reviewer is an untenable position yet again. —Jeremy v^_^v Bori! 19:17, 8 October 2012 (UTC)[reply]
@ Monty: If you have plans, then there are plans. I'm hoping we can begin drafting the next RfC before this one winds down. Rivertorch (talk) 05:47, 3 October 2012 (UTC)[reply]
  • If I wanted to make certain PC wouldn't work, I would support having it apply to all BLPs. DGG ( talk ) 03:11, 10 October 2012 (UTC)[reply]

Proposal: time to close this RfC[edit]

(Note: I'm assuming this is best discussed here on the talk page. Anyone who disagrees should feel free to move it onto the project page and remove this note.)

Per the procedural note at the top of the RfC page, I propose that this RfC be closed. Please vote below. Rivertorch (talk) 05:42, 8 October 2012 (UTC)[reply]

Support[edit]

  1. Support. It's been running for more than a week, with no new contributions in almost 24 hours. Additional comments will undoubtedly straggle in, but without a watchlist notice it is doubtful that many more editors will participate. Discussion can—and should—continue here on the talk page. Rivertorch (talk) 05:42, 8 October 2012 (UTC)[reply]
  2. Support Selective close Some of the discussions have reached relatively clear consensus, others may develop a clearer consensus if given more time. Suggest leaving open sections 1.3, 4, and 5 which really have no consensus yet, and sections 1.4 and 3 which could probably be closed with consensus, but are close enough that another week could make it clearer, after another week no-consensus closes would also seem a reasonable possibility, but 8 days isn't enough to give up on finding one. The rest are lopsided enough that further discussion is unlikely to change the outcome. Monty845 19:42, 8 October 2012 (UTC)[reply]
  3. Support bcause by the time we take several days to discuss whether it should be closed, it will be even more obvious that the most interested people have already commented. WhatamIdoing (talk) 01:40, 11 October 2012 (UTC)[reply]
  4. Support Stop having RfCs and just do something. If the something that is done turns out to be broken, then we'll address it then. Gigs (talk) 17:37, 11 October 2012 (UTC)[reply]
    The purpose of these RfCs are to develop a policy of a tool to be implemented in the coming future. Without a policy, there'd be chaos among the reviewers.—cyberpower ChatOnline 13:10, 12 October 2012 (UTC)[reply]
  5. Support I've got my reasons in.—cyberpower ChatOnline 13:10, 12 October 2012 (UTC)[reply]
    All right, I guess I'll handle it sometime tonight; this should be interesting. The Blade of the Northern Lights (話して下さい) 18:29, 12 October 2012 (UTC)[reply]
    Update; my nerves are still in tatters after the thrilling Yankee win today, and I'm still regaining my composure, so I'm in no shape now to do this. I'll take care of it tomorrow afternoon. The Blade of the Northern Lights (話して下さい) 04:56, 13 October 2012 (UTC)[reply]
  6. Support. We have enough to work with. - Dank (push to talk) 17:06, 14 October 2012 (UTC)[reply]

Oppose[edit]

  1. Reviewing the discussions, too many of the suggestions have evenly divided opinions. DGG ( talk ) 01:35, 15 October 2012 (UTC)[reply]
    So what do you want to do? Encourage people to discuss things further? I don't see much in the way of discussion at the moment. Yaris678 (talk) 12:39, 16 October 2012 (UTC)[reply]
    If opinions are divided, close this RfC and start a smaller, more focused one (for only the unresolved sections) that incorporates voters' commentary to create a pool of answers that more people can agree on. Nothing is ever "yes or no" on this project. Sven Manguard Wha? 03:46, 18 October 2012 (UTC)[reply]
    I agree we should close this RfC. I think we should try to draft a new policy and a WP:Rough guide to pending-changes protection that best reflect the results of the RfC. WP:Rough guide to pending-changes protection would be similar to WP:Rough guide to semi-protection and would allow us to expand on things. For example we could say "There is no firm consensus on a process for reviewing. However, one of the approaches that has received a lot of support is as follows...." Yaris678 (talk) 08:40, 18 October 2012 (UTC)[reply]

The vote[edit]

This vote has been open for 10 days, and the ayes have it. I have marked the RfC closed. With regard to DGG's oppose above: very true, but it's unclear that keeping this open any longer will do anything to resolve that. While we await TBOTNL's formal close, I'd like to urge my fellow editors to come on over to Wikipedia talk:PC2012/RfC 3, which is still in the early stages of construction. Rivertorch (talk) 09:46, 18 October 2012 (UTC)[reply]

Comment - The Google results will show the "vandalized" versions[edit]

In conjunction with one of my comments on this RfC, I have asked Jdforrester (WMF) about whether GoogleBot would pull the most recently reviewed version of a PC article, or would pull the most recent version of a PC article regardless of whether it had been reviewed. He was looking into this, and I have suggested that he respond here on this page. I've got a vague recollection that during the PC trial we saw Google results that showed the "wrong" version of some articles, but given the intervening time I don't want to rely on my own memory for this potentially important issue. Suffice it to say that if GoogleBot is only pulling reviewed changes, there's no issue. On the other hand, if it is pulling unreviewed changes on PC articles (potentially including vandalism and BLP violations, which could show up in Google search results), it would be a significant factor that was not known to the community at the time of the initial RfC, and would mean that PC does not have the protective effect that was assumed. I'd like to suggest holding the close until we have this information, because it might have an effect on next steps. Risker (talk) 03:48, 10 October 2012 (UTC)[reply]

Unfortunately I've confirmed that the PC work did not include modifying the output of the API feeds in this way (so yes, GoogleBot et al. will get the "latest" version regardless of the page's PC state). Sorry to be the bearer of bad news. Clearly fixing this oversight could be undertaken, but there are no resources assigned to the PC codebase at present and choosing so to do is not something in my power. Jdforrester (WMF) (talk) 18:54, 10 October 2012 (UTC)[reply]
Yes. I would say that it is reasonable for the devs to make this change after PC is rolled out. It isn't something that will cripple PC if left till later. Yaris678 (talk) 15:42, 11 October 2012 (UTC)[reply]
Which API feeds, exactly, would need to be changed? Anomie 17:10, 12 October 2012 (UTC)[reply]
  • Hold the phone. Please read carefully what Jdforrester has said here. One of the entire purposes of Pending Changes is to make vandalism less publicly viewable. However, any vandalism added will *still* be seen on Google results, which is the most common way that readers come to our articles. "[T]here are no resources assigned to the PC codebase at present" - that is, despite what so many people think is going to happen, there are no developer changes that are going to happen to pending changes in the foreseeable future, one of the factors that was key to a lot of the support for pending changes in the first place. We're no further ahead, and in a way further behind, than we were when the initial RfC was put forward. Would people have supported PC if they knew that Google results would still contain the very problems that PC is intended to address? Would they have supported it if they knew that the WMF had no developer resources that it could spare to fix the known problems with the software? Risker (talk) 12:54, 12 October 2012 (UTC)[reply]
    I will be raising this issue at WP:VPT because this is a big problem.—cyberpower ChatOnline 13:16, 12 October 2012 (UTC)[reply]

@Risker, It won't do one of its puposes quite as effectively as we would have liked... but... Most pages will get reviewed fairly quickly so the risk is small. Another purpose is denying instant gratification to vandals and that is not damaged by this issue. The important thing is that we roll it out slowly and watch the backlog. Once it is up and running we can see if resources get assigned to improving it. If they don't it will still be useful, but probably only on a very small number of pages. Yaris678 (talk) 14:00, 12 October 2012 (UTC)[reply]

My understanding was that at present there are no developer resources assigned, but that's because PC was in limbo. Now that it's coming out of limbo they will assign resources as needed. ~Adjwilley (talk) 17:38, 12 October 2012 (UTC)[reply]
I spoke to several devs and other Foundation folks about this during and after Wikimania and that is the general impression I got. At present they are not willing to put any further resources into developing it, but if we are using it on a regular basis that can change. However, the way it is now is the way it is going to be for probably at least the first six months after it goes back into use. For the record, at both of the RFCs I opened I endeavored to make it clear to all that at the present time the WMF would not be putting any resources towards this. There was an entire section at the last RFC explaining why "fix it first" was not a tenable position. I tried to get that across but when a discussion is that big details tend to get lost in the shuffle, as evidenced by how many commenters there on all sides seemed to believe we had already resolved the use it/don't use it issue, when all previous efforts to do so had actually failed to arrive at an clear result. Beeblebrox (talk) 19:05, 12 October 2012 (UTC)[reply]
The current bugzilla thread is odd ... someone named Brad is implying that the current bug is intentional, that the community voted to display vandalism by default in Google searches but hide it on Wikipedia. - Dank (push to talk) 20:30, 14 October 2012 (UTC)[reply]
I don't think he's saying that; he asked what API is Google using, and in response to someone saying this is a security issue, responded that the latest version is always accessible to all users, if they go to the page history. isaacl (talk) 21:41, 14 October 2012 (UTC)[reply]
Exactly, Isaacl. You can test this by going to Wikipedia:Pending changes/Testing/4 (which I've just "unaccepted" again for this purpose) while logged out and see how easy it is to access the unreviewed version. As far as I know, Pending changes was never intended to restrict access to anything, just to show casual readers a known-good version of the article. Anomie 23:18, 14 October 2012 (UTC)[reply]
I think I'm confused; this would make a good question for the next RfC. - Dank (push to talk) 23:30, 14 October 2012 (UTC)[reply]
I don't see any reference in the bugzilla thread to the community voting to display vandalism by default in Google searches, so I'm not sure what is the confusing point. (Personally, I'm confused how search engine web crawlers can appear to be a logged in user, but hopefully someone with the appropriate knowledge can clarify how web crawlers access Wikipedia for indexing purposes.) isaacl (talk) 23:48, 14 October 2012 (UTC)[reply]
Since Wikipedia is such a huge, popular site and the big search engines would generate so much traffic, Wikimedia gives Googlebot (and probably other search engines) some special feed of changed pages so they don't have to waste both their and our bandwidth crawling the pages like they normally would. Were someone to tell me where to find the code that generates that special feed, I might well be able to write a patch to fix it so PC protection is honored. Anomie 00:00, 15 October 2012 (UTC)[reply]

In case anyone is still confused about this bugzilla thread, I will attempt to explain. Maximilian Doerr has got the wrong end of the stick:

  1. To most users, PC displays the latest approved version by default (which may be different from the latest version).
  2. All users can see all versions by checking the article history. Anything else would be a massive blow to the wiki way.
  3. I don't know what Maximilian Doerr meant by a security issue but this is the way it is supposed to work.
  4. The issue is that an API call will return the latest version of the article by default, when it should probably return the latest approved version.
  5. When Google extracts information from Wikipedia it uses the API call.

Yaris678 (talk) 15:02, 16 October 2012 (UTC)[reply]

Thanks. This would make a good question for the next RfC. - Dank (push to talk) 15:54, 16 October 2012 (UTC)[reply]
Comments:
  1. If you start from the mistaken assumption that PC is supposed to hide the unreviewed version from non-reviewers, then it would be a security issue (for "leak of rather nonsensitive information" values of "security"). I guess that's what Maximilian meant.
  2. Note the actual issue here may not have anything to do with the MediaWiki API. It's as likely that "API feeds" refers to some feed we are providing for a Google API.
  3. As above, it may be that "API feeds" refers to a Google API that we are calling or providing data for polling.
Anomie 16:54, 16 October 2012 (UTC)[reply]

Taking stock[edit]

Most sections of the RfC haven't had as clear-cut a response as I had hoped, but I think several are lopsided enough in their !votes to provide some tentative guidance in concocting a third RfC. Assuming there is support for a third one, I have started a page where construction can begin if and when anyone is ready, as well as a a talk page to go with it. While the quality of contributors' comments has been rather high in this RfC, I am frankly disappointed that more people haven't participated. I wonder if a watchlist notice might be a good idea the next time around. Rivertorch (talk) 06:12, 8 October 2012 (UTC)[reply]

I think the community as a whole is tired of /bored with/no longer cares about this issue. It is not unlike elections in the U.S. When there is a presidential election turnout is high (by our pathetic standards of a good turnout) but when it is only a local election, turnout can be pathetically low. In my own town of over 5,000 people we just had a mayoral and city council election in which a few hundred people decided who would run the city for the next two years.
I agree it is disappointing and when this is all implemented we will see the inevitable protests that only a few users made policy that is affecting everyone, but that is the situation and I appreciate that the core group here is doing what they can to make the best of it, so by all means get RFC #3 up and running and thanks for soldiering on after all this. Beeblebrox (talk) 21:03, 10 October 2012 (UTC)[reply]
I think it's more a matter of voting fatigue/single-issue wonkery/belief that the provisional policy was the be-all-end-all that killed the turnout. In any case, as I predicted, virtually nothing with 66% or greater support. —Jeremy v^_^v Bori! 06:32, 11 October 2012 (UTC)[reply]

Cancel RfC 3[edit]

Just do it for God's sake. I took a look at the RfC3 draft and it's absolutely nothing that hasn't either been hashed to death already or is pure bike shed trivia. Cancel RfC 3, add the wording that is on the RfC3 draft to the protection policy, and go directly into trials. If there's a problem that comes up, we can address that when it happens. Gigs (talk) 17:46, 11 October 2012 (UTC)[reply]

"Go directly into trials"? The trials already happened (as did the tribulations). When PC goes live in a few weeks, tweaks will still be possible but major policy changes will be a lot more difficult to effect. Better to get as much of it right as possible in the first place. By way of analogy, how about "Never mind the seatbelt—just start driving. Paramedics and trauma surgeons are standing by." Rivertorch (talk) 07:56, 12 October 2012 (UTC)[reply]
Well Gigs may have missed a few things and stated things in intemperate language... but I am inclined to agree with Gigs on RfC3, as currently envisaged, being unnecessary. When RfC2 closes, let's use the results to draft some new words to be inserted into policy pages. We should be ready to call a new RfC on specific points of contention, if they arise during the drafting process. But in general we should just trust the usual wiki editing process. Yaris678 (talk) 08:03, 12 October 2012 (UTC)[reply]
I think my intemperate language reflects the general community sentiment on this. Many people are sick of talking about it and want to see something happen. Asking us to predict the future problems and design policy for them is not going to lead to productive consensus. It's going to be much easier to identify real problems once we start using it (again). Yaris, the draft wording on the RFC 3 page already takes the rough consensus from this RFC 2 into account and seems to be a good starting point. Rivertorch, your analogy is invalid, there's no sunk cost here, everything we do can be changed instantly with a single edit. Gigs (talk) 13:29, 12 October 2012 (UTC)[reply]
Yes. I think when we draft a new policy it will look very similar to some of the words in RfC3. Yaris678 (talk) 13:47, 12 October 2012 (UTC)[reply]
Good editors, old and new, who leave out of frustration cannot be brought back with any number of edits. Rivertorch (talk) 00:58, 13 October 2012 (UTC)[reply]
  • I withdraw my earlier comments about pressing forward since the revelation that PC won't keep unapproved revs out of Google. I see little point in moving forward at all so long as that is the case. I guess my position is still that we shouldn't have another RfC, to be honest I don't think we should spend any more time on this at all until the code actually works. Gigs (talk) 00:31, 18 October 2012 (UTC)[reply]

Let's use flagged revisions then[edit]

Given that

  1. Google is precisely what worries the media and BLP subjects (press articles are regularly illustrated with screenshots of Google hits displaying vandalism; here is one recent example, with abuse in the first line), and
  2. the Foundation can't get it together to make the PC extension work,

I suggest we use Flagged Revisions as used in other Wikipedias (which to my knowledge does not suffer from this problem) rather than Pending Changes.

Also, I've written about the general topic of Flagged Revisions and Wikipedia defamation off-wiki, if anyone's interested: [2] AndreasKolbe JN466 08:46, 18 October 2012 (UTC)[reply]

PC is a variant of flagged revisions. It exists because the standard version of flagged revisions was not acceptable to the majority of English-language Wikipedians.
The idea of using the standard flagged revisions on en.wp will get nowhere but may distract from PC.
I think you exaggerate the importance of the Google issue. I'm not saying it is irrelevant, but it is a relatively low risk because reviewers will review most articles pretty quickly.
Also... I am not saying this will change my opinion on any of the above.... but do you have any evidence that the Google issue does not apply with the standard flagged revisions?
Yaris678 (talk) 09:26, 18 October 2012 (UTC)[reply]
I suggest we discuss the Google issue in one place so that we get a range of views. Either the talk page of RfC 3, or RfC 3 itself, would work. - Dank (push to talk) 12:45, 18 October 2012 (UTC)[reply]
The only question is whether it's a showstopper or not, and I'm not even sure that's a question we need to ask to the wider community. To me it's pretty clear that it is a showstopper. Gigs (talk) 14:03, 18 October 2012 (UTC)[reply]
I think it isn't a show stopper... but then maybe that is why we should ask the wider community. It may be worth finding the answer to the flagged-revs question first though. i.e. Does flagged revs expose the latest version of the article to Google? I suspect the answer is "yes". However, if the answer is "no" it should be fairly easy to apply the same code to PC, since it is based on flagged revs. If the answer is "yes" then it makes you wonder why no one on the German Wikipedia (or the other places that use flagged revs) cares about the Google issue. Yaris678 (talk) 15:28, 18 October 2012 (UTC)[reply]
Good question, I've asked on the German Wikipedia, here. - Dank (push to talk) 16:30, 18 October 2012 (UTC)[reply]

I think the only reason we should take this back to the wider community at this point is to ask the question whether we should go forward with PC on December 1 with the new knowledge that it is not going to keep unapproved revs out of Google. We should get the information on whether flagged revs has the same problem first though. BTW- I may still have SVN access, but I haven't done any Mediawiki dev in a very long time and I'm rusty. Gigs (talk) 16:50, 18 October 2012 (UTC)[reply]

  • I think the question we need to be asking ourselves before we talk about trying to kill PC over this is: "If non-approved changes are indexed by Google, will be be any worse off than we are now?" I would argue no. Whenever you view a cached page in Google, you get the message "This is Google's cache of <<page url>>. It is a snapshot of the page as it appeared on Oct 15, 2012 19:48:49 GMT. The current page could have changed in the meantime." People realize that Google isn't necessarily showing the correct page, and I don't know very many people who read their Wikipedia pages from the Google Cache.

    The second reason we will be no worse off than we are now is that currently all of our revisions are "unreviewed". Yes, they get reviewed over time, but we have millions of "unreviewed" edits that are getting indexed by Google without being "reviewed". This is not a problem that is unique to Pending Changes, and at least with PC the Wikipedia page will be showing the correct "reviewed" version, no matter what the Google cache shows. ~Adjwilley (talk) 17:12, 18 October 2012 (UTC)[reply]

Let's be realistic. As I read the close of the big RfC, it would be next to impossible to "kill PC" over this or anything else; killing it would require another big RfC (i.e., two months long, advertised everywhere, and brimming with acrimony) that officially overturned the last RfC, and that simply isn't going to happen at this point. Might it be possible to place certain limits on the use of PC because of the Google issue? I don't see why not. That's a question that can be addressed in the third and final informal RfC. Rivertorch (talk) 17:59, 18 October 2012 (UTC)[reply]
What's the purpose of PC (assuming that it works as intended)? We can revert vandalism now; we don't need PC for that. I was thinking the 3 main purposes are: stability (we can revert vandalism all day long, and it won't undo the damage that was done when Obama's page was replaced by "Nigga Nigga Nigga" long enough to show up on Google searches), denying the thrill that some get from displaying their bad behavior to the whole world, and the fact that new people usually take "official" actions more seriously (for better or worse) than what they regard as random reversions. Google doesn't work instantaneously, of course ... so if I "officially" deny your edit, but Google keeps on showing your version and not mine, that undermines all 3 of those purposes of PC: if anything, it heightens the thrill from the bad behavior (because now they're defeating an "official" WPian rather than just edit-warring), and if we're choosing to send Google the bad version of the page rather than the good version, it undermines the notion that the "officially" approved version actually is any better than the bad version. - Dank (push to talk) 18:03, 18 October 2012 (UTC)[reply]
That's not a notion you should be cultivating (that the approved revisions are "official"). All it does is give Wikipedia more black eyes when some reviewer with a single-digit IQ in the topic area approves an innocuous-looking but factually incorrect revision. And this isn't a question of "if" but "when" it will happen. —Jeremy v^_^v Bori! 20:21, 18 October 2012 (UTC)[reply]
Dank may have chosen his words poorly, but his sentiment is very valid. If PC puts the unapproved stuff into Google's cache, I don't see any benefit over the status quo. In fact, it's a detriment, because Obama's vandalized page may last far longer in Google's cache since readers who visit the page will be less likely to revert it if what they see is the proper biography, instead of blatant vandalism. They'll assume Google was out of date and shrug. The vandalism will sit there in Google's cache until someone that knows what a pending change is can revert it. Gigs (talk) 21:21, 18 October 2012 (UTC)[reply]
Barack Obama is such a high-traffic page that it's not really a good candidate for PC anyway. That doesn't mean that we shouldn't be able to use it on other pages. WhatamIdoing (talk) 00:47, 19 October 2012 (UTC)[reply]
The quote marks around "official" mean: people may think it's "official" when it isn't. Since we're giving reviewers a tool that lets them deny edits by new users, the new users are likely to think of these reviewers as part of WP's bureaucracy or power structure. Agreed that, with the current software, PC can't be applied to the Obama page. - Dank (push to talk) 02:06, 19 October 2012 (UTC)[reply]
  • I can't believe we are seriously having this discussion. First of all, at this point WP is well known enough that many people search here first if they think we have an article. This does not strike me as the major flaw some are making it out to be, as is pointed out above there are many unreviewed changes right now, but we aren't banning all editing by unconfirmed users because Google might pick up some of it. and the idea of just replacing it with FlaggedRevs is a complete non-starter. the discussions we had over the last several years we not about FLagged Revs, they were about using pending changes, a tool developed specifically to be used on this project because this project asked for it. There's no way we can just say "oh never mind we'll just use the tool this community already explicitly rejected three years ago". and no, we should not use PC on large high-traffic articles, semi protection is a better fit for those types of articles. I thought we had already established that several months ago. Beeblebrox (talk) 18:21, 20 October 2012 (UTC)[reply]
    • Agreed that FR, and using PC on large high-traffic articles, are off the table. - Dank (push to talk) 18:50, 20 October 2012 (UTC)[reply]
      • Obviously. I didn't think it even needed to be said. Rivertorch (talk) 19:28, 20 October 2012 (UTC)[reply]
        • I still think it's a major issue in that it increases the potential harm done from vandalism. You all have persuaded me that it isn't the showstopper I initially thought, but I think it should be addressed as soon as possible. Gigs (talk) 18:43, 21 October 2012 (UTC)[reply]

Close[edit]

Hello everyone; I apologize for not getting to this earlier, a look at my talkpage should give you the reasons why. Anyways, there's no way I'll be able to do it today, but tomorrow early afternoon I should be able to take care of it. The Blade of the Northern Lights (話して下さい) 16:40, 21 October 2012 (UTC)[reply]

And thanks for doing it. A comprehensive and clear close. Rivertorch (talk) 11:39, 23 October 2012 (UTC)[reply]
Yep. A good close. It fairly describes the consensus where it exists and points us in the right direction for how to deal with some of the unresolved issues. Yaris678 (talk) 12:17, 23 October 2012 (UTC)[reply]