Wikipedia:Requests for comment/Extended confirmed protection policy

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

This was a lengthy RfC and took quite some reading. Thank you for your patience in awaiting a close. First of all, thanks are due to the initiators for getting the discussion underway; it was a discussion that needed to be had at some point and starting with a properly structured RfC gives us the best chance of establishing a consensus and making the best use of the time that the hundreds of participants have invested. I should also thank all the participants, especially those who provide insightful rationales and those who do not yet meet the criteria for 'extend confirmed', who brought a different perspective that would otherwise have been easy to overlook.

To business. Let me fist state the obvious. Of the three options presented here, option C is by far and away the most popular. While closing discussions is not merely a matter of counting heads, administrators are not entitled to a supervote and cannot ignore such a large groundswell of opinion. Therefore, I find that there is a consensus for option C:

Option C: Allow use to combat any form of disruption (such as vandalism, edit wars, etc.) on any topic, given that semi-protection has proven to be ineffective. Notification is to be posted in a subsection of AN for review, unless the topic is already authorized for 30/500 protection by the Arbitration Committee.

This is borne out not just by the number of participants supporting option C (though it is worth noting that almost twice as many people supported option C as supported option A and B combined), but by the detailed rationales that many of the participants left, and it was these—rather than drive-by or "pile-on" votes—to which I paid particular attention.

The obvious aside, the job of a discussion closer is to sum up the discussion, to pick out common themes, and to help provide recommendations based on those for further refinement or to bring the issue to a final conclusion. So, first, there was a common feeling—or perhaps more an acknowledgement in some cases—among most participants that there are certain situations in which semi-protection is simply inadequate to protect the encyclopaedia from harm from anybody sufficiently determined, and that full protection is too blunt an instrument, and therefore we (the community, through our elected administrators) need to be able to use the new "extended confirmed protection" in at least some circumstances. I acknowledge that there is a principled minority who would rather this new level of protection did not exist or was not used at all; they have conducted themselves honourably, but as I understand it such discussion is outwith the scope of this RfC: the deed is done and we are here to decide under what circumstances admins should be using the new protection level. Despite the overwhelming support for option C, many editors expressed reservations about it being used flippantly and tempered their comments with caveats like "extremely rare", "sparingly", "truly necessary", "clear-cut criteria", and "only when all lesser options have been exhausted" (to pick out a few); clearly many feel that the mandatory notification to the administrators' noticeboard (for protections not related to arbitration enforcement) will serve an important purpose in allowing the community to monitor and review its use, and expect that these protections will be rare (possibly excepting an initial wave as admins make use of an option that was not available before). Therefore I believe it is reasonable to say that there is a consensus that extended-confirmed protection should not be used as a first resort, and possibly only where full protection would be necessary were it not for the new protection level. Other recurring themes worth picking out include:

  • There is little appetite to see extended confirmed protection become commonplace, and certainly not anything like as commonplace as semi-protection.
  • Concerns that reckless or naive admins will over-use the new protection level and use it in cases where it is not appropriate (which is a possibility with ~1200 admins, but I hope one that can be addressed through the reviews at AN).
    • Further to this, BethNaught's suggestion on the talk page to send a mass message to all admins informing them of the policy for use of extended confirmed protection is one I endorse, and MusikAnimal is to be commended for volunteering his bot to assist with tracking new uses of the protection level.
  • Similarly, that those of us who are long past the threshold for 'extended confirmation' will simply forget that the vast majority of people cannot edit articles under extended confirmed protection. I recommend (though this is a personal recommendation, not one based on the discussion) that we consider putting a red background in the edit window as we do for admins editing fully protected pages and template editors editing protected templates, or some similar visual reminder.
  • At least one editor cautioned against over-using the new protection level and starting an "arms race" with disruptive editors.
  • As with any other protection, extended confirmed protection should be set for the shortest practicable duration (the initiators apparently believed this to be a given—as did I initially—but there was some confusion over it so it bears repeating in the closing remarks).

I recommend that the Protection Policy be updated with the wording from option C, with guidance related to over- or mis-use, but that this not come fully into force until the mass message to administrators has been sent out. I further recommend that a review of extended-confirmed protection (excluding arbitration enforcement) be done in three months' time to establish whether its use is living up to expectations.

HJ Mitchell | Penny for your thoughts? 18:46, 12 August 2016 (UTC)


Background[edit]

Extended confirmed protection (also known as "30/500 protection") is a new level of article protection that only allows edits from accounts at least 30 days old and with 500 edits. The automatically assigned "extended confirmed" user right was created for this purpose. The protection level was created following this community discussion with the primary intention of enforcing various arbitration remedies that prohibit editors under the "30 days/500 edits" threshold to edit certain topic areas. The Arbitration Committee recently passed a motion that established expectations for use of the protection within the scope of arbitration enforcement.

The protection policy currently states that extended confirmed protection may only be applied in topic areas authorized by the Arbitration Committee or as a result of community consensus (per this discussion). However, it also states that Criteria for community use have not been established. This request for comment seeks to establish such a community process for the use of extended confirmed protection. A discussion at the village pump ideas lab produced the following options.

Options[edit]

  • Option A: Allow use only for topics authorized by the Arbitration Committee (current policy).
  • Option B: Allow use only for topics authorized by the Arbitration Committee or for persistent sockpuppetry where semi-protection has proven to be ineffective (similar to what ArbCom stipulated for arbitration enforcement and discretionary sanctions 30/500 applications). Notification is to be posted in a subsection of AN for review, unless the topic is already authorized for 30/500 protection by the Arbitration Committee.
  • Option C: Allow use to combat any form of disruption (such as vandalism, edit wars, etc.) on any topic, given that semi-protection has proven to be ineffective. Notification is to be posted in a subsection of AN for review, unless the topic is already authorized for 30/500 protection by the Arbitration Committee.

Regarding the duration of the protection, extended confirmed protection does not differ from semi or other forms of protection in that the duration is proportional to the disruption observed. The one exception is topics authorized by the Arbitration Committee, which are often protected indefinitely.

For clarity, please support only one option. Supporters of option C may inherently support option B unless stated otherwise. Katietalk 00:31, 4 July 2016 (UTC)

