Wikipedia talk:Requests for comment/Extended confirmed protection policy

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

Please refer to the RfC itself for closing commentary. HJ Mitchell | Penny for your thoughts? 17:20, 12 August 2016 (UTC)[reply]

Option B vs C

@Mz7, KrakatoaKatie, and SlimVirgin: Hope you don't mind the ping; I reworded option A to say topics authorized

Option B says ...continued use of new, disruptive accounts where other methods (such as semi protection) have not controlled the disruption and C says ...when other protection measures have failed and full protection would be inappropriate. These are essentially the same. I cannot envision a scenario where semi and full protection are not effective or viable options, but disruption does not pertain to "new, disruptive accounts". If they are old accounts we simply block them. It's also unclear if option B includes the criteria of option A (ArbCom authorization). I didn't want to flat out change what you have, but in short this is what I'm thinking:

Option A – Allow admins to use on topics authorized by ArbCom (what it is now)
Option B – Allow admins to use on topics authorized by ArbCom and for sockpuppetry where semi has proven to be ineffective. WP:AN notification required unless the topic is authorized by ArbCom
Option C – Allow admins to use in response to any form of disruption (vandalism, edit wars, etc.) on any topic, given semi has proven to be ineffective. WP:AN notification required unless the topic is authorized by ArbCom

I think some wording similar to this would make it clear the linear sequence of Option A to C. A is no change, B is what we have now except also for sockpuppetry, and C is for general use with common sense, like any protection level. When the time comes to evaluate consensus, you can probably assume !voters for C are also in favour of B, unless stated otherwise — MusikAnimal ^talk 06:06, 30 June 2016 (UTC)[reply]

@MusikAnimal: Thanks - I was having writer's block there. Unless Sarah has better wording, I think this is the way to go. A couple of days ago, I started to put in a note that support for C implicitly includes support for B, but then thought better of it. Katie^talk 12:45, 30 June 2016 (UTC)[reply]

@MusikAnimal: The wording here definitely looks more succinct. With regards to option B, I wanted to mimic the outcome of ArbCom's internal discussion on 30/500, but it came out rather clumsily worded. I would invite any change to make the options more clearly expressed. Mz7 (talk) 15:46, 30 June 2016 (UTC)[reply]

I've updated the wording accordingly. I'm looking forward to this RfC as I think it is very much needed. Thanks for putting it together! :) — MusikAnimal ^talk 18:13, 30 June 2016 (UTC)[reply]

For B and C, may I suggest that "Notification is to be posted in a subsection of AN for review unless the topic is already authorized for 30/500 protection" become "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". I think that is the intent, but also experience has taught us that these things need to be absolutely watertight. BethNaught (talk) 18:16, 30 June 2016 (UTC)[reply]
Sounds good — MusikAnimal ^talk 20:45, 30 June 2016 (UTC)[reply]

Option A

@MusikAnimal and KrakatoaKatie: There may be a problem with option A. Yesterday, a thread at ANI closed with a consensus that authorizes 30/500 protection "for specifically pages that have previously been vandalized by Nikita, or else are currently being vandalized by Nikita". In other words, current practice allows the community (in addition to the Arbitration Committee) to authorize topic areas for 30/500. If option A remains how it is now (restricting use only to ArbCom) and it ends up passing, then would the ANI consensus yesterday be effectively invalidated? Option A should perhaps read: "Allow use only for topics authorized by the Arbitration Committee or by community consensus at AN or ANI." Mz7 (talk) 21:30, 1 July 2016 (UTC)[reply]

Let's just use the Arbcom wording there. In addition, make it clear that this is the status quo, and choosing A means no change from current practice. I'm kind of under the weather today so one of you guys should probably write it. Katie^talk 21:41, 1 July 2016 (UTC)[reply]
I think the wording is fine – there will always be exceptions made on the dramaboards, so we don't need to mention that. That discussion in particular was only started because there was a need for 30/500 and the policy defining whether it was applicable was still unclear – hence the need for this RfC. The result of this RfC may in fact invalidate the Nikita consensus, but again when a situation is severe enough and consensus permits, we can break the rules — MusikAnimal ^talk 21:46, 1 July 2016 (UTC)[reply]

Thank you for your responses.

I find them well-reasoned. Mz7 (talk) 23:18, 1 July 2016 (UTC)[reply]

Very late to the party. As the closer of that discussion, it was my intention that if option A were to gain consensus, the authorization for 30/500 granted there would be overwritten by the broader consensus here. I regret if this was not clear. However, by a straight tally of the !votes, it looks like it will soon be a moot point. Tazerdadog (talk) 05:27, 26 July 2016 (UTC)[reply]

Watchlist notice

I added a watchlist notice for this, as it can impact most editors. — xaosflux ^Talk 04:32, 4 July 2016 (UTC)[reply]

