There has been a fair amount of discussion about whether or not to scrap PC-2. There seems to be a fair consensus that PC-2 is not going to be widely used, and that its usefulness is very small. I agree with this. There is also the feeling that PC-2 will scare away potential supporters of PC, which I also agree with. I would argue, however, that PC-2+Semi (the next level up) would be a very useful level for articles that border on needing full protection. (I gave the examples of Barack Obama and Mitt Romney above.)

I was hoping to get people's opinions on this: specifically whether PC-2 should go away or be written out of the policy, and whether PC-2+Semi protection should follow suit. ~Adjwilley (talk) 19:00, 20 July 2012 (UTC)[reply]

• If we're voting (and I don't mind votes, btw): scrap both, and experiment with letting people edit a working version of at least some pages that are full-protected. - Dank (push to talk) 19:06, 20 July 2012 (UTC)[reply]
  • The attraction of PC2 for some WPians is that, unlike PC1, it doesn't distinguish between IPs and autoconfirmed users; this is seen as more egalitarian. I think that's a problem too, but there are ways to limit the damage. If it turns out that PC1 is used only in cases of recent vandalism, then I suggest we not even mention that the IP is being treated any differently, just say something like "Because of recent vandalism to this article, edits may take minutes or hours to appear." (If reviewing takes days, then IMO we're starting to damage our reputation and need to re-think.) By the time the IP learns that autoconfirmed editors don't have to wait, hopefully they'll understand WP well enough to know that reviewers aren't in fact going to reject their edit just because they don't like it, except in cases of vandalism. - Dank (push to talk) 21:11, 20 July 2012 (UTC)[reply]
• (edit conflict) In the end I think we should punt on PC2, the rollout of PC that occurs in January should include a guideline that neither PC2 nor PC2+semi may be used, with the intention that they be left in the technical implementation, and at some point down the line, after people have adjusted to PC1, there can be an RFC that considers PC2/PC2+Semi. We can make a final decision on scraping PC2 then. Monty₈₄₅ 19:10, 20 July 2012 (UTC)[reply]
  • "Punt" is not off the table for me, I just want to point out the downside. If you propose a vote on "ice cream for everyone, with excruciating torture to be decided later", you may find that you don't get your ice cream. If we're going to say "punt", then at least make it clear that all of us "get" the arguments against PC2 and PC2+semi, and that we don't have any intention of going with it unless a clear need arises ... and describe what that need would look like. - Dank (push to talk) 19:15, 20 July 2012 (UTC)[reply]
• I think that PC2 should be available as tools, but should be severely restricted by the policy. PC2 should be included in the policy/table for reference (to explain what it is), but should not be used. PC2+Semi should only be used as an alternative to full-protection. ~Adjwilley (talk) 19:18, 20 July 2012 (UTC)[reply]
• Emphasising that "least" is a relative word, PC1 is objectively the least controversial part of PC, given that it opens the possibility of IPs editing some articles that are currently locked. The argument against PC1 as a tool is very weak, given that it is less of a barrier to a good-faith IP than semi-protection. With PC1 the fears are over how widely it will be deployed, and that is a matter of policy.

  The use of PC2 is perceived by many as creating an elitist cabal that may edit as they please in return for the responsibility of deciding whether other people's edits are acceptable. I don't think that is a fair picture of PC2, but it is a mainstream view. I respect Adjwilley's suggestion that we severely restrict it, but if it creates 80% of the drama for 1% of the potential benefit, I question whether in the long run it would be a net positive for Wikipedia.

  In summary, if kicking PC2 into the long grass allows us concentrate on the most productive element of pending changes – PC1 – then I'm all for it. —WFC— 19:25, 20 July 2012 (UTC)[reply]

Yea - me too - Youreallycan 19:28, 20 July 2012 (UTC)[reply]

That is more or less how I see it as well. During and after the trial I struggle to remember even one incidence of PC2 being used. It will expedite matters here if we are discussing only one tool. "Normal" PC is almost certainly going to be the default use of PC in almost all cases. Maybe instead of saying it is scrapped or deprecated we go with not including it in the pilot project, with an eye to re-examining its usefulness later once we have a better handle on PC level one. we should endeavor to keep things as simple as possible here as we have limited time to make some rather important decisions. Beeblebrox (talk) 19:36, 20 July 2012 (UTC)[reply]

I would really prefer to keep PC2 in the potential toolbox. There are a small number of low-traffic BLPs I've dealt with get hit, perhaps only a couple times a year (but in one case, this went on almost five years), with some pretty harsh slander, and the individuals involved don't see any difficulty at all getting new accounts autoconfirmed. I don't care if it's PC2 or PC2+SP, but either of those would be a better fit than full indef. Maybe I should just accept indef full. *shrug* --j⚛e decker^talk 20:00, 20 July 2012 (UTC)[reply]

If any editor supports this level of protection use (PC 2) as beneficial with a decent explanation as per Joe Decker above I support it - imo the level of usaghe will be so low as to never be an issue to the reasons users/editor opined against the tool - Youreallycan 20:03, 20 July 2012 (UTC)[reply]

I guess my argument is that there is a massive, massive benefit in splitting PC1 and PC2 into separate issues, and introducing 1 before considering the future of 2.

If, and only if, PC2 is completely unused, those who were only against that part of it will presumably be less hostile, neutral or supportive of PC1. If on the other hand PC2 remains, most of them will continue to be against PC.

By giving PC1 and PC2 very distinct identities, and kicking one of them into the long grass, it is possible to have rational discussions about each tool in turn. If the price of reconciling the community and making PC1 work is that we have to keep the current policy for full protection a little longer, I see that as a bargain. —WFC— 20:37, 20 July 2012 (UTC)[reply]

I'm completely agreed that Monty's argument and your argument makes sense. I see no bad faith in this at all. But I think there's a chance that you're missing how this is going to sound to some of the opposition. Consider the following argument: "I think that drug abuse laws fill our prison system with non-violent offenders and promote organized crime. The issues for me are the same whether we're talking about weed or heroin, and most people agree with me about weed, but not about heroin. So I'm going to get a proposition on the ballot to legalize pot. After that passes, and people get some experience with it and see that the world hasn't come to an end, then we can talk about legalizing heroin." Are we agreed that, if I say that publicly and if other people are agreed, that that approach might cause the ballot initiative on marijuana to fail? - Dank (push to talk) 21:24, 20 July 2012 (UTC)[reply]

But that argument could be applied either way. Weed could refer to PC1 and heroin to PC2, or weed could refer to the use of PC2 only in the most egregious of BLP situations, and heroin a liberal application of PC2.

Using the former analogy, which I assume was the one you had in mind, at the moment we already have a date for the legalisation of heroin. I can't see those opposed to all drugs being unhappy if we decide to keep heroin illegal. They would want us to go further, but be relieved that we have taken at least one step back. —WFC— 21:46, 20 July 2012 (UTC)[reply]

Sure, that's true too. I think both points were useful, and now all we have to do is see what the voters have to say about it. - Dank (push to talk) 21:58, 20 July 2012 (UTC)[reply]

I tend to think of PC as crystal meth or perhaps bath salts, but that's neither here nor there. Rivertorch (talk) 17:08, 22 July 2012 (UTC)[reply]

Couldn't we just list the pages that are targets of nasty slander somewhere, and ask people to watchlist them and revert quickly? What would be the downside? - Dank (push to talk) 20:21, 20 July 2012 (UTC)[reply]

Yes. And we don't need PC in any form to do that. I've been toying with the idea of a "please watch" or "more eyes needed" noticeboard for some while. Rivertorch (talk) 17:04, 22 July 2012 (UTC)[reply]

A shared watchlist perhaps? It occurs to me that it would be very easy to implement one, set up a "legit alternate account", give it an accessible watchlist code (that technology already exists), and set up a process for adding/removing entries to it. (To the extent that I believe that PC2/PC2+SP are useful, it's for worrying about the vandal that will probably strike far down the road, on a very low traffic article. So, for my use case, *any* solution that guarantees eyes on changes down the road would be fine too.) --j⚛e decker^talk 00:36, 25 July 2012 (UTC)[reply]

Interesting. Could you expand a bit on the shared watchlist idea? I'm not quite sure how that would work.

The thing about PC2 is that it addresses a problem—autoconfirmed editors, particularly of the sock- or meat-puppet persuasion, disrupting articles—that otherwise can be hard to deal with. PC1 addresses a problem that is easily solvable by other means: semi-protection. Rivertorch (talk) 20:22, 27 July 2012 (UTC)[reply]

Rivertorch, sure. It's possibly half-baked, but here goes. First, I would agree with your descriptions of the use of PC1/PC2. My own work tends towards the very infrequently edited biography, and yet, I've found a few cases where the intent to add problematic content to a handful of biographies is strong enough that the same editor will make attempts "now and then", maybe a dozen runs over half as many years, but under different usernames, and they seem smart enough to get auto-confirmed to work around semi. The couple cases I can think of come are low-traffic articles too (while not much vandalism, it's more than half the non-bot edits), at least two are cases where I've conversed with the article subject via OTRS and they're pissed. While I would love to *completely* protect these articles from having that content added, what concerns me more is the case where it sits there for a year.

The value of PC2 is it gives me a way in a handful of cases of forcing eyes onto a relatively tiny number of concerning changes. And it's possible that a watchlist dedicated to high-risk bios of this type could accomplish some of those same ends, even if there'd be more reversions.

How would that work? Well, technically, it's possible, as I understand it. to do with existing code. Make a dedicated account for the purpose. Use it's watchlist. Export it using the feature that lets you give out a big long magic cookie to make your watchlist public. I'd imagine some sort of RFPP / Spam whitelist like venue where people could request addition or removal based on similar criteria. You could use something like a file with the related changes function, I'd imagine, to do something similar. In short, there'd need to be a public way to look at edits to a public list of articles that were deemed high-risk.

The upside is that it doesn't have "PC" written on it, and avoids whatever aspects of PC people find uncomfortable. The downside is that it allows the negative comments into the article, and doesn't guarantee one set of eyes on 'em, but perhaps the ratio of articles/watchers could be small enough that those changes *usually* got noticed. *shrug* As I said, half-baked. :) --j⚛e decker^talk 19:10, 13 August 2012 (UTC)[reply]

I'm more concerned about the possibility that Pending Changes will do harm, and this doesn't have much to do with anything people have said here, it comes from soliciting opinions privately. The biggest problem I think is that, regardless of whether we have a lot of reviewers and argue over who to demote, or have a few and argue over who to promote, politics is going to play a role, and that's going to create problems. This is more or less the same issue that's scuttled every attempt for many years to either lower the bar for adminship or create a new role under adminship; the main worry has been that the fights over who gets the new role will suck up time and push people away. I can't say that that's an actual problem, I can only say that it's been the most consistent worry in the many discussions at WT:RFA and elsewhere. If reviewing is changed so that it's a relatively easy job, that might fix the problem, but I think we're going to have a hard time getting consensus on that or any other substantial change, so let's assume until a vote proves otherwise that reviewing requires knowledge and competence. Do we let admins demote anyone they want to for any reason? That didn't work out so well in the trials; at least one person who didn't ask to be a reviewer and hadn't done any real reviewing had his privileges taken away because an admin suspected he might misuse the privilege. Do we have a noisy community process to remove the privilege? Are privileges removed quietly by some committee? I'll issue an invitation over at WT:RFA; some who watchlist there have years of experience with these arguments. - Dank (push to talk) 20:03, 4 August 2012 (UTC)[reply]

Do we let admins demote anyone they want to for any reason? I'm very much in the "there is a systemic problem with admins" camp. But that is the most workable way, provided that there is a firm counterbalance to ensure that in practise only blatant abuse of the right is dealt with in this way. Why does wheel warring rarely happen? Because individual admins know that anyone without a VERY good reason for their actions will get crucified for it. And yet the theoretical threat of being hauled before Arbcom rarely stops admins from reversing or reinstating administrative actions, in cases where it is appropriate to do so without discussion. —WFC— 20:54, 4 August 2012 (UTC)[reply]

This seems like an issue that doesn't exist - a user that shows understanding of policy and guidelines qualifies for the user right - WP:Policy and guidelines - its a minor/ish user right - if its abused remove it - if that removal is disputed - take it to a noticeboard for further community discussion - In the trial there was a single case of disputed removal of the user right. - Youreallycan 21:57, 4 August 2012 (UTC)[reply]

That's the way it works with rollback and other low-level permissions. The community has made it clear they pnly want permissions revoked if the user has spcifically misused the tool as opposed to generally not being productive but not in a way that involvs misuse of the tool. I can't see why that approach won't work here. To be granted one need only demonstrate that they can recognize vandalism when they see it. Beeblebrox (talk) 00:31, 5 August 2012 (UTC)[reply]

Simply put, Beeblebrox, I can think of at least half a dozen admins who should be desysopped if they're only supposed to remove tools because of misuse - and keep in mind I'm not really paying attention. The rollback tool is essentially just fancy "undo" and its removal from a user has no effect on anything, except for the embarrassment of the user involved. Removal of reviewer permissions goes to the heart of content building: edits made by non-reviewers are not treated as those by other users. What a wonderful way to retain editors... Risker (talk) 01:29, 5 August 2012 (UTC)[reply]

What I am getting at, but perhaps did not clearly express, is not so far away from what you are saying as you might think. I think it is more important to have clear standards for the reviewers themselves than to spend a lot of time worrying about how they get the right. If a user is misusing the reviewer right to reject good faith edits because they just don't agree, have a prejudice against IPs, or whatever, they need to have the tool yanked as quickly as possible. if we are clear from the outset with the reviewers that this tool can and will be taken back if they abuse it even a little bit, that will give admins the tool they need to go ahead and do it with a minimum of fuss when they see the need. It is a tool with a greater potential for abuse than rollback, but it doesn't really require much more judgement than rollback as its purpose is essentially the same: to stop bad faith edits. If someone is using it for some other purpose we have got to be able to stop them as quickly and simply as possible. Beeblebrox (talk) 01:42, 5 August 2012 (UTC)[reply]

(and I really do think the community has told admins they do not want permissions revoked unless those specific permissions are being abused, but it usually leads to a lot of yelling, not desysopping. However off the top of my head I can't remember where I got that idea. Beeblebrox (talk) 01:50, 5 August 2012 (UTC))[reply]

Beeb, on top of the problem that Risker just mentioned ... why in the world would our experiences with the rollbacker userright tell us what to expect from reviewership? One lets you revert slightly faster, the other is the most significant new userright since adminship arrived in 2003. It's not just about "bad faith edits" unless we get a consensus to change the results from the RFC ... and anyway, is it a trivial job to guess whether an edit was made in bad faith? Better analogies would be the various proposals that have been debated and rejected over the years concerning traineeships, clerkships, and other sub-admin positions. I'm hoping one of the guys from WT:RFA will drop by to give us a summary of the main concerns people have had about promotion and demotion procedures. - Dank (push to talk) 01:58, 5 August 2012 (UTC)[reply]

If it's concern over the functionality of the reviewer usergroup that you're worried about, when/if Pending Changes goes into effect, that can simply be addressed by having a bot send a boilerplate message to everyone within the usergroup. The message can explain to everyone who has the reviewer flag about a list of functions they have been entrusted with, and how they work. After that, if there is any abuse of the function, then you can have an administrator remove it. This seems like the best course of action here. Regards, — Moe ε 09:45, 5 August 2012 (UTC)[reply]

On promoting reviewers: There needs to be a legal agreement between the Wikimedia Foundation and reviewers. It needs to define who owns the risk that the reviewer mistakenly approves something that's defamatory, in breach of copyright, etc. (Is there a "do not ever grant reviewer permission under any circumstances" list? If not, please start one with my name at the top.)—S Marshall T/C 07:44, 7 August 2012 (UTC)[reply]

• We basically have two major problems with this userright. One is the concern that there will not be enough reviewers to handle the workload. We can resolve that by making it relatively easy to get if a user has a minimum level of experience that shows the judgement needed to distinguish vandlism, blp violations, etc from non-problematic edits.

• Conversly, the other issue is the concern that this will give these users the ability to act like petty thugs and keep out any edit that they don't happen to like even if there is no legitimate reason for doing so. Making the userright even easier to remove than it is to get in the first place seems like the best way to address that concern. So what I am saying is that we should make it clear to all reviewers that as little as one example of them using the tool in a manner inconsistent with its stated purpose will result in immediate revocation, and that they will be held to a higher standard if and when they elect to re-apply for it. I think it is extremely likely that our most active reviewers will be folks who already do new page/vandalism patrol. These users are sometimes not our best content editors, they tend to make hasty decisions because of the rapid-fire nature of such work, and dealing with various kinds of bad faith edits all day long can lead them to assume bad faith when they shouldn't. We need to keep them on a short leash to avoid driving away good faith new users and IPs.

• So, low bar for getting it, even lower for losing it. Simple and to the point, and we should put it just like that to be clear as possible. If anyone can think of a better way to satisfy both of those concerns without a lot of needless bureacracy or instruction creep I'm all ears. Beeblebrox (talk) 02:26, 8 August 2012 (UTC)[reply]

That approach should work, provided that there is a low bar for accepting edits, such as the one I attempted to outline at the bottom of the Vandalism and reviewership section. —WFC— 10:03, 8 August 2012 (UTC)[reply]

I was under the impression that the new page patrollers were understaffed. If this already small group is anticipated to be one of the primary sources of reviewers, and you're envisioning that not all of them will be retaining reviewer status, then it sounds like the deployment of pending changes will have to be carefully scaled to match the pool of reviewers. isaacl (talk) 02:49, 8 August 2012 (UTC)[reply]

Okay, so this issue would be my call for the first RfC. My expectations keep dropping; at this point, I'd consider identifying and avoiding the worst possible outcomes for Pending Changes as a "win". If Pending Changes harms articles, we can fix the articles, and if we find we have to shut it down after a couple of months because it's driving away some first-time contributors, all we lose is a few first-time contributors. But IMO there's no fixing the damage to the community that would be done by giving admins wide discretion on publicly handing out warnings to and demoting reviewers, while expecting editors with no more experience than most rollbackers to try to fix a wide range of BLP edits. Different admins draw the BLP line in different places; some will be warning reviewers for being too bitey by rejecting edits, while others will be warning reviewers for violating BLP policy by accepting the same kinds of edits. And remember that this is a more shameful warning that most talk-page warnings ... if you warn someone that an edit was wrong, then technically, you're only saying the edit was wrong; if you warn someone that you might revoke a common and popular userright, you're commenting on their worthiness to hold the userright. I think what people are missing here is that a large majority of helpful edits to Wikipedia are made by people who really don't feel a strong connection to all of Wikipedia ... and if we hassle them, they're not going to demand changes to the system or take their complaint to the proper forum, they're just going to leave. Most editors who apply for reviewership are going to be doing it because it seems either inconvenient or shameful to have to wait for approval for their edits on some pages, not because they're volunteering to make Wikipedia a better place. But to get their edits to show up immediately, they'll have to approve or reject previous unapproved edits, and when admins can't agree on where the dividing line should be on BLP edits, what are the chances that less-devoted editors will get it right every time? And what are the chances that admins who feel strongly about either BLP or biteyness are going to be persuaded not to give talk page warnings when they see Pending Changes having an effect they don't like? Without changes to the draft version of Pending Changes, we're probably going to lose quite a few valuable contributors, and even if we fix or discontinue Pending Changes later, they won't be coming back. - Dank (push to talk) 16:42, 8 August 2012 (UTC)[reply]

All very true, and all very disturbing. Rivertorch (talk) 19:34, 8 August 2012 (UTC)[reply]

Because the work is very similar, I think that it would be appropriate to use the same request/removal procedure for the reviewer right as we are already using for WP:Autopatrolled right. The one allows you to mark your own new articles as reviewed, and the other allows you to mark your own individual edits as reviewed.

I think that the worst thing we could do is to create a brand-new special procedure. We should always seek to build on the familiar and functioning. WhatamIdoing (talk) 18:12, 13 August 2012 (UTC)[reply]

... is nobody discussing the legal risk to reviewers? Is there something I'm missing or failing to understand?—S Marshall T/C 07:41, 8 August 2012 (UTC)[reply]

• The argument was that since other Wikipedias use flagged revisions since 2008 and the issue never popped up, it should not be that important.--Ymblanter (talk) 07:51, 8 August 2012 (UTC)[reply]

• That was the principal substantive argument, yes. There has also been a considerable amount of out-of-hand dismissal. As far as I can tell, the reality is that nobody really knows. It has been brought up repeatedly (and rightly so, imo), but I can't imagine extended discussion amounting to much more than speculation. It would be really nice if the WMF would provide some guidance, but I'm not holding my breath. My two-cent speculation: the risk is quite small but not vanishingly so. Those who accept the reviewer flag and approve certain borderline edits should consider themselves guinea pigs of a sort. It might be as well if reviewers were reminded that there'd potentially be fallout (e.g., loss of pseudonymity) even if any legal case against them were dismissed or decided in their favor. Rivertorch (talk) 09:30, 8 August 2012 (UTC)[reply]

  Yes, this is probably correct.--Ymblanter (talk) 09:38, 8 August 2012 (UTC)[reply]

• I would suggest that it is not possible to come to a worthwhile conclusion on the legal situation until we have decided what we would like reviewers to do. It is therefore a waste of time to primarily focus on legalities at this stage. And it's interesting that those who wish to discuss legalities have little interest in helping out with the prerequisite discussion. —WFC— 10:07, 8 August 2012 (UTC)[reply]

  I'm disappointed at how few of us have stuck around to this stage, but I recognize that people are busy elsewhere on the wiki and elsewhere in their lives. Anyway, it's a legitimate question for anyone to raise, regardless of whether they've joined in other discussions. You may be right about the order of things, but I'm not so sure. If we had a better handle on the legal implications, we might be able to make better-informed decisions on what reviewers should do. Rivertorch (talk) 10:16, 8 August 2012 (UTC)[reply]

  As I mentioned above, for whatever it's worth, Wikipedia's general disclaimer is currently in place. In part, it says, "...while readers may correct errors or engage in casual peer review, they have no legal duty to do so and thus all information read here is without any implied warranty of fitness for any purpose or use whatsoever. ... None of the contributors, sponsors, administrators, or anyone else connected with Wikipedia in any way whatsoever can be responsible for the appearance of any inaccurate or libelous information or for your use of the information contained in or linked from these web pages." isaacl (talk) 10:56, 8 August 2012 (UTC)[reply]

  @WFC: I participated in the RfC, but I find it very difficult to participate now in the discussion which is spread over five pages. May be later this month I will have time to read all of them and contribute (I have an extensive experience from a different language Wikipedia), but right now I was not able to keep up with it.--Ymblanter (talk) 13:16, 8 August 2012 (UTC)[reply]

• What this says to me is that there may or may not be a legal aspect to those with the "reviewer" flag. It may vary according to nationality. (For example, if a British reviewer mistakenly or negligently approves a defamatory edit by a Dutch vandal to a biography of a Canadian politician, and the Canadian politician brings an action against the British reviewer, which law would apply? Matters of venue in international law can get extremely complicated.) It follows that morally speaking, the "reviewer" flag can't be handed out on a whim like rollback. I see it that at minimum, the "reviewer" flag should be something you apply for. More properly, there should be a legal agreement between the reviewer and the Wikimedia foundation that sets out who accepts legal risk for what.

  I suspect that the Wikimedia Foundation's position will be that it's protected by the American acts that also protect web forum hosts—i.e. that it's not sue-able for the actions of the site's users. That seems understandable and logical but it also represents a concern for the person who is excercising editorial control, and it seems ethically essential that the editor accepting the risk should somehow "sign for" or document (a) their awareness of the risk and (b) their acceptance of it.

  This also opens up further questions about who's liable if the reviewer who mistakenly or negligently approves the problem edit turns out to be a child, or otherwise protected from the legal consequences of their actions. Does the risk then fall on the sysop who granted the flag?

  It's all very simple when editors are individually responsible for their own edits. In a Pending Changes environment where reviewers make themselves responsible for the edits of others, it seems to me that what we have is a horribly tangled mess.—S Marshall T/C 11:16, 8 August 2012 (UTC)[reply]

Sure. Given that pending changes is now definitely going to be introduced, in my opinion the easiest way to provide that protection is to oblige the acceptance of any edit which does not fail a set of criteria, whilst permitting reviewers to accept an edit and then revert if they consider it necessary. —WFC— 14:02, 8 August 2012 (UTC)[reply]

(blinks) What?—S Marshall T/C 14:14, 8 August 2012 (UTC)[reply]

The longer version can be found two sections above. —WFC— 14:15, 8 August 2012 (UTC)[reply]

• Oh, I see. I wonder if that's what users had in mind when they voted in favour of this marvellous proposal.—S Marshall T/C 15:51, 8 August 2012 (UTC)[reply]

Mmm (biting tongue hard enough to hurt) Rivertorch (talk) 19:40, 8 August 2012 (UTC)[reply]

The people who opposed PC generally did so on the assumption that it would amount hierarchical censorship. Those who supported it generally did so on the grounds that it provided a necessary additional level of protection, one which is less of a barrier to good-faith editors than semi or full protection.

My suggestion puts all editors who are not here to vandalise on a similar footing to that they are currently on: both subject to our rules on edit warring, neither permitted to use their positions to gain an editorial advantage. PC does introduce a "safety net" or "needless delay", depending on perspective. But given that you are both sincerely concerned about the legal considerations, you will be delighted that when a BLP is edited to include claims that the subject is a child raping facist, this "information" will no longer immediately go live on protected articles.

If either of you have constructive criticism rather than sarcastic sneers (or threats of self mutilation...) then I'd be interested to see them. —WFC— 22:00, 8 August 2012 (UTC) (edited "thoughts" to "criticism") —WFC— 22:08, 8 August 2012 (UTC)[reply]

• The grave and profound problems with most implementations of PC have nothing to do with a "needless delay". My point was that those who supported PC may have been taken to supporting broadly what we've written here.

  Regardless of what the RFC purports to say, it's unreasonable to contend that the community has written out a blank cheque to pre-approve whatever totally new process a small number of editors come up with on this page, regardless of what it is. What you come up with has to bear some kind of basic resemblance to the process originally advertised.

  It follows that there's a basic expectation in the community that reviewers will examine an edit for vandalism, BLP issues, copyright violations, legal threats, personal attacks, or libel before approving it. Because that's what we said. This means reviewers are exerting editorial control, and at least for editors of some nationalities, editorial control means legal risk, as I have explained above, which has the implications I have listed above about the process of selecting and appointing reviewers.—S Marshall T/C 06:58, 9 August 2012 (UTC)[reply]

• All right, I guess I'll stop biting my tongue, and I'm very sorry to have attempted to lighten the mood. (Fwiw, I see no sarcastic sneers in S Marshall's remark—just a bit of mild irony.) The people who opposed PC did not "generally [do] so on the assumption that it would amount hierarchical censorship"; it requires no lengthy analysis to discover that the people who opposed PC did so for a raft of reasons, many of which had absolutely nothing to do with hierarchy or censorship. One of the many concerns that came up, both during the recent RfC and previously, was the question of legal responsibility. Therefore, it seems reasonable that that concern should be addressed as part of the process we're going through now. If that discussion doesn't interest you, that's fine, but I assume you have no objection to our discussing it. While the legal angle isn't my main concern, more than one editor whose judgment I respect have raised it, so I think it warrants consideration. Rivertorch (talk) 08:30, 9 August 2012 (UTC)[reply]

• As reasonable as a discussion on legalities might be, you cannot have a meaningful legal discussion without first defining the thing that might cause legal issues. You can speculate on bright-line scenarios, but if the threat of litigation is remotely credible (and you're the one asserting that it is), it needs to be more in-depth than that.

  Nonetheless, I'll give it a try. At the most simplified form, the legal concern is the question of whether the reviewer is exercising control over the content, and if so, how likely it is that something which could plausibly end up in court could both be accepted, and be considered the reviewer's responsibility. We cannot possibly address any of those issues without first outlining how we would like PC to look. That is not me being awkward: it is literally impossible to deal with those issues while we have an undefined process. —WFC— 11:07, 9 August 2012 (UTC)[reply]

• In response to S Marshall's second paragraph, the RfC's outcome was that the community accepted the tool's adoption, but was *not* satisfied with the process under which that tool would be used. This process isn't a case of a few editors changing it at a whim. It's the case of a small number of editors trying to draft a better procedure than the original train-wreck, and at the end of it, asking the community whether to go with the original draft proposal, or the one that emerges from this process. —WFC— 11:14, 9 August 2012 (UTC)[reply]

Oh, I see the source of the confusion. My original remark was in the context of Dank's question; please read it in that light. I am not attempting to start an in-depth discussion on international law between unqualified people on this page. I am talking specifically about the approvals process for potential reviewers.

My position is that part of that process should be the reviewer indicating his or her awareness of the potential legal issues involved. I accept that we can't yet define those issues. The Wikimedia Foundation's counsel should draft an appropriate paragraph once we've established the parameters.—S Marshall T/C 12:55, 9 August 2012 (UTC)[reply]

From purely the perspective of an eventual closer, I'd be a lot more concerned about legal ramifications of accepting edits if 1. the WMF indicated at any point there could be any or if 2. people were similarly concerned about using the rollback tool to reinstate a revision that turned out to be problematic for any number of reasons. To get proof for or against 1 would require someone to ask the right person, and for 2 I'd at least need a bit of clarification to understand the difference in scenarios. The Blade of the Northern Lights (話して下さい) 22:26, 12 August 2012 (UTC)[reply]

Rollback is a shortcut to doing something an editor can already do the long way around. It doesn't change the basic fact that on Wikipedia at the moment, each individual editor is responsible for their own edits. "Reviewer" is a new tool that, by its naming and nature, makes the reviewer responsible for someone else's edits. You don't exactly have to be Sherlock Holmes to see the legal risk the reviewers are running, do you?—S Marshall T/C 09:25, 13 August 2012 (UTC)[reply]

That is true. Thus, the solution is to change the name to something a little less loaded than "reviewer", and to ensure that the role becomes a shortcut to something that users can already do (namely keep vandalism or harmful unsourced material off of articles). —WFC— 12:45, 13 August 2012 (UTC)[reply]

Based on Dank's previous post regarding what WMF's general counsel said, with the appropriate wording to the review policy, I imagine that the Wikipedia's general disclaimer at the bottom of each page, if not already sufficient to disclaim responsibility, can be broadened as needed. isaacl (talk) 14:30, 13 August 2012 (UTC)[reply]

I don't think it says that at all, and I strongly doubt that it's true. If a person exercising editorial control who publishes defamatory content could be immune from prosecution because of a standard disclaimer, then it would be virtually impossible to sue for defamation.—S Marshall T/C 15:34, 13 August 2012 (UTC)[reply]

On your original question: I believe the reason nobody is discussing legal risk is because nobody knows whether there really is any. It is entirely unclear whether the reviewer is legally the publisher. It is, so far as I know, entirely unclear exactly what the courts have decided a publisher is, e.g., in moderated comments on a blog.

If there were an obvious risk, then the WMF General Counsel would have said so. Since he didn't, I assume that the risk is non-obvious. But short of you going off and hiring your own attorney and asking him for his advice, I don't think that we are going to get a definitive answer about the actual risks (and maybe not even then). My non-lawyerly recommendation is that if you are worried about it, then you should not be reviewing edits, and that you should let each individual user make his or her own choice about whether to participate, without any FUD. WhatamIdoing (talk) 18:18, 13 August 2012 (UTC)[reply]

• I'll be the judge of what I should do, WhatamIdoing. If there's unquantifiable legal hazard to reviewers then it's only right to say so on the application page. It's not FUD to tell people that; it's unethical not to.—S Marshall T/C 18:52, 13 August 2012 (UTC)[reply]

I encourage you to be the judge of what you do. I encourage you not to be the judge of what others do, or even to try to scare them off.

We aren't looking at a question of unquantifiable hazard, which implies a definite hazard of unknown, but non-zero, size; we are looking at a question of unknown risk, including the possibility of zero risk. Furthermore, it is definitely possible to use the system with zero legal risk. A reviewer who only rejects pending edits cannot have any risk related to publishing, because he's never publishing anything, no matter how you define the term publishing. WhatamIdoing (talk) 19:25, 13 August 2012 (UTC)[reply]

• "Scare them off" is a bit strong, really. It's quite true that I dislike pending changes and I think it creates a whole raft of problems; it's also true that I will seek to mitigate some of the problems that I see. But I don't advocate exaggerating or misleading editors so as to prevent them signing up. That really would be FUD.

  Of course, I also don't advocate concealing the potential risk by omitting to mention it; that's just wrong. What I advocate is telling people the truth and letting them decide for themselves. We'd need to agree the exact wording.—S Marshall T/C 19:40, 13 August 2012 (UTC)[reply]

• I sympathise more with S Marshall on this point – it's not scaremongering to say it as it is. But we won't know what "the truth" is until we have first determined exactly what the role will entail. And unless we get back to working that out, we will end up with the pigshit of a policy that is the draft proposal. —WFC— 19:56, 13 August 2012 (UTC)[reply]

• @ WFC: I agree with your last sentence 110%. @ WhatamIdoing: It's worth noting that "a reviewer who only rejects pending edits" can mistakenly prevent the insertion of a clarification without which the article is erroneous and, in the case of BLP content, potentially problematic from a legal standpoint. @ everyone: Can we tentatively agree that reviewers should be notified that there may be a potential risk? Per WFC, we can hammer out the wording a little bit later. Rivertorch (talk) 21:43, 13 August 2012 (UTC)[reply]

• Yes - that is all there is - as there is with any edit you make to the project - if you don't want - to review don't review - but there is no more legal worry or responsibility than any other edit you make to the En Wiki project - so - if you disagree with reviewing then consider your full position of contributions here - the concerns about this are nothing more than red herring by opponents of the tool - any edit you make here you are legally responsible for - end of - all of them - any review you make you will have mitigation that you are a good faith reviewer and did yer best - unless you add hateful vandalism or potentially defamation content you wont ever have an issue and why would you as a reviewer add potentially defaming content or vandalism - Youreallycan 21:52, 13 August 2012 (UTC)[reply]

• The risk is that as a reviewer, you might mistakenly or negligently approve an edit that contains a copyright violation or subtle defamatory falsehood. On Wikipedia at the moment, everyone's responsible for their own edits. A reviewer exercises editorial control, making themselves responsible for someone else's edits, which isn't the same thing at all.

  Personally I think it would be a great deal more effort to review an edit than to make that edit myself. When I write something I need only check the source, cite it and put the content in my own words; I know already that it isn't defamatory or a copyvio. When someone else writes something I would need to do a whole lot of careful checking before approving it.—S Marshall T/C 06:57, 14 August 2012 (UTC)[reply]

• Just a thought on this: I know I've been pushing the idea a lot of having PC edits be automatically accepted after a predefined time period (say, 24 hours), but I see that as a possible solution to this problem. If the system automatically approves an edit (as it currently does 100% of the time) then the user who made the edit is responsible for the content of that edit. You can't peg it on the system. Now add pending changes with automatic approval. Instead of being a gatekeeper who takes responsibility for others' edits, a reviewer becomes a person who reverts bad edits before they are automatically approved. Obviously reviewers will accept edits too, and it's unlikely that the backlog will ever be long enough to have edits automatically approved, but even then there's a change of mentality. You can sue somebody for making a bad edit, but you can't sue somebody for failing to revert a bad edit. And if the reviewer takes no action at all on a particular edit, it will automatically be accepted by the system. So if a reviewer accidentally accepts a bad edit, they can now make the argument that if they had done nothing it would have been accepted anyway. ~Adjwilley (talk) 18:34, 19 August 2012 (UTC)[reply]
  • I agree with every word that you say as far as liability is concerned. The problem with introducing a time limit for this reason, having rejected it as a means of curtailing backlogs, is that it's a slippery slope. It only takes a couple of popular know-alls to vocally argue that it doesn't need to be 24 hours, and later 12 hours, then 6 hours, 3 hours, 1 hour, and then 30 minutes, for us to end up in a situation where PC is automatically accepting edits that would definitely have been rejected.

    If we're going down this route, the policy would need to make crystal clear that it is intended exclusively as a measure of last resort when reviewers were unable to determine an edit's validity, and not a method of backlog prevention. —WFC— 19:26, 19 August 2012 (UTC)[reply]

    • I personally wouldn't have a problem if it were automatically accepting changes after 30 minutes. Inappropriate edits can be reverted anytime, whether they're pending or not. In my mind, Cluebot would revert 90% of the obvious vandalism within 5 minutes. Give it another 20 minutes and vandal fighters using STiki, people with the articles on their watchlist, and Reviewers who happen to be online step in and catch 90% of what's left. Sure there will always be some "stealth" vandalism that slips through the cracks, but that happens anyway and we deal with it, though it might take a few days. The only difference is that we got an extra 30 minutes to revert it before it went live.

      Of course I'm not arguing that we should set the time at 30 minutes, but just saying that it wouldn't be a huge problem if we did. ~Adjwilley (talk) 19:50, 19 August 2012 (UTC)[reply]

      • I tend to agree with this. While I don't see much of a slippery slope concern, perhaps setting it at 36 or 48 hours would be a workable compromise. Rivertorch (talk) 20:27, 19 August 2012 (UTC)[reply]

Okay, I seem to be failing at the job of facilitating consensus, so now I'm working on a different problem: when Pending Changes goes live, I'd like to see some actually useful data collection. (We had a trial of Pending Changes a couple of years ago, but only sparse discussion of that trial during the RfC that ended in June.) The main thing I want to look at is editor retention, and I've started a thread at WT:WikiProject Editor Retention#Pending Changes. - Dank (push to talk) 17:46, 19 August 2012 (UTC)[reply]

Things seem to have stagnated a little here, so I'm wondering if it's not time to prepare for our first real RfC where we invite people outside of our small community here to participate. As some have probably noticed I've created WP:PC2012/RfC 1 in anticipation of this, and I'm working on adding some of the ideas that have been tossed around here and on some of the sub-pages. You'll notice that I'm trying to ask a simple 1-2 sentence question with a yes-no answer, putting further background information in a collapsible template to keep things clean.

Anyway, please let me know if you think we're ready for this kind of RfC, and if we're not, what we need to do to get ready. There are a lot of good ideas out there that I think are sufficiently baked, and this seems to be the next logical step to see if there's wider consensus for these ideas. ~Adjwilley (talk) 22:53, 19 August 2012 (UTC)[reply]

Thanks for setting that up Adjwilley!

The only other topic I think we should touch on is a broad, philosophical question: should reviewing be light-touch (check that the edit is not obvious vandalism, if not the edit must be accepted), or full-on (only accept edits if you are happy to vouch for the content). I'm not sure about how to word the question, but something along those lines. A steer from the community on that would set the tone for later discussion on the finer points of what reviewing entails. —WFC— 23:05, 19 August 2012 (UTC)[reply]

Sorry to be a party pooper, and all of your questions in the proposed RFC are important Adjwilley - but they're all moot until the community determines the circumstances under which PC can be used, and what the standard will be for accepting/rejecting edits. The rest of the structure is dependent on how the tool will be used. Risker (talk) 00:25, 20 August 2012 (UTC)[reply]

Indeed. I think some of these issues are already addressed in the provisional policy, which I see as the starting point for everything. For instance, it gives several examples of when to use PC (vandalism, NPOV/V/OR violations, disruption by IPs, etc., to be interpreted more liberally on BLPs, blah blah blah. If people want to change that, the departures should be framed as questions in the RfC. The standard for accepting/rejecting edits is a very important question that the provisional policy isn't clear on (I think that's what WFC was saying above).

Your concern of the other points being moot until these issues are decided could perhaps be resolved by putting these questions first in the RfC. That way users can decide where they lie on those, and they will flavor the responses to the rest of the less-important questions. ~Adjwilley (talk) 00:54, 20 August 2012 (UTC)[reply]

The draft version (provisional policy) says: "Suitable issues for pending changes protection include persistent: Vandalism; Re-insertion of rumor, error, and NPOV/V/OR violations", etc. So ... "include", not "involve", meaning there are other times you'd want to use PC ... without a hint of when those times are. And what does "persistent" mean? Some supporters believed that one BLP violation every 6 months was a trigger for PC, and they thought that's what they were voting for. Some admins who feel strongly about BLP think that the whole point of PC is to apply it liberally; no admin, as far as I know, is on record saying they're going to revert or challenge admins who choose to apply it liberally. And what's an "NPOV violation"? No two editors always agree on what constitutes undue weight; my FAC might contain something you think is an NPOV violation. I have to agree with Risker: the draft policy doesn't even come close to defining what PC will or won't be used for, and until we at least have a clue, it's hard to predict anything else. So I agree that any meaningful RfC has to put those questions right up front. - Dank (push to talk) 01:10, 20 August 2012 (UTC)[reply]

Point taken. I'll work on getting those issues right up front. In the meantime, I would welcome help from those who have obviously thought about this more than I have. If there is to be an RfC, I want to be asking the right questions. ~Adjwilley (talk) 20:46, 20 August 2012 (UTC)[reply]

You're doing great, keep going. - Dank (push to talk) 20:54, 20 August 2012 (UTC)[reply]

Thanks, Adjwilley. Actually, if there's the chance that we're going to have multiple RFC's, the one I'd start with is cleaning up the policy. The responses to other questions, such as who should get reviewer status, are largely dependent on the answer to what we're trying to do with the tool, and until that's settled we run the risk of establishing a very high bar for doing what every autoconfirmed editor can currently do right now on 99.9999998% of our articles, such as removing BLP violations and reverting vandalism. I've yet to hear an argument that it requires a higher level of editorial ability to remove "Joe is teh gay" from a PC queue, for example. Risker (talk) 22:17, 20 August 2012 (UTC)[reply]

I'm a little confused by your last sentence, and I've heard similar concerns voiced before, so do you mind if I pick your brain a little? It sounds like you're assuming that if an article has PC protection and some IP writes "Joe is teh gay" in the article, only a reviewer will be able to revert that change. As I understand it, anybody can revert it before the reviewer comes along. Then when the reviewer sees the article, he'll have two unreviewed edits in the history and he can mark the reverted version as "reviewed". Besides, for this example I'd imagine Cluebot would probably catch it before any humans, and since Cluebot would have reviewer status, its revert would be auto-reviewed.

It would be nice to have multiple RfCs, but I'm beginning to wonder if we have the time. The big RfC closed nearly two months ago, and we've been working here for a month and a half. We've only got 2 months before our November 1st deadline, and we're going to be hard pressed to get in the 2 RfC's that we'll need, let alone 3 or 4. The way I see it, we should have a big RfC that takes a shotgun approach to the various ideas we've come up with. (Beginning of September) Keep the format and votes simple so that people can finish it. Then take the results from that and use them to draft a new policy. (Mid Sep to mid Oct) The second RfC will be simple: Choose between the provisional policy and the new draft policy. The draft should win by a landslide, but if there are concerns they can be addressed in the close, and minor changes can be made up til the Nov 1 deadline. It would be nice to be able to squeeze a third RfC in, but we'd have to work like crazy to make that happen. ~Adjwilley (talk) 22:42, 20 August 2012 (UTC)[reply]

Well, if we can't get it right then we shouldn't do it. Instead of asking if administrators should have the reviewer right stripped from them, ask "Should the implementation of Pending Changes protection be delayed until the change in protection policy is approved by the community?" (Users were not informed that this is a change in the protection policy when the original RFC was created.) Frankly, I find it insulting that I can be trusted to apply pending changes but would require special permission to review those changes. Risker (talk) 22:59, 20 August 2012 (UTC)[reply]

Hmm... can we do that? Delay the implementation? That would go against the RfC close, but I suppose another RfC could do that. It would put us back in limbo however, and two big contentious RfCs are a lot of work to end up back where we started. As for the debundling question for admins, I agree that it's a stupid question, but I remember it being a concern that several people had. I don't think it has a chance at passing, so I didn't see harm in asking it. ~Adjwilley (talk) 00:01, 21 August 2012 (UTC)[reply]

I think suggesting an new RfC to overturn the last one would be regarded as very poor form. One has to accept that change at Wikipedia is inevitable and the consensus as summed up very competently was quite clear. There is no reason however, why minor crossing the 'T's and dotting the 'i's cannot be done by a small task force here, as it was done following the monumental round of discussions for introducing the BLPPROD (see this much later comment). The actual implementation was left up to about six of us who were still interested and there was no opposition. There is a very big difference between the 100s of users who vote for or against a proposal, and those who remain who are sufficiently interested to do the actual work on it. If this discussion does not reach any conclusions by the deadline, the implementation will go ahead per the suggested default. Kudpung กุดผึ้ง (talk) 03:43, 21 August 2012 (UTC)[reply]

Yes well, that's exactly the problem, Kudpung. The "default" is already being interpreted in at least a dozen different ways, basically working out to "put whatever article you want on Pending Changes for whatever reason you can think of". And nobody's saying not to implement, I'm saying we should delay implementation until we have a policy that isn't going to cause both the admin corps and the community as a whole to implode. Risker (talk) 04:14, 21 August 2012 (UTC)[reply]

A delay is simply not an option. Firstly, there is no mechanism to implement a delay – the community expressed support for the draft proposal, and when asked, Arbcom found nothing improper about the decision. Secondly, and I don't care how beansy stating it is, any delay beyond a hard cut-off date would demonstrate that the community doesn't have the guts to turn PC on without changes. Thus, trolling, shouting or otherwise contriving to prevent any changes would be able to kill off PC. —WFC— 04:36, 21 August 2012 (UTC)[reply]

I think you're mischaracterizing the result of the request for arbitration, WFC: Arbcom declined it as out of scope.[1] Desysopping people for radically misinterpreting consensus on a repeated basis would be within scope, but I don't see that as applying in this case, regardless of my opinion of the close. Risker (talk) 05:03, 21 August 2012 (UTC)[reply]

I was just about to say the same thing, Risker.
WFC, the way I see it is that it will be delayed, albeit through no one user's actions. You'll be stuck using the provisional policy, since getting two people to agree on PC implementation beyond use/don't use is akin to pulling teeth. Just look at the responses to the various RfCs and straw polls up to this point and you'll find that there is no consensus for any specific implementation. —Jeremy v^_^v ^Bori! 05:07, 21 August 2012 (UTC)[reply]

That's right. I imagine there are quite a few Option 2 supporters who assumed that the provisional policy would be improved before the turn-on date. (It would be lovely if a few of them had stuck around, but I guess we play the cards we're dealt.) My two cents on all of this: we're not at an impasse, we've made some slight progress, and there's no reason yet to panic. I'd suggest one, and only one, RfC before the turn-on date. It should be multifaceted, geared toward definitively (if temporarily) answering several basic questions that need to be answered asap, as well as gauging support for other questions. Trying to squeeze more than one RfC in? I don't see it. Rivertorch (talk) 11:08, 21 August 2012 (UTC)[reply]

@Risker: User conduct is within Arbcom's scope – had the closers acted improperly, it could have stepped in. The case was declined as out of scope because there was no credible suggestion of this. —WFC— 15:18, 21 August 2012 (UTC)[reply]

@Jeremy: "You'll be stuck"? —WFC— 15:18, 21 August 2012 (UTC)[reply]

I'm not the one who's going to be using the shit. —Jeremy v^_^v ^Bori! 18:11, 21 August 2012 (UTC)[reply]

@Rivertorch: I completely agree. —WFC— 15:18, 21 August 2012 (UTC)[reply]

• I am as alarmed as anyone that so little progress has been made so far, but I think the suggestion that Wikipedia will implode or whatever if we go ahead and start using PC again is a bit ridiculous. It will be confusing, there will be arguments, changes to the policy will happen as reactions to these incidents, and eventually it will be improved anyway. That is pretty much the way things seem to work around here these days, very few users seem to want to discuss this in the abstract any longer. As such it is unlikely that delaying further would help. However there is nothing stopping any one of the few who are still discussing it from opening a formal RFC aimed at making a specific change or improvement to the policy. Beeblebrox (talk) 18:20, 21 August 2012 (UTC)[reply]

Beeblebrox: As the person who wrote the provisional policy and probably followed the RfC closer than most, I'll bet you have a better idea than most of what the problems and concerns are. Would you be willing to help me draft an RfC aimed at making specific changes/improvements to the provisional policy? The current draft is here. ~Adjwilley (talk) 19:03, 21 August 2012 (UTC)[reply]

This is actually a slight misconception that a lot of folks seemed to have. All I did was modify the policy used during the trial slightly to reflect what few concrete results we got from the 2011 RFC, it is not really my original creation at all. the other thing is that I think it is kind of important that somebody other than myself speahead this phase of discussion as I have done that for the last two RFCs and it has led to a lot of people feeling, rightly or wrongly, that I am somehow soleley responsible for pushing PC forward. The rather obvious fact that several hundred other users participated in the two RFCs I opened doesn't seem to have any impact on this perception. So, I am fairly determined to be more of an observer and occaisional commenter during this part of the process but I do think it is important that we move forward, and soon, and that we take into account all the feedback we already have on-wiki, including results from phases one and two of the 2011 RFC. There are some good indicators there. (I actually found the tool very easy to understand myself so I may not be the best person to ask abput that anyway) Beeblebrox (talk) 21:19, 21 August 2012 (UTC)[reply]

Yeah, I remember seeing your RfB getting derailed over that. Sad :-( ~Adjwilley (talk) 21:23, 21 August 2012 (UTC)[reply]

Poking around in the talk archives of the 2011 RFC, which have somehow become a maze of weird redirects, I did manage to find this analysis of the endorsement phase of that discussion. I don't put much stock in the concept of "time-scaled votes" but you can see the raw data as well. Wikipedia:Pending changes/Request for Comment February 2011/Archive 2 shows the actual endorsement phase, and Wikipedia:Pending changes/Request for Comment February 2011/Archive 1 shows the rather chaotic open discussion that preceeded it. Hurts my brain just looking it again... Beeblebrox (talk) 21:32, 21 August 2012 (UTC)[reply]

This looks like it may also contain some good clues about the technical issues, rather than digging trhough hundreds of diffs I am just going to reproduce the entire remark Beeblebrox (talk) 21:47, 21 August 2012 (UTC):[reply]

The latest update was in November. This was laid out in the short term roadmap. Since that November update, it's been basically in maintenance mode, as you can see if you browse the monthly engineering updates. If the community decides it wants Pending Changes in the long run, there is some significant work that needs to be done, including forking the codebase entirely away from Flagged Revisions as it is implemented on Polish and German Wikipedia. There are also significant new improvements that could be made, as described under future releases in the roadmap. But the short answer is: there isn't another upgrade currently in the works. Promising developer time on Pending Changes means taking time away from other current or potential projects, so we have to have some signal from the community about whether it wants Pending Changes permanently or not. If that's the case, then we're committed to working on it just like any other major feature in use. If the community either says, "No, turn it off." or is unable to come to a consensus, then we can't commit more resources of course. Steven Walling at work 05:42, 20 February 2011 (UTC

Also see Steven's viewpoint and Okeyes's reply in this year's RFC. isaacl (talk) 22:24, 21 August 2012 (UTC)[reply]

Thanks, those are quite helpful. ~Adjwilley (talk) 16:33, 22 August 2012 (UTC)[reply]

• Personally, I'd like to see PC applied to all BLPs by default, and the standard for approving edits should be "Will the resulting BLP be compliant with BLP policy if the edit is approved". I would hope that any future RfC would offer that as an option. --JN466 13:17, 22 August 2012 (UTC)[reply]

I think you'd see a lot of resistance to that idea, and I doubt it would gain consensus in the RfC. I can see a lot of people quoting the idea that page protection should not be preemptive. ~Adjwilley (talk) 16:33, 22 August 2012 (UTC)[reply]

I'm sure you're right. Nevertheless, I'd like to see it put up for discussion at some point, and I'd like editors to become familiar with the idea. Compared to Polish, German and other Wikipedias it would only be a halfway house used to protect the most vulnerable articles where failures make the project look worst, and cause real people most harm and pain. --JN466 20:35, 22 August 2012 (UTC)[reply]

My initial reaction was "way the heck too big". If you want answers, you've got to ask one small question. So a question like this "Pending changes is a type of page protection, but it is a different style of protection compared to our traditional page protection systems. Should the policy about using Pending Changes be part of the main Wikipedia:Page Protection policy, or should it be on a separate policy page?"—just that, and nothing else—is the kind of focused RFC that will actually result in some sort of answer. "Let's talk about half a dozen different questions at once" is not going to work as well. WhatamIdoing (talk) 16:38, 22 August 2012 (UTC)[reply]

So, the close of the RFC as it currently exists anticipates completion of the rewriting of the software by November 1. I have been told by several reliable sources that there is no way this will be completed by that date even if they started right after the RFC, and there are still several issues to be improved. (We haven't, for example, talked about what software tweaks need to be made, and since we can't test the current version nobody remembers what the "old" version looks like.) So...do we proceed with the old software on December 1? That's something clearly NOT anticipated by the RFC.

Has anyone asked for a test environment to be set up so that trials of current software can be done? We've been spending months talking about this, but as far as I can see, we've not given any recommendations about what needs to be fixed. Risker (talk) 11:46, 21 August 2012 (UTC)[reply]

Yes, when we spoke to the devs prior to publishing our RfC close, the impression we got was that that the code as it existed was ultimately usable, and while they didn't like being under a community deadline for tweaks that might be requested, December was about as doable as anything else. Since then, I've heard probably the same rumblings Risker has - that the code as it stands is in fact undeployable, and that even if the community could tell them today exactly what they wanted implemented in PC, they'd probably still have to rewrite substantial portions of code to keep things from going "boom". This was unexpected, at least from the perspective of the closers (and, I suspect, from the perspective of the devs who've had to look at the PC code again and go "...oh. Oh, dear."), and I venture to say that no matter what the community has on Nov. 1, if the PC code isn't usable, it can't be turned on. I'm going to leave notes for my fellow RfC closers and for James Forrester, who's the product lead for PC, asking them to drop in here and comment. My personal feeling is that when we wrote the close, we intended "if the community cannot agree on implementation changes, then the previous implementation will be turned on", not "if the software doesn't work, you're doomed to turn it on anyway". I'd be comfortable amending the close to something along the lines of "PC will be implemented [when the devs finish rewriting the code and doing whatever else is necessary]; if at that time the community has agreed on specific implementation changes/notes, they can be incorporated into the software, and if the community hasn't, then PC will be implemented according to the base guidelines discussed in the RfC." A fluffernutter is a sandwich! (talk) 15:23, 21 August 2012 (UTC)[reply]

If the problem is technical that's obviously different. Wikimedia would be improved if Wikidata were fully operational now, for instance, but that fact is that this isn't possible: phase one still needs polishing and phase two is nowhere near completion. But the part of the RfC which surely needs to be upheld is that what the community has on 1 November is what the devs will work to. At this point it's the devs waiting for our confirmation; after 1 November, it is us tweaking policy around the design brief that we gave to the devs in the first place.

EDIT: In a nutshell, if the development takes longer than hoped, so be it, we can't deploy until it's ready. But on 1 November the framework should be locked in. —WFC— 15:48, 21 August 2012 (UTC) EDITED —WFC— 15:50, 21 August 2012 (UTC)[reply]

Well, true enough. However, I do remember there were quite a few things we found in the few weeks before the trial that "ought" to have been fixed, but I'm not sure where that testwiki is anymore so that we can even see what the notes were back then, let alone the issues we found during the trial. I'd really like to see the creation of a test environment so that we can go back and putter around, trying out different things, refreshing our memories, and identifying areas for improvement. It's important that a significant number of participants NOT have much technical expertise, so that any exceedingly complex tasks or issues are far more apparent. Risker (talk) 16:11, 21 August 2012 (UTC)[reply]

You should check out Wikipedia:Pending changes/Testing/1. ~Adjwilley (talk) 16:34, 21 August 2012 (UTC)[reply]

I did so long ago, but it is a good idea to put the link in. A test site is needed to actually put the tool through its paces and see what does and does not work. The test site needs to have the same setup as the current enwp, with templates transferred over etc. Remember that the biggest fail of PC right now is its inability to manage larger articles; this example isn't anywhere near big enough, nor does it have enough templates, to be able to to assess the issues. Nor can we give non-administrators access to the administrator end of the software so that they can see what it looks like from there and make suggestions for improvement. It does, however, give reviewers a chance to see what the interfaces look like. Risker (talk) 17:21, 21 August 2012 (UTC)[reply]

Thanks for the link, Adj. To the issue above; I pretty much agree with WFC and Fluffernutter on this. The intention was obviously never to foist an incomplete tool on everyone, so we shouldn't implement it until the devs say it's ready. However, I also agree with getting the policy locked down (for the start of PC, obviously once we implement it it's subject to change like anything else) by November 1. The Blade of the Northern Lights (話して下さい) 17:13, 21 August 2012 (UTC)[reply]

• I don't think the devs are going to tell us when it is ready since they aren't actually working on it and we have not told them what it is we want changed. I am rather alarmed that after several months of discussing a series of short RFCs not one has actually been opened yet and nothing has been decided. However, since PC didn't cause WP to blow up when it was on before it can reasonably be assumed it won't blow it up if we start using it again. If we go with the idea of the pilot project, which would severly limit how PC is used at first, it should give us the experience we need to make informed requests for software changes. Devs I have spoken to gave me the impression that one month was laughable as far as getting a change done and that they generally have a six month time frame from request to implementation of any major changes. I am of the opinion, expressed by some already, that we should concentrate on improving and clarifying the policy in what little time remains to do so before the redeployment. Beeblebrox (talk) 17:29, 21 August 2012 (UTC)[reply]
  • Beeb, I never pushed any particular RfC because, even when I was soliciting opinions only from supporters, I couldn't get over 30% agreement on any one set of policies or goals. The draft version implies that there are extra reasons beyond the ones listed that extra pages will be PC-protected, but doesn't tell us how many pages or what those reasons are, and different supporters during the RfC imagined different potential outcomes, and voted based on what they were hoping for ... it was difficult to see that during the RfC, but after talking with the supporters, I can see it in hindsight. If we ever actually nail down how PC will and won't be used in an RfC, you'll lose at least half the supporters. In addition, if it turns out to be true, as I suspect it might, that many non-Wikipedians will get a garbled message about PC, something like "Now your edits have to get prior approval on Wikipedia", then that's going to undercut the main recruiting advantage we've enjoyed over our competitors all these years, and fewer new editors will show up. And ... no fault of yours, certainly, but another thing I've found out is that many editors plan to use PC as the new arena for various old fights ... and fights mean casualties, which are going to get blamed, perhaps unfairly, on PC. I'll be surprised if PC has any significant support in the end. Theoretically, that's a shame, because like the supporters, I can imagine some potential uses for PC ... but consensus just isn't there IMO for any single coherent policy or purpose. - Dank (push to talk) 18:17, 21 August 2012 (UTC)[reply]

Yeah, the closers did the best they could with the results they got, and this delayed redeployment was certainly a novel solution, but it does not seem to have worked out as intended. It seems likely we will end up deploying it with something pretty close to the draft policy and fixing it as we go along. I personally think we can do that, although there will certainly be bumps in the road. No policy we could have come up with would end up being set in stone anyway, it is really only through use that some kinds of flaws or gaps in a policy become apparent. Beeblebrox (talk) 18:27, 21 August 2012 (UTC)[reply]

If I'm not mistaken, some supporters will switch to opposition if an RfC passes limiting PC to not many more articles than we're currently semi-protecting; the whole point of PC for them is to handle more problems than the protection policy is currently handling. Others will switch if PC is used widely; they think that violates core principles. If you go back through the last RfC, I think in hindsight you'll see both positions well-represented among supporters. One old, unresolved fight involves BLP on the one hand and BITE and NOTCENSORED on the other hand; some people supported specifically because they are thinking that PC will become a powerful new tool to shift the balance in that fight in their favor, and at some point, maybe during a new RfC, at least one side is going to switch to strong opposition when they perceive PC is going to hurt their side rather than help them. PC is going to inherit other old fights, too. I'm sorry I can't say more than that; I have had a lot of private conversations on the subject. It's possible people have changed their minds and will now be more flexible; I guess we'll see during the next RfC. - Dank (push to talk) 19:04, 21 August 2012 (UTC)[reply]

This is precisely what I've been saying. The likelihood of getting consensus for anything but the grossest of measures isn't possible, and this is because everyone has a different idea of what PC should and shouldn't do. Reconciling the sides is a noble goal, Dank, but for the swindlers' sake I hope you realize you've got an uphill battle ahead of you that isn't guaranteed to work and indeed may end up taking down CRASH before it can scream at a single unregistered user for misspelling "quantum". —Jeremy v^_^v ^Bori! 17:54, 22 August 2012 (UTC)[reply]

Dispense with the attitude Jeremy, or I will have it stopped for you. If you're finished here, I'm happy to let what's said and done lie. But I will report you to ANI for your conduct over the course of the PC discussion, if you contribute to this page again without retracting "swindlers". Occasionally personal attacks are understandable – while never, EVER to be condoned, when someone is provoked and lashes out, sometimes the best thing to do is to let the comments slide and move on. I've been in that position myself on several occasions, and how you must have felt when the RfC closed was without question one of those occasions.

But now, months on, you are still banding attacks around. Continuing to have legitimate grievances about PC does not give you free reign to repeatedly attack those who hold a different view over a prolonged period of time. —WFC— 18:38, 22 August 2012 (UTC)[reply]

Hmm. I'm not entirely sure what's going on here, or what past grievances are being aired, but it should probably stop. For what it's worth, in my view, the Pending Changes train is already in motion, and nobody is gonna stop it. Our job here is to fix the tracks so that we don't get a train wreck down the line. Things are what they are, and no amount of bickering can change that; it will only distract from trying to solve the important problems. ~Adjwilley (talk) 19:04, 22 August 2012 (UTC)[reply]

Disclaimer: a few voters during the last RfC saw some of these issues more clearly than I did at the time, and I'm going to post on their talk pages asking them to chat on my talk page about these issues if they feel like it. If this feels like "canvassing" to anyone (that's certainly not the intention), tell me. - Dank (push to talk) 16:32, 22 August 2012 (UTC)[reply]

I think that we proceed with the existing software and that, if necessary, we limit the number of pages to accommodate any limitations in the software. We know, for example, that the servers don't break if we have a couple thousand pages under PC, because we did that, and nothing actually died. If it's a bigger problem for certain pages due to size, traffic, number of templates, or whatever, then we can recommend that people choose alternative methods of handling problems at articles that seem to fare worse than average under the existing software.

I do not believe that we should count on any changes being made to the software by December. Actually, I'm not sure that we should really count on upgrades in the foreseeable future. We had several editors during the PC debate acting like they had the right to boss around the Mediawiki community and the WMF staff, and that's not a recipe for winning friends and getting people to update your software. WhatamIdoing (talk) 20:21, 22 August 2012 (UTC)[reply]

Unless we have a volunteer who knows how to do it, we are not going to get any updates done before this goes live. Why the desa told the closers what they did is a bit obscure, but it is not feasible. As it has been explained to me, the fixing of the long load times on longer pages is basically impossible without rewriting the entire thing from scratch, which is not going to happen anytime soon, if ever. Simce we have not only no consensus but no discussion at all of what other changes might be desirable it is essentially a moot point and I believe we should concentrate our efforts on the policy, which should probably have an addendum stating that PC is not reccomended for use on longer articles. Beeblebrox (talk) 21:20, 22 August 2012 (UTC)[reply]

I agree.

Should we give a hint about what constitutes a "longer article"? Do we know whether it's just the size of the file (Glass–Steagall below is 292K), or is it the size of the file + the size of transcluded elements (e.g., infoboxes and citation templates)? WhatamIdoing (talk) 23:43, 22 August 2012 (UTC)[reply]

I have seen it reported that large articles had problems with PC during the trial. So I have created one we can test at Wikipedia:Pending changes/Testing/Glass–Steagall Act.

Page load and save times seem a lot slower than for Glass–Steagall Act. Interestingly, to see a pending change is very quick.

Maybe that is just what happened to me so I invite others to have a go.

Yaris678 (talk) 17:03, 22 August 2012 (UTC)[reply]

I tested it out with the tool at tools.pingdom.com and got some interesting results. For some reason the first time I load a page it gives me a significantly longer wait. On subsequent loads the load times was much shorter. At first I thought the long load time was an outlier, but then I realized I could reproduce it by accepting/unaccepting a revision, or by making a change to the article. Here is a summary of my results:

Page	First load	Subsequent loads
Original article	16 s	3.8 s
PC version (no pending changes)	35 s	2.8 s
PC version (with pending change)	34 s	2.8 s

It looks like on the first load, Pending Changes roughly doubles the load time. On subsequent loads, having PC slightly reduces the loading time. No idea why this is. ~Adjwilley (talk) 18:29, 22 August 2012 (UTC)[reply]

On my test of the two pages, both took about eight seconds to load. WhatamIdoing (talk) 20:01, 22 August 2012 (UTC)[reply]

• The shorter load time the second time through is because you're using cached versions. (As an aside, that's a seriously bloated article that should be broken up into a multitude of daughter articles.) Risker (talk) 21:43, 22 August 2012 (UTC)[reply]

So, here's a crazy idea. I recently looked at Special:Log/stable and I noticed that some administrators are protecting pages with PC with an edit summary including the words "Accept: require "autoconfirmed" permission" instead of "Accept: require "review" permission". Does this mean that we have the option of having ordinary users accept or reject pending changes? And wouldn't it be more sensible to do this for articles protected with PC/1? (Obviously any articles protected with PC/2 would need reviewers to accept/reject, but there's a chance PC/2 won't make it through the coming RfC.) Does anybody know anything about this? ~Adjwilley (talk) 00:27, 23 August 2012 (UTC)[reply]