Option A[edit]

  1. Support As the lesser of evils. I am against this type of protection in general, and prefer the old "nothing-semi-full" system. Debresser (talk) 08:11, 4 July 2016 (UTC)
    The old system is "nothing-full", semi-protection is a more recent invention. HighInBC Need help? {{ping|HighInBC}} 13:42, 4 July 2016 (UTC)
  2. Support. This option will obviously fail, but I will cast my vote for what I believe is correct. Admins don't need more practically unrestrained discretionary power, especially considering that this is a rather powerful level of protection. If we are to use this type of protection for purposes other than Arbitration Enforcement, the criteria for doing so should be specific, not a sweeping mandate for discretionary use "whenever necessary." Biblio (talk) WikiProject Reforming Wikipedia. 15:16, 4 July 2016 (UTC)
  3. Support. As Biblio said above, Option C gives far too much discretion to admins. This RfC does little to prevent 30/500 protection from being used as frequently as semi-protection, and I am concerned that extended confirm protection will drive away the good-faith new contributors that Wikipedia needs for its long-term survival. See the Wikipedia:Request_for_comment/Extended_confirmed_protection_policy#Discussion section for my full reasoning. I can live with Option B, but I strongly oppose Option C. Altamel (talk) 19:15, 4 July 2016 (UTC)
  4. Strong support: I would have been much more hesitant to support ECP earlier this year if I had known it would lead down this slippery slope. Content disputes should not be solved by applying ECP instead of full protection—even if the original war was between two (or more) non-500/30 users, a 500/30 account could come along and (either maliciously or making an honest mistake) carrying on the reverting. We have enough protection levels for combating vandalism: pending changes is something I am a big supporter of and while few people !voting here might agree with me because they can't remember ever being at that point, I think even semi-protection will stop quite a few people from editing (lots of people create an account specifically because they want to edit one page, and if they find out that page is semi-protected, they might just give up and we have lost a potential new editor; the 30/500 criteria will seem ridiculously unattainable to a newbie). Since option A seems like it will fail (although anything is possible), I should note that I would strongly prefer option B to option C—I don't like the idea of more esoteric protection rules for rare cases (persistent autoconfirmed socks); although I can see its benefits, I think the disadvantage of instruction creep outweighs them. I agree strongly with the sentiments of Altamel and Biblioworm, both of whom phrased their concerns much more eloquently than I have. Bilorv(talk)(c)(e) 20:32, 4 July 2016 (UTC)
  5. Support. I actually support wider use than just approval by the arbitration committee, but both options B and C are too lenient as they allow it to be imposed at the discretion of a single user so this is the only option I can support. In my view the restriction should be applied only with the prior consensus of multiple independent administrators that other methods have failed or are not appropriate. Thryduulf (talk) 20:55, 4 July 2016 (UTC)
  6. Support At this point we are moving from "encyclopedia anyone can edit" to "encyclopedia anyone can edit unless it's a contentious topic." I don't think it's a useful sanction at all, it's just a tool for owning the article by the regulars of Wikipedia who are not necessarily the experts of the subject and might be the bigger problem. Funny thing is, WP fought creationists, Scientologists and climate change deniers and it was a stupid Hashtag that needed such draconian protection. And I remember why. It happened because an experienced editor could not stop biting the newcomers, who, short time later, topic banned from the subject. This sanction is a massive failure to assume good faith and should not be used anywhere. But if it is, it should at least be authorized by arbcom. Darwinian Ape talk 21:26, 4 July 2016 (UTC)
  7. Weak support here for now – My thoughts tend to align with Altamel's comment in the general discussion section below. I'm mostly concerned that if this becomes widely used, it will have a negative impact on our newer editors. With regards to an intermediary between semi-protection and full protection, we already have one that isn't so restrictive as 30/500: pending changes level 2. But PC2 has been rejected every time it's come up. I'm still thinking, but I'm very hesitant to extend 30/500 beyond our most strife-torn articles. Mz7 (talk) 21:36, 4 July 2016 (UTC)
  8. Support Recognizing that 500/30 is needed at times, this should only be determined after evaluating the case to know that semi really is not working and other forms of admin actions can't handle it. --MASEM (t) 01:15, 5 July 2016 (UTC)
  9. Support Keep as is, I don't see any problem with requiring the committee approval for the 30/500. I also agree with points made about use of 30/500 intimidating new users and inspiring them to raise their edit count rather than edit only when they see a need. Felisse (talk) 22:10, 8 July 2016 (UTC)
  10. Support option A in lieu of abolishing it altogether. Marginalized editors are less likely to create accounts that can be used to harass them. Silencing them with this protection policy is another form of victimization. This includes sexual harassment where female editors don't wish to edit except as anonymous IPs. Reject expanding this as it would be detrimental to efforts to attract diverse contributions and close the gender gap. --DHeyward (talk) 05:30, 5 July 2016 (UTC)
  11. Support. Option C is too restrictive. While Option B is better than Option C, there should also be an expiry date or a mechanism in place to allow the removal of 30/500. OhanaUnitedTalk page 06:03, 5 July 2016 (UTC)
    @OhanaUnited: By your wording, it sounds like you probably meant a different option in your !vote. Option A, the current policy, is probably the most restrictive, not explicitly allowing sysops to apply ECP for sockpuppetry / disputes, whereas the other options do. Also, does the software really prevent application of extended confirmed for a duration other than indefinite? — Andy W. (talk ·ctb) 15:45, 5 July 2016 (UTC)
    @Andy M. Wang: No, the most restrictive (from a new editor's point of view) is option C. Option A is where ArbCom is going to use ECP. Option C is where ArbCom and any perceived disruption will use ECP. OhanaUnitedTalk page 16:22, 5 July 2016 (UTC)
    Ahh I see... looked at this from the wrong perspective. (we serve editors after all) Thanks for letting me know — Andy W. (talk ·ctb) 16:27, 5 July 2016 (UTC)
    #Support. 500/30 is an extreme form of protection which disallows a very wide swathe of the editors. There should be first a serious examination of the results of the 500/30 protection on the areas it has been used, before expanding it any further. Absent this review, I am unwilling to extend it any further than it already has. Kingsindian   09:23, 5 July 2016 (UTC)
    I have struck my vote on the explicit assurances made that the tool use would not be indefinite in general. And as mentioned in the RfC, the tool should only be used when semi-protection etc. has failed. I do not see anything inherently wrong with this proposition. Kingsindian   07:44, 6 July 2016 (UTC)
  12. Support I am a bit ambivalent about the use of this on articles - I don't like it, but it is another tool to consider. What I don't like is the use of this rule on talk pages. There it disenfranchises new editors from even involving themselves in the discussion. Semi-protection serves to keep most socks at bay, but this isn;t aimed at socks, or disruptive IPs, but 30/500 states that certain editors aren't considered to be experienced enough to even discuss the topic. Given that Option A already sees it applied to talk pages, I'm concerned that any further opening up of its use will see far wider and even less careful application. - Bilby (talk) 12:41, 5 July 2016 (UTC)
  13. Support I support this option. The EC protection should be used only for ARBCOM approved articles. If another article is heavily vandalized, then fully protect and open an ARBCOM case to switch to EC protection. Perhaps ARBCOM should develop a fast-track system for EC protection? Sir Joseph (talk) 16:13, 5 July 2016 (UTC)
  14. Support: It is a bad idea to give more importance to edit count. An user who has 500 edits of wiki-gnoming is no more deserving of editing some pages that an editor who has extensively contributed to a few articles doing a few edits of 1,000+ bytes each plus a few minor edits, who may easily not have totaled 500 edits yet could have done a much more valious contribution than a wiki-gnome. Also, we already have a lot of people reverting vandalism. This kind of restriction (“protection”) can't be justified on the basis of vandalism when most of it gets reverted in minutes. Wikipedia doesn't have a problem with vandalism. It ha a problem with excessive restrictions and revert-happy editors. Mario Castelán Castro (talk) 18:27, 5 July 2016 (UTC).
  15. Support: The 30/500 protection was created for extraordinary circumstances, and should remain limited to extraordinary circumstances. ~ ONUnicorn(Talk|Contribs)problem solving 19:56, 5 July 2016 (UTC)
  16. Support - As per what was stated above including DHeyward.--Catlemur (talk) 21:08, 5 July 2016 (UTC)
  17. Support - I worry, with other editors, that B and C (unchecked) risk creating an undue burden on new users. 500 edits is a lot to ask of a newbie, and I fear this protection will discourage a fair bit of useful and productive content creation. I recommend reading the comments below the voting section, which inform my vote. Vesuvius Dogg (talk) 05:17, 6 July 2016 (UTC)
  18. Support - Normally I don't get involved in these kinds of things, but I don't like this kind of protection at all. As a recently extended confirmed editor myself, I still shy away from editing any blue-locked article, especially when I see the warnings of sanctions and other woes promised on disruptive editors. Even making a minor edit e.g. spelling would make me cringe. And even without the ArbCom warnings, I think the protection itself is intimidating to newbies who are terrified of making a mistake. I know this because I spent literally months reading Wikipedia policies and editing my user space before starting to make constructive edits. While not fully supporting this, I agree that it's by far better than B or C. I don't think this kind of environment is a friendly one. MediaKill13 (talk) 08:32, 6 July 2016 (UTC)
  19. Support I tend towards the view that these hyper-contentious articles ought to be protected from established users so as to prevent ownership, and that it is the still contentious but less visited articles that actually benefit from protection from drive-by edits. This level of protection isn't useful against vandalism anyway. Allowing admins to lock people out of their pet articles without supervision is obviously an invitation to article ownership on a new level. Mangoe (talk) 11:11, 6 July 2016 (UTC)
  20. Support - I feel that this policy should not have even be discussed in the first place. We do not need further confusion to brand new users who have just joined Wikipedia. As such, we must remember about people who actually help Wikipedia, but have only just created a Wikipedia account, and how this policy, if one were such to exist, affect those people. See discussion below for more details. (And yes, my account is just 3 months old at the time of editing, hence the support.) --JaventheAlderick (talk) 13:15, 6 July 2016 (UTC)
  21. Support. I'm not a fan of this protection level except when invoked by ArbCom after deliberation. StevenJ81 (talk) 14:14, 6 July 2016 (UTC)
  22. Support - I am against this level of protection as a whole. The community doesn't get a direct say about the arbitration committee's use of it as a remedy, but it can and should strike it down as a community approved protection level. Use of this level of protection, especially allowing wider applications, is against the Wikipedia's core value of being "the free encyclopedia that anyone can edit".Godsy(TALKCONT) 18:33, 6 July 2016 (UTC)
  23. Support per arguments above, in particular because I'm worried about the possibility of this being over-applied. --Gimubrc (talk) 19:22, 6 July 2016 (UTC)
  24. Support I support as limited implementation of protections as possible. As a new(ish) editor, coming across and article with any type of protections is still intimidating, and it definitely discourages me from editing, as I don't want to run afoul of whatever incident led to the protections in the first place. Increasing the use of protections discourages the participation of the casual user. UiLego (talk) 20:51, 6 July 2016 (UTC)
  25. Support and strongly oppose Option C. If semi has failed to control disruption on any particular article, there must be autoconfirmed editors that are causing the disruption. The best course of action is to take those editors to ANI and get a page ban or topic ban. Locking out many uninvolved editors (who are in their critical learning-the-ropes stage) because of disruption by identifiable & bannable bad actors is a terrible solution, but it's just what Option C (and to a lesser extent Option B) propose. I can accept an extraordinary exception in the case of truly intractable and highly disruptive sockpuppetry directed at a single article (i.e. Option B). A2soup (talk) 07:07, 7 July 2016 (UTC)
  26. Support. The principle of the least required power should be always applied. There are many compelling comments in the discussion section below explaining how widely applying 30/500 would discourage newcomers and IP editors (who are responsible for a huge bulk of the edits) from contributing just because they don't have the numbers. Not to be anecdotal, but I wanted to contribute to another language's wiki (that's poor in quantity and quality), but couldn't and kept hitting walls with every edit or request, because I was considered by the software to be a "newcomer", even though I had much higher edits here on enwiki (not even allowing me to post a request to lift the restriction). Needless to say I'm not gonna be contributing to it anymore. And I don't want newcomers here to have a similar experience. I feel like this goes against the spirit of Wikipedia's openness. Initially I was in favor of Option B, but then what quantifies "persistent"? And if it's persistent, then other measures should be followed, up to ArbCom (which is the current procedure for the few problematic topics that emerge). This type of high-level protection should be always decided per case. —Hexafluoride (talk) 14:56, 7 July 2016 (UTC)
  27. Support. No, I am highly opposed to the imposition of 30/500 by a single admin anywhere ArbCom has not authorized it. This creep is not OK. We don't need to alienate and bite newcomers more than we already do. Altamel's point should resonate with everyone here: 500 edits is quite a lot to a newcomer. I may support cases where the community reaches a consensus (at AN, for example) for imposition of ECP on one article, or a specific group of edits, similar to the community's authority to impose "discretionary sanctions"-similars – I may be adding that as an option to this RfC – but no single admin should be able to impose ECP on their say-so. Kevin (aka L235 · t · c) 16:20, 7 July 2016 (UTC)
  28. Support. I'd leave well enough alone, our existing protection should deter most socks and bad-faith accounts. Jjjjjjdddddd (talk) 02:00, 8 July 2016 (UTC)
  29. Support per Masem and DHeyward. SSTflyer 07:19, 8 July 2016 (UTC)
  30. Support. We already have an intermediate category between full-protection and semi-protection - Pending Changes Level 2. However, the community overwhelming rejected the implementation of PC2, citing unnecessary bureaucracy / hierachy and fears over widespread usage as reasons of opposition. Same applies for 30/500 protection. --Dps04 (talk) 04:35, 9 July 2016 (UTC)
  31. Support because there is unfortunately no option for opposing 30/500 protection completely at this stage. Wikipedia is supposed to be the encyclopedia that anyone can edit. I fear that this new 30/500 tool, in the hands of ArbCom, administrators, or other “trustworthy” authority figures, will regularly disenfranchise new editors and encourage ownership of articles by entrenched, adroit factions. Edit counts should not be used as a license to edit or to lock down articles. It took me 10 years to get 500 edits, yet, even were I now to start editing an extended restricted page, I would likely be dismissed as simply a sleeper account that grinded just enough edits to game the system. If it must exist, then I adamantly oppose its use except in the most drastic or extraordinary cases and adamantly oppose its unchecked use by administrators. Appreciate the watchlist notification. Hftf (talk) 09:23, 9 July 2016 (UTC)
    "because there is unfortunately no option for opposing 30/500 protection completely at this stage." Indeed.Godsy(TALKCONT) 22:24, 9 July 2016 (UTC)
  32. Support per WP:CREEP and WP:NVC. Looking at existing usage of this feature, we find it being used on disgusting, where this level of protection was applied indefinitely to resolve a matter of petty vandalism. Such casual use indicates a risk that the project will gradually get locked up and so prevent new editors from making the edits which would enable them to qualify for incumbency. Tight controls seem necessary to mitigate this risk. Andrew D. (talk) 09:51, 10 July 2016 (UTC)
  33. Support Scaring off the newbies isn't a mantra, it's math. 5–10 edit requests per month for 70–80 EC-protected pages. The average EC-protected page today sees a new editor go through the trouble of an edit request at a rate of once per year. Let's hope, under option B or C, sock puppeteers don't figure out they can disrupt Wikipedia for new editors on a large scale by baiting admins into EC-protecting popular pages. Matt Fitzpatrick (talk) 08:34, 11 July 2016 (UTC)
  34. Support. It is becoming harder and harder for newbies to contribute to Wikipedia, for many reasons in addition to page protection. Let's not increase a trend that is gradually destroying Wikipedia as it becomes less accessible and more bureaucratic. Also a basic life principle is to use the minimum force required. We don't need to give admins greater powers. I fail to see why we need this high bar of protection without ArbCom authorization.
    This RfC is biased, with options B & C saying "semi-protection has proven to be ineffective", which is an (apparently successful) attempt to lead the reader to accept those options. The statement is not true in any universal sense; at best semi-protection has only proven to be ineffective in specific circumstances, and even that is disputable, since page protection is not the only tool in the toolbox.
    Why is my point not numbered? Because Wikipedia is supposed to be about discussion, not voting. RfCs that depend on people adding their name to the discussion without contributing anything that hasn't already been said are fundamentally flawed and in violation of policy. Like this whole "votes followed by discussion" format - the "votes" section is supposed to be discussion. ··gracefool 💬 00:16, 11 July 2016 (UTC)
  35. Support - as per User:ONUnicorn. Vandalism, sockpuppetry, edit wars, etc. can be combated otherwise such as temporarily banning single editors from specific articles etc. I don't think this policy change is really needed and think that it should only be considered if it's truly badly needed. --Fixuture (talk) 17:42, 12 July 2016 (UTC)
  36. Support I accept the occasional need for 30/500 protection, but not its extension as proposed in B or C. Those who propose this change need to make a stronger case for why it is needed. Adh (talk) 08:41, 13 July 2016 (UTC)
  37. Support I believe that this is the best plan in order to combat vandalism. Iazyges (talk) 06:20, 14 July 2016 (UTC)
  38. Support per Andrew Davidson (!). Already we have admins using ECP where it is not allowed. You can bet that if we loosen the policy, some admins will, out of a combination of ignorance and not caring, apply this inappropriately, neglect to notify AN as option C envisages, and so on. I would support an option allowing general use of ECP with prior community authorisation, however this was already provided for by the RFC which introduced ECP and in one case (the Nikita troll) has been used. Note to closer: please see my discussion section below. BethNaught (talk) 15:06, 14 July 2016 (UTC)
  39. Support The current policy is working fine. Edit warring, vandalism, edit wars and/or persistent sockpuppetry can be resolved by an admin. Options B and C propose changes that may make problems worst rather then improve the current situation.( See Cobra effect.) FockeWulf FW 190 (talk) 15:19, 14 July 2016‎ (UTC)
  40. Support Lots of votes in the other two sections betray misgivings like "not to be used too frequently" and "only in the right circumstances". It's easy to see that this is a slippery slope. SteveStrummer (talk) 06:02, 15 July 2016 (UTC)
  41. Support I'm for A because I'm against B&C. I'm against B&C because they could prevent editing by people new to Wikipedia of an article because of a single bad actor. It's like banning all cars on a road because a single driver is being reckless.War (talk) 02:12, 16 July 2016 (UTC)
  42. Support Nupedia was an encyclopedia that only experts could edit, but this led to very low levels of recruitment, and ultimately both worse articles and far, far fewer of them. These protection mechanisms take us back towards the Nupedia model in small steps after the giant leap towards openness Wikipedia was. I fear that this and other quality controls have reduced recruitment, and could explain much of the slowdown in Wikipedia's growth. I therefore don't want to make this very strict protection mechanism too easy to use. Amaurea (talk) 02:01, 17 July 2016 (UTC)
  43. Support or rather definitely oppose the other ones. The latest comment (as I write) on option C says it all about what the current majority thinks Wikipedia should be headed towards: You could make it 90/1000, and I'd be fine with it. This is the exact opposite of the encyclopedia anyone can edit, come on, let's be serious. LjL (talk) 02:44, 17 July 2016 (UTC)
  44. Support Current policy seems to be working fine. Changing it is unnecessary and prevents new editors from contributing to the wikipedia. Full Rune(Speak, child of Guthix) 20:30, 17 July 2016 (UTC)
  45. support seems unneeded and is yet another lock on our content. Hobit (talk) 00:20, 18 July 2016 (UTC)
  46. Strong support In almost all cases where 30/500 is being proposed, the use of full protection, with policy written as it already is currently, is more appropriate. The issue of stratification should carry a lot of weight - the ability to edit an ECP article is a powerful tool, and which editors do we want to give tools and powers to? Admins can edit full protected articles because they passed community scrutiny, and are expected to be able to read consensus out of discussion, ensure policy is followed in said consensus, and implement. If we pass ECP, 30/500 editors will be allowed to edit ECP protected articles because they made a bunch of edits, whether they spent 2 years significantly improving/creating 500 articles, or 30 days archiving dead reference links on 500 pages from the backlog. Many people here have already mentioned that many very trustworthy editors and/or topic experts will be falsely assumed untrustworthy and discouraged under 30/500; it's also important to consider that many editors, good faith and trustworthy or not, who are regardless not necessarily equipped and community-vetted to read consensus, will be automatically trusted as extended confirmed, and given an inappropriate amount of automatic power. With the semi/full dichotomy, we avoid stratification, because either almost all editors can, or almost all editors can't, edit. It's much less discouraging for an active editor with, say, 150 edits, to encounter a full protected page than a 30/500 page, because they know that power-editors are just as restricted as they are, and everyone is subject to the same edit request system. The same goes for a completely new editor, who sees even the experienced power-editors discussing and arguing for their proposed edits on the talk page, and thus sees a path to their participating on the exact same level as those power-editors, but in talkspace. PC2 would also be a good solution, but in the absence of PC2, full protection serves this purpose a lot better than ECP. As for sockpuppetry, yes, ECP would be a monumental tool for combating it. But I think that the stratification it causes, further discouraging our dwindling supply of new editors, is a far greater concern, especially when there's already systems in place for identifying and quickly limiting the impact of socks. A tool to pre-empt socks, when we already have good tools to limit their impact within minutes, is not important enough to overlook the stratification of the entire encyclopedia it will cause. Additionally, even with option B, we'd essentially be allowing socks and what they want to do, to determine the scope ECP takes on the encylopedia. No matter how much we want to keep it small, the socks will determine how many pages it's used on. Jhugh95 (talk) 19:22, 18 July 2016 (UTC)
    Are you suggesting using lengthy periods of full protection to combat sockpuppetry? Just want to make sure I'm reading this correctly. ~ Rob13Talk 20:05, 18 July 2016 (UTC)
    Thanks for asking to clarify, that was a little poorly phrased - I am not. I'm supporting (lengthy if necessary) periods of full protection to combat consistent edit warring over content disputes from real editors. And I'm supporting continuing to use the existing counter-sockpuppetry tools to combat sockpuppetry, i.e. SPI, semi-protection, etc. I'm not supporting using extended periods of full protection to combat sockpuppetry; that too would be throwing the baby out with the bathwater in my opinion. Jhugh95 (talk) 05:45, 19 July 2016 (UTC)
  47. Support for most of the reasons already stated. It's easier to undo bad edits then to produce good edits, admins will be too aggressive in implementing this protection and it will result in turning off editors from making improvements to articles. M. A. Bruhn (talk) 03:35, 19 July 2016 (UTC)
  48. Support for the least bad option. Having 30/500 protection will turn away all but the most elite of users. There are 24608 https://en.m.wikipedia.org/wiki/Wikipedia:User_access_levels#Extendedconfirmed users, and 1.4 million active users, so only those in the most active 1-2% of users can edit. I try to edit and help where I can on wikipedia, and have had an account for aaages, but don't have 500 edits yet. cannywizard (talk) 15:51, 19 July 2016 (UTC)
  49. Support Such powers should be used only when absolutely necessary, and determined by Arbitration. -Phiselm (talk) 15:42, 20 July 2016 (UTC)
    Oppose So much for the public part of WP. I have no tin foil hat but WP (and its "Arbitration committee") does begin to resemble animal farm. Juan Riley (talk) 00:02, 22 July 2016 (UTC)
  50. Support The reason I say this is that we need to encourage people to contribute to Wikipedia. After 11 years as a user with over 20,000 edits I have found that there are folks that show up out of the blue and make positive contributions, we need to welcome and encourage them. On the other hand there are experienced editors who spend most of their time pushing their POV that is not supported by reliable sources, these folks know all rules of Wikipedia and are looking for an angle to ban other editors. These persistent POV pushers and ethnic warriors need to identified and banned from editing, the newcomers that make positive contributions need to find a welcoming atmosphere.--Woogie10w (talk) 16:04, 24 July 2016 (UTC)
  51. Support, per WP:CREEP (and I don't invoke it that often). I agree with what SteveStrummer said, too. Enterprisey (talk!(formerly APerson) 01:43, 25 July 2016 (UTC)
  52. Support as the lesser of the levels of intrusiveness and complication. I agree that a new level of protection is needed. But initially, err on the side of caution. It can always be expanded if that becomes necessary. Dmforcier (talk) 23:37, 25 July 2016 (UTC)
  53. Support ECP was always a necessary evil based on the otherwise unenforceable Arbcom decision, but anything else is just scope creep. The kind of editor willing to wait four days to make a disruptive edit is not the kind of editor you want trying to sneak 500 edits into the encyclopedia prior to disruption. --Ahecht (TALK
    PAGE
    ) 17:23, 26 July 2016 (UTC)
  54. Support Let's keep things as they are, I don't see how options B and C will help, they seem to just create more committees and rules. --OMouse (talk) 18:58, 26 July 2016 (UTC)
  55. Support. I'll go on record as being around 130/1200 and having no idea what's going on half the time - editcount might suggest I'm not a sockpuppet but I don't feel terribly qualified. For example, to my uninformed mind this sounded like a perfectly reasonable and useful tool. Then I read through comments like I was being warned by the ghost of wikifuture. So, strongly oppose B and C, and support A so long as it is not overused. - Reidgreg (talk) 22:55, 26 July 2016 (UTC)
  56. Support there's plenty of modes of protection as is, and extended confirmed protection is strict enough that it should be used as sparingly as possible. Pianoman320 (talk) 06:11, 27 July 2016 (UTC)
  57. Support I joined Wikipedia last year and have made somewhere around 100 edits by now. While I feel like this tool would be useful in blocking sockpuppets, the people who it would affect the most would be people like me: good faith editors who aren't very avid and do what they can to help every so often. I understand that to a seasoned editor, 500 edits is nothing, but if I continue at this rate, I will have clearance to re-edit some of the articles I've already made contributions to in four more years. I don't think that the miniscule benefits Option C produces outweigh the damage to the morale of new editors or infrequent editors, so I will support using this as infrequently as possible. Gpapazian (talk) 14:35, 27 July 2016 (UTC)
  58. Support per Gpapazian-the majority of edits are made by good-faith but low edit count users. Wikipedia was founded as "the free encyclopedia that anyone can edit; users are encouraged to [[WP:BOLD|be bold]. Currently, there are 28,741,544 editors on Wikipedia, yet only 25,247 of them are ECP. Joshualouie711 (talk) 13:44, 28 July 2016 (UTC)
  59. Strong Support - Semi and full are still the correct choice for "whenever necessary" is necessary. Mlpearc (open channel) 00:07, 31 July 2016 (UTC)
    @Mlpearc You have already voted, but for Option C. Which vote would you like to keep? Altamel (talk) 14:49, 2 August 2016 (UTC)
    This one :P thanx, Mlpearc (open channel) 16:04, 2 August 2016 (UTC)
  60. Support I have read the section "Impact on newcomers" on this page, and I think edit count is not a good parameter. Given edit count is already in use as a parameter, I support option A, as B or C would lend even more weight to edit count. I hope a more meaningful parameter will be found eventually. Carystus (talk) 13:32, 31 July 2016 (UTC)
  61. Support The other options would place a substantial burden on newcomers. AntiCompositeNumber (talk) 20:16, 1 August 2016 (UTC)
  62. Support as less bad than B & C. That some editors see ECP as preferable to full protection because less restrictive suggests that it will be overused. Full protection is used sparingly because it's so obviously restrictive. ECP is as restrictive as full protection except for a relatively small minority of editors. But since the extended-confirmed editor who imposes it will still be able to edit (and all his Wikipedia buddies will too), he will underestimate the downside of imposing it, and do so too often. Many of the !votes for Option C appear to confirm this. - Nellis 15:05, 2 August 2016 (UTC)
  63. Support per Bilorv. 4nn1l2 (talk) 21:12, 4 August 2016 (UTC)

Option B[edit]

  1. Support: Option C is vague, creates more caste and encourages editors to put "this user has extendedconfirmed permission" userboxes (more hat collecting!), and gives too much power to silence newcomers. Semi-protection works just fine for most cases. I support use only to stop paid advocates and other sockpuppets. Esquivalience (talk) 03:50, 4 July 2016 (UTC)
  2. Support – I originally supported the creation of 30/500 protection on the assumption that its use wouldn't be expanded beyond Arbcom-initiated areas, and I'm a little disappointed that this is being rushed towards the door of being used as "just another semi-protection level" already... --IJBall (contribstalk) 04:39, 4 July 2016 (UTC)
  3. I'd prefer to see how we go with this for a while before we give all 1,202 admins carte blanche. Jenks24 (talk) 08:51, 4 July 2016 (UTC)
    Support - 30/500 protection would definitely be more effective against persistent sockpuppetry than semi-protection (i.e. "4/10 protection") in that it would take a full month for a sock to gain auto-extended confirmed status. However, I would add the caveat that community-imposed 30/500 should last no longer than 60–90 days, after which ArbCom would have to authorize indefinite 30/500 protection. Option C goes too far, and Option A doesn't give admins the flexibility to impose 30/500 in an emergency. — Jkudlick • t • c • s 09:05, 4 July 2016 (UTC)
    Oppose - "for persistent sockpuppetry where semi-protection has proven to be ineffective" I've seen several WP:RFP that make the claim it's sockpuppetry. Maybe it is, maybe it isn't, but the article history shows IP edits and/or redlink accounts. WP:SI requires diffs and proof before they take on a case. This well-meant option requires no proof, and relies on the judgement of the requester and admin. Too much room for error. — Maile (talk) 14:52, 4 July 2016 (UTC)
  4. Support. Addressing Maile66, any admin can already block socks at WP:SPI based on the proof presented; the process there is already "requester and admin" for patrolling admins. As always, the discretion and accountability lies with the administrator. If admins go around placing protection without making a determination of sockpuppetry (or if they make such determinations with no regard to proof), then that's an issue of tool misuse. I don't believe I've ever been convinced that a rule shouldn't be made because people could break it. ~ Rob13Talk 14:57, 4 July 2016 (UTC)
    While Option C goes way too far, in my opinion, its preferable to Option A by a wide margin. Option C is my clear second choice. ~ Rob13Talk 13:27, 6 July 2016 (UTC)
  5. Support I am concerned, except in a few situations, about the message that this sends that newcomers are automatically less trustworthy than established editors. I think the best way to prevent new but autoconfirmed editors from with editing things they do not yet have the competence for is mentoring and advice rather than automated means. I am very uncomfortable about EP being used in edit warring situations because it effectively gives older accounts a great upper hand over newer users. I am not as concerned about full protection since admins go through a vetting process and risk desysop if they abuse their power over protected article. I would be open to creating a user right that would be granted upon request to edit through an intermediate protection level, but since extended confirm is about account age and not trust, it doesn't satisfy me in that regard. The only use of ECP I feel confortable with is to prevent socks, and even then I worry about overuse leading to a sort of arms race with sockmasters. Happy Squirrel (talk) 19:11, 4 July 2016 (UTC)
  6. Support - I can understand seing Option C as too vague and/or too far away from the wiki idea. If semi-protection doesn´t work get the 30/500 authorized by the ARBCOM and everything is fine. And the addition of usage against sockpuppetry makes absolute sense to me. What I would think about is making the 30/500 temporary at first, like automatically downgrading it to semi-protection after a month or something like that; with the option to easily renew and lengthen it if necessary. ...GELongstreet (talk) 11:55, 5 July 2016 (UTC)
  7. Support - without prejudice to migrating to C down the road after this is tried out. Recent use of 30/500 has been, in all cases so far, a "we're at the end of our wits trying to solve this, so its either this or full-protection". So Option B would maintain that Last-Resort mentality without having to tie up ArbCom. I think we give this a try and see how it works first. Using this for "regular disruption" treads the line on infringing on "anyone can edit" due to a few bad apples. It may be that it is inevitable, but I'd rather go incrementally down that road. CrowCaw 16:42, 5 July 2016 (UTC)
  8. Support - I agree that along with this, there should be a set expiration as well. DrkBlueXG (talk) 20:43, 5 July 2016 (UTC)
  9. Support - Without prejudice to Option C if proven to not be effective - the impact on (legitimate) new editors is likely to drive editors away from the project in frustration. -- sandgemADDICT yeah? 03:36, 6 July 2016 (UTC)
  10. Support. I'm concerned about making editing too difficult for new editors. It seems to me that the rationale of socking makes sense as being something where semi-protection really does not work. If there were to be a consensus among more than one admin before applying it to a page, I could support a revised option C. --Tryptofish (talk) 19:25, 6 July 2016 (UTC)
  11. Support - pages experiencing persistent sock-puppetry lack the safeguards to really do anything effective. Similarly, since I've been fairly active in outing sock and meat puppets, I know that they get smarter - they don't keep attempting the same obvious edits, meaning classifying them as socks is more difficult. They also learn pretty easily how to use different IP addresses. Creating this statute will help minimize tendentious editing from socks, as well as vandalism. DaltonCastle (talk) 19:08, 7 July 2016 (UTC)
  12. Support - I don't think that Option B is perfect, but I think it has the right idea behind it. The other options are not better. Britcom 02:06, 9 July 2016 (UTC)
  13. Support I think we might want to expand it further in the future, as with C, but we should get some more experience with it first. DGG ( talk ) 04:32, 8 July 2016 (UTC)
  14. Support, as much as I would have liked to support option C. (And scrap the automatic posting at AN for review, if someone that is actually editing the article disagrees they can raise the issue.)
    I do not agree with most of the blanket opposes to C. 30/500 is harsh, but it is less harsh than full protection. Moreover, a new level of protection is instruction creep, but it will exist anyways (or so it seems), be it admin action or ArbCom, so the proposal does not add to complexity. (Actually, making 30/500 admin action would reduce the complexity...) And finally, newbies are underrepresented in the decision-making that takes place here, but (1) it does not mean the decision reached will be wrong and (2) so are minors in the instances where the drinking and driving ages get decided. Newbies might be as intelligent as veteran editors (or arguably more, bunch of Wikiaholics), but they have less experience with those issues.
    I see two arguments against 30/500 as admin action, and the second one is what pushes me to support B as a "trial option" before going full C (my clear second choice).
    1. 30/500 allows a downgrade from full, which is good in general (less protection is better most of the time), but it also allows an upgrade from semi/pending when no admin would have been willing to impose full. I think this does not matter, because 30/500 is likely to come under as much scrutiny as full protection (if not more) for the next year or so, and afterwards the admins will have made necessary adjustments to community feedback to know which articles should go under which protection. Cases on the fence between semi/pending and full are precisely the ones that would benefit from 30/500 anyways.
    2. Unlike full that locks out everyone and semi that does not lock out anyone for long, 30/500 has real potential to lock out of editing one side of an edit war while the other remains. I am ready to believe most admins are aware of such issues, but if "most" is 90% it still means a few of them could be misled into such an action. The potential for drama just seems too high to me.
    TigraanClick here to contact me 15:29, 9 July 2016 (UTC)
  15. Support - based on review of the options. Kierzek (talk) 21:11, 9 July 2016 (UTC)
  16. Support Option B, but oppose Option C. I'm a big fan of incrementalism. Let's give option B a try and see how well it goes before moving on to Option C. NewYorkActuary (talk) 14:36, 10 July 2016 (UTC)
  17. Wikipedia has proven itself time and again to be a pure democracy regardless of the weight of arguments, and therefore option C will be implemented. The problem (as with a certain vote in my country not too long ago), is that while people are clear on what they don't want (a simple-to-game system), they're not at all clear on what hoops they are and are not willing to jump through, what sacrifices they are and are not willing to make, to achieve it. Thus, we are in a situation where we agree that we need a tool capable of making things harder for vandals, but have consensus to implement the tool with no policy other than "semi protection must have been tried and failed". 500 edits is a lot of effort for a vandal to go to, but it's also quite a hurdle for a good faith new user. In short of a workable policy to protect such users, option B is the appropriate step - signal that this should go further than Arbcom, but that we are not willing to use this as a free-for-all. StillWaitingForConnection (talk) 00:11, 16 July 2016 (UTC)
  18. I support option B. This option combines the merits of Option A with additional but limited protection. With Option C, editors with good intentions but few edits (myself included) could be locked out of making key edits on important articles. Therefore I also strongly oppose C unless A or B is tried and found unsatisfactory. Mooseandbruce1 (talk) 23:32, 19 July 2016 (UTC)
  19. Support (moved from option C) – I changed my mind, actually I don't think there are really any valid uses outside sockpuppetry that can't be dealt with in other ways. nyuszika7h (talk) 14:00, 20 July 2016 (UTC)
    Oppose So much for the public part of WP. I have no tin foil hat but WP (and its "Arbitration committee") does begin to resemble animal farm. Juan Riley (talk) 00:04, 22 July 2016 (UTC)
  20. Support - The problem with discretionary power is not that it is prone to misuse, but that it is discretionary, and I have seen more of a trend not to enforce in discreetionary matters unless there's a "serious" issue (subjectively speaking). So I think Option C won't really change anything (despite the naysayers), and as Option A is by default no change, I support B. MSJapan (talk) 18:44, 24 July 2016 (UTC)
  21. Support Option B would be a good choice. Sockpuppetry is a huge problem here that need to be dealt with. I don't see the need for option C because we already have simi-protection and pending changes which works fine. Lets not make editing for the newcomers more difficult to contribute to the encyclopedia. Also, if option C was implemented, then there will be huge amount of requests at WP:RFP, and it would also encourage users to add this user has extendedconfirmed permission userboxes as Esquivalience has pointed out above. Ayub407talk 16:25, 25 July 2016 (UTC)
  22. Support, I'm aware that this point that this is likely pissing into the wind, but I would prefer caution before adopting this wholesale. If this limited trial is successful then we could look at "Option C" down the track. Lankiveil (speak to me) 09:51, 26 July 2016 (UTC).
  23. Support. Option C is too vague, which introduces the potential for misuse. A clear demarcation of when it would be okay to use—i.e. passing through SPI—would introduce a needed check here. Titoxd(?!?) 20:08, 26 July 2016 (UTC)
  24. Support can't really think of may times that 30/500 would really help, other than sock and arbcom sanctions -- Aunva6talk - contribs 03:36, 27 July 2016 (UTC)
  25. Support and strong oppose option C. It seems to me that option B is the main reason why this protection level was created. Implementation of option C will definitely result in Wikipedia appearing to be hostile to newcomers, which is the exact opposite that this site needs to continue to maintain quality content. Many protected pages are major pages, which are often the ones where new users will first try to edit Wikipedia. Making that an immediate locked door will no doubt turn those new editors away. --Iamozy (talk) 14:26, 1 August 2016 (UTC)
  26. Support A is not enough, C is too much. IronDuke 23:30, 2 August 2016 (UTC)

Option C[edit]

  1. Support One more option in the toolkit. Sockmasters, vandals, trolls etc have been getting more savvy lately, so as they get trickier so must the toolkit evolved to deal with them. Blackmane (talk) 01:17, 4 July 2016 (UTC)
  2. Support as an obvious intermediate to semi and full, which, being less restrictive, should not be subject to more use-restriction than full. TimothyJosephWood 01:43, 4 July 2016 (UTC)
  3. Support This is a great intermediate option between semi and full and would cause minimal to no disruption since we already have an edit request system in place for protected pages --Cameron11598 (Talk) 01:45, 4 July 2016 (UTC)
  4. Support But we should only use this sparingly as a short-term measure for really heated issues that it would be difficult for administrators to otherwise keep on top of. We shouldn't create barriers to editing for new and occasional contributors, lest it become another gentle step away from the original vision of a free and open encyclopedia. That said, it's a tool that would be eminently useful to have. KaisaL (talk) 02:05, 4 July 2016 (UTC)
  5. Support and agree with KaisaL. We should only be using this as little as possible and only as a short-term measure unless further authorized. I especially like the notification part of this option so that any uses of this level can have community input. If further authorization is required it can be discussed there. --Majora (talk) 03:01, 4 July 2016 (UTC)
  6. Support another useful tool for admins that will be useful in vandalism fighting. - Yellow Dingo (talk) 04:36, 4 July 2016 (UTC)
  7. Support. From what I can observe, 500/30 has worked well in curbing disruption to Gamergate and caste-related articles. Semi-protection is no longer effective against persistent sockmasters, vandals and trolls. MER-C 05:37, 4 July 2016 (UTC)
  8. Support Option B is too specific, because this could be used fine to prevent issues that don't necessarily have anything to do with socking. I do of course agree that this should only be utilized in major issues where semi-protection has proven ineffective. Omni Flames (talk) 06:21, 4 July 2016 (UTC)
  9. Tentative support as preferable to either rampant, calculated vandalism or full protection. I join KaisaL's comments that this should only be used when it's truly necessary as, unlike semi-protection, this excludes a significant part of our user base. I think a new pending changes level that held changes by users who weren't extended-confirmed (instead of merely confirmed) may be a better option. Rebbing 07:07, 4 July 2016 (UTC)
  10. Support I'm in favour of admins having more fine-grained tools to deal with disruption like this. I would much prefer protecting an article with this protection level to fully protecting it. However, as others have said above, I think this should only be used when semi-protection has been tried and has failed. — Mr. Stradivarius ♪ talk ♪ 07:25, 4 July 2016 (UTC)
  11. Support Net positive - useful for admins to combat disruption. -FASTILY 07:26, 4 July 2016 (UTC)
  12. Support as a useful and relatively benign tool that should be available when full protection would otherwise deprive established content editors from participating. Jclemens (talk) 07:48, 4 July 2016 (UTC)
  13. Support Good alternative to full protection. Armbrust The Homunculus 08:04, 4 July 2016 (UTC)
  14. Support: Perfect where ever recurring semi P is insufficient, full P too restrictive, or pending P inappropriate. - DVdm (talk) 09:09, 4 July 2016 (UTC)
  15. Support. Makes sense. Nsk92 (talk) 09:23, 4 July 2016 (UTC)
  16. Support Combat those vandalism is better. SA 13 Bro (talk) 09:38, 4 July 2016 (UTC)
  17. Support From occasional visits at WP:RfPP, administrators already do a very good job on applying the most appropriate, minimally necessary, level of protection with their current toolset. 500/30 will just be another tool to allow a more efficient protection in some cases - and I trust that it will only be used where really necessary. GermanJoe (talk) 11:04, 4 July 2016 (UTC)
  18. Support Though I think posting at AN every time it is used is excessive. I think it can just be posted there when someone takes issue with it. HighInBC Need help? {{ping|HighInBC}} 13:38, 4 July 2016 (UTC)
  19. Support, though I still hope to see it used sparingly, and only where semiprotection has clearly proven ineffective. We should always be using the least drastic measure; most garden variety vandalism sprees and the like can be handled with semi. Seraphimblade Talk to me 13:43, 4 July 2016 (UTC)
  20. Support Much too easy to create new accounts. "Anyone can edit" should really be "Anyone can edit, responsibly".--☾Loriendrew☽ (ring-ring) 14:32, 4 July 2016 (UTC)
  21. Support Like others, if this option is chosen I think some guidance is warranted. While I agree with the general sentiment that this should be viewed as a tool when semi-protection is not sufficient and full protection might be overdoing it, I prefer not to be so explicit as to require evidence of a failed semi-protection. As an example, which I offer cautiously as I have not been involved in Gamergate issues, I see that it has proved useful in that brouhaha. I can envision that a new article about a player in that controversy might be created and then might erupt into problems. I can imagine that this level of protection might be warranted rather than insisting that semi be added and failed before jumping to this level, but I am totally on board with the concept that jumping immediately to this level of protection would be extremely rare.--S Philbrick(Talk) 14:36, 4 July 2016 (UTC)
  22. Support As others have said: another tool in the toolkit. If semi-protection doesn't work, this is definitely better than giving full protection to articles as it would allow edit requests to still be fulfilled. ECP isn't used often enough to warrant its existence otherwise, I think. KieranTribe 14:39, 4 July 2016 (UTC)
  23. Support As this is a preferable option over full protection in many cases. The admins that work at WP:RFPP are competent enough to use this new option with care. —Ruud 14:48, 4 July 2016 (UTC)
  24. Weak support - It's the best of the options being offered, but I'm unsure of how effective it will be over the long haul. But it's better than nothing. — Maile (talk) 14:55, 4 July 2016 (UTC)
  25. Support. The current option between either semi-protection or full protection is too broad; there are some cases where semi-protection doesn't help and full protection halts all meaningful contributions. 30/500 is a good alternative, and should be used far more often. Colonel Wilhelm Klink (Complaints|Mistakes) 16:20, 4 July 2016 (UTC)
  26. Support. Conceptually, I hate the idea of restricting editing from new users on certain pages. Practically, I acknowledge the necessity. That being said, this is a less restrictive option than full protection, and it adequately addresses the weaknesses of semi-protection. There are cases of vandalism, BLP violations, highly visible pages, etc. where this will be useful temporary measure of protection. I agree with the comments above that this should be used sparingly and only after lesser forms of protection have failed. ERK talk 16:29, 4 July 2016 (UTC)
  27. Support. This is a good protection scheme when full protection is unwarranted. --Coemgenus (talk) 17:15, 4 July 2016 (UTC)
  28. Support, and, given the persistence of some vandals, I'd raise the edits to 1,000 (and erect a wall and have Britannica pay for it). Randy Kryn 18:02, 4 July 2016 (UTC)
  29. Support per Randy Kryn. I support the fullest possible implementation to protect the hard work our content contributors have made. Chris Troutman (talk) 18:18, 4 July 2016 (UTC)
  30. Support. I regularly (as "on an almost daily basis") see cases where semi-protection isn't enough, and it's far from only cases of vandalism, but also POV-pushing, persistent addition of unsourced material and BLP-violations. Thomas.W talk 18:22, 4 July 2016 (UTC)
  31. Strongly Support! Just what our WP:MVPs need when semi won't do. I've been longing for this option for years and now is the time! <<< SOME GADGET GEEK >>> (talk) 18:27, 4 July 2016 (UTC)
  32. Support I trust our admins will use this form of protection wisely, just as we do with other levels. It is nonsensical and contrary to our mission to resort to full protection when the lesser evil 30/500 would adequately control the disruption, and allow more contributors to edit. You might have found me doing it even though the policy says not to, per WP:IAR. For the purposes of sockpuppetry, 30/500 should work wonders. We can't keep making expensive edit filters for each and every issue of sockpuppetry, and no one is having fun combing through revision histories fact checking every change. Same rules apply with 30/500 – don't protect preemptively and use it only when necessary. The flexibility of having a new form of protection at our disposal is only going to make things easier, save us a lot of headaches, and still allow articles to develop MusikAnimal talk 18:31, 4 July 2016 (UTC)
  33. Support So much time is wasted combatting persistent vandalism, POV-pushing, etc.; time that could be spent on creating new content. More flexible tools can only help. Peter coxhead (talk) 20:09, 4 July 2016 (UTC)
  34. Support - This will prevent vandalism from socks on pages, and works much better than having Semi-Protection. Class455fan1 (talk) 20:35, 4 July 2016 (UTC)
  35. Support because semiprotection is too easy to game. --Rschen7754 22:37, 4 July 2016 (UTC)
  36. Support. In fact, I think this protection level would be a good default for user pages. Funcrunch (talk) 22:39, 4 July 2016 (UTC)
  37. Weak Support. I think that this option is the best of the three, but it should be used as little as possible: after every possible semiprotect or pending changes method has been exhausted, and even then, under strict scrutiny from both admins and non-admins—ideally, almost a one to one ratio. Dschslava Δx parlez moi 22:45, 4 July 2016 (UTC)
  38. Support - This is a more precise tool than full protection, it should be permitted for use in more situations rather than fewer. James086Talk 23:22, 4 July 2016 (UTC)
  39. Support - Good alternate to full protection. SlightSmile 00:20, 5 July 2016 (UTC)
  40. Support as long as this is used as a last resort (i.e. after multiple blocks have been ineffective), and not as a default measure for persistent disruption. I do believe however that in very specific cases, not necessarily established by Arbcom or consensus, that this should be used to protect pages/topics on a permanent or semi-permanent (~6 months–1 year) basis, given multiple periods of short-term 30/500 protection and subsequent semi-protection has proven ineffective. –Gladamastalk 00:50, 5 July 2016 (UTC)
  41. Support, except that I see no need to ask for review on AN. Better to handle it as a protection option like any other. SarahSV (talk) 02:17, 5 July 2016 (UTC)
  42. Support With Wikipedia's size and fewer active editors, tougher protection is needed against inappropriate behavior like vandalism and edit-warring. Xxanthippe (talk) 02:29, 5 July 2016 (UTC).
  43. Support We need to have tougher rules on editor's use of vandalism, disruptive editing, edit war and sock puppetry. This one is the best option, but I think it should be only used when it's absolutely necessary. BattleshipMan (talk) 04:41, 5 July 2016 (UTC)
  44. Support – the more protection options, the better, and we need something in between semi- and full protection. I can also see this being useful for very high-traffic articles (e.g. after the death of Michael Jackson). Graham87 07:46, 5 July 2016 (UTC)
  45. Support – This would have spared myriads of editor hours and heaps of reader frustration had it been applied to the articles about Republican and Democratic primaries over the last few months. The Republican one was using the pending changes mechanism and the Democratic one was semi-protected for several periods; both articles were susceptible to 1RR and discretionary sanctions. None of these approaches were very effective in controlling the outpour of craziness, leaving a volunteer army of level-headed editors to sort the mess repeatedly. With a 30/500 protection, knee-jerk reactions from drive-by editors would have been channelled to the appropriate talk page debates or edit requests. — JFG talk 08:03, 5 July 2016 (UTC)
  46. Support - given that the current main alternative when semiprotection doesn't seem enough is full protection, it seems silly to have a greater threshold for the use of ECP than FP, which seems to be the gist of the other two options. WaggersTALK 12:21, 5 July 2016 (UTC)
  47. Support This will be a vital tool in trying to help with vandalism and socks. RickinBaltimore (talk) 12:40, 5 July 2016 (UTC)
  48. Support essentially per Mr. Stradivarius above. Yes, this is introducing additional complexity into the protection options; but to strike a healthy balance between preventing disruption and encouraging constructive contributions, wider use of such protection would be helpful. Of course, it should only be used if semi-protection is not going to help. Vanamonde93 (talk) 12:45, 5 July 2016 (UTC)
  49. Support as long as it is applied carefully. shoy (reactions) 13:17, 5 July 2016 (UTC)
  50. Support provided at least five admins all agree at AN, and there is also an actively patrolled {{edit request 30-500}} available. (No real difference between B and C.) (Yes some process overhead and constraints to reduce the non arbcom use of the process. Wikipedia is and must remain essentially a responsible editors free for all. Aoziwe (talk) 15:22, 5 July 2016 (UTC)
    Changing my vote to very very weak support. The 500 edits also must be main space only, and still present, not reverted, etc. - far too easy to game otherwise. 30-500 is the content equivalent of a large IP address range block, a relatively blunt instrument affecting innocent and value adding editors too. Will there also be exceptions allowed for those who can demonstrate good behaviour but do not have 500 edits ? as per ip range blocks ? Aoziwe (talk) 12:10, 14 July 2016 (UTC)
    Yes, {{edit extended-protected}}, Category:Wikipedia extended-confirmed-protected edit requests, and User:AnomieBOT/EPERTable already exist and are being monitored. Just wanted to mention to avoid any possible duplication of processes in case folks were confused — Andy W. (talk ·ctb) 05:03, 10 July 2016 (UTC)
  51. Support - we trust admins to full-protect, delete and block, so we can trust them to do this and not use it as a "kick out everyone I don't like in a content dispute" magic button. Ritchie333 (talk) (cont) 15:39, 5 July 2016 (UTC)
  52. Support This is simply another tool to use, a level between semi-protected and full protection. Certainly it's better to use this than full protection on an article. However, I believe that using this should be avoided on talk pages, even when there are concerns about persistent sock-puppetry. Mamyles (talk) 16:45, 5 July 2016 (UTC)
  53. Support Per MusikAnimal. Not only has this proven effective in contentious areas, it is also a more precise option than full protection. Mizike (talk) 17:15, 5 July 2016 (UTC)
  54. Support This adds another tool to the admin's chest, which could be useful in stopping the sorts of problems that currently slip through the cracks. However, it's only useful if admins can actually use it. The more rules governing its use, the more work it will take for an admin to implement it, and thus admins will be more reluctant to use it. This, in addition to the restrictions those rules represent on their face could severely strip this option of usefulness if regulated too tightly. MjolnirPants Tell me all about it. 17:33, 5 July 2016 (UTC)
    Support - Pile-on, per above. Mlpearc (open channel) 17:56, 5 July 2016 (UTC)
  55. Support - Good alternative to full protection when semi-protection isn't enough. MartinZ02 (talk) 18:00, 5 July 2016 (UTC)
  56. Support I am concerned that this new privilege could be abused and used to keep away newcomers but as many others have said, semi-protection is easily gamed and does not stop persistent vandalism. Mkdwtalk 18:29, 5 July 2016 (UTC)
  57. Support Makes sense in the present scenario. --QEDK (T C) 18:40, 5 July 2016 (UTC)
  58. Support Forcing the use of ECP to be confirmed by a review at AN and only allowing its use proportionally seem like reasonable restrictions. ---- Patar knight - chat/contributions 21:59, 5 July 2016 (UTC)
  59. Support Obviously the best option. This serves as a very reasonable intermediate step between semi and full protection and I see next to no risk in extending its usage. Swarm 23:23, 5 July 2016 (UTC)
  60. Support eminently sensible suggestion...and I was considering proposing this myself. Cas Liber (talk · contribs) 03:50, 6 July 2016 (UTC)
  61. Support - I have confidence in the admins to use this in a proper way. It can be a usefull tool inbetween semi- and full-protection. Sincerely, Taketa (talk) 06:54, 6 July 2016 (UTC)
  62. Support Makes sense and is a logical addition in my view -- Whats new?(talk) 07:39, 6 July 2016 (UTC)
  63. This one, as a step short of full protection, though the limitations on its use should be stringently adhered to, since it will affect legit editors. At some point, an exemption mechanism for individuals should be devised (i.e., grant the userright before it auto-applies). Would also support a 15/250, if needed, but no more restrictive than 30/500. Despite the beliefs and behavior of far too many GA/FA-focused editors and certain wikiprojects, WP is not a good ol' boys' club of vested editors who have increased content control per their tenure. A terrible result would be something like a 1yr/6000 level. The 3:50 ratio seems okay; very active editors, not using automation, but participating in frequent discussion and making lots of minor cleanup edits, seem to average in the ballpark of 1,000 per month, so half that seems reasonable. If you can't make 50 edits in 3 days you are not trying very hard (or you are very focused on improving a particular article, thus the need for exemptions; I've sometimes worked all day long on an article in a text editor without any edits showing on WP itself). I support this stuff at all because the lengths that PoV pushers and programmatic vandals will go to, and their numbers and even coordination, have all increased, even as the number of casual vandals has gone down since the novelty of Colbert, et al., telling audiences to vandalize WP as a joke has worn off.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:15, 6 July 2016 (UTC)
  64. Support - given that the assumption here is that semiprotection has failed, and the only other option currently is full protection, this seems a reasonable halfway house and I don't see the harm in adding it to administrators' arsenal when combating vandalism. Assuming it doesn't get applied in cases where semiprotection would have done, of course. That can be monitored in the early days of it being used, but we generally assume our admins are sensible people.  — Amakuru (talk) 09:43, 6 July 2016 (UTC)
  65. Support - Amakuru says it nicely above: under this formulation, it would be a useful mid-level of protection, with the risk of it being too restrictive kept in check by a) requirements for prior attempts of solving by semi, and b) we do assume admins to be both conservative and accountable in this regard. -- Elmidae (talk · contribs) 12:16, 6 July 2016 (UTC)
  66. Support - although I don't follow either topic closely, this protection framework has proven effective in WP:ARBGG and WP:ARBPIA, two of our most heated topic areas. It makes sense that this should be effective in less complicated topics which experience the same forms of disruption. Fills the critical gap between where semiprotection is ineffective and full protection is unwarranted. Inherently support any option but strongly prefer C. Ivanvector 🍁 (talk) 14:09, 6 July 2016 (UTC)
  67. Support, newcomers and topic-experts can always post drafts or suggestions to the talk page, which is what WP:BRD requires and is likely on contentious topics; vandalism and edit warring by new accounts and socks is a growing problem, which exhausts constructive new/old contributors and admins; for other reasons see my comment in the "Impact on newcomers" discussion section. Ms Sarah Welch (talk) 14:14, 6 July 2016 (UTC)
  68. Support. I expect that admins who choose to employ these tools will be responsive and flexible in response to concerns. TenOfAllTrades(talk) 15:01, 6 July 2016 (UTC)
  69. Support. Devolution of power to admins is generally good. The criterion that semi must have been proven ineffective and the requirement for AN notification (thus opening up scrutiny) are sufficient procedural safeguards against misuse. Deryck C. 16:10, 6 July 2016 (UTC)
  70. Support - Given the clarification of duration in the comments below (I had presumed that 30/500 would always be indefinite, which I now know is wrong), I now support option C. Admins need a tool between semi- and full-protection, and this is that tool. — Jkudlick • t • c • s 00:29, 7 July 2016 (UTC)
  71. Support - As long as this is used responsibly, I think it's a very good addition as a step between semi and full protection. Garzfoth (talk) 01:52, 7 July 2016 (UTC)
  72. Support - this would be the most effective addition and as stated - halfway between the ineffective semi-protection and the most effective full protection. Another tool against the usual flavors of foolishness. Challenger l (talk) 02:16, 7 July 2016 (UTC)
  73. Support It would need to be a last resort rather than a first; but that's merely the kind of judgement that WP:RFA is meant to prove, and that we assume to our admistrators every day in any case. Muffled Pocketed 15:38, 7 July 2016 (UTC)
  74. Support, as a finer-grain protection level that is both a relatively low bar for constructive editors and a relatively high bar for vandals.   ~ Tom.Reding (talkdgaf)  16:06, 7 July 2016 (UTC)
  75. Barely support, with the idea that it is basically full protection with more users that can edit; the the page will be uneditable for a vast majority. Of course the majority of people in this RfC will be extendedconfirmed anyway, so won't notice - we have to remember the newbies. —  crh 23  (Talk) 21:07, 7 July 2016 (UTC)
  76. Support as another option to be used with care in helping to stop disruption. INeverCry 22:00, 7 July 2016 (UTC)
  77. Support. As the Wikipedia content grows, so does the need for enhanced control over content grow with it, especially the professional attempts to abuse the encyclopedia for promotional purposes. This comes as a much needed intermediary protection level between semi and full protection and I see no need whatsoever for notification to be posted in a subsection of AN for review - WP:RFPP exists and it is most unlikely that unilateral use by admins will be abusive - we must assume that our admins act in good faith and to imply their work needs additional control is an expression of mistrust; as per HighInBC in the cmments section below: 'It should be like a block review, we don't post every block for review just the ones someone takes issue with'. On the other hand, I do see a possible case for partially unbundling the right to semi protect articles under some circumstances (e.g. vandalism sprees), but that would be another discussion. Kudpung กุดผึ้ง (talk) 00:21, 8 July 2016 (UTC)
  78. Support: Best option to deal with sockpuppets, IP-hopping vandals, trolls and all the other ways users who are WP:NOTHERE can disrupt the pace. Clearly, it's a last resort short of full protection and the ability to apply it should be limited to trusted admins and a clear-cut set of criteria, but Options A and B are too limited. Montanabw(talk) 04:12, 8 July 2016 (UTC)
  79. Strong support As vandals evolve, we should evolve too. --Pokéfan95 (talk) 05:38, 8 July 2016 (UTC)
  80. Pile-on support As somebody who primarily works in counter-vandalism on Wikipedia, I feel as if this is yet another small step to combat the issue. Sockpuppet editing is very common and this should help minimise the number of these events. --PatientZero talk 09:09, 8 July 2016 (UTC)
  81. Support and additionally remove the requirement for posting a notification to AN review, we don't do that for full protection so there's no point in doing so for 30/500 - especially considering that full protection is more harsh, not less. Satellizer el Bridget (Talk) 10:35, 8 July 2016 (UTC)
  82. Support I see no reason not to make it a additional tool for admins to use. AIRcorn (talk) 11:58, 8 July 2016 (UTC)
  83. Support - a good balance of extra power with extra check by obligatory review. Staszek Lem (talk) 17:12, 8 July 2016 (UTC)
  84. Support - I've felt for a while that a usable intermediate between semiprotection and edit=sysop was needed. This seems like it'll accomplish exactly that.--Newbiepedian (talk · contribs · X! · logs) 18:40, 8 July 2016 (UTC)
  85. Support as additional variables would be beneficial, such as when dealing with long-term abuse/sockpuppetry where the existing alternatives would be far more restrictive. Regards, Yamaguchi先生 (talk) 19:18, 8 July 2016 (UTC)
  86. Support. I'm in favor of any shifts in policy in the direction of asking our editors to prove their dedication and dependability. I'm favor of any new policy that moves us away from the idea that anyone can edit anonymously, which I realize was necessary during 2003–13 to build momentum and mass but which is no longer so good for the encyclopedia, in my opinion. Option C is a step in the right direction. Binksternet (talk) 19:41, 8 July 2016 (UTC)
  87. Support No reason not to. It will greatly help the encyclopedia. ThePlatypusofDoom (Talk) 20:56, 8 July 2016 (UTC)
  88. Support This would certainly improve on the present state of affairs. Albrecht Conz (talk) 22:16, 8 July 2016 (UTC)
  89. Weak support, with acknowledgement for Option A. I think it's not easy to enforce/monitor/gauge ECP limitation to sockpuppetry/disputes bureaucratically, even with logs. However, if ECP instances are not notified, I'd go with current policy, which is the cleanest. Adding: I can't imagine notifications (at AN) enforced well. Should be bot-handled) — Andy W. (talk ·ctb) 03:06, 9 July 2016 (UTC) 03:08, 9 July 2016 (UTC)
    I strongly support the use of a bot here. Possibly on a transcluded subpage of AN similar to WP:AALERTS? ~ Rob13Talk 04:54, 9 July 2016 (UTC)
    @BU Rob13: Yeah, makes sense. MusikAnimal mentioned below that MusikBot may be able to handle the task, so if the RfC passes for B/C, can perhaps have an implementation discussion post-RfC Oh and congrats on the mop :) — Andy W. (talk ·ctb) 07:21, 9 July 2016 (UTC)
  90. Support I'd like to see this used rarely, only when all lesser options have been exhausted. The concerns about discouragement to new editors, well valid, ignore the fact that higher levels of protection only have more of the same effect. Oh, and no userboxes. This isn't a matter for pride, only safety. Tamwin (talk) 05:49, 9 July 2016 (UTC)
  91. Support as a useful tool, especially against misguided single-purpose accounts. The amount of users impacted by semi-protection is significant, and those impacted by full protection even more so, yet we don't require implementation of those protections to be logged at AN, so requiring this one to be logged seems to be unnecessary bureaucracy, and a bit lop-sided. An Option D to allow this protection to be used at admin discretion without the need to report the action at AN would have been helpful, and I would have supported that option. I do feel, however, that whenever any form of protection is applied that a message, such as Template:Semi-protected, should be placed on the talkpage to give guidance to those users impacted on what they can do. Accounts impacted by Extended confirmed protection can apply to have their user rights adjusted to edit through the protection, and such information should be placed on the talkpage advising such users they can apply at Wikipedia:Requests for permissions/Extended confirmed. SilkTork ✔Tea time 07:44, 9 July 2016 (UTC)
  92. Support but only in very strict circumstances. Many newer users (such as myself) who do not meet the criteria will be put off contributing. Situphobos (talk) 13:28, 9 July 2016 (UTC)
  93. Support in limited situations - mainly for sockpuppetry and tendentious editing by SPAs - as per MusikAnimal. It's another useful tool, but it shouldn't be used in excess. GABgab 20:29, 9 July 2016 (UTC)
  94. Support. The use of ECP will help greatly when it comes to POV warriors, prolific sockmasters, and LTA vandals. It seems both bureaucratic and counterproductive to limit ourselves in when we can make use of this tool. If it will stop the disruption while still allowing through at least some constructive edits, that's a win for the encyclopedia. It is tedious beyond belief to deal with some LTA vandals. The ones who add sneaky vandalism, such as plausible-sounding hoaxes, consume massive amounts of volunteer time. If ECP turns out to be problematic in itself, we can review its use. We can also add restrictions if the community finds it's being used indiscriminately. NinjaRobotPirate (talk) 02:56, 10 July 2016 (UTC)
  95. Support I'm a fairly new editor with less than 500 edits, but I'm not really worried about not being able to edit articles because of ECP. I mainly edit math articles, and only a tiny number of those are even semi-protected. None of the articles I have been interested in editing so far have even been semi-protected. A new editor who is serious about improving Wikipedia can easily find interesting articles to edit. Jrheller1 (talk) 06:30, 10 July 2016 (UTC)
  96. Support if semi-protection proves to be ineffective at preventing disruption, then the only available tools we have right now are pending changes protection and full protection. Pending changes protection is not available or not useful in a wide range of situations, such as where the disruption is due to sockpuppetry, the disruptive nature of the edits isn't immediately visible to editors not familiar with the situation or where the article has a high edit rate. Full protection, whilst highly effective at stopping disruption, also prevents almost all legitimate editing as well, and is rarely applied outside specific circumstances such as edit wars between established editors. With safeguards I think it is appropriate to have an alternative available for these rare situations. Hut 8.5 18:41, 10 July 2016 (UTC)
  97. Support. As a cross-wiki editor, I pretty much agree with what's been said above. The need for a (yet another) protection level has been obvious for some time. Therefore, pioneering ECP on en.wiki would be beneficial for all (larger) Wikimedia projects, at least in terms of policy making. Qweedsa (talk) 21:58, 10 July 2016 (UTC)
  98. Support Unswayed by the 'this destroys Wikipedia, the encyclopedia anyone can edit' and 'scares off the newbies' mantras. A useful tool for dealing with LTA and sock puppetry. Bellerophon talk to me 22:38, 10 July 2016 (UTC)
  99. Support Much needed to combat sockpuppetry. New editors are going to be turned off by the hostility inherent on the pages this would be used for already. A deterrence for new editors directly editing in these areas might be a good thing, while encouraging editors to learn and meet the requirements for extended confirmed in less controversial areas first.  Adrian[232] 11:24, 11 July 2016 (UTC)
  100. Support Unfortunately autoconfirmed can be easily gamed. See Wikipedia:Sockpuppet investigations/Никита-Родин-2002 for examples of this happening. When it happens, semi-protection is no longer effective. Full protection is an option, but is probably too restrictive. ECP seems to me to be a good pragmatic alternative to full protection, and if applied like this will be a constructive countermeasure to sneaky vandalism from gaming autoconfirmed socks. Option C also gives the option for other scenarios in which it may be needed, without the need for full ArbCom cases. --Jules (Mrjulesd) 12:35, 11 July 2016 (UTC)
  101. Support. This would be very useful on article prone to attracting POV-pushing sockpuppets. —Compassionate727 (T·C) 15:48, 11 July 2016 (UTC)
  102. Support An effective "happy medium" between full protection and semi-protection is long overdue, IMO. I believe this would fit the bill for those occasions when full protection is unwarranted and semi-protection fails to quench the problem of persistent and rampant trolling/vandalism.--JayJasper (talk) 19:15, 11 July 2016 (UTC)
  103. Support Given the balance between persistent vandalism and defense against this, a reasonable tool. HGilbert (talk) 05:23, 12 July 2016 (UTC)
  104. Support - incredibly useful tool, per all of the above. Neutralitytalk 05:27, 12 July 2016 (UTC)
  105. Support - I think it's beneficial to have a protection level between semi and full. This protection would have been extremely useful for some cases in the past where full protection was applied for content issues instead. One I can recall off the top of my head is the whole One Direction outrage when Zayn left. It would be useful for articles about current events, which are particularly vulnerable to edit warring or vandalism. Eventhorizon51 (talk) 12:58, 12 July 2016 (UTC)
  106. Yes, but I'd agree with EventHorizon, we should review all Fully protected pages and see which ones can step down to extended confirmed. ϢereSpielChequers 15:53, 12 July 2016 (UTC)
  107. Support. Re-evaluating indefinite fully-protected pages would be good but a large job. It could be incremental by suggesting that admins who service a protected-update-request on a talk page should at the same time consider lowering the page's protection to extended confirmed.--R. S. Shaw (talk) 05:31, 13 July 2016 (UTC)
  108. Support The current restriction on use is silly bureaucratic policy-nazi nonsense and we need to do away with that sort of self-inflicted handicap.--v/r - TP 05:47, 13 July 2016 (UTC)
  109. Support As another intermediate level in protection that admins have available to fight persistent vandalism. VMS Mosaic (talk) 23:22, 13 July 2016 (UTC)
  110. Support a very useful tool as long as it is the most appropriate lowest level of protection (that is, that semi protection won't work). Callanecc (talkcontribslogs) 05:23, 14 July 2016 (UTC)
  111. Support as a way to control certain types of disruption. However, instead of cluttering an existing admin page with compulsory notifications, an automatic list should be available to see what pages are ESProtected. Such a list would be more useful anyway. Zerotalk 09:17, 14 July 2016 (UTC)
  112. Weak Support, Option C is fine for me but I generally support Option D. KGirlTrucker81 talk what I'm been doing 11:21, 14 July 2016 (UTC)
  113. Support with the caveat that I think accounts that were obviously created and used to get around 30/500 should be blocked on-sight unless consensus is established that they are not the sock accounts that they appear to be. Hijiri 88 (やや) 12:52, 14 July 2016 (UTC)
  114. Support with modification of 30/500: Auto-protection will reduce activity by casual bad actors, but determined ones will spend a couple hours making 500 edits to cross the threshold. Rather than (or in addition to) the total number of edits, include a parameter that looks at number of edit DAYS. For example, must have XX number of days with edits. This would then prevent someone from gaining edit access by simply making 500 edits on one day for the purpose of crossing the threshold. - - - Another thought: is it possible to apply additional limits to editors with, say, X number of bans in the past 12 months? Drdaviss (talk) 14:55, 14 July 2016 (UTC)
    Am I missing something here or do you not understand what 30/500 is? The "30" means "account must have been created at least 30 days ago". So yes, someone could make 500 edits in a day to cross the threshold, but only if they had also waited a month since creating their account. Bilorv(talk)(c)(e) 12:08, 16 July 2016 (UTC)
    Yes Bilorv, you are missing my point; thus, I did not explain sufficiently. My point is that it takes little effort to set up accounts, then wait 30 days to use one of them to make 500 bogus edits to vex the intent of auto-protection. However, if one was ALSO required to have at least, say, 10 Edit-days in one's history, then this takes much more effort, because it requires making at least one edit on 10 different days. Thus, one could not take a >30-day account and use it just for a single purpose one day. It would take at least 10 days of effort to get there. Get it? So, this would be 30/500/10. Drdaviss (talk) 16:01, 17 July 2016 (UTC)
    Ah, thank you. I understand now. I still don't approve of 500/30 in the cases you support them, but I do agree that the 10 would in theory be an improvement and defend against sockpuppets who amass sleeper accounts, while not blocking any good faith users for whom editing on 10 separate days is almost certainly a lesser challenge than 500 edits / 30 days since registering. However, I do wonder whether this complexity—and in particular the discussion and consensus required to implement your idea—is warranted for what I believe is such a small-scale problem (a couple of persistent vandals). Bilorv(talk)(c)(e) 16:11, 17 July 2016 (UTC)
  115. Support The best of all worlds. Kiltpin (talk) 20:41, 16 July 2016 (UTC)
  116. Support You could make it 90/1000, and I'd be fine with it. - Pocketthis (talk) 00:10, 17 July 2016 (UTC)
  117. Support and I don't even have 500 edits yet. I'm going to stir the pot here, but I think we editors need to admit that, in spite of some of the above comments, Wikipedia isn't a "pure democracy"; it has to police itself to some extent and there is some authority vested in Admins and Bureaucrats--blocking vandals, protecting pages, etc. Nor is it completely true that it's "an encyclopedia anyone can edit"--some are blocked from editing because of vandalism or use of sockpuppets. The persistent vandalism I've seen on some pages is ridiculous and helps no one, only to tie up Admins and editors who might otherwise contribute good content. [Waits for rotten fruit to be thrown from the audience] Foreignshore (talk) 04:16, 17 July 2016 (UTC)
    Support As long as it's used in accordance with the protection policy, I see no issue with this, it's a useful protection level when semi-protection does not suffice but full protection would be excessive. nyuszika7h (talk) 14:14, 17 July 2016 (UTC)
    Moved to Option B – I changed my mind, even though this option seems to have the most !votes so it may end up passing. nyuszika7h (talk) 14:00, 20 July 2016 (UTC)
    Though probably not in the scope for this RfC, I would support making it 30/500/10 which would make it harder for sleeper accounts, per Drdaviss. Extending it even further like Pocketthis says ("You could make it 90/1000, and I'd be fine with it") would be a bad idea though, at that point it's really a pointless whack-a-mole, as determined vandals will eventually find their way around, and it will just end up hurting good faith editors even more, but I believe 30/500 is a good compromise for when it's really necessary. nyuszika7h (talk) 16:59, 17 July 2016 (UTC)
  118. Support Many articles, such as those involving the 2016 United States Presidential election and other popular articles need this type of protection when semi-protection is not helpful in these cases. Redolta📱 Contribs 17:46, 17 July 2016 (UTC)
  119. Support More granularity is better. Just recently, for example, Taylor Swift was repeatedly vandalized because of current events and placed under administrator access only protection level, preventing many legitimate editors from working on the article. Although it's no longer protected at that level, in the worst case, lengthy periods of vandalism would severely limit editor access to the article. – FenixFeather (talk)(Contribs) 19:07, 18 July 2016 (UTC)
  120. Support Either we trust those entrusted with the mop, or we don't. As with any other action (from what I understand) taken by an administrator, if the community disagrees with their usage of any specific tool, the action can be undone. The consequence of error if an administrator improperly applies 30/500 is far less than that of an inappropriate deletion, or even of an IP block. I understand the arguments against 30/500 in its entirety, however I have trouble with the "it needs to be a separate bit/it is too easily misused" argument. PGWG (talk) 17:36, 19 July 2016 (UTC)
  121. Support - Would be fine with Option B as well, but I think the added flexibility in Option C may be beneficial in some other situations, and I trust that the flexibility would be used appropriately. Rlendog (talk) 19:28, 20 July 2016 (UTC)
  122. Support Useful protection level. --Wario-Man (talk) 19:54, 20 July 2016 (UTC)
  123. Support Provides a much better alternative when semi-protection fails (but does not warrant a full protection), which I have witnessed on multiple occasions where it simply didn't stop sockpuppetry, vandals and trolls (since the requirements of becoming auto-confirmed is very easy). — AYTK talk. 22:22, 20 July 2016 (UTC)
  124. Support I believe it provides a much-needed extra layer of protection. As long as it is used as a last resort, the impact on new users will be minimal, and as someone who is involved in vandal fighting, this would be particularly useful in preventing especially pernicious vandals or those seeking to use the Wiki for promotion... -Pax Verbum 13:56, 21 July 2016 (UTC)
  125. Support — it should never be widespread, but should be applied to problematic topics/article sets where disruption exists despite semi-protection. Semi-protection should always be the first step, only when that doesn't cut it should this be implemented. Controversial topics can otherwise be overrun by SPAs, at detriment to seasoned editors — eating up their time, especially so when policies need to be reiterated over and over again. I've never seen a new editor who started editing with an agenda on something controversial, who later went on to do constructive edits elsewhere. It just doesn't happen. Carl Fredrik 💌 📧 15:25, 21 July 2016 (UTC)
  126. Support. We need another option between semi and full. Regards, James (talk/contribs) 15:39, 21 July 2016 (UTC)
    Oppose So much for the public part of WP. I have no tin foil hat but WP (and its "Arbitration committee") does begin to resemble animal farm. Noting that there was no choice for no such protection at all. Juan Riley (talk) 00:06, 22 July 2016 (UTC)
    You're welcome to move to the moral oppose section, but the community cannot overturn an ArbCom remedy. ArbCom has mandated that this protection level be implemented on certain articles. The community can restrict itself from applying it beyond that, but we can't restrict ArbCom. ~ Rob13Talk 03:17, 22 July 2016 (UTC)
    The community most certainly can overturn an arbcom ruling. If it wants to it can entirely get rid of ArbCom. I agree in principle that such a move would be very unlikely to be good for anyone, and it isn't going to happen here, but it can be done and don't go saying otherwise. Carl Fredrik 💌 📧 23:30, 23 July 2016 (UTC)
    It would be a very interesting conflict if the community ever got together and formed a consensus to "overturn" a ruling of the Arbitration Committee. Generally, ArbCom decisions are understood to override community consensus—see the WP:CONEXCEPT section of the consensus policy. However, what the arbitration policy states is that The arbitration process is not a vehicle for creating new policy by fiat. The Committee's decisions may interpret existing policy and guidelines, recognise and call attention to standards of user conduct, or create procedures through which policy and guidelines may be enforced. The real brain exercise occurs when one of the community enforcement policies—that is, policies created to enforce other policies, like the protection policy—are deliberately modified to conflict with one of those "procedures through which policy and guidelines may be enforced" that the ArbCom creates. A reading of CONEXCEPT would find that the ArbCom procedure overrides the policy-mandated procedure, but an initial reading of the arbitration policy would find that policy overrides ArbCom cases. My personal intuition here is that the ArbCom procedure would indeed override the policy procedure. It is not the role of the community to hear appeals of ArbCom decisions—the ArbCom was created because we accept that there are issues the community cannot resolve by itself. The policy conflict would have to be resolved by the Committee, not the community. Mz7 (talk) 17:29, 28 July 2016 (UTC)
  127. Support Makes sense and is a logical addition in my view. Safeguards appear adequate. Pincrete (talk) 13:56, 22 July 2016 (UTC)
  128. Support where one would otherwise use full protection instead. Requiring posting to AN for review is not a bad idea, but I'd further suggest that it be only be used as a substitute for full protection against vandalism. Effectively relegate full protection of articles to content disputes. More full protection = less editing = discouraged editors but more encouraged trolls. Less full protection = more editing = more editors and more discouraged trolls. The only exception I can see is WP:UPROT: applying it to a user page when that user (who has extended confirmed status but is not an admin or template editor) requests it for their user page. Ian.thomson (talk) 16:58, 22 July 2016 (UTC)
  129. Support Having a finer grained response is a good idea, especially when semi does not prove effective. In regards to user pages, these pages, IMHO, should only be ever edited by the owing user and by admins when there is a breach of policy. I have had my user page used in an inappropriate fashion on many occasions despite it being permanently semi protected. High profile editors (who are not administrators) shouldn't have to put up the extra harassment from disgruntled editors and vandals. User pages should be allowed to be 'sacrosanct'. There is no 'need' for anyone and everyone to edit my user page. It's bad enough that user talk pages are routinely vandalised, but to then allow it to also occur to user pages, despite semi protection, definitely requires a different policy response. David.moreno72 05:38, 23 July 2016 (UTC)
  130. Support. This could be very useful in dealing with, for example
    -an edit war between two new-but-autoconfirmed editors
    -an edit war between one new-but-autoconfirmed editor and one IP
    -an article on a controversial subject attracting a lot of disruptive editing by throw-away autoconfirmed accounts
    These may be less commmon, but that is why posting to AN for review makes sense.
    Yaris678 (talk) 08:46, 23 July 2016 (UTC)
  131. Extra Strong Support - VarunFEB2003 (talk) 11:11, 23 July 2016 (UTC)
  132. Support a useful too that can provide an additional measure of protection to controversial pages. I don't see a reason why use has to be limited to Arbcom only. --Tom (LT) (talk) 00:07, 24 July 2016 (UTC)
  133. Support more measures to deal with disruption beyond semi-protection. starship.paint ~ KO 08:02, 24 July 2016 (UTC)
  134. Support this level of protection would be useful. Sock puppet editors often do pointless edits just to get autoconfirmed, so semi-protection is not a huge barrier for them. I do not see a good reason for restricting this to areas favoured by Arbcom. It is much fairer if it can be applied by community consensus as proposed by Option C.-- Toddy1 (talk) 03:35, 25 July 2016 (UTC)
  135. Support - should clearly be useful, and will help admins deal with awkward situations on controversial articles. Chiswick Chap (talk) 18:12, 25 July 2016 (UTC)
  136. Support - Having previously dealt with situations where throwaway autoconfirmed accounts were vandalising topics that were already being heavily edited (making full protection a hinderance), I believe that this measure can be useful. -- The Voidwalker Discuss 18:30, 25 July 2016 (UTC)
    Oppose Give an admin a shotgun and suddenly everything needs shooting. I support a 30/500 level, but start with the most limited applications. Dmforcier (talk) 23:42, 25 July 2016 (UTC)
  137. Support. The essential point is "given that semi-protection has proven to be ineffective". Under present circumstances, if semi-protection fails, the options are either to let the disruption continue or to stop all non-admin editors from editing. The option of stopping a limited range of editors will sometimes be a lesser evil than either of those two. The editor who uses the pseudonym "JamesBWatson" (talk) 13:48, 26 July 2016 (UTC)
    Support. With Wikipedia's increasing maturity, protection against vandals must be made more effective. Xxanthippe (talk) 07:21, 27 July 2016 (UTC).
    @Xxanthippe You have already voted Altamel (talk) 14:36, 27 July 2016 (UTC)
    Sorry, I lost count. Xxanthippe (talk) 22:31, 27 July 2016 (UTC).
    @Xxanthippe: Indented your second !vote here. You seem to be vote #42 as of this post — Andy W. (talk ·ctb) 23:52, 27 July 2016 (UTC)
    Could you please explain what you mean by maturity? BorkBorkGoesTheCode (talk) 09:06, 28 July 2016 (UTC)
    Most of the important articles are written (although there is always need for more), so attention needs to shift from creating new articles towards protecting from vandalism the ones that are well established. Xxanthippe (talk) 09:16, 28 July 2016 (UTC).
  138. Support as autoconfirmation is too easy to achieve, and admins should be able to combat vandals without full protection. Jjamesryan (talk | contribs) 08:29, 27 July 2016 (UTC)
  139. Support nice for userspace pages, extremely controversial pages, pages targeted by sockpuppeteers and many more. --Laber□T 20:15, 27 July 2016 (UTC)
    I most certainly agree on that. Userspace pages, controversial pages, pages targeted by sockpuppets and such should have this kind of protection. BattleshipMan (talk) 21:18, 31 July 2016 (UTC)
  140. Support per Xxanthippe Gary "Roach" Sanderson (talk) 00:36, 28 July 2016 (UTC)
  141. Support The better of the three options, admins please use wiselyXyzspaniel (talk) 23:34, 28 July 2016 (UTC)
  142. Support - We're not gonna ban IP editing and require registration and sign-in-to-edit in my lifetime, it would seem. Blocking IPs is at best an inexact science and creates a great deal of collateral damage. Sockpuppetry can't be stopped but can be slowed. This is another tool for the arsenal. Carrite (talk) 14:09, 29 July 2016 (UTC)
  143. Support This will allow the most amount of problems to be solved and combatted. Emir of Wikipedia (talk) 14:22, 29 July 2016 (UTC)
  144. Support Seems the most reasonable tool against people with good intentions but lack of understanding of the Wikipedia guidelines. Baldusi (talk) 20:20, 29 July 2016 (UTC)
  145. Support Like others, I see it as less restrictive than an uncontroversial power available to all admins, and a useful option for the appropriate case. I do think notification at RFPP should be sufficient. Xymmax So let it be written So let it be done 15:51, 30 July 2016 (UTC)
  146. Support - I'm going to pile on also. My reasons are mostly the same as those expressed above by MjolnirPants and MusikAnimal. This will be another useful tool and semi-protection is too easy to game. - tucoxn\talk 20:09, 30 July 2016 (UTC)
  147. Support - I became less active in Wikipedia because of sockpuppets, so I prefer this option. Zezen (talk) 07:28, 31 July 2016 (UTC)
  148. Support - I see it as an alternative between full- and semi-protection. Time limited. Few good contribs will be banned, but mostly a newbie and a high controversial issue ... it doesn't fit together. --Keysanger (talk) 21:31, 31 July 2016 (UTC)
  149. Support - I don't feel like ArbCom should have to be tasked with making decisions about page protection-- admins can be trusted to do this, so option A doesn't jive well with me. I think there does need to be a responsive measure for folks who try to game the system with sockpuppetry and sleeper accounts intended to circumvent the semi-protection process. I JethroBT drop me a line 23:24, 1 August 2016 (UTC)
    Support Per Blackmane, MER-C, MusikAnimal, Carrite, and many others above. I've been fighting sockmasters for years, and they can be very creative and tough to handle. New tools that help to protect content and aid productive editing are a welcome addition to the project for me. INeverCry 02:43, 2 August 2016 (UTC)
    @INeverCry: You have already voted. Altamel (talk) 04:32, 2 August 2016 (UTC)
    Oops. Thanks. INeverCry 05:52, 2 August 2016 (UTC)
  150. Support as a last resort in situations where all else has failed Atlantic306 (talk) 05:57, 2 August 2016 (UTC)
    Support This to me is the "In case of emergency, break glass" option to deal with vandalism when semi-protection just won't cut it. RickinBaltimore (talk) 12:56, 2 August 2016 (UTC)
    @RickinBaltimore: You have already voted. Altamel (talk) 14:34, 2 August 2016 (UTC)
    Striking my comment, oops! RickinBaltimore (talk) 14:37, 2 August 2016 (UTC)
  151. Support. For so many reasons given above Bluehotel (talk) 15:55, 2 August 2016 (UTC)
  152. Support, all the other options are bureaucracy creep. Max Semenik (talk) 19:52, 2 August 2016 (UTC)
  153. Support This level of protection should be useable by the community wherever reasonably necessary. DavidLeighEllis (talk) 04:11, 6 August 2016 (UTC)

Discussion[edit]

AN notification[edit]

Option C question. Need clarification on "Notification is to be posted in a subsection of AN for review, unless the topic is already authorized for 30/500 protection by the Arbitration Committee." What does this mean? Will this be a general notification permanently posted at AN, or is this to be posted every time it's used? Wording is open to interpretation. — Maile (talk) 12:52, 4 July 2016 (UTC)

As a disclaimer, I was the one that proposed the addition of the notification requirement during the village pump idea lab discussion. The idea, in my mind, was to require admins to post the levying of ECP on any given article for community review. The exception above means that if the article has been granted ECP through an Arbcom case, Gamergate for example, then the ECP is an Arbcom action, with the authority of the whole committee, and not an unilateral action by an admin. An Arbcom action such as this already requires a majority vote by the committee before being performed. As for the subsection notification, the requirement is like a block review. It's posted as a new thread, the community reviews, the discussion is closed once consensus supports or opposes the ECP action then it is archived as normal. Blackmane (talk) 13:12, 4 July 2016 (UTC)
I think it should only be posted if someone has a problem with it to avoid cluttering the noticeboard. If nobody takes issue with the protection why take up space? It should be like a block review, we don't post every block for review just the ones someone takes issue with. HighInBC Need help? {{ping|HighInBC}} 13:40, 4 July 2016 (UTC)
Agreed. TimothyJosephWood 13:44, 4 July 2016 (UTC)
I agree. I think require notification in every instance may be overkill. We obviously need to monitor make sure it doesn't get overused but there are better mechanisms than counting AN posts.--S Philbrick(Talk) 14:39, 4 July 2016 (UTC)
No objection from me. My thinking was in the early days of it, there probably won't be that many requests for ECP so the first bunch of them may (or may not?) be worth putting past the community, but after that it would be as you and HighinBC indicate, that only those objected to would be reviewed on the noticeboards. WP:Requests for ECP board anyone...? Blackmane (talk) 14:51, 4 July 2016 (UTC)
I strongly object. If this measure is to be used "sparingly", as many supporting option C have indicated, the notifications will be occasional and will not clutter the noticeboard. If ECP is used so frequently that the number of notifications is cluttering the noticeboard, we need to reexamine the use of ECP, not get rid of the notifications. The point of the AN notifications is to actively prod the community to monitor the use of this protection method. Just waiting for someone to object is not a good alternative, since the users with fewer than 500 edits that would be unable to edit an ECP article are unlikely to voice a complaint at AN, or even know what that noticeboard is for. Altamel (talk) 16:30, 4 July 2016 (UTC)
Suggestion - If this action needs posting at AN, why not just have a bot trigger a posting everytime it's used. Either on the main AN page, or a sub page. That way, everyone will get an idea of whether it looks like it's being used too liberally. If it's only a once in a while usage, then it's no problem for an uninvolved editor to click on the link and see if it warrants a second look. — Maile (talk) 16:39, 4 July 2016 (UTC)
I was going to say the same thing. Special:Log and the category will give us what we need, but it'd be nice to have a clean automated report to some subpage that we can transclude wherever we want, namely AN. User:MusikBot would be happy to do this for us :) MusikAnimal talk 18:35, 4 July 2016 (UTC)
  • The notification needn’t be set in stone; there’s nothing to prevent revisiting the procedure in a few months should it become a waste of time on the one hand, or be deemed inadequate on the other. I think it’s only prudent to have some ‘peer review’ under proposals B & C until a pattern of application is established. Moreover, if the only attention it receives is in the form of complaints (assuming there will be at least a few) there will be a sort of selection bias in people’s perception of the policy‘s success, while mandatory reporting will create an easily visible ‘track record’. (For that matter, it may be worthwhile to survey the reversions and edit-requests on ECP pages, to evaluate the balance of disruption-reduction against inconvenience to good-faith newbies and the editors who process their requests.)—Odysseus1479 07:10, 14 July 2016 (UTC)

Will probably cast a vote soon... I hope that EC-P can effectively counter the sockpuppet accounts that are used to counter semiprotection i.e. accounts making 10 dummy edits and waiting 4 days to disrupt. (ex. see Special:Contributions/Rack3515, Special:Contributions/Rah2882, possibly (!AGF) Special:Contributions/South Morang. as far as I'm aware this is happening quite a bit) If they start to create sleeper accounts and make 500 dummy edits on their userpage or sandbox, that would be detrimental to this project. EC-P will likely make User:AnomieBOT/EPERTable more active and worthy of monitoring. — Andy W. (talk ·ctb) 16:15, 4 July 2016 (UTC)


  • I'd like to see a change to Options B or C to add "... unless the topic is already authorized for 30/500 protection by the Arbitration Committee or community discussion at AN or ANI." If the community has reviewed multiple articles related to a topic area and endorsed the 30/500 protection on each of them, the community should eventually be allowed to make the determination that 30/500 is appropriate within the general topic area and future review isn't necessary unless someone disputes the protection. WP:NOTBUREAUCRACY and all that. ~ Rob13Talk 16:30, 4 July 2016 (UTC)
  • We discussed that (see the talk page). We left it out because anyone is free to bring up anything at AN at any time, including ECP for a page, as evidenced by the discussion that closed earlier this week. This is strictly about administrator discretion using ECP. Katietalk 18:23, 4 July 2016 (UTC)

Impact on newcomers[edit]

This proposal is being voted on by the people it would affect the least: we are approaching this RfC through an enormous blind spot. Who among us has fewer than 500 edits or can remember what it was like to be a newcomer? This proposal will drive away new users, and here's why: 500 edits seems like an insurmountable barrier to the average good-faith new user or IP (whereas making 10 edits for autoconfirm is quite achievable). To seasoned editors like us, 500 edits is nothing, but keep in mind new users are unsure of how to edit and may have been bitten by unnecessary warning templates on their talk page. The more frequently a newcomer encounters ECP-locked pages, the more they will conclude that Wikipedia does not want them.

Now, I see many users have asked that ECP be used only rarely, or when semi-protection fails. But besides the AN notification, nothing in this proposal would actually discourage admins from excessively applying ECP. Although this RfC sells ECP as an alternative to full-protection, ECP could easily become as widespread as semi-protection: with full vs. semi-protection, many active non-admins will argue against full protection. This is not the case when choosing between ECP and semi-protection, since the newcomers ECP restricts are unlikely to speak out against it. Wikipedia is failing to attract as many new editors as in the past; ECP will only exacerbate the decline.

TL;DR: ECP will be used excessively and drive away good-faith newcomers. Altamel (talk) 18:52, 4 July 2016 (UTC)

Absolutely right, It's easy to ask this kind of sanctions if you know you wont be effected.
-Hello new user, welcome to the encyclopedia anyone can edit!
-Oh, I see you want to contribute to something related to the Israeli–Palestinian conflict, excuse me but you first have to edit Broomstick and Garden hose articles to be eligible! Because, after all, a good editor is an editor with the highest edit count.
-Oh you are an expert on the subject you say? You have no interest in editing Broomsticks and Garden hoses? You shameless SPA, get out of here!!! Darwinian Ape talk 21:49, 4 July 2016 (UTC)
At least it's not Shrubbery and Path again. — xaosflux Talk 22:18, 4 July 2016 (UTC)
Many newcomers are diving into the most contentious and bitter of dispute areas, Israel Palestine, India Pakistan, Syria, American Politics, Gamergate, etc.

There is a reason why these all have Arbcom cases. What has come out of the Gamergate is that the admin corps needs a new tool to deal with disruption. Autoconfirmed is easily gamed and protection might be too strong. There's not been an intermediate protection level that lets newbies who have picked up some experience continue while telling complete newbies "this article has seen some issues, we'd like you to test the waters in less conflict prone articles before diving in here" as opposed to Semi protection or protection which basically prevents all newbies from contributing altogether. Blackmane (talk) 22:59, 4 July 2016 (UTC)

Yes there is a reason why these all have arbcom cases, and it's not the newcomers. Yes there might be a certain amount of disruption from newcomers especially when the topic is hot. But lets not pretend that newcomers are like children and the experienced editors are the adults trying to keep order. As I said above in the vote section, it was actually the biting from an experienced editor, who was shortly after topic banned, that led to 500/30 protection. Wikipedia was against creationists with all the resources to build an Ark, Scientologists with the power of Xenu, climate change deniers who are friends with creationists, all of which were much more powerful and well funded, those topics did not require this kind of protection but a hashtag with a lame internet drama was too much, we need new tools for admins, man the harpoons, it's Gamergate!!! I don't buy it. This protection might make the subject much more quiet, it does not make it better. Gamergate article didn't improve as far as I can see, It still reads like autism incarnate. And now people suggest using this protection as commonly as semi protection. Darwinian Ape talk 00:15, 5 July 2016 (UTC)
One thing you may have missed is that the RFC is not about the topics that Arbcom has jurisdiction over but to grant admins discretionary use of ECP in lieu of semi protection, which is very rarely applied indefinitely. The articles Arbcom have jurisdiction over has, if I remember correctly, indefinite ECP applied. What the RFC is asking is whether Admins should be allowed to apply limited duration (at least that should be thrust of it) ECP to articles that are seeing heavy disruption from new accounts, sock accounts, IP's and sleepers. If ECP is not necessary, then the fall back position is semi protection. @KrakatoaKatie:, this may be something we missed when framing the RFC at the Village Pump discussion. Blackmane (talk) 01:34, 5 July 2016 (UTC)
Nothing in this RfC says ECP can only be applied for a limited duration. And given that there is no limitation, admins will extended confirm protect articles indefinitely. Altamel (talk) 01:47, 5 July 2016 (UTC)
You are correct that the RFC does not say this. That is outside the scope of the RFC when admins aren't even permitted to apply ECP in the first place. The community needs to come to a consensus that actually permits admins to do so first before framing the policy that governs the practical use of the added protection. Step 1: You are allowed to do this. Step 2: This is the scope and here are your limitations. It'd be somewhat pointless if a policy was created and then the community consensus was "sorry you're not allowed to use ECP". Now that would be a right waste of time. Blackmane (talk) 02:46, 5 July 2016 (UTC)
I should clarify that I meant to say, "given that there is no limitation, there will be instances where admins extend confirm protect articles indefinitely." I do believe that in most cases, admins will protect for a shorter period of time. Altamel (talk) 03:17, 8 July 2016 (UTC)
  • Option C is a terrible precedent. Wikipedia is the encyclopedia anyone can edit, and Option C purposely works against that. While there are points where semi can fail and full is not sufficient, requiring 500/30, and the current cases outlined by ArbCom seem reason (though I still object to how broadly it is used for I/P), but realistically, if semi is not working, there is something else going on that needs a better evaluation of the situation and not just slapping a closed door onto an article. The Internet is inherently not a safe space, and I've seen people suggesting 500/30 to make WP such a place, which can't happen without closing off the open-edit fundamental system. It might take more work and for editors and admins to show patience and restraint, but if we close off Wikipedia, the experiment has failed. --MASEM (t) 01:13, 5 July 2016 (UTC)
I knew this was where we were heading since the first proposal of this protection, and warned about the slippery slope. Edit count is becoming a wiki currency, perhaps always kinda was but never so profoundly. Let me tell you another problem with this protection, people will immediately be suspicious of anyone with just above 500 edits who participate in an ECP'ed article. I mean anyone who is willing to take the time to edit 500 times and wait a month just to be able to edit a topic must have an agenda, right? I actually saw a conversation exactly like that, and it wont be the last I assure you. With this RFC going the way it is, we will be throwing the AGF out of the window and the articles with this protection will be OWNED spaces. I sometimes understand the frustration of an editor who works in a contentious area, or an admin. It's easy to lose perspective and see the IP's and New editors as a disruption, but they are what makes this project what it is now. You are breaking the Wikipedia albeit with good intentions. Darwinian Ape talk 02:33, 5 July 2016 (UTC)
I would add that although vandalism commonly comes from IPs and new users, on unprotected pages it is often the IPs and new users (in other words, casual readers) who spot the vandalism and remove it. On the other hand, it will be much more difficult to vandalize a 500/30 protected page, but if the Wikipedians using anti-vandalism tools fail to spot it immediately, we can no longer depend upon casual readers to revert vandalism that has fallen through the cracks. This is a feature, and not a bug of the open-edit system. Altamel (talk) 16:39, 5 July 2016 (UTC)
As an occasional IP editor and long time reader, I have to agree with the concerns here. Many often ask how we can improve editor numbers on Wikipedia, yet additional bureaucracy like this does little but discourage newcomers and long time editors in both controversial and mundane topics as they try to navigate the minefields. Personally, I don't think Wikipedia can return to glory without a serious trimming of policies and guidelines and a serious review of every member of the administration, and this change is antithetical to what was built as the encyclopedia that anyone can edit, but that's neither here nor there. 50.32.227.204 (talk) 02:22, 12 July 2016 (UTC)

Can the multitude of people who support Option C, give a few examples of how the current none-semi-full protection system falls short on some articles? In practice, 500/30 has only been used so far as an "indefinite" (or very long duration) measure. I am concerned that this might become the new default "semi-protection" measure which is often used for an indefinite duration. This has resulted, in some cases, an indef semi-protection on an article for years after the original vandalism/sockpuppetry, simply because nobody switched it off. See the history of Imaginary number for an example. If Option C passes, then may I suggest an explicit time limit on the protection, with indef 500/30 only allowed via ArbCom directives. I see many people saying that it is "a good alternative to full-protection": but full-protection is typically only used for a short duration, till the dispute cools down. Kingsindian   09:33, 5 July 2016 (UTC)

A good example, digging into the past, would have been the MMA (Mixed martial arts) articles that, for a time, showed up at ANI virtually every week. There was a great deal of disruption from a lot of new accounts and IP's largely due to off wiki forums, so many articles were semi'd however, there was a solid enough fan base who ensured they were autoconfirmed to keep pushing the disruption. ECP would have been an excellent choice to deploy at that point. Articles relating to politicians that are not covered by WP:ARBAP2, particularly around election time in any given country especially those given to extreme partisan politics, would be another example. Like I said in an another post, a discussion about specific aspects, such as duration, should wait until consensus has been reached as to actually permit admins to deploy ECP. Blackmane (talk) 15:15, 5 July 2016 (UTC)

The edit request process should already be working - if it is broken it does not need to wait for this RfC to fix

Proposal - Is there any possibility of creating a suitable method for non-extended-confirmed users to suggest changes to a 30/500-protected article? For semi-protected pages, users can place {{Edit semi-protected}} on the article's talk page to request edits, but many 30/500 article talk pages (such as Talk:Gamergate controversy) are also 30/500 protected. Creating Wikipedia:Administrators' noticeboard/30/500-protection edit requests or similar might work, but there would be a lot or disruption on that page, too. –Gladamastalk 01:18, 5 July 2016 (UTC)

Feel free to create a RFC for this question after this one is complete. Adding things in to a structured RFC usually just causes chaos Blackmane (talk) 01:29, 5 July 2016 (UTC)
What Blackmane said. We should create a category and template similar to {{edit semi-protected}} and {{edit protected}} anyway, but that's outside the scope of this RFC. Katietalk 02:11, 5 July 2016 (UTC)
What need is there to wait—why not create it now? If there is an edit request template for the higher-level full protection, what good reason would there be to not create a template for this type? We should never create a system in which any admin can unilaterally impose protection and consequently block even edit suggestions. Be bold—we certainly don't need an RfC for the creation of every little obvious thing. Biblio (talk) WikiProject Reforming Wikipedia. 03:29, 5 July 2016 (UTC)
These things already exist and should be working - if they are not then they should be fixed. I just logged on with my alt account that is not 500/30 - trying to edit a ECP goes to the "edit request" dialog just like full protected, and uses template {{edit extended-protected}}. Additionally, if the talk page is protected such as with that gamergate page - the edit request goes to Wikipedia:Requests_for_page_protection#Current_requests_for_edits_to_a_protected_page. Is there some part of this that is not working? — xaosflux Talk 03:39, 5 July 2016 (UTC)
Note: talk protection should be extremely rare - it is currently only in use on 6 pages. — xaosflux Talk 03:47, 5 July 2016 (UTC)
Additionally, these should be appearing in Category:Wikipedia extended-confirmed-protected edit requests. — xaosflux Talk 03:42, 5 July 2016 (UTC)
And additionally, there is a bot generated list of these that should be present at User:AnomieBOT/EPERTable - anyone who is extended confirmed that is interested in following these requests may want to watchlist that page. — xaosflux Talk 03:45, 5 July 2016 (UTC)
@Gladamas, KrakatoaKatie, and Biblioworm: I've been actively monitoring the EPERTable since around May. It's very very quiet, and typically there are ~1–2 requests per week, whereas SPERTable sees about 6–8 per day. You can actually put {{edit semi-protected}} on the talk page of an ECP page, and the template doesn't actually care – it senses the editprot level on the target and picks up on the fact that it's ECP anyway — Andy W. (talk ·ctb) 04:00, 5 July 2016 (UTC) 04:13, 5 July 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

By the way am just misunderstanding this or are some admins already using ECP for articles that weren't sanctioned by arbcom. See the list of EC protected articles (example article) Darwinian Ape talk 04:13, 5 July 2016 (UTC)
There have been some out-of-the-lines usages, and some accidental usages. For any specific page that you think is improperly protected, please start on the protecting administrators talk page. — xaosflux Talk 04:21, 5 July 2016 (UTC)
@Darwinian Ape: the page Disgusting (for example) would fall into Option B (minus the post/review), and so would example page you mention I think. But apparently EC-P still didn't do its job. See Special:CentralAuth/JeremyCubsfan98, who made 500 edits just to do the damage at that page. (confounding) — Andy W. (talk ·ctb) 04:42, 5 July 2016 (UTC)
Well, I think these accidental uses are a preview of what we will see if B or C is passed(which is likely,) a beta test if you will. Notice that their expiration dates are indefinite, which I believe will be the norm. Full protection by it's nature has to be short termed, ECP is more like the Semi that it can be used in long periods because the article is technically open to edits. Caution to anyone who see this as a lesser evil. Also someone who has no job never fails to amaze the occupied. Darwinian Ape talk 04:57, 5 July 2016 (UTC)
  • Comment about Option C, EC is permanent, or usually is, yet socking or edit warring is a fleeting thing. Why would we want to protect an article so that someone can't contribute positively? Perhaps Option C should have a time limit, temp-EC. As for my Option A, I could see a fast-track system of ARBCOM approvals so that we don't have to wait for a full case to get ARBCOM approval for EC. The one thing we SHOULD NOT have is EC available to every admin. It will do terrible things to Wikipedia. Everyone can edit is turning into only the elite can edit. Sir Joseph (talk) 16:30, 5 July 2016 (UTC)
    To implement your not-every-admin suggestion, the permission protect would need to change, and ECP protection would need to be its own permission then, called "extended-protect-pages" perhaps, that doesn't get packaged to sysops by default. Who would grant this permission? Bureaucrats? I personally don't see this happening any time soon. — Andy W. (talk ·ctb) 17:06, 5 July 2016 (UTC)
    What is the problem with giving ECP to admins? MartinZ02 (talk) 20:35, 5 July 2016 (UTC)
  • 30/500 protection (or ECP) is absolutely not permanent. The only time an indefinite duration is appropriate is for topics authorized by ArbCom, and even then it's no hard requirement. Usage of 30/500 will follow that of any protection level – use the shortest effective duration. I'm sorry this was not clear, perhaps we should amend the wording for clarity. Semi on the other hand may be handed out more liberally since it involves less collateral damage, but semi itself is not given a longer duration because it is still "technically open to edits", and this would be much less the case for the more restrictive 30/500 protection. This should go without saying, but we can amend the policy language to clarify that 30/500 is no different than the other protection levels when it comes to deciding on a duration (with exception of highly visible templates which are given an indefinite duration) MusikAnimal talk 21:17, 5 July 2016 (UTC)
    Pinging @Sir Joseph and Darwinian Ape: as this is in response to their concerns MusikAnimal talk 21:19, 5 July 2016 (UTC)
    @Blackmane, Altamel, and KrakatoaKatie: I've boldly clarified this. It's impossible to think that we could as a functioning open encyclopedia allow indefinite extended confirmed protection to be applied haphazardly. The protection duration is relative to the disruption, just as it is with semi, PC and full protection. Template protection on the other hand is for highly visible templates, which are intrinsically protected indefinitely MusikAnimal talk 21:38, 5 July 2016 (UTC)
    That is a step in the right direction, thanks. However, I still have my doubts with how vigorously protection duration guidelines will be enforced. Part of the reason why long-length full protection is so rare is because sysops recognize only 1,296 Wikipedia accounts will be able to edit that page, and if they do apply full protection haphazardly, the multitude of experienced editors who are not admins will surely raise complaints. On the other hand, experienced non-admins won't be affected by the haphazard application of EC protection, so they have no incentive to complain unless they dislike EC on principle. Meanwhile, the new users (those with less than 500 edits) are unlikely to request unprotection due to their unfamiliarity with Wikipedia, or unwillingness to jump through so many hoops. Proportional duration is still up to each admin's interpretation. If an admin does decide to EC protect a page indefinitely, it could easily languish that way forever. Just looking through Special:ProtectedPages, I see many indefinitely-semi'd articles that should probably have been unlocked years ago. I can provide examples upon request. Altamel (talk) 23:01, 5 July 2016 (UTC)
    No need to provide examples. Ask the protecting admin about it, and if you get no response post at WP:UNPROTECT. You are absolutely right that non-extended confirmed users are less likely to speak up about their inability to edit, but they are certainly more likely than unconfirmed users. My point here is that no admin in their right mind is going to add indefinite extended confirmed protection without trying shorter durations first. If they do that is abuse or severe negligence, plain and simple. Outside ArbCom-authorized topics or long-term issues of sockpuppetry, you probably won't see a need for an indefinite duration since semi usually does the trick. Even for semi, I can't tell you how many times I see "indefinite semi-protection" being requested at RFPP and the response is "semi-protected for a period of 1 week". As much as we care about protecting the wiki we care about keeping it open MusikAnimal talk 23:48, 5 July 2016 (UTC)
    @MusikAnimal: I can see why long EPP may be jumped to - technical limitation of not allowing stacked protections and having to watch to put back on something else if needed prior to the new expiration. — xaosflux Talk 01:40, 6 July 2016 (UTC)
    @Xaosflux: I'm not sure technical limitations should warrant malpractice. Here we are effecting editor engagement and an article's ability to develop, and that should have priority. Patrollers are quick to re-request the appropriate protection, especially if the disruption is truly that severe; but you're right, we run into the same issue with full protection all the time. Fortunately with ECP the fallback is not as significant (full to none vs ECP to none). I don't know how long it'd take for a core solution to happen, but I've meaning to propose a bot-automated report of full protections that have expired, perhaps pinging the protecting admin. This would be a straightforward task to implement, and the same could be done for ECP MusikAnimal talk 02:05, 6 July 2016 (UTC)
    I'm not saying it is a good reason - just that I see where it may happen...I was just thinking of bot options too--will ping your talk. — xaosflux Talk 02:09, 6 July 2016 (UTC)
    (edit conflict)x2. Personally, I'm not focused on the duration of the ECP at this point as I'd rather be more focused on the actual question which the RFC frames. The discussion has already deviated from the main question. While the concern of ECP duration certainly needs to be addressed, my opinion is that it doesn't need to be addressed just yet. The RFC discussion is already getting bogged down in policy minutiae. Blackmane (talk) 23:50, 5 July 2016 (UTC)
    We don't need a follow up discussion on what durations to go with for ECP. The philosophy of minimum effective administrative action is already in practice and I have every reason to believe competent admins will do no different with a new form of protection MusikAnimal talk 00:01, 6 July 2016 (UTC)
  • Comments: [1] Articles with serious quality issues, such as largely unsourced or poorly sourced (blogs/non-RS), should not be subject to ECP or only for very short periods. Else, ECP will be protecting articles with amazing OR or fascinatingly absurd POVs with no sources cited, and preventing contributions from new editors who might be rightfully bothered. [2] I am not persuaded by comments above that are worried about new topic-experts unable to participate, because they can always post their draft or suggestions on the article's talk page. For contentious topics, that is usually the best first step anyway. [3] An article that is subject to persistent vandalism, edit warring and disruptive WP:TE will exhaust any topic-expert (anyone for that matter). Semi-protecting and ECP for 1 to 6 months can actually help new knowledgeable editors or topic-experts to help improve the quality of difficult or contentious topics, in a more stable format through the article's talk page. We must assume good faith not only for new users, but also for not-new users and for admins. Ms Sarah Welch (talk) 12:55, 6 July 2016 (UTC)
  • I agree that this is likely to have an adverse effect. I'm a fairly casual Wikipedian, I've been here since 2007 and thought I'd amassed hundreds of edits - but it turns out to be 94. To me, and I suspect *many* others, 500 edits is the same as full protection. Some of my edits have been gnoming, whereas some have been creating new (or vastly improved) graphics for articles into which I put a lot of work; and I have never vandalised, been rude, or engaged in an edit war. I feel that (a) I have earned my right to make good-faith improvements to articles, and (b) I shouldn't have to, beyond auto-verification.
I understand that some articles need semi- or full protection, but 30-500 seems just a re-branding of full protection with less oversight, allowing people to effectively take ownership of an article, either in bad faith or in misguided good faith.
If an article needs strong protection, give it full protection. If it needs less protection, give it semi or nothing. 30 days is a reasonable request for new but genuine editors; 500 edits is an insurmountable hurdle. Cosmogoblin (talk) 00:47, 13 July 2016 (UTC)
This is exactly the sort of viewpoint that we need to see more of, but our RfCs will always have an inbuilt bias against users like you—casual editors who would probably voice strong opposition were they aware of the proposal. For me, 500 edits was nothing, because I'm a sort of spammy-style editor who will make tons of typo corrections as I see them, but I absolutely agree that there will be many editors out there who feel the way you do—for whom amassing 500 edits using automated tools or for such trivial wastes of time as searching for typos is an absurd concept, and the fact that they plod along at their own pace, making fewer but more important edits, provides no reason why they shouldn't have the same right as '30/500' users to edit controversial pages. Bilorv(talk)(c)(e) 16:34, 17 July 2016 (UTC)
While I don't fully agree with Cosmogoblin, I do agree with some of his points. I'm also a fairly casual Wikipedian. I've been here a bit more than one and a half years now and I've made about 60 edits per year, give or take a few. Therefore, it would take me about six to seven more years to achieve EC status, which could be a big problem if ECP was used on many articles. I've never tried to edit an article on a very contentious topic, so this wouldn't really affect me yet. However, it feels like content creators or casual Wikipedians could take a long time to achieve 500, even if they are good-faith members of the community and good at what they do. I would be much more comfortable with a 30/200 restriction or something similar. Greatedits1 (I hope so | If not, let me know) 22:14, 2 August 2016 (UTC)

Time limit clarification based on Option C comments[edit]

Many of the option C supporters have either mentioned 500/30 ECP as intermediate between semi- and full protection. Both of those protections usually have a short duration. Some have even stated using ECP only for a short period to stop disruption. This is not the current experience. ECP is generally applied as a permanent page restriction. Is option C only attractive if there is a commitment to expirations similar to full and semi expirations? --DHeyward (talk) 00:24, 6 July 2016 (UTC)

Sorry for being unclear. I've updated the options to state the duration chosen should be no different than that of semi/PC/full except for topics authorized by ArbCom. This is why the pages you've seen under ECP thus far are of indefinite duration (not that I completely endorse this practice). This will not be the case for general disruption like edit wars, sockpuppetry and vandalism. ECP is only to be used if semi has proven to be insufficient and full protection is inappropriate MusikAnimal talk 00:46, 6 July 2016 (UTC)
I'm concerned because even outside the lines articles have very long time or no expiry (the example article Disgusting has no expiry which I think is problematic and will be going forward without strict rules). The irony of it being used on caste articles is not lost especially when applied indefinitely. I'd prefer a much stricter non-arbcom article time limit so as not to make the restriction a characteristic of the article or topic (those are ArbCom decisions or community decisions). Say a 3-month maximum. It should probably be treated as full-protection in terms of time in order to be egalitarian and avoid the problem of registered user castes. Also clarify that it is never appropriate in user or WP spaces (i.e. admins who semi-protect their userspace should never escalate to EC protection, they should warn/block the registered account). EC is solving an admin resource issue rather than an article content quality issue and shouldn't reflect "not trusted enough yet" back on the editor. --DHeyward (talk) 08:24, 6 July 2016 (UTC)
Your example is an excellent one; This is a redirect that will not form a new article since it's merely a grammatical variation of the target article, so indefinite duration is not really inappropriate (though I would have gone with something more brief). We saw repeated vandalism from multiple confirmed users (blocks proved ineffective), so it was fully protected, but Yaris noticed ECP would do the job just fine so extended confirmed users can still add redirect sorting, or what have you. Next, one could conceivably have good reason to protect user pages and Wikipedia pages under ECP, for the same reasons we would in the mainspace. My userpage is actually fully protected. There was some disruption from way back when, but either way it's my userspace; it is not meant for collaboration. The exceptions are of course user talk pages (or any talk page for that matter) – rarely protected in any form. I don't know why admins would add ECP to their userspace but I see no harm in doing so if there's good reason. There is also no maximum duration for protection levels, including full protection, ECP will be no different. It's about good judgement and mostly common sense, and the same judgement will be applied with ECP, with added caution in situations where it is used over the less restrictive semi. If semi doesn't work and I protect under ECP for 2 days, 1 week, 1 month, 3 months, 6 months, 1 year, perhaps 2 years, and disruption still is out of hand, it's time for indefinite. It would have to be really bad for that to actually happen; like I said I think such scenarios will be few and far between. Most of the time it's just juvenile vandalism or BLP violations that require page protection, and semi takes care of that quite well. Anyway you are correct that this is an admin resource, precisely, just like any other tool in the toolbox. The only protection that really could be perceived as reflecting the trust of the user is template protection, since such pages are highly visible and changes will be widespread, e.g. we don't want a bunch of trial/error edits that break the template on 20,000 pages. If we're only looking at maybe 100 or so transclusions, the template might be a good candidate for ECP given we're only suffering from vandalism or edit warring from confirmed users. ECP allows extended confirmed users to still contribute to this otherwise not-so-high-risk template, which is a win-win, right? In a nutshell, semi/PC/ECP/full are just as you say admin resources to combat disruption, plain and simple, but revolve around our policy which purposefully reflects the spirit that a wiki is supposed to be open, and it's this mentality that admins are expected to have MusikAnimal talk 21:48, 6 July 2016 (UTC)

ECP should be treated exactly like Full Protection and further clarification on when to use is needed.[edit]

The current wording for the time limit clarification is "protection does not differ from semi or other forms of protection." But the semi and full protection are applied very differently, that is, semi protection tends to be longer while full protection is much shorter. I would ask the ECP to be treated exactly as the full protection, and given the cautious tone of most people who voted the option C, I think that it could be the consensus. I should also like the wording to be clearly state when it's appropriate and when is not. For example, if there is a conflict with two sides, one EC the other not, ECP should not be used as a means to silence the non-EC editors. Because that will in effect topic ban the one side of the discussion regardless of the behaviors of the individuals. Currently admins have to assess the situation to see exactly which editors are being disruptive, they don't ban all inexperienced editors indiscriminately. Using this protection, in effect bans every good faith non-EC editor working on that area even if they are not disruptive, while allowing any EC editor who is disruptive but not enough to warrant a ban yet. Darwinian Ape talk 22:47, 7 July 2016 (UTC)

Treating ECP as a substitute for Full Protection for vandalism is why I support option C: full protection for vandalism rewards trolls who want articles locked and punishes all non-admin editors. And if an article has a lot of new editors who want to make changes, using ECP instead of full protection allows more editors to carry out edit requests, reducing the amount of time before someone can carry out those changes. Ian.thomson (talk) 17:04, 22 July 2016 (UTC)
My fear is that, in time, there will be as many ECP articles as semi articles, which will impact the project severely. The current proposal says it would be used against "any form of disruption" Also the duration is said to be like semi or full protection. I think the option C should be amended to state exactly which kind of circumstances it is appropriate rather than giving a general description like "to combat any form of disruption." and caution admins never to place indefinite ECP on articles. I've missed this reply, apologies for the late response. Darwinian Ape talk 04:07, 25 July 2016 (UTC)
A significant number of articles ending up under ECP would only mean that semi protection has failed anyway ("given that semi-protection has proven to be ineffective"). Under a more conservative interpretation of option C (read as "only use this if semi has failed, i.e. instead of full protection"), then it's just a replacement for full protection in cases of heavy vandalism or where all editors involved are not extended confirmed, and like full protection would always be temporary. The problematic examples you've listed elsewhere (e.g. applying ECP in a content dispute when one party is extended confirmed and the other isn't) would be obvious misuse of admin tools (like semi protecting an article when one party is autoconfirmed and the other isn't). That situation isn't an argument for getting rid of semi protection, is it? Ian.thomson (talk) 14:16, 26 July 2016 (UTC)
You say it will be, like full protection, always temporary. That's great, can we write that down clearly in the proposal so as to avoid any future misunderstandings? It would also be helpful to note that it's not appropriate to use ECP in content disputes, just to be on the safe side. Currently the wording of proposal C is that it can be used against any kind of disruption, which includes content disputes gone wild. I still don't think ECP is a good idea, but at least we can minimize the damage done by it this way. Darwinian Ape talk 02:40, 28 July 2016 (UTC)

Removal[edit]

This may have been answered above but could someone clarify how extended protections are removed? Do they require a consensus at AN or can it be done at the discretion of an administrator? Or is it cannot be removed until it's time limit has expired and what about in the case whereby it has been applied indefinitely? Thanks, Mkdwtalk 15:46, 6 July 2016 (UTC)

Given the expectation that Admin levied ECP, except ArbCom authorised ECP, would be time limited, it would be removed at the end of the time limit. Alternatively, I (taking a punt here) expect that requests for removal can be made to WP:RFPP or, failing that, WP:AN. Blackmane (talk) 15:55, 6 July 2016 (UTC)
Yes, non-ArbCom usage of ECP works like any other protection level and can be removed at admin discretion, requested at RFPP, or simply expire MusikAnimal talk 20:45, 6 July 2016 (UTC)

Option C: Finding or proviso?[edit]

Option C would allow 30/500 limitation, "given that semi-protection has proven to be ineffective". As written, this is a general finding that semi-protection is not effective. Is that the intended meaning, or does the proponent mean for it to be a proviso, so that if semi-protection has been tried in a particular case, and is found to be ineffective, then 30/500 limitation may be imposed? The present language grants unlimited and arbitrary power to impose 30/500 limitation wherever semi-protection might otherwise apply. Is this what the proponent and supporters want? If not, and the language is intended as a proviso, then it should be rewritten, substituting "if" or "where" for "given that". J. D. Crutchfield | Talk 16:21, 7 July 2016 (UTC)

Excellent point. While I still prefer Option A myself, I'd feel better about C if we agree that semi-protection and/or pending changes be tried first. StevenJ81 (talk) 16:53, 7 July 2016 (UTC)
We don't necessarily need to try semi first. If I look at a revision history and see that there are numerous confirmed users causing disruption, I know that semi won't be effective. That is proven purely by the edit counts of the abusers. If we see that disruption is from unconfirmed users, no admin is going to jump to ECP knowing semi will work just fine. There may however be a scenario where semi was deemed appropriate at first, and then the numerous socks or what have you waited till they became confirmed to continue disrupting. In that case the protection might be elevated to ECP. The decision to use ECP over semi of course also involves other considerations: Will blocking the users be effective? Is there an edit filter that could be tweaked? This is the normal process and having ECP does not change that. It's about judgement and carrying out the most effective preventive measure that has the least amount of collateral damage. I'm sorry this unclear to users who are less familiar with the administrative process, but I don't think we need to spell it out because frankly that's the philosophy ingrained in a wiki and a new level of protection is not going to change our core values MusikAnimal talk 20:15, 7 July 2016 (UTC)
In that case, why bother with a written policy at all? Option C pretends to establish some kind of standard, but it really just authorizes administrators to do whatever they think is best with the power placed in their hands. J. D. Crutchfield | Talk 20:51, 7 July 2016 (UTC)
Just today I saw an RFPP request for several pages that are being disrupted by a sockfarm of users that will all be autoconfirmed in the next 72 hours. That's one example of the kind of thing we're trying to stop, and that's how ECP will be useful to us. As administrators, we take the whole 'encyclopedia anyone can edit' thing seriously. We do not want to stop IP editing, and we do not want to discourage new editors. But there are an increasing number of cases of sockpuppetry and disruption where ECP could help us. We are experienced at this, and we understand how long and what type of protection is best. Please assume good faith in the admin corps. We really are here to help the encyclopedia, and we want the best for the project and the movement. Katietalk 21:05, 7 July 2016 (UTC)
Administrators already have the power to fully protect the article, which is far stronger a protection level than semi or ECP; any "if-then-else" or "if-and-only-if" approach is overly restrictive. Admins who regularly patrol RFPP and are experienced in applying protection should be, by default, given the benefit of the doubt that they will assess the situation and do their own due diligence before protecting an article. The addition of the community review requirement is to ensure there is oversight of their actions, since ultimately, admins are answerable to the community. Blackmane (talk) 02:59, 8 July 2016 (UTC)
Why not rewrite this as "given that the disruption is caused by autoconfirmed users"? This requires that semi-protection has proven ineffective but also allows for the edge case where the disruption is being caused by users which semi wouldn't work on. It doesn't make sense to require the step of semi-protecting an article where the accounts being used to edit it wouldn't be affected by that protection level. ~ Rob13Talk 03:16, 8 July 2016 (UTC)

Content disputes[edit]

I would hope this would be incredibly obvious to all admins, but can we include text in Option C indicating that extended confirmed protection is never appropriate in response to a content dispute where one side is extended confirmed and the other is not? Full protection "works" in response to edit warring because it forces discussion. It would be horribly inappropriate to lock one side out of the page as a substitute for discussion. I'm not talking about abuse from an involved admin. I'm talking about an admin who responds to an RFPP request or AN3 report and may be tempted to try the new lower protection level before full protection without considering the ramifications. This is the main reason I'm not supporting Option C as written. ~ Rob13Talk 03:20, 8 July 2016 (UTC)

It is obvious to admins, particularly those of us who regularly work RFPP and AIV, that semi-protection is never appropriate in a content dispute when one is not autoconfirmed and the other is not. This is no different, and it's already written into WP:PP. Almost every day there's a request for protection from someone who wants their 'side' to prevail in an content dispute with an IP while disguising it as an attempt to control disruption, and we always have to be sure we're not locking out someone who has a real problem with content. If admins understand the protection policy – and we do – there's no need to add your text. Katietalk 10:25, 8 July 2016 (UTC)
The place it's written into the protection policy is under the guidance for WP:SEMI, though. Does it not make sense to provide similar guidance for 30/500? Alternatively, the existing guidance could be relocated somewhere that isn't specific to only one protection level. This isn't only applicable to the admins protecting pages, but also to newer editors who seek to understand the protection policy and how it's applied. ~ Rob13Talk 18:45, 8 July 2016 (UTC)
I would boldly change WP:BLUELOCK to add the same text as in the semi subsection, but since we haven't finished this RFC yet it doesn't make any sense to do it. Honestly, though, this RFC was open to suggestions and the draft was open and advertised for editing for almost a month before I published it. Over 100 editors have weighed in on the options given. We cannot keep amending it now and expect any kind of consensus. If Option C passes, I give you my word that I will add that text to BLUELOCK. Katietalk 18:59, 8 July 2016 (UTC)
That's perfectly fine. I agree that boldly adding this would be appropriate. I'm just trying to avoid the almost inevitable cry of "But Option C said 'edit wars'!" in a month. I did participate somewhat at the village pump thread, but that language was introduced on June 30 when I was on vacation. ~ Rob13Talk 19:13, 8 July 2016 (UTC)

PC2 protection[edit]

Someone above (Dps04) made a good point: Why is it that editors are overwhelmingly approving unrestricted use for this "intermediate" protection level, but yet rejected the also intermediate PC2 for reasons of "bureaucracy and hierarchy"? Even more remarkably, PC2 was weaker, to a certain extent. With PC, changes are simply reviewed and not blocked outright. But ECP is hard protection—editing is completely disallowed for those who have less than 500/30. What is the reason for this conflict? Could it be that people voting here are not concerned because they know that ECP will not affect them due to their long tenures and high edit counts? Biblio (talk) WikiProject Reforming Wikipedia. 20:16, 9 July 2016 (UTC)

I fully support PC2, but as I see it, ECP is currently the path of least resistance. We've not even established that PC2 should exist yet, and that's not necessarily a trivial thing. I just checked, and one of the current pending changes reviewers isn't yet extended confirmed. It's Widr's alternate account Rdiw, to be fair, but what even happens from a technical standpoint when that occurs? Can the reviewer review edits but not make them? ~ Rob13Talk 20:40, 9 July 2016 (UTC)
  • I didn't participate in the PC2 discussions because they were during a health break for me; I'm on the fence about it in concept, and I can see some practical difficulties with it as we're set up now. Rob correctly points out one of them. The biggest one to me, though, is that if we enable PC2 we're giving the reviewers much more control over content, and to some that sets up an additional hierarchy of users to which Biblioworm referred. An edit by an established user without the reviewer user right, even one with 100K edits, would have to be approved by another established user on an edit-by-edit basis. It sets the reviewers apart from other users, and that rankles some people that might not be so rankled about ECP. We're also not currently granting the reviewer user right based on PC2 criteria – we're doing it based on countervandalism history and experience, and that would need to change if PC2 were implemented. This isn't the place to rehash the PC2 discussion, though. It's been two years since the last well-publicized RFC on the subject, so when this is over, if someone wants to propose it again, maybe it's time. (Not going to be me, though. I'm RFC'd out for a while.) Katietalk 21:48, 9 July 2016 (UTC)
  • The biggest [problem] to me, though, is that if we enable PC2 we're giving the reviewers much more control over content. ... An edit by an established user...would have to be approved. ... [T]hat rankles some people that might not be so rankled about ECP. That is exactly my point. Experienced editors who habitually vote in RfCs would naturally be much more inclined to support this because it has no effect on them. A good deal of experienced editors had a personal stake in opposing PC2, because it would subject their edits to review. However, the fact is that they have absolutely no stake in whether this is implemented, because ECP will not affect them in the least. They will still be able to freely edit all ECP-protected articles, even though new users are locked out. I find this very concerning. Note that my object here is not to revive the PC2 discussion, but rather to use it a contrasting example. Biblio (talk) WikiProject Reforming Wikipedia. 22:03, 9 July 2016 (UTC)
  • PC2 is complicated to administer, and somewhat confusing. (so is PC1, but the combination would make them yet more confusing). EPC has the advantage of being self-operating and immediately understandable. DGG ( talk ) 22:18, 23 July 2016 (UTC)
  • As BU Rob13, I support both and the community is happy to accept 30/500 thanks to GamerGate. PC2 makes more sense as it enables contributors to limit content disputes but there's far more trust in the admin corps than there is in the reviewers. Chris Troutman (talk) 00:27, 2 August 2016 (UTC)
  • I've actually reviewed PC2 more recently and don't think I'd support it anymore in its current form. I was unclear on what exactly PC2 was when I previously gave my opinion, and I'm now concerned that the reviewer user right wasn't granted to reviewers with the intent for them to serve as basically respondents to fully-protected edit requests. I'd only support PC2 if we separated out the reviewer PC1 and reviewer PC2 user rights (with the PC2 needing to be requested by current reviewers). Specifically, any editor with a history of edit warring should not be able to review PC2 revisions for obvious reasons, but we've never had cause to heavily consider that when granting that flag up until now. ~ Rob13Talk 00:42, 2 August 2016 (UTC)
As far as I'm concerned, PC2 + semi should be available right now as an option for pages subject to extreme disruption. And yet... here we are. Even if PC2 were available, however, 30/500 would be valuable as another tool in the chest. Pages that would otherwise be subject to full protection might benefit from PC2 + 30/500 simultaneously. DavidLeighEllis (talk) 02:44, 9 August 2016 (UTC)
By the way, extended full protection of articles due to extreme disruption is not a hypothetical. Right now, we have List of social networking websites, Syed Mohsin Nawab Rizvi, and Mass killings under Communist regimes under indefinite full protection, with no apparent end in sight. These are exactly the sort of situations in which PC2 + 30/500 might prove useful. DavidLeighEllis (talk) 02:54, 9 August 2016 (UTC)

Bots (bug)[edit]

This is a tech bug, following up on VPT

(c.f. Wikipedia:Village_pump_(technical)#My_bot_can.27t_edit_extended_protected_pages ) If we expand this permission for more general use, it may also be appropriate to bundle the access permission to the existing bot usergroup. Bots may already be manually flagged if their operator qualifies, but do not autopromote. Any thoughts? — xaosflux Talk 21:29, 10 July 2016 (UTC)

The permission is already bundled to the bot group per Special:ListGroupRights.Jo-Jo Eumerus (talk, contributions) 21:33, 10 July 2016 (UTC)
Was just reverting this! Looks like a "bug", will follow up on VPT with phab ticket. — xaosflux Talk 21:34, 10 July 2016 (UTC)

Oppose extended confirmed protection policy[edit]

If anybody opposes extended confirmed protection policy, comment here.

  1. Oppose If this is necessary, then Wikipedia has failed. BorkBorkGoesTheCode (talk) 09:51, 9 July 2016 (UTC)
    @BorkBorkGoesTheCode: Prohibiting edits from users with less than 30 edits and 500 days tenure is a remedy passed by the Arbitration Committee for certain topic areas (notably WP:ARBPIA3#500/30) and is therefore beyond the remit of community consensus. For the most restrictive implementation measure of extended confirmed protection, I would support option A. Mz7 (talk) 15:12, 9 July 2016 (UTC)
    @Mz7: We could revoke its implementation as a level of protection, but not the restriction itself.Godsy(TALKCONT) 22:35, 9 July 2016 (UTC)
    One could as easily say that "if full protection is necessary, then Wikipedia has failed" -- yet judicious use of full protection has been with Wikipedia nearly since its inception. The small number of fully protected pages has not conferred major damage upon the openness of the project. DavidLeighEllis (talk) 04:19, 6 August 2016 (UTC)
  2. Oppose We have far too many rights for editing articles as it is. Don't add more complexity. --AmaryllisGardener talk 21:13, 9 July 2016 (UTC)
  3. Oppose. WP:CONEXCEPT or no CONEXCEPT, I will make it clear that I oppose this level of protection. In the end, it will become another means for the increase of stratification and administrative power, which I do not believe in. It simply is not ArbCom's business to be creating new classes of users by fiat. It's about time that editors read and apply this userbox. Biblio (talk) WikiProject Reforming Wikipedia. 22:16, 9 July 2016 (UTC)
  4. Oppose Obviously this will not make any difference, but I believe I must show my colours. Because I believe this kind of exclusionist protections and sanctions will be the downfall of Wikipedia, maybe not now but a few years from now... And I want to make my position clear. Darwinian Ape talk 03:42, 10 July 2016 (UTC)
  5. Oppose determinedly (refer back to my post under "Option A" and to what the few other opposers have said above). Judging by the responses to this RfC so far, obviously I don’t think my position will matter at this stage, but I must stand up for my convictions. Hftf (talk) 04:34, 10 July 2016 (UTC)
  6. Oppose per the reasons I already stated. Mario Castelán Castro (talk) 03:08, 11 July 2016 (UTC).
  7. Oppose Per my reasons when supporting Option A MediaKill13 (talk) 08:16, 11 July 2016 (UTC)
  8. Strongly Oppose Apparently my "indented" opposes above mean that arbcom has decided on the issue. It is beyond our humble ability to protest. The man behind the curtain has decided. Tell me folks, when did we decide to accept arbitrary rules? Gosh...."we" voted for them? Its kinda like the old joke: they have decided what you are...they are now only discussing your price. Juan Riley (talk) 01:43, 23 July 2016 (UTC)
  9. Mild oppose I've been a Wikipedia editor for 10 years now and haven't reached 500 edits yet. On the other hand, I have yet to attempt to edit a protected page and been denied, so I don't think it is that harmful as is; I don't object to it staying as currently, but I do feel as though 500 edits is a lot. I've created a dozen or so pages, fixed a couple hundred typos and errors, added some sources, commented on some consensus discussions, and in 10 years I'm at 350 or so edits total. 500, really? Felisse (talk) 15:50, 27 July 2016 (UTC)

Option D, et al?[edit]

The Environment Created by Extended Confirmed[edit]

I mentioned this before, but I think it should be discussed more thoroughly.

The environment which the extended confirmed policy creates is highly toxic. It assumes bad faith for all potential editors and locks them out, not for lack of merit, but for an arbitrary edit count and a tenure, in turn the editors who are participating in an ECP area are much more willing to throw the AGF away. In part because of the most likely correct assumption that anyone willing to fulfill the requirements for ECP just to edit an article must have at the very least very passionate opinions about the article subject. I've already given an example for this exact attitude of assuming bad faith.

People are already discussing the ineffectiveness of 500/30 at the AE talk page with some editors assuming very bad faith. But you created this environment.Yes the autoconfirmed is easily gamed, and this protection is not, but who do you think you are barring more? Dispassionate new contributors, or the disruptive POV warriors who are willing to work their way to ECP? And by chance someone who is a good faith editor edits after becoming an ECP, he or she will be met with extreme failure to AGF because of this environment you are creating here. I ask all the Wikipedians who care about this experiment to reconsider. I am, humbly yours, Darwinian Ape talk 01:59, 14 July 2016 (UTC)

All ARBPIA articles fall under 30/500, but new accounts and IPs often edit in the area as most articles are not actually locked down under 30/500. I and other users only care to enforce 30/500 in the topic area for the worst editors and not at all for the casual editor. Under this system serious editors are no longer blocked by admins when they revert a wave of sockpuppets. This has dramatically reduced the effectiveness and thus number of sockpuppets, though these puppetmasters are now putting in 500 mostly minor edits and waiting 30days per account to again disrupt the encyclopedia. I think those accounts clearly owned by previously blocked editors who quickly pass 30/500 to disrupt the topic area should be blocked just as their previous accounts were. Sepsis II (talk) 02:43, 14 July 2016 (UTC)
You only care to enforce ECP for people you deem are "worst editors," don't get me wrong I don't assume you are pushing a POV and allowing only the editors who share your POV while reporting others, but you have to agree that it may be used as such and is a broken system to begin with. You in effect have an administrative power to choose who is productive and who is not. There is a reason for the distinction of involved admins. (This is unique to ARBPIA3 where the arbcom unwisely created a broad sanction which made it impossible to ECP every article this sanction applies, another of the many flaws of this new protection.) Secondly, as you just said, the puppetmasters are willing to create and game this new system too, which supports what I said that the only people who are being disallowed are the dispassionate new editors.
Right now the uniqueness of the ARBPIA3 allows you to permit the casual good faith editors because not all pages of I/P conflict is physically ECP'ed, that is assuming the established editors wont favor casual editors who support their POV. But it wont be the case for articles with ECP in place, which will only leave the sock masters who are patient enough to EC their way to the articles, and the occasional good faith editors who just passed 500/30 will be lumped together with these disruptive editors. Tell me what is the benefit of having this proteciton again? Darwinian Ape talk 03:27, 14 July 2016 (UTC)
If you had edited in the ARBPIA area you would have made thousands of reverts, filed hundreds of reports, been blocked by naive admins, and been called various racial slurs hundreds of times, due to socking. I wish you had been there years ago, then you would know. Sepsis II (talk) 15:20, 14 July 2016 (UTC)
I do not deny the frustrating nature of contributing in a contentious area, and sympathize with you even though I've never edited in that area. But this protection is fundamentally flawed and it's the antithesis of Wikipedia. Furthermore this protection, while it may reduce the socking, encourages the ownership of articles which is another big problem, at the end It is more trouble than it's worth. Darwinian Ape talk 17:18, 14 July 2016 (UTC)

This is a good example of the flaw inherent to the 30/500 system: https://en.wikipedia.org/w/index.php?title=User:HistoryWrite&oldid=702887766 It was posted at the Arbitration/Requests/Enforcement page by https://en.wikipedia.org/wiki/User:Malik_Shabazz. The full conversation is here: https://en.wikipedia.org/wiki/Wikipedia_talk:Arbitration/Requests/Enforcement#WP:ARBPIA3.23500.2F30_2 BorkBorkGoesTheCode (talk) 06:14, 14 July 2016 (UTC)

I hate the generalization that ECP makes. Editors are always going on about how "edit count doesn't matter", then come on RFCs and say another thing entirely. Compared to other editors, I've done rather poorly on the edit count basis, and a third of my edits are in user space. But my point is that if I decided to start inflating my edit count legitimately right now, I might be at 1500 edits at the end of the month. But I don't want to. And the Option C supporters are making the generalization that edit count shows how useful you are on Wikipedia. Yesterday I encountered an editor with more than 3,000 edits, with only around 200 in mainspace. His only interest seemed to be to get people to sign his guestbook to earn the {{User X}} Guestbook Barnstar. (Not to embarrass the editor, he has already been warned and has promised to change.) Is this what we want to encourage new editors to do to inflate their edit counts? Secondly, I think this will just serve to perpetrate a society where the elites only get more elite, and the rest sink into oblivion. When a non-EC editor spots an error on a blue-locked article, who's going to have to edit it? An EC editor. Which is going to inflate his/her edit count even more. In the future, should the community decide they want a 1-year 1000-edit restriction, the EC editor will benefit while the non-EC editor is locked out once again while he could have edited and overcome this restriction. MediaKill13 (talk) 06:27, 14 July 2016 (UTC)

I took a random sample of 20 (out of ~120) users who voted for Option C. The result: most accounts were several years old, about 30-40% claimed to have made several thousand edits, and a few were administrators. I'm afraid that the people who are voting for C are not representative of Wikipedia editors in general, especially since most people would be unlikely to vote on this page, let alone know about its existence.

It has been found that, although the majority of edits are performed by experienced users, the majority of bytes are written by inexperienced users. These editors lacking extended confirmation should not be penalized for the small minority of vandals. It is easier to revert vandalism than it is to write new content. Mooseandbruce1 (talk) 23:55, 19 July 2016 (UTC)

I would wager that many of those users you sampled would also be well experienced in, or personally exposed to, the disruption that led to the RFC. Might I consider you spend a month or two on WP:ANEW, WP:AIV, WP:RFPP, WP:ANI or WP:AN for a sample of the environment that necessitates protection of whatever level. The various entries at WP:LTA would also be enlightening. Blackmane (talk) 00:04, 20 July 2016 (UTC)


  • What about the environment that full protection for vandalism creates? It tells trolls "if you fuck with us enough, we'll crawl in our shells and not allow anyone except admins to edit." It tells non-admins "you can only edit these pages when (or if) an admin sees your edit request on the talk page." If we use ECP as a substitute for full protection for vandalism, it would reduce this. Using ECP against vandalism instead of full protection, any extended confirmed user would be able to carry out edit requests. Ian.thomson (talk) 17:10, 22 July 2016 (UTC)
    @Ian.thomson:Why would you use full protection against vandalism? Semi effectively deters any vandal. Since the vandalism is a blockable offense, even if the hypothetical vandal was determined enough to create new accounts(which would have to be auto-confirmed first) they would easily be dispatched. Only reason for this protection to be justified is if there is consistent disruption from sock puppet accounts who are not vandals but disruptive editors, even then you bar every new potential good faith editor just because some people are ban evading socks. Full protection is almost always is a result of content disputes that turn into edit wars, if you replace full protection with EC protection, you may be helping one side of the conflict or another, depending which side has EC editors more Darwinian Ape talk 05:17, 23 July 2016 (UTC)
Semi protection deters the common "can I really do this?" vandals, but it doesn't stop the sort of sockpuppeting vandals (those are not exclusive categories) you find at WP:LTA or during organized attacks (which do occur). This is why WP:FULLPROTECT does include vandalism (first, even). But with ECP for vandalism, then full protection would only be for content disputes (and the few other instances like generic image names). And please don't put words into my mouth, I said nothing about using ECP for content disputes. Ian.thomson (talk) 14:54, 23 July 2016 (UTC)
I didn't mean you specifically would use it as such, It was a general statement, and I apologize if that was not clear. You can't though, guarantee that the admins will not use it for content disputes, even if unintentionally, being lulled by the experienced editors. Darwinian Ape talk 22:44, 23 July 2016 (UTC)
Hence the requirement that use of ECP needs community review upon activation. Blackmane (talk) 04:52, 25 July 2016 (UTC)

Appeal to closer: delayed implementation and notification[edit]

Does extended confirmed protection work? A case study[edit]

On July 1, a discussion at ANI was closed with consensus to deploy 30/500 in response to the sockpuppetry of Никита-Родин-2002. Now that it's been "in action" for two weeks, we can start to take a look at whether it appears to be working.

In response to the initial use of this protection level, Talk:The Who discography shows various IPs used by Nikita requesting the addition of false information to the article (which is his typical MO). All of them have been declined, preventing active disruption to the article. Further, you can see him asking when the 30/500 protection will expire, which suggests he doesn't feel himself capable of vandalizing the article until it's gone. Having dealt with this sockmaster quite a bit before, I can never recall him making edit requests or requesting information about the expiry time on semi-protected articles; he just used sleeper accounts to get around the semi-protection without comment.

Nikita attempted to make a sleeper account to get around extended confirmed protection (Soundblack). His usual preferred method of getting around semi is to make 10 edits to his user page and then jump into vandalizing without warning, so that his sleeper isn't found before he can get to the semi-protected articles. Here, he made 115 edits to his userpage (which have now been deleted), apparently got bored, and made a single vandalizing edit to an unprotected page ([1]) which got him blocked. No similar account has been found since then. I've been monitoring new user pages to check for any that have an unusual number of edits, and nothing has popped up.

Multiple CU checks have been run on Nikita since 30/500 was deployed. None of them have uncovered accounts that appear to be successfully making their way toward extended confirmed status.

All of this seems to indicate that 30/500 is capable of working against sockpuppetry. Since this is the first time (to my knowledge) the community has authorized 30/500 outside of arbitration enforcement, this might be a useful case study to inform the positions of editors on how we should use 30/500 going forward. ~ Rob13Talk 18:32, 17 July 2016 (UTC)

Why would you consider that as a case study when we have the patient zero, the infamous Gamergate controversy article. Let's just look at the first sentence of the lede:
The Gamergate controversy concerns issues of sexism and progressivism in video game culture, stemming from a harassment campaign conducted primarily through the use of the Twitter hashtag #GamerGate. Gamergate is used as a blanket term for the controversy, the harassment campaign and actions of those participating in it, and the loosely organized movement that emerged from the hashtag.
What a marvelous sentence! So many buzz words, you have to read it several times to even make sense of it... And it gets no better in article body. This sanction made the Gamergate article a space owned by a handful of editors, scaring off admins and editors alike.(Latest attempt, I believe, was to the admin Wordsmith for daring to moderate) Not to mention some article regulars made several visits to the AE since the implementation of the rule. Let's be real, will it be effective in some articles where there is an insistent sock or socks who make disruptive edits? Yes. Will it be effective against POV warriors and SPA's who are willing to put in the time and reach 500/30? Nope.(even if they are sock accounts of banned users.) Will it make it easy for articles to be owned by the editors? Hell yes. Will it discourage the new editors and, with the widespread usage, further decrease the already dwindling number of new editors? Absolutely. One more thing, this was supposed to be a consensus rather than a majority rule. And I see a lot of editors casting votes, but not a lot of arguments for the pros and cons of this protection. I really wish Wikipedia was a place where its policies were actually followed... Darwinian Ape talk 04:54, 19 July 2016 (UTC)
In the context of how ECP is being looked at in this RFC, Nikita is patient zero. They were the first one against which ECP was deployed per community consensus rather than by Arbcom. ECP on Gamergate is under Arbcom jurisdiction so should be considered in a separate context. You ask: Will it be effective against POV warriors and SPA's who are willing to put in the time and reach 500/30? It may not stop them, but it will certainly slow them down and invariably most of these editors have such a slavish adherence to their M.O. that by the time they reach EC status, they will have let slip who they are and will be dealt with.
Along the same lines, you could also argue that semi protect could have the same impact, and yet the regular limited duration deployment has not proven to be detrimental in any way except to drive off the disruptive editor who has a short attention span. ECP is to drive off the somewhat more determined, but no less disruptive/destructive editor. Blackmane (talk) 05:56, 19 July 2016 (UTC)
I also want to point out that I'm not arguing with you because I think you're wrong. In fact, I think you raise excellent points and worthy of debate. Blackmane (talk) 06:19, 19 July 2016 (UTC)
Thank you, I raise these issues because I see this protection to be detrimental to Wikipedia, especially in the long run. And of course I know everyone who comment on this RFC do so with the best intentions.
Community consensus or not, this protection has been in place on Gamergate controversy article for more than a year. If we are to discuss the long term effects of this protection, that's your patient zero. And I think it's a prime example of what an ECP'ed article will look like give or take, depending on the vexatiousness of the topic. The problem with the edit-count based privileges is that the edit count has no bearing on the editor quality. The auto-confirmed protection works well, because it is not too much of a burden for good faith editors while it is an inconvenience for disruptive editors.(especially effective against vandals since vandalism is quite a blockable offense) But this one asks too much of a casual contributor in good faith. I don't deny that it can, in some instances, prevent persistent disruption. but in my opinion, the cost far outweighs the benefits. Darwinian Ape talk 07:05, 19 July 2016 (UTC)
The GamerGate article is a good example. Before 30/500 was applied, semi-protection was working. In the two months leading up to the restriction, very few editors who would have failed that restriction were taking part, there was no revdel, and those editors who didn't meet 50/300 were either not being disruptive or were being managed easily by existing rules. Since it has been applied it has effectively disenfranchised any new editor from taking part in the discussion without considerable work. Given that there was no evidence provided that there was a problem that semi-protection wasn't already handling, we've managed to prevent new editors from taking part in discussion with no significant sign of reduced disruption.
Looking at The Who discography, it seems that the important distinction is that the talk page is not under 30/500, only the article. That allows people to request changes even if they haven't met the restriction. In that sense it is working. However, I also note that semi was only applied in June, and there were three minor vandalism attacks since then. Although there have been no edits to the article since 30/500 was applied, we've got four edit requests that needed to be turned down. In terms of stopping disruption, 30/500 seems only mildly more effective than semi was. The long term effect may be better, though, so I guess we'll see what happens over time, as 10 days is a bit short to evaluate the result. - Bilby (talk) 08:04, 19 July 2016 (UTC)

May I also add that this "per community consensus" case study ECP's duration is set to indefinite, much like any other ECP'ed article we have.(which we all know likely to be infinite.) Gives confidence that it will be used with serious discretion and for short periods of time... Darwinian Ape talk 09:44, 19 July 2016 (UTC)

And thus, we have the RFC. For those non-Arbcom EC protected articles/pages, I expect that there will be no grandfathering of protection levels and that those pages will have protection levels reduced or readjusted to be in line with the outcomes of the RFC. Blackmane (talk) 23:42, 19 July 2016 (UTC)
But the current wording states that the duration will be no different than semi or full protection, that it will be proportional to the disruption. In reality, it will most likely be used like semi protection level 2, and we know how many indefinitely semi protected articles we have. I recommended above in the discussion that the wording should be changed to state that duration should be set not like semi, but like the full protection which is almost always limited, but it did not get any traction. Darwinian Ape talk 04:08, 20 July 2016 (UTC)
This is a Twinkle mistake, most likely. Currently, Twinkle is set to only allow ECP with "Arbitration enforcement" as the reason and "indefinite" as the length. Pinging NeilN, the protecting admin, who I'm almost certain would consider lowering the length to something in the realm of 3–6 months. Nikita is absurdly persistent, so the lengthy protection period is justified, but indefinite is a bit much. I doubt indefinite 30/500 was intentional here. ~ Rob13Talk 06:26, 20 July 2016 (UTC)
Reduced to six months. This discussion should also determine if these kinds of protects fall under arbitration enforcement. I've gotten a couple responses indicating that they don't, However WP:ECP states that "The Arbitration Committee has authorized use on articles reasonably construed as belonging to the Arab-Israeli conflict and as an arbitration enforcement. In its use as an arbitration enforcement, extended confirmed protection may only be applied in response to persistent sockpuppetry or continued use of new, disruptive accounts where other methods (such as semi protection) have not controlled the disruption. This provision does not apply to a page or topic area which has been placed under 30/500 protection by the Arbitration Committee." I've been taking this to mean that 30/500 is implicitly an arb enforcement tool. --NeilN talk to me 07:59, 20 July 2016 (UTC)
@Opabinia regalis: Mind clarifying the above? That's not the way I read that passage, but it does seem to be a valid reading. ~ Rob13Talk 13:51, 20 July 2016 (UTC)
@BU Rob13 and NeilN: It was implemented as a result of the ARBPIA3 remedy, so it did originate as an arb enforcement tool, but I think we've posted up, down, and sideways now that the standards laid out a couple of months ago were for AE/DS use and it's up to the community to decide what else to use it for (if anything). Given how often this comes up, it might be worth tweaking the policy text - but I guess it'll be edited to reflect the result of this RfC eventually anyway... Opabinia regalis (talk) 00:15, 21 July 2016 (UTC)
I highlight this case study because I see the value of 30/500 being combating sockpuppetry. This is the first time it has been deployed for that specific purpose, bar none. In a sense, 30/500 is being used currently in the area it is least effective – contentious topic areas where civil POV pushers have not been adequately dealt with by the community or ArbCom. 30/500 will never fix issues in those topic areas (although they may lessen them). Note also that I'm supporting Option B, not Option C, as I can't think of any appropriate use outside of sockpuppetry. If Option C passes, I'll be scrutinizing such applications of 30/500 very closely. ~ Rob13Talk 06:26, 20 July 2016 (UTC)
It was brought up by Bilby (is that how you ping? I'll consider that a ping because I have no clue how to wiki) but it's a great point that it deserves to be mentioned again. The talk page is NOT under 20/500, only the article. If edits can be requested and discussion is encouraged to new users who don't fit 30/500 they can do so. Sethyre (talk) 19:09, 20 July 2016 (UTC)
Your ping will work, as does this: @Sethyre: I agree completely that talk pages of ECP-protected articles should be left unprotected, so 30/500 doesn't completely lock out those who don't yet pass the criteria, and I imagine basically everyone in this RfC, whichever option they supported, would agree. (For what it's worth, I think the protection of Talk:Gamergate controversy is an absolute disgrace, but that's not under the community's control.) However, while this reassures me slightly, I still don't think it's a very nice compromise. If a newbie comes across an ECP-protected article and wants to edit it, all they'll see is that the system won't let them make a normal edit, and they'll give up in frustration. Now, 30/500 locks out quite a lot of people who I wouldn't call 'newbies', and who I imagine are quite competent in making a protected edit request, but a lot of good faith newbies will simply not know how to make an edit request, or have the patience to make one, so even if there are technically ways for anyone to get their constructive edit onto a protected page, what any form of protection (even semi) does in reality is lock out most people who fail the criteria completely. Bilorv(talk)(c)(e) 20:56, 20 July 2016 (UTC)
Why are the talk pages being placed under the 30/500 restriction. That to me seems quite foolish. It prevents discussion on the article for many editors absolutely. If the article needs protection to prevent vandalism, POV pushing or what have you then that is fine. But to lock editors out of the discussions on the article's talk page as well, that's too much. I can hardly think of any reason to ever do so. Mr rnddude (talk) 09:56, 21 July 2016 (UTC)
Mr rnddude there are currently six pages this is applied to, all claiming to be protected under the authority of arbcom sanctions. You may contact the protecting administrator to point out the specific authority for any one you are concerned with. — xaosflux Talk 11:24, 21 July 2016 (UTC)
Xaosflux I would be concerned with all of them. The 30/500 sanction on talk pages makes it difficult for many (possibly most) editors to actually contribute to those pages in any meaningful way. Like I said, 30/500 on the article page I can understand. But, for the talk page what does this achieve (other than to obstruct improvement)? In some circumstances I can understand temporarily putting this protection in place, but, all six of these currently have no expiry date set (in other words are indefinitely protected). I also find it interesting that all six of these 30/500 protections were set within two weeks of the first (6th to 18th April 2016). Mr rnddude (talk) 11:36, 21 July 2016 (UTC)
They all refer to a very broad arbcom remedy that is not just for articles but "any page", so it is really beyond the "community use" that is being discussed in this RfC. Please note, editors may request edits to such pages here:Wikipedia:Requests_for_page_protection#Current_requests_for_edits_to_a_protected_page for these pages - which is where the "submit an edit request" will land if clicked. — xaosflux Talk 11:48, 21 July 2016 (UTC)
Huh, sorry, I had been entirely unaware that this existed. I don't need to use it (am extended confirmed). It's not exactly the most user friendly system but at least it exists. Mr rnddude (talk) 11:54, 21 July 2016 (UTC)
The difficulty is that allows people to suggest changes, but generally those are turned down quickly. To be involved in the discussion about the direction of the article you need access to the talk page. We're going to see a lot of cases of 30/500 being applied to talk pages, which is something I tend to strongly disagree with. - Bilby (talk) 01:39, 22 July 2016 (UTC)

Observation[edit]

For the hell of it I want to point out that as an admin I have no interest whatsoever in using a new level of protection, so this is going to go right along side pending changes and super-protect as a new tool I neither wanted nor plan to use. Keep that in mind: you can role it out all you want, but if I won't use it then it is essentially no more effective towards improve the encyclopedia as new coke was for improving Coca-Cola's profit. TomStar81 (Talk) 10:05, 22 July 2016 (UTC)

  • But if other admins use it, what you decide to do isn't relevant. Peter coxhead (talk) 10:25, 22 July 2016 (UTC)
  • And if option C goes through, I don't plan on ever using full protection for vandalism. Ian.thomson (talk) 17:14, 22 July 2016 (UTC)
    If option C passes (which is looks like it's on track to), there really needs to be some guidance for admins that ECP should only be used in cases where the page would've been fully protected if ECP didn't exist, and for a duration equivalent to how long the page would've had full protection. Otherwise, despite the best intentions of admins like you, I can see it greatly increasing the number of pages that a majority of Wikipedia editors are unable to edit. --Ahecht (TALK
    PAGE
    ) 15:22, 5 August 2016 (UTC)
    Agreed. Mlpearc (open channel) 15:58, 5 August 2016 (UTC)
    I have to disagree. We also have to consider the class of pages where we previously wouldn't have used full protection but wouldn't have been able to control the disruption either. This is mostly true with sockpuppetry. It's obviously not customary to fully protect articles for long periods of time when combating long-term sneaky sockpuppetry, but it's also not ideal to leave them unprotected. Long-term blue locks can be a solution when all else fails. I fail to think of any situation usually requiring full protection where 30/500 would be appropriate. ~ Rob13Talk 17:04, 5 August 2016 (UTC)
  • This is a silly argument; if you choose to use a protection level sub-optimally, that's your choice, but that doesn't mean it's ineffective for improving the encyclopedia. That's like throwing away a bar of gold and using that as your proof that gold isn't worth anything. ~ Rob13Talk 19:27, 22 July 2016 (UTC)
  • I join TomStar in noting that I will never use this level of protection. ArbCom instituted this new "extended confirmed" usergroup by fiat. Seeing that unlimited admin use will now become official policy, new users will be increasingly shut out as it is applied in a liberal, over-the-counter manner to any vandalized page. Our current editor retention is dismal, and the statistics show it, but changes continue to be passed which simply make the environment even more stratified and hostile than it is already. Biblio (talk) WikiProject Reforming Wikipedia. 21:24, 25 July 2016 (UTC)
    On a point of fact, false. ArbCom applied the 30/500 restriction to the ARBPIA zone. It was a community decision to implement this using a usergroup and protection level. BethNaught (talk) 21:30, 25 July 2016 (UTC)
    I already knew that ArbCom did not create the technical protection level. But ArbCom basically created the new class of non-30/500 users, and knowing how things work around here it was inevitable that it would eventually be made a technical protection level (although it shouldn't have been, because as we see now its usage is being rapidly expanded beyond the original purpose). Biblio (talk) WikiProject Reforming Wikipedia. 21:36, 25 July 2016 (UTC)

AN notification[edit]

Option C, which is (unfortunately) the option being approved overwhelmingly, actually requires that a notice be posted to AN for review every time an article is protected with EPC. We must keep to this requirement and set up a mechanism to post these notifications—it is necessary that at least some degree of accountability be maintained here. Could we have a bot (such as Cyberbot) take on this function? Biblio (talk) WikiProject Reforming Wikipedia. 20:26, 30 July 2016 (UTC)

We could transclude User:MusikBot/ECPMonitor/Report. An individual section heading for each new protection will be overkill, I think, but I can make that happen too of we really want MusikAnimal talk 21:07, 30 July 2016 (UTC)
@MusikAnimal: As a start, individual sections would be helpful to give ECP notifications some visibility. In time, this can then be migrated into a transclusion of the report. I don't know if others would want a report at the top of the noticeboard right from the start. Perhaps by then a new noticeboard would be created to furnish ECP with a home and individual cases can then be pulled from there to AN for review. Blackmane (talk) 07:00, 1 August 2016 (UTC)
I envision the report being at the top of the noticeboard, which should fit nicely next to the table of contents which is typically very long. This to me would be quite visible. The idea I think is to start a discussion when someone disputes the use of ECP. At the rate we're seeing it being applied now, we're going to see a lot of headings with little or no discussion, cluttering the noticeboard MusikAnimal talk 20:36, 1 August 2016 (UTC)
Are you envisioning something like the WP:CENT notifications list? Blackmane (talk) 05:47, 3 August 2016 (UTC)
I don't like the idea of an additional noticeboard. We already have so many freaking noticeboards that they're losing their effectiveness. Eyes are glazing over at the sheer number of noticeboards one needs to watch. I really think transclusion of MusikBot's report in a section of AN will be fine. If someone has an issue, they can then raise it with the individual admin (which should always be the first step, as some of these are turning out to be simple errors – I almost did it myself the other day) or in its own AN section. Katietalk 13:31, 3 August 2016 (UTC)
I also think that transcluding MusikBot's report is the best approach. Katie is absolutely right that talking to the admin should always be step #1. Only when that fails to produce a satisfactory resolution should we start an endorse vs. overturn discussion at WP:AN. Mz7 (talk) 21:04, 6 August 2016 (UTC)
Important note: Bots, and their edits, are the responsibility of an editor. I do think that User:MusikBot/ECPMonitor/Report is very useful (watchlisted!) - however any bot operator can freely stop their bot any time, for any (or no) reason. If consensus is that a posting must be placed on every use, - expect this step will be missed, especially if anyone is used to someone else's bot doing it for them. — xaosflux Talk 02:40, 7 August 2016 (UTC)
See also the talk page discussion. At the least, I think we've agreed that we don't need to automate posting new sections. Admins may be expected to manually make a post for any applications of ECP that could be debatable (as opposed to ArbCom-related matters), but I still think the transcluding the bot report will suffice. And rest assured I won't kill this bot task :) If I do or if Tool Labs blows up you can still rely on the link the header of the report that brings you to Special:ProtectedPages. That lists all protection chronologically. The bot report merely allows you to "watch" for changes and transclude the page MusikAnimal talk 16:16, 8 August 2016 (UTC)

User requests[edit]

We should specify that users who meet the 30/500 criteria can have any page in their userspace except their talkpage placed under extended confirmed protection upon request as an anti-vandalism/sockpuppetry/defamation measure. The value in allowing new users to edit another editor's userpage is extremely low. Even if otherwise required, AN posting should not be necessary in this situation. DavidLeighEllis (talk) 02:34, 9 August 2016 (UTC)

I consider myself one of the loudest voices in opposition to ECP, but I have no objection to DavidLeighEllis' sensible proposal above. Altamel (talk) 03:57, 9 August 2016 (UTC)
I supported option A, but I agree that userspace should be an exception and anyone [who meets the ECP criteria] should be able to request ECP within their own userspace. Bilorv(talk)(c)(e) 09:39, 9 August 2016 (UTC)
I also supported option A, but an exception for user space makes good sense, particularly when we note that administrators (including me) can and do fully protect their own user spaces without controversy. BethNaught (talk) 09:55, 9 August 2016 (UTC)
If this userspace suggestion becomes policy, good opportunity to mention it at WP:UPROT. — Andy W. (talk ·ctb) 20:44, 9 August 2016 (UTC)

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