Option D, et al?

Moved from Wikipedia:Requests for comment/Extended confirmed protection policy

– — Andy W. (talk · ctb) 19:50, 21 July 2016 (UTC)[reply]

If none of three options are satisfactory, what about creating another option, Option D? I don't know what policy, but I think another alternative is desired. --George Ho (talk) 08:05, 13 July 2016 (UTC)[reply]

"None of the above". BorkBorkGoesTheCode (talk) 11:47, 13 July 2016 (UTC)[reply]

Curious about close

Something just came to mind while I was re-reading the discussion, which I might add has been lively and interesting with a variety of view points. The opening statement says Supporters of option C may inherently support option B unless stated otherwise. From this statement, would it be correct to state that both Option C and Option B would be enacted if Option C reaches consensus? Blackmane (talk) 06:30, 19 July 2016 (UTC)[reply]

Doesn't option C include option B? I think the statement is intended to mean that, if it comes to counting the !votes (like it or not, it may happen), those who !voted C would be deemed to support B over A (if C fails). If it splits - say - 33%-33%-33%, it still means a majority would support a change from the current (A) to B. Tigraan^{Click here to contact me} 11:06, 19 July 2016 (UTC)[reply]

You're probably right, I was mulling through it and must have been too tired as I couldn't figure it out. Blackmane (talk) 05:58, 1 August 2016 (UTC)[reply]

Appeal to closer: delayed implementation and notification

Moved from Wikipedia:Requests for comment/Extended confirmed protection policy

– — Andy W. (talk · ctb) 19:47, 21 July 2016 (UTC)[reply]

When ECP was first created, the rollout was a total cock-up. Admins didn't know what the rules were and many just applied it at will. If option C passes, as looks likely, it is imperative that all admins know the important details, particularly a) it is necessary that "semi-protection has proven to be ineffective", b) that the protection must be posted to AN for review. Otherwise ECP will be deployed willy-nilly and beyond the rules even of option C.

Therefore I would ask that there be a delay, say of one week, between the closure of this RFC and any widening of the rules (i.e. option B or C). During this time, a mass-message should be sent to all admins informing them of the new rules, so that, should they break them, they cannot claim ignorance. BethNaught (talk) 15:12, 14 July 2016 (UTC)[reply]

It's true not every admin is going to be aware of this RfC and it's outcome, but letter (a) should go without saying. I'd hope any admin would know not to use a higher-level protection when a lower-level one does the job just fine. If they do, I don't think it's an issue of ignorance, but lack of judgement that the community has entrusted them to have. I also think we will have to automate posting at AN, as it's a bit too much to ask for admins to remember to do this. I can write a quick bot task to monitor the protection log and create a rolling archive of EC protections as they occur on a dedicated page, so that it can be transcluded on AN. The high visibility there will allow us to point any misuse of ECP and those few admins will quickly learn. That being said I don't oppose sending out a mass message as you say, I just don't think we should have to — MusikAnimal ^talk 21:42, 15 July 2016 (UTC)[reply]

@MusikAnimal: What would you think about delaying implementation until you have that bot running and approved for a trial? If you think it's an easy bot to write, then I think it makes sense to wait for it to be operational. ~ Rob₁₃^Talk 22:09, 15 July 2016 (UTC)[reply]

If it writes to the userspace (User:MusikBot/ECP log, let's say), then I shouldn't need trial/approval as it's not very expensive. Transcluding in AN probably will require some eyes from bot approvers, since it's highly visible. I'll ask. I can get started on the implementation soon. Even if no changes are made to how ECP can be used I think this would still be useful — MusikAnimal ^talk 22:16, 15 July 2016 (UTC)[reply]

I accept that this discussion is taking place in good faith, and applaud the work being considered. But surely the point of AN notification is that to discriminate against a significant subsection of editors is not to be taken lightly? In controversial articles where the content will not be significantly altered by current events, the 500/30 restriction is arguably a bigger deal than full protection (which puts all editors in the same boat, and where an admin making a substantive edit is treading on thin ice). If an admin does not have time to post a short explanation at AN for the decision to use this form of protection, I would argue very strongly that they did not have time to carefully evaluate the alternative options and conclude that 500/30 protection was the most appropriate solution. I say this as someone mildly opposed to Option C due to lack of clarity on what it will actually mean, but acknowledging that the wind is blowing in that direction. StillWaitingForConnection (talk) 02:56, 16 July 2016 (UTC)[reply]

The "short explanation" is what goes in the protection summary. That's what people will see in the logs. You shouldn't have to go to AN to find out why it was protected. The point of posting at AN is so that a discussion can be started if someone has concerns, so rather than clutter the noticeboard with empty sections (like we're doing at WP:EFN), we can have a bot-generated report and people can start a new discussion as they feel necessary. I've got the bot

Running at User:MusikBot/ECPMonitor/Report. It's being updated hourly. If we decide we don't want to transclude that's fine, but note you can still watch the bot-generated page so you can stay informed when new pages are put under ECP — MusikAnimal ^talk 03:04, 16 July 2016 (UTC)[reply]

@MusikAnimal: Currently, the expiry date at that page is actually the date of protection, just fyi. ~ Rob₁₃^Talk 16:16, 17 July 2016 (UTC)[reply]

Fixed! I've also now using the normal date format without "(UTC)" because if we include that, some gadgets will reformat the date to a very long string, and throw off the appearance. Hopefully this doesn't matter much — MusikAnimal ^talk 16:54, 17 July 2016 (UTC)[reply]

Moved from project page — Andy W. (talk · ctb) 19:47, 21 July 2016 (UTC)[reply]

@MusikAnimal, BethNaught, and BU Rob13: I might be mistaken, but it appears that this ~~is an edit protection log~~logs edit/move/upload prots, but does not log the pages that are ECP salted ~~or upload-ECP'd~~. Is this expected behavior? See ecp-create protected pages — Andy W. (talk · ctb) 23:59, 25 July 2016 (UTC)[reply]

Wowza. The protection policy as currently written certainly does not allow extended confirmed creation protection, and I really don't think that should become a thing without further community discussion. ~ Rob₁₃^Talk 00:24, 26 July 2016 (UTC)[reply]

Yeah... some folks would question create/upload prot options outside full anyway, whereas they're not too distinct from the backend perspective as far as I can tell. But yeah, agree that ECP salting is quite out of scope with original intent. My question/request still stands for now — Andy W. (talk · ctb) 01:45, 26 July 2016 (UTC)[reply]

The bot is now tracking all protection types (edit, move, create, and probably upload?) — MusikAnimal ^talk 02:30, 26 July 2016 (UTC)[reply]

Hi MusikAnimal,

The report created by the bot is potentially very useful, but it isn't the form that I imagined posts to AN to be in. I imagined a new thread starting that says something like the following.

Extended-confirmed protection of <page>

<Admin> has applied extended-confirmed protection to <page> until <date>, with summary "<summary>". - MusikBot 11:49, 4 August 2016 (UTC)

This will allow people to comment on this decision and potentially decide to change the protection level.

Does this sound like a good idea?

If the protection was anything other than edit protection, I guess the bot would have to add another sentence to explain this.

Yaris678 (talk) 11:49, 4 August 2016 (UTC)[reply]

It depends how we see the community's role here. Do we see the community's role as identifying abuses of the protection level (bad judgement, not necessarily abuse abuse) or do we see it as redoing this RfC every single time someone applies this protection level? This will turn into a shit-show very fast if we start a genuine discussion for every single application of this protection level, regardless of the merits. Applying extended confirmed protection is not like an ArbCom decision. ~ Rob₁₃^Talk 12:15, 4 August 2016 (UTC)[reply]

It won't necessarily be like an RfC. On many occasions, the thread may get zero comments. But it could be a bit like an RfC on some occasions. This is what I read the requirement to post on AN to mean. If we want to avoid discussion, why bother posting at all?

Note the discussion at WP:Requests for comment/Extended confirmed protection policy#AN notification, where HighInBC has suggested that the notifications could clutter the noticeboard but Altamel says "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." The idea of sumarising the recent ECPed pages in a table seems to be similarly based on an assumption that this will be used quite a bit.

I'm not suggesting that the need to post on AN should be "set in stone". It is OK to remove it in future if there is community consensus for that, but when the protection level is first rolled out, I think this will provide a useful mechanism for the community to review how it is used.

Yaris678 (talk) 15:36, 4 August 2016 (UTC)[reply]

This is what the requirement to post on AN meant, but I don't think we thought this through very well. I think the report transclusion is fine, so you can hand pick instances of protection that are worthy of discussion. If we post a section for each and every one, it may be difficult to identify those that are debatable from those that are procedural (ArbCom-related). Quite frankly I think we'll find it to be annoying. Anyway, I'm happy to do the coding, but this will require a WP:BRFA. Since the requirement about posting to AN in this RfC is unclear, I think we should take time to develop some rough consensus on which route we'd like to go, before we do any coding — MusikAnimal ^talk 16:53, 4 August 2016 (UTC)[reply]

I think I may have misunderstood the potential role for the bot. Now, it looks like the best idea is to leave responsibility with admins to post to AN about any uses of ECP that aren't covered by Arb Com decisions. The table produced by the bot is just to list all recent application of ECP, so that people can more easily check that this posting by admins is going on. If that is the way we are going to use the bot, I am OK with that. Yaris678 (talk) 08:15, 7 August 2016 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.