Gpedia:Arbitration/Requests

Jump to navigation Jump to search

Weighing scales

A request for arbitration is the last step of dispute resolution for conduct disputes on Gpedia. The Arbitration Committee considers requests to open new cases and review previous decisions. The entire process is governed by the arbitration policy. For information about requesting arbitration, and how cases are accepted and dealt with, please see guide to arbitration.

To request enforcement of previous Arbitration decisions or discretionary sanctions, please do not open a new Arbitration case. Instead, please submit your request to /Requests/Enforcement.

This page transcludes from /Case, /Clarification and Amendment, /Motions, and /Enforcement.

Please make your request in the appropriate section:

Requests for arbitration


Requests for clarification and amendment

Amendment request: Community ECR request

Initiated by El C at 22:44, 23 November 2022 (UTC)Reply[reply]

Case or decision affected
Armenia-Azerbaijan_2 arbitration case (t) (ev / t) (w / t) (pd / t)
Kurds and Kurdistan arbitration case (t) (ev / t) (w / t) (pd / t)
Clauses to which an amendment is requested
  1. Extended confirmed restriction: The extended confirmed restriction is imposed on the area of conflict (from Gpedia:Arbitration/Requests/Case/Palestine-Israel_articles_4#ARBPIA_General_Sanctions)
  2. Extended confirmed restriction: The extended confirmed restriction is imposed on the area of conflict (from Gpedia:Arbitration/Requests/Case/Palestine-Israel_articles_4#ARBPIA_General_Sanctions)
List of any users involved or directly affected, and confirmation that all are aware of the request
Confirmation that all parties are aware of the request
Information about amendment request

Statement by El C

I realize I'm a broken record, but how record broken is this template? Anyway, there was a proposal at AN (live, permalink) which read:

Proposal: WP:ARBECR (which includes a 500edits/30days restriction) over WP:AA2 and WP:KURDS articles.

That proposal has seen a unanimous 17/17 support, but the proposer (HistoryofIran) and others weren't sure how to affect that resolution. Arb L235 recommended to wait for a WP:CLOSE to do the WP:ARBEEWP:GS/RUSUKR thing. I said that it'd be better to amend AA2 and KURDS by motion rather than create a new GS with separate logs, alerts, page notices, etc., which is what should have happened with RUSUKR (→ ARBEE).

I think most participants don't really care either way, they just want to see that community consensus affected. Personally, I'm for streamlining rather than adding further to the maze of DS/GS pages, so I'm bringing it here. Needless to say, ARCA is intimidating and has a very high access ceiling (one of the least accessible areas of the project). And I still fucked up that impossible template, but that was always a given (but it sort of displays, so there you go). Thank you for your time and attention. El_C 22:44, 23 November 2022 (UTC)Reply[reply]

Barkeep49, yes. As stated, the proposal reads: over WP:AA2 and WP:KURDS articles. El_C 22:56, 23 November 2022 (UTC)Reply[reply]
Sorry, writing in haste, but a few quick notes. First, I actually have no firm opinion if the mentioned (17/17) community consensus is an appropriate re/action to whatever influx it represents (long term, etc.). It probably is, but I've not reviewed the material closely, so ultimately can't say that I'm certain about it. Here, I'm mostly just serving as an informal clerk (but also the best clerk!). That said, note that the last ARCA I filed here was also about issues that concern this general region of West Asia and these two associated DSs, in particular (in 2021, I believe; I'll see if I can find it later, now that ARCAs are separately archived thanks to me and to real best clerk, Dreamy Jazz). But as I recall, there was a warning there, a forewarning, even.
But no one remembers, not even me. And, I mean, say this resolution becomes WP:GS/AAKURDS, a split GS like WP:GS/RUSUKR — in a couple of years, when ArbCom subsumes it, no one will remember, either! On a separate note: I hesitated on filing this ARCA because the ACE adds a layer to this that I (best clerk) am a bit uncomfortable with. But the ACE just takes so fuckin' long, it really can't be helped (unless whatever is being discussed coincides with the ACE concluding in, like, a week or mere days). El_C 20:21, 26 November 2022 (UTC)Reply[reply]
Wugapodes, no, I'm not calling to abolish all GSs. I'm calling to end parallel GSs for existing DSs (i.e. splits). Not sure what logs have to do with anything, as one is required to log at WP:GS/RUSUKR just as they would if the existing WP:ARBEE would have been amended per community consensus there.
Again, the overarching trend has been to subsume, so for example WP:GS/IPAK no longer runs in parallel to WP:ARBPAK, and so on and so forth (example example). But it doesn't really matter, I've hit a bureaucracy wall here, with reasoning I'm not really able to meaningfully understand; unless it just means 'ArbCom is too busy, do it yourself,' which I'm getting the sense is largely what's behind Izno's stance (i.e. not wanting to spare the time to examine the matter at hand substantively, which in some sense is understandable, busy-busy).
Anyway, I'm not gonna try again, at least not for a long while, so, see you all (?) again at my next ARCA in, like, a year per usual — I'd probably had forgotten by then the extent of the bureaucracy wall, only to be reminded yet again (that, subsume/split, ultimately it's a cycle with not much rhyme or reason). El_C 21:26, 28 November 2022 (UTC)Reply[reply]
Izno, in one breath you reject my you're-on-your-own interpretation of your stance, but then in the same breath, you go on to detail basically that very thing: 'the community should own it, not our thing, etc.' Not only that, you then try to impose additional barriers to even have the Committee look into acting on this matter (full RfARs, plural). Honestly, your original terse response, that read dismissive, was better. Better than trying to crank up the inaccessibility even further.
Thanks, though, Wugapodes, for at least trying to think outside the box, and for communicating clearly. So, not all bad; it evens out, I suppose. Maybe the Committee will be able to help after all, if not with the fundamentals (i.e. unrefined ECR), at least with the organization and presentation. Which does count for a lot. El_C 12:13, 29 November 2022 (UTC)Reply[reply]
Barkeep49, I call em like I see em. And I don't need anything done, but I'm against some of you seemingly working to make the process even less accessible, when the rest of us are working towards more access. Here, and overall. The way forward is not for you to shelter yourselves from the rest of the project. El_C 16:31, 29 November 2022 (UTC)Reply[reply]
Barkeep49, whatever you say, I'll leave you to it. El_C 17:36, 29 November 2022 (UTC)Reply[reply]

Statement by HistoryofIran

Statement by Guerillero

These are big topic areas to place under ECP. Is there a more narrow topic area that might work better? --Guerillero Parlez Moi 20:40, 25 November 2022 (UTC)Reply[reply]

Statement by ProcrastinatingReader

ECR is pretty draconian and an extreme measure to prevent disruption.

The problem is not inherently with ECR, as I accept it may sometimes–very, very rarely–be appropriate. My concern is: no other lesser restrictions have been considered in that discussion (e.g. a topic-wide semi or ECR on a narrower topic area), no assessment of how many high-quality non-ECP user contributions the topic will lose, and no assessment of the size of administrative burden if a GS is not imposed (which should be a key factor in imposing GS, as otherwise ANI/admins can handle topic disruption as usual). I'm also unsure how this is distinct to other sockpuppeteers who are single-topic focused, we don't fight these with topic-wide ECR. Some of the comments are literally politician's fallacy (e.g. Surely something must need to be done about this disruption.)

If ArbCom is to make a motion, it should be due to substantive agreement and not just rubber-stamping. And ArbCom doesn't need to act here, the community can under the auspices of consensus. If the community wants to motion this, they should do so themselves, but I do wish these GS discussions had some more guidance to, well, guide them. With few exceptions, the fate of almost all community-authorised sanctions is that they were not necessary (see their logs for instance). The only other time the community authorised 500/30 was India-Pakistan I think, which turned out to be unnecessary and was repealed last year after several years of being nominally in force. My overarching point in this paragraph is that the community doesn't have too many tools in its toolbox to deal with this kind of disruption, which I accept is a problem, but it tends to use a hammer when it comes to GS authorisation requests. It's relatively surprising, given how conservative the community is with topical actions otherwise.

I would suggest ArbCom substantively review the issue which caused community concern, in line with WP:AA2/WP:KURDS and Gpedia:Arbitration/Policy#Jurisdiction (The Committee retains jurisdiction over all matters heard by it, including associated enforcement processes, and may, at its sole discretion, revisit any proceeding at any time.). Not to overrule the community, but to see if ArbCom can identify the locus of problem and form a better tool to deal with these kinds of issues. I think ArbCom is best placed to do this.

Barkeep49 reasons:
  1. I think an ArbCom ECR has a greater chance of being enforced as-written or less chance of being forgotten. In the case of India-Pakistan's 500/30, I'm glad it wasn't enforced as-written, because it was never necessary in the first place, and it would've been detrimental to the encyclopaedia's content if it were enforced. Letting administrators maintain discretion is key, and I think that's more likely with a community GS. And IMO, remedies being forgotten is a decent signs they're no longer (if ever) necessary.
  2. IMO it falls out of ArbCom's scope unless you consider the issue substantively, as the community can and did 'resolve' this. I don't feel it's WP:NOTBURO because WP:ECR prescribes no requirements, not even logging, so there is no bureaucratic overhead or procedural differences, unlike DS. Both community and ArbCom non-DS GS are listed on WP:General sanctions in the same manner. I see no blocker to a new table row being added to WP:GS and am unsure why the Committee is needed here.
  3. I'm not a fan of ArbCom rubber-stamping community motions and implementing them as arbitration decisions, at least if ArbCom wouldn't have made the same decision itself. (Would you have motioned this if the AN discussion never happened and an ARCA was filed detailing the socking problem? Or would you do something else?) In paragraph 1 I outline some issues/omissions in that discussion. I dunno if you agree with any of the points I made, but if you do, I feel like you should be wary of authorising a remedy that may not be tightly fitted to the problem. The numerical vote may be there, but this is a strong restriction, and there is no equally strong discussion. I accept it'll probably be implemented anyway, but it's a community decision, the community should own it and have the ability to directly revoke it.
  4. If you wished, this could be an opportunity for ArbCom to figure out how we can address these issues without ECR. I'm personally sceptical of ECR's proliferation. While I appreciate it stops some bad behaviour, I don't think it stops as much bad behaviour as it does good in most cases, and I'm concerned of you setting a precedent where we turn to properly-enforced ArbCom-authorised broad topic-wide ECR implementations in the face of (potentially transient) sockpuppetry and canvassing. I'd maybe go as far as saying ArbCom should conduct a review of the effectiveness of ECR, in particular does it remain the best tool at our disposal for this problem, and when is it actually appropriate?
ProcrastinatingReader (talk) 22:13, 26 November 2022 (UTC)Reply[reply]

Statement by Newyorkbrad

I am not familiar enough with the editing in these topic-areas to opine whether ECR, or any other restriction, is warranted, and I defer to the arbitrators, administrators, and other community members who have commented above for knowledge of the recent editing histories on the topics. I do have two short, more general observations to offer, though, paralleling ones I have made before about other geographical topic-areas:

(1) There is an enormous difference between (for example) requiring 500 edits' experience to edit "all articles about disputes between Azerbaijan and Armenia" and requiring 500 edits to edit "all articles about Azerbaijan and all articles about Armenia." The former is limited to the area of conflict; the latter takes in every article, however non-contentious, between the two countries that happen to be in conflict, and unless the situation has deteriorated to the point where most Armenian editors are unable to edit anything without mentioning Azerbaijan and vice versa, is too broad.

(2) There is also an enormous difference between "administrators, in their discretion, may impose ECR on any article in such-and-such topic-area where problems arise" as opposed to "all articles in such-and-such topic-area are now automatically subject to ECR (whether there have been any problems or not). If the Committee decides to proceed with any motions, please consider these thoughts for what they might be worth. Newyorkbrad (talk) 23:56, 28 November 2022 (UTC)Reply[reply]

Statement by Andrew D.

There was recent discussion at ITN about applying such restrictions to discussion of news items such as the recent missile strike in Poland or a fire in Gaza. This seemed to be technically difficult because such discussions are bundled in dated sections rather than on separate topical pages. And establishing the scope of "broadly construed" didn't seem clear either. So, my impression is that the EC restriction already doesn't work well and so further proliferation should be resisted.— Preceding unsigned comment added by Andrew Davidson (talkcontribs) 10:20, 29 November 2022 (UTC)Reply[reply]

Statement by Nosebagbear

Over on the VP, I've just given a mixed oppose/support on the issue (I'm also not the only oppose, though certainly still close to). ECR is a very severe restriction, and AA2 is a huge scope unless you don't have much of a link to either country. In terms of the general ECR question, I'd support a restriction on the conflict, but not the individual countries (and just accept that a certain amount of gaming will have to be handled by the standard DS regime).

In terms of "should it be DS at all" - I have made abundantly clear that I oppose DS subsumption of GS without community agreement, but likewise don't really mind if the community itself would like it all under one banner. Though with all that, Izno's position is not unreasonable and has a lot to say for it. Nosebagbear (talk) 10:35, 29 November 2022 (UTC)Reply[reply]

Statement by Rosguill

I'm undecided on the merits of the proposal itself, but I want to push back against CaptainEek's characterization of the Arab-Israeli conflict as uniquely thorny or that it goes back thousands of years (case in point: the only way to construe the A-I conflict as thousands of years old is if we include the Roman-Judaean conflict or the early Muslim conquests as part of its scope; we do not apply PIA protection to such articles). Pretty much any ethnic conflict has the propensity to motivate extremely disruptive editing: the question to be answered is whether the level of disruption on Gpedia merits a given sanction. This should be an assessment of the quality and quantity of edits on Gpedia alone, not an evaluation of how intractable we believe the actual nationalist conflicts to be. signed, Rosguill talk 16:08, 1 December 2022 (UTC)Reply[reply]

Statement by Nil Einne

I don't have an opinion on the need or wisdom of imposing ECP in the area at the time, nor on whether arbcom should take over the community proposal or really anything in the area at this time. But an obvious question if the alts pass, does Gpedia:Arbitration Committee/Discretionary sanctions#Appeals and modifications apply in entirety? I'm particularly thinking of the ARCA aspect. It seems a little weird that people can appeal to arbcom, or for admins to try and get agreement from abcom before modifying sanctions when arbcom is basically saying they're not taking over this it's still only a community decision; and arbcom stopped considering appeals for community sanctions long ago. Nil Einne (talk) 15:30, 4 December 2022 (UTC)Reply[reply]

I see this proposal is maybe somewhat dead given DS/contentious topics motion. Having skimmed through that it maybe does imply that ARCA cannot be used as I guess a community-imposed remedies where discussion is designated to take place on the AE noticeboard is still not a "contentious topic restrictions", and perhaps somewhat clearer, a community restriction even taking place on the AE noticeboard is still not "an arbitration enforcement request". However although again I only skimmed and I'm also fairly tired, it's surprisingly less explicit than I would have though. (I'm mentioning this here since I couldn't figure out any place to comment on the motion.) Nil Einne (talk) 15:57, 4 December 2022 (UTC)Reply[reply]

Statement by {other-editor}

Other editors are free to make relevant comments on this request as necessary. Comments here should address why or why not the Committee should accept the amendment request or provide additional information.

Community ECR request: Clerk notes

This area is used for notes by the clerks (including clerk recusals).

Community ECR request: Arbitrator views and discussion

  • El C the ask here is to add ECR to Kurds and Kurdistan and also to Armenia-Azerbijan? Just want to make sure I understand this correctly before investigating the substance. Barkeep49 (talk) 22:51, 23 November 2022 (UTC)Reply[reply]
    I've thrown up a couple motions below. I'm weakly in support of both but also think the community could just enact based on the consensus of the AN thread, no action from us needed. Alternatively if the intent was always to ask us my wish would be for that to have been noted - as is it's not clear if the editors participating want this to be a community sanction, an arb sanction, or don't care. I post this more in hopes that other community members will weigh in but if nothing happens I'm inclined to support. Barkeep49 (talk) 19:13, 25 November 2022 (UTC)Reply[reply]
    ProcrastinatingReader broadly I agree with you on ECR and the role of arbcom and the community. But I am a bit puzzled with how you apply it in this case. The feedback you and Guerillero have given is why I didn't support the motions after proposing them - I wanted to hear from more voices. When you say If the community wants to motion this, they should do so themselves isn't that what happened at AN? So why should ArbCom spend a lot of time making its own determination rather than acknowledging that having parallel ArbCom and Community restrictions is messy and respecting community consensus by incorporating it into ours? Neither of you are opposing the community motion and so absent ArbCom passing these motions these restrictions will still come into effect at some point when someone gets around to closing it and opening the pages, so why not have the simpler method of doing it? Barkeep49 (talk) 17:49, 26 November 2022 (UTC)Reply[reply]
    @ProcrastinatingReader if El C had filed a request an ARCA request without that community discussion I would absolutely be taking it seriously given that these remain contentious topic areas and El C actively works them. The argument that having two different sets of places to record issues is to be celebrated as evidence that the community can handle so no need for ArbCom it is not an argument that resonates with me. I'm glad you and Guillero have now opposed at the community discussion. I will continue to wait to see what others in the community have to say. Barkeep49 (talk) 22:33, 26 November 2022 (UTC)Reply[reply]
    El C it feels like you're frustrated at the committee for not doing what you want when the overwhelming agreement of the people giving feedback on "should ArbCom do this" (vs people giving feedback in the !vote on "Should the community do this") is no. I get why you're frustrated with this but also do want to call out that it's not like the Arbs are getting caught up in bureaucracy here and not listening to what people want. Barkeep49 (talk) 16:02, 29 November 2022 (UTC)Reply[reply]
    Listening to the feedback of the community telling us not to do something feels like the opposite of sheltering ourselves from the rest of the project. Barkeep49 (talk) 17:26, 29 November 2022 (UTC)Reply[reply]
  • My read of the discussion is that users don't care but that El C thinks it would be administratively simpler if we did it ourselves. I'm happy to support the motions; I will be copyediting them to be in line with existing ECR remedies shortly. Best KevinL (aka L235 · t · c) 20:17, 25 November 2022 (UTC)Reply[reply]
    ProcReader and Guerillero's points here are great, and I will further consider the best path forward. Best, KevinL (aka L235 · t · c) 22:26, 26 November 2022 (UTC)Reply[reply]
  • I was going to follow up my below votes with something much shorter and simplistic but much along the same lines as ProcrastinatingReader has this afternoon, but I think his points are better framed anyway. ECR doesn't have any overhead and no fundamental complexity in implementation. Pages get protected and wherever else an unregistered or 'new' editor is editing in the topic area they can be reverted with enforcement at 3RRN. Izno (talk) 22:32, 26 November 2022 (UTC)Reply[reply]
    ArbCom is too busy, do it yourself Decidedly not. It is resolutely "the community wants it, so they should own it", as I have said already.
    We could examine it, but if that's what you want, what you actually want are AA3 and KURDS2 cases given the draconian nature of the restriction you are attempting to add committee authorization to and the lack of evidence of disruption the community cannot handle even with existing restrictions under our name (or even attempts to do so), at least as presented here. I'd be willing to entertain such cases, but certainly not in parallel with the community discussion. That discussion could serve as evidence of community discontent making a basis for a case, but I don't think it sufficiently indicates by itself (and by itself I mean in the text of the discussion, not just its existence) the necessity either for arbitration-committee-backed-ECR or any other addition to the discretionary sanctions already available here and maybe isn't even sufficient to take a case. That would be something for WP:ARC either way.
    As for the splitting of documentation and such, it looks like I'm not going to get what I personally want on the matter and arbitration and community documentation is going to fall under the new contentious topics nomenclature with its requirement for summarizing subpages and allowance for use of AE if requested by the community. (Mind you, the new subpages I liked, so I'm quipping mostly about the name and use of AE.) I imagine such subpages could or even should directly display community additions to arbitration remedies or link to the community additions elsewhere.
    So, if this amendment request had shown up literally a week or two later, I would just have said "that looks like sufficient community direction to use the same enforcement/summary mechanisms, go ahead and add it over there as a community restriction in the same area". Maybe I should have said that earlier, but I didn't know if the associated proposals were likely to pass. Izno (talk) 22:30, 28 November 2022 (UTC)Reply[reply]
  • @El C: I agree with Izno's reading that a community-imposed ECR restriction doesn't require logging under the cited procedures. Is your goal to eliminate the need for a GS page at all or just logging? I agree with streamlining and harmonizing these processes, but it's not clear to me how us implementing the restriction resolves that. Wug·a·po·des 20:38, 28 November 2022 (UTC)Reply[reply]
  • Rosguill Thanks for pointing that out. I'm not sure my analogy landed in the way I wanted it to. So let me say I agree: we should be making decisions based on how disruptive something is being to Gpedia, and so far we only have evidence that this is disruption based on a short to medium range harassment campaign. I point out the real world dimension because I simply question whether this is actually a long term problem for Gpedia. It would be a massive waste of admin time to go through the labor of ECP'ing thousands or tens of thousands of pages...for the harassment to die down in a few months or a year, and then we've just neutered a topic area for no reason. CaptainEek Edits Ho Cap'n! 18:52, 1 December 2022 (UTC)Reply[reply]

Kurds and Kurdistan ECR request

The following remedy is added to the Kurds and Kurdistan case:

Extended confirmed restriction

11) The extended confirmed restriction is imposed on all edits and pages related to Kurds and Kurdistan, broadly construed.

Support
Oppose
  1. The original ECR placed on PIA was noted as draconian. If that's what the community wants in this topic area, I think the community should own these accordingly. Izno (talk) 21:53, 25 November 2022 (UTC)Reply[reply]
  2. I am sharply opposed to the proliferation of ECR. This is the encyclopedia that anyone can edit. ECR is almost universally so high a burden (to would be editors, and to our administrators) that it has not been implemented even in highly acrid areas. The exception that proves the rule is WP:PIA. PIA represents a simply different paradigm. The conflict between Israel and Palestine is the single most intractable political problem of the last century. It sharply divides dozens of countries and entire populations. It encapsulates an ethnic and religious dispute that goes back thousands of years. It was attracting editors from the entire world that made the topic an unapproachable editing wasteland. I understand that issues with Kurds and AA2 are bad, but they simply pale in comparison to PIA. I might support a narrowly targeted scope, but there isn't evidence to support such a broad scope.
    I understand the idea that if the Community wants this, ArbCom should implement it. But I think a rigid formulation of that rule is unhelpful. Also, the latest five comments at AN all oppose the idea, so I suspect we may seeing a sampling error given that this is a rather stale discussion on AN. I would also caution that the proposal in the AN thread came out of an off-Wiki harassment campaign. The users in question were blocked. We have had harassment campaigns in the past (think Muhammed images, or the vast harassment campaign against Ahmadiyya that plagued VRT a few years ago). But they passed. I do not think implementing long-term ECR across a topic area is warranted in response to a short or medium term problem. I understand the frustration with the topic area, but ArbCom (or the community) should not implement a fundamentally flawed solution just because of frustration. CaptainEek Edits Ho Cap'n! 08:12, 1 December 2022 (UTC)Reply[reply]
Arbitrator discussion (Kurds and Kurdistan ECR request)

Armenia-Azerbaijan ECR request

The following remedy is added to the Armenia-Azerbaijan 2 case:

Extended confirmed restriction

3) The extended confirmed restriction is imposed on all edits and pages related to Armenia, Azerbaijan, or related ethnic conflicts, broadly construed.

For administrative simplicity, the section titled "Standard discretionary sanctions" is redesignated as Remedy 4 of the Armenia-Azerbaijan 2 case.

Support
Oppose
  1. The original ECR placed on PIA was noted as draconian. If that's what the community wants in this topic area, I think the community should own these accordingly. Izno (talk) 21:53, 25 November 2022 (UTC)Reply[reply]
  2. Refer to my vote on the first motion. CaptainEek Edits Ho Cap'n! 08:13, 1 December 2022 (UTC)Reply[reply]
Arbitrator discussion (Armenia-Azerbaijan ECR request)
Copyedited both motions. This second one is a bit messy because the case page is a bit messy and this motion redesignates the currently un-numbered remedy "Standard discretionary sanctions" with a remedy number for future ease of reference. When enacting this motion, it would be great if the clerks would also collapse all rescinded or superseded text on the case page. Best, KevinL (aka L235 · t · c) 20:26, 25 November 2022 (UTC)Reply[reply]

Kurds and Kurdistan ECR request (alt)

The following remedy is added to the Kurds and Kurdistan case:

Extended confirmed restriction

11) The committee authorizes using the procedures of remedy 1 to administer a community-imposed extended confirmed restriction in the topic area or any sub-topic. For administrative simplicity, alerts, warnings, and sanctions regarding a community-imposed extended confirmed restriction may be given as if the Arbitration Committee had authorized an extended confirmed restriction. If the community repeals its extended confirmed restriction on this topic area, this remedy will be automatically revoked.

Support
Oppose
Arbitrator discussion (Kurds and Kurdistan ECR request alt)


Armenia-Azerbaijan ECR request (alt)

For administrative simplicity, the section titled "Standard discretionary sanctions" is redesignated as Remedy 3 of the Armenia-Azerbaijan 2 case.

The following remedy is added to the Armenia-Azerbaijan 2 case:

Community-maintained extended confirmed restriction

4) The committee authorizes using the procedures of remedy 3 to administer a community-imposed extended confirmed restriction in the topic area or any sub-topic. For administrative simplicity, alerts, warnings, and sanctions regarding a community-imposed extended confirmed restriction may be given as if the Arbitration Committee had authorized an extended confirmed restriction. If the community repeals its extended confirmed restriction on this topic area, this remedy will be automatically revoked.

Support
Oppose
Arbitrator discussion (Armenia-Azerbaijan ECR request alt)
  • So I'm going to think outside the box here, and try to hash out a compromise. I'm incredibly sympathetic to the idea that we should reduce the maze of templates, logs, and pages required for what are essentially parallel ArbCom and community sanctions; it's bad from a maintenance perspective, from an administrative perspective, and from an editorial perspective. We should avoid duplicating work where possible. That said, I'm also sympathetic to the idea that the community should ultimately be the one to own these restrictions, and ArbCom shouldn't subsume sanctions that the community is capable of administering itself.
    The issue I see is that the community (or at least El_C who does his fair share of the DS/GS work) would like to use our infrastructure for it's sanctions, but we have no mechanism for that other than subsuming the sanctions which (like this situation) isn't always the ideal choice. We need some (new) way of allowing the community to use our infrastructure, but leave the actual maintenance of the sanction (including its repeal) up to them.
    So the two alternative motions I'm proposing are a little rough, I'd welcome copyedits, but I think the gist is there. We make clear that these are community-imposed sanctions, but we authorize the use of our (soon to be renamed) DS infrastructure for administrative simplicity; don't worry about the GS/DS distinction, if you act like the ECP is a DS no one will yell at you. The community maintains control over when to terminate the sanction, and if they do so, this whole thing becomes null without us having to do anything; we can revoke this authorization early by motion if it turns out to be a horrible idea in practice. Wug·a·po·des 22:28, 28 November 2022 (UTC)Reply[reply]
    This was also the direction that I've been thinking – if I can get past my current questions about whether ECR would be a Bad Thing here. Best, KevinL (aka L235 · t · c) 22:59, 28 November 2022 (UTC)Reply[reply]
    I think these are basically (American) mooted by the DS rework as I noted above that we posted almost simultaneously. Izno (talk) 23:27, 28 November 2022 (UTC)Reply[reply]
    I think so too. But this is also why I've asked for clear sample language for the community to use in such instances. One of the hang-ups for me is that there is a clear understanding by the community, when participating in the discussion and voting, what they're voting for. Given the idea of merging with ArbCom came after discussion had (at that point) died down is part of my overall reluctance in this instance. Barkeep49 (talk) 23:43, 28 November 2022 (UTC)Reply[reply]

Motions

Return of permissions

Return of permissions

The Return of permissions procedure is amended to read as follows:

Removal is protective, intended to prevent harm to the encyclopedia while investigations take place, and the advanced permissions will normally be reinstated if a satisfactory explanation is provided or and the issues are satisfactorily resolved. If the editor in question requests it, or If the Committee determines that a routine reinstatement of permissions is not appropriate, normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances.

In cases where an administrator account was compromised, the committee will review all available information to determine whether the administrator followed "appropriate personal security practices" and whether the account has been appropriately secured before restoring permissions. Factors used to make this determination include: whether the administrator used a strong password on both their Gpedia account and associated email account (such as by using a password manager); whether the administrator had reused passwords across Gpedia or the associated email account and other systems; and how the account was compromised; and whether two factor authentication is being used. If the Committee determines the administrator failed to secure their account adequately or is failing to take reasonable measures to secure their account going forward, the administrator will not be resysopped automatically. In particular, the Arbitration Committee generally will not resysop administrators who failed to use adequate password security practices, such as by reusing their Gpedia or associated email account passwords on other websites.

Unless otherwise provided by the committee, the administrator may regain their administrative permissions through a successful request for adminship.

Furthermore, the Level II procedure is amended to add:

6. If the Committee determines that a routine reinstatement of permissions is not appropriate, normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances, provided that the editor in question requests it; failing that, the removal is final. As with a Level I desysop, an administrator desysopped in this manner may still run for adminship again.

For this motion there are 13 active arbitrators. With 1 arbitrator abstaining, 7 support or oppose votes are a majority.

Arbitrator voting

Support
  1. As proposer, with thanks to Barkeep, Salvio, and Kevin for wording. See my comment below for a full explanation of the changes, which serves as my reasoning as well. CaptainEek Edits Ho Cap'n! 18:59, 1 October 2022 (UTC)Reply[reply]
  2. On balance, I think this is a positive step. Sysop tools have the potential to be quite harmful in the wrong hands, and editors with these tools should take all reasonable measures to secure themselves. I think it's reasonable that we tighten the wording here, and in the process give more guidance on what not to do. Wug·a·po·des 22:25, 16 November 2022 (UTC)Reply[reply]
Oppose
  1. I cannot support this change simply because of this line "In particular, the Arbitration Committee generally will not resysop administrators who failed to use adequate password security practices, such as by reusing their Gpedia or associated email account passwords on other websites." I have seen a lot of account compromised over the years, leading to emergency desysops - and by and large, I have felt that the administrator in question has simply not realised the security mistakes they have made. I am all for education and improving our administrator account security, but I am not for setting out a guideline stating that we will "generally" be punishing individuals who make mistakes. I would much rather review on a case by case basis. If the individual cannot recognise and will not learn from the mistake, then sure, but if they accept their mistake and update their security, I have no issue with "generally" returning the tools.
    On a wider note, we have hundreds of administrators, all with different levels of technical online ability, each of which has dedicated a large portion of their lives to the encyclopedia. I will not be part of a culture who black balls these hard workers simply for not understanding what they're doing wrong. WormTT(talk) 08:46, 3 October 2022 (UTC)Reply[reply]
  2. The current language already gives leeway to deal with extraordinary cases where an admin is especially sloppy or repeatedly hacked. BEANS is really a factor here, but I'll also add that we don't need any more incentives for admins to be targeted by bad actors (i.e., if you pull it off, maybe you can get them desysopped too!). --BDD (talk) 14:21, 3 October 2022 (UTC)Reply[reply]
  3. I'm generally in agreement with Worm That Turned. I don't think less-than-ideal security practices ought to be a bright-line offense; there's too much nuance involved, and a rule that we would generally not resysop is draconian. Maxim(talk) 13:28, 4 October 2022 (UTC)Reply[reply]
Abstain
  1. Primefac (talk) 12:46, 29 November 2022 (UTC)Reply[reply]
Comments

Three big changes: first, I've implemented Salvio's suggestion with some elaboration, and have moved that clause to the Level II procedure instead. The sentence seemed to imply that we open a case to review a compromised account. But we don't, that is just way too much bureaucracy. The discussions have to be private anyway, so the structure of a case isn't necessary. Current practice is that we talk to the compromised admin via email, get their story, do our fact finding, then vote on a private motion. That's how we do basically all private stuff, so no need to specify the modus operandi there. Second, I have clarified that we will still open cases for Level II desysops by simply adding that as point 6. I have used the wording "final", rather than Salvio's "permanent", since one may still RfA again. Third, I have added a clause noting that the Committee will generally not resysop for password security failures. To me, that is key. This in my mind is basically our final warning to admins to get their passwords in order. We raised the issue years ago, and things still haven't been solved. But in the interest of fairness, I think we need to put the admins on notice before we just start pulling hacked permissions. I am also open to sending some sort of mass message to communicate this change. As much as I wish there was a technical solution, the WMF is not known for its speed in implementing technical fixes. Thus we need a social solution. CaptainEek Edits Ho Cap'n! 18:32, 1 October 2022 (UTC)Reply[reply]

  • I don't have any strong feelings about this topic. If the arbs whose concerns were the impetus to start this discussion like this I stand prepared to support it. if this isn't it, I am prepared to support something else. Barkeep49 (talk) 22:17, 1 October 2022 (UTC)Reply[reply]
    I can support the general direction that we're going. I would like to make it much more explicit that the major issue we are seeing is password reuse and that we will treat that differently going forward – either through ArbCom action or by community action saying we need to take it more seriously (my preferred route). I do not think the removal of the safety valve of a full case is wise; it's not causing any problems and if a desysopped user really does think they want a full case I would support holding one. I do not think we need to add 2FA to this list. I do not think we need to add "or is failing to take reasonable measures to secure their account going forward" to the procedure; that's not what's broken. Best, KevinL (aka L235 · t · c) 20:57, 2 October 2022 (UTC)Reply[reply]
    That's not what was broken here though 2FA would have stopped the last compromise we had. I don't feel strongly on this but I think a reasonable assurance that measures are being taken to secure the account going forward is entirely compatiable with Admin policy of Gpedia's policy on password strength requirements requires administrators to have strong passwords and follow appropriate personal security practices (emphasis added). Barkeep49 (talk) 21:00, 2 October 2022 (UTC)Reply[reply]
    Sure. I just think that's implied. Best, KevinL (aka L235 · t · c) 21:03, 2 October 2022 (UTC)Reply[reply]

Return of permissions (alternate draft; not yet open to voting)

The Arbitration Committee's procedure titled "Return of permissions" is amended by appending the second paragraph with the following sentence: In particular, the Arbitration Committee generally will not resysop administrators who reused their Gpedia or associated email account passwords on other websites.

Arbitrator discussion

  • This is my attempt to capture some behind the scenes discussion about this procedure. I'm not precious about any of it so if I've missed the mark in some way from arbs who'd like to see it changed, I hope they will refine the motion or offer their own. I will note that the motion I've proposed does include 2-factor authentication, but it is one criteria among many for whether or not to restore, which is a substantial difference from the previous committee communication that was later walked back. In other words no admin is being forced to use it, but if they choose to use it that decision will factor (positively) in the decision about returning tools. Barkeep49 (talk) 17:28, 26 September 2022 (UTC)Reply[reply]
  • I'll add some detail here. A good portion of the Committee, me included, is unthrilled that administrator accounts keep getting breached because of lax password practices. The Committee has historically erred on the side of returning administrator tools to compromised accounts once administrators are confirmed to be in control of their account. But at least for me, going forward I intend to oppose restoration of permissions (absent compelling community input) on the basis that admins have had ample warning about password practices. Whatever we pass here, I want to make sure we're loud and clear about our changing approach, so that admins have one last chance to make sure they have a strong password, that they're not reusing, and that otherwise conforms to best password security practices. I'm particularly interested in what the community thinks here, especially as to what extent we should weigh password security practices, and in what general situations the community believes we should not return the administrator toolkit, thus forcing the editor to run for adminship again if they want the tools back. Please remember WP:BEANS in your answers, since we're not trying to create an instructional guide for our trolls. CaptainEek Edits Ho Cap'n! 18:05, 26 September 2022 (UTC)Reply[reply]
    I don't want this discussion to be about 2FA, but understand that it probably will. The Committee has not forgotten the opposition to 2FA expressed in 2019, and is not requiring 2FA, nor do I want to. Even without using 2FA, your account can be uncrackable. However, if you don't use 2FA, you better be conforming to best password security practices. That, in my view, is the bare minimum. The admin tools are more powerful in the wrong hands than people give them credit for (WP:BEANS). CaptainEek Edits Ho Cap'n! 18:14, 26 September 2022 (UTC)Reply[reply]
    I don't think this motion is "loud and clear" about the change you're outlining Eek. I would suggest if that's the goal - and I suspect you're not the only arb to feel this way - that we would need another motion - perhaps as a complement, perhaps as an alternative - that would communicate the Committee's new view on this topic. Barkeep49 (talk) 20:26, 26 September 2022 (UTC)Reply[reply]
  • As a note, the present wording of WP:RETURN is as a result of a 2019 motion that came after some 6 administrator accounts were compromised (see footnote therein). While any one compromise from an administrator might be a single for that administrator, that administrators continue not to secure their accounts is basically a failure to uphold WP:SECUREADMIN. --Izno (talk) 18:41, 26 September 2022 (UTC)Reply[reply]
    @Legoktm, the current policy is 10 characters for certain permissions holders. Which, to be honest, is also an abysmal minimum. (I am also not particularly certain how that is enforced? When the administrator right is added, how does MediaWiki check? :)
    I am not sure how an audit would be run except at the login step, seeing as the storage of passwords is industry standard (salt + hash). This only (to me) feasibly catches the short passwords and the most common passwords. We might get lucky catching others on the pwned lists, but since we require a user name and not an email to login, I foresee this as being minimal. Still, better something than nothing?
    The RFC TNT mentions is WP:Security review RfC, from 2015. There is an earlier one from 2011, Gpedia:Village pump (proposals)/Account security. Gosh, do the beginnings of those RFCs look familiar. That makes 4 times this has come up, including 2019 (when Arbcom last modified WP:RETURN) and 2022 (now). While I agree that it would be draconian for Arbcom to desysop someone for the first time, our continuing issues with it indicate to me that might be necessary. It's been over a decade, folks. Izno (talk) 04:51, 27 September 2022 (UTC)Reply[reply]
  • Just throwing some spaghetti at the wall: what if there were a rule saying "if an admin gets compromised and there's public evidence of password reuse, they have to re-RfA"? Enterprisey (talk!) 01:27, 27 September 2022 (UTC)Reply[reply]
    That is what the alternative motion that we voted on said. Desysop, and the community can decide whether Staxringold deserves to retain the permissions. Izno (talk) 04:53, 27 September 2022 (UTC)Reply[reply]
  • The case in hand was covered by the existing wording. There's little point changing the wording unless the committee is willing to enforce its own stated position which has been in place for years. I'm still thinking on the change but the wording "appropriate personal security practices" says what needs to be said in an enduring way. Specifying what those practices are sets a fairly short "best before" date to the advice. Cabayi (talk) 08:18, 27 September 2022 (UTC)Reply[reply]
Follow up to TNT's pointer to HIBP. The site has a NotifyMe option so you'll be informed if it's found that your email is caught in a data breach in the future. Cabayi (talk) 08:25, 27 September 2022 (UTC)Reply[reply]
  • I do think we need to leave 2FA out of this. While I use 2FA on my email accounts associated with WP, I will not ask anybody to use the 2FA method currently implemented by WMF, and do not use it on WP, except where explicitly required by WMF. Consistent with my position in the recent restoration discussion, I support the strictist enforcement of conditions for restoration of admin status after an account compromise that the committee will endorse. - Donald Albury 22:30, 2 October 2022 (UTC)Reply[reply]
  • I am not aware of any changes to the 2FA system, meaning that it is not robust with regards to lost tokens. In those cases, manual intervention by T&S (I think?) and they were not in a position for all admins to flip that bit. Given that not all admins trust WMF either, I believe pushing for 2FA is a non-starter. Regarding strengthening of passwords, that's something I support and have supported for a long time. Yes, password re-use is the biggest problem, but our password requirements are pitiful and should be updated as a technical change. WormTT(talk) 08:31, 3 October 2022 (UTC)Reply[reply]
  • Further background, with Worm and my fingerprints all over it, is at Gpedia:Security review RfC and Gpedia:Password strength requirements (which was superseded by meta:Password policy). Beeblebrox (talk) 21:48, 3 November 2022 (UTC)Reply[reply]
  • @ArbCom: - I am worried we haven't addressed the concerns that led to split opinions on the last compromised account. From my general read of the situation it feels like we have some arbs who feel like existing policy is sufficient to deny re-sysop to some compromised accounts (in particular the case of re-used passwords), some arbs who feel we do not have that in existing policy, and some arbs who would like to more forcefully suggest that use of things like 2FA be considered. I think the fact that we have a few different groups is part of what is making it hard for us to find consensus. I'm pretty open to a range of solutions personally so I'm hoping that we can find a way to get to a solution that works for this committee. Best, Barkeep49 (talk) 18:57, 11 November 2022 (UTC)Reply[reply]
    I would prefer making some easy progress by seeing where we stand on the alternative proposal above (about reusing passwords on other websites). @L235, would you be OK with proposing it? Enterprisey (talk!) 22:46, 13 November 2022 (UTC)Reply[reply]
    Without going into too much detail about Staxringold specifically, the major issue I see is that we basically ignored the wording of the current procedures because we did not want community backlash. I find the second/draft proposal to be ideal, because it states clearly our stance, but I am concerned that if we encounter this type of situation again the majority will still vote to overrule it simply because they do not want to make an example of someone (again). If we are going to say "what leads up to a compromise is important" in our policies, then we need to stick to that. If all we care about is what the user does after regaining control of the account, then we should not have any statements about what led up to the compromise. Primefac (talk) 09:52, 14 November 2022 (UTC)Reply[reply]
    I think I'd be OK with proceeding to a vote on the alt, yeah. Best, KevinL (aka L235 · t · c) 22:26, 16 November 2022 (UTC)Reply[reply]

Community discussion

  • In an ideal world, 2FA would be a requirement for all administrators. I appreciate that many do not agree, and given the current implementation of two-factor authentication perhaps this is for the best. I would however urge ArbCom to make enabling 2FA a requirement for returning sysop permissions to a previously compromised account — I think this would be a fair middle ground. — TheresNoTime (talk • they/them) 18:05, 26 September 2022 (UTC)Reply[reply]
    Agreed. We cannot audit passwords or password manager use - we can check that 2FA is on. For restoring tools to a previously compromised account we absolutely should be doing this. firefly ( t · c ) 18:09, 26 September 2022 (UTC)Reply[reply]
    @Firefly: - I thought that it could only be known if they had a 2FA userright. Actual knowing if 2FA was being utilised/enabled was limited to Steward sight and not able to be shared? Nosebagbear (talk) 18:21, 26 September 2022 (UTC)Reply[reply]
    @Nosebagbear ahhh yes that is I believe true. Whether we want to go there (asking stews to check) is another matter I suppose. firefly ( t · c ) 18:24, 26 September 2022 (UTC)Reply[reply]
    @Firefly - they'd probably have to get a position from WMF Legal to adjudge whether they could hand it over. It would certainly count as private information (although not especially sensitive private data). There might be more to be said for having CUOS rights tied to it, with that information taken and handled purely privately. Nosebagbear (talk) 19:41, 27 September 2022 (UTC)Reply[reply]
    @Firefly: iirc password strength can be audited — T121186 ("Implement results of enwiki Security review RfC") was meant to regularly audit administrator passwords. — TheresNoTime (talk • they/them) 18:56, 26 September 2022 (UTC)Reply[reply]
    phab:T265726 would be required to allow crats to audit if 2FA is on or not, currently only stewards and WMF may do so. — xaosflux Talk 18:58, 26 September 2022 (UTC)Reply[reply]
    @TheresNoTime Ah my apologies I’d forgotten about that task. It seems however that password audits for admins has yet to be implemented(?). firefly ( t · c ) 20:02, 26 September 2022 (UTC)Reply[reply]
    @Izno: agreed — compromises do happen, and given enough time and technical ability no account is entirely secure, but the unfortunate reality is that, for the majority of compromises, WP:SECUREADMIN is not being followed. It seems to be somewhat of an unenforced policy at this point — TheresNoTime (talk • they/them) 18:51, 26 September 2022 (UTC)Reply[reply]
  • While I am confident that I meet the password criteria for admins, I am very reticent in Eek's position. I don't believe that a single failure there is adjudged by community standards to be a failing on an equivalent standard to the other single-failures that would get the admin userright removed even where the admin apologised and acted to correct the issue going forwards. With regards to Tamzin's TNT's proposal, it's not unreasonable, but I would want it generally limited to cases where it is known that either the admin had not been meeting the minimum criteria, or had met them, and was compromised in a way that 2FA would have stopped (certain limited categories of keyloggers, password dumps etc) Nosebagbear (talk) 18:21, 26 September 2022 (UTC)Reply[reply]
    The most common compromise vector we've seen would indeed be stopped by 2FA (though in the most recent case, perhaps not) — it's certainly not the "be all and end all" of account security, and has its own fairly significant drawbacks. It is, however, another layer to the account security best practices. — TheresNoTime (talk • they/them) 18:33, 26 September 2022 (UTC)Reply[reply]
  • The motion seems fine as written. Eek, I'll agree to bite my tongue about 2FA (especially this implementation), but it's going to be difficult to hold steady if others are still lobbying for it. --Floquenbeam (talk) 18:24, 26 September 2022 (UTC)Reply[reply]
  • I agree the motion as written is good. Regarding 2FA, I use it* but I am opposed to requiring it until there are no technical, legal or economic barriers to every admin being able to use it. In the last discussion I was part of extant technical and economic barriers were noted that prevented some admins in wealthy countries in the global north from using 2FA, let alone those from less online parts of the world. I don't recall what the state of play is regarding legality. *Although I have had to temporarily disable it twice in the last few years, first for about 10 days when my second device was away being repaired and then for about a day when I replaced that device earlier this year. Thryduulf (talk) 01:11, 27 September 2022 (UTC)Reply[reply]
  • Having your account be compromised is embarrassing enough (I speak from personal experience on this), I don't see value in doubling down and then punishing the person for their bad luck. Rather, if we're going to enforce password policies (e.g. must be 8 characters or longer), then we should enforce them equally. It would be relatively straightforward to have MediaWiki desysop any admin who logs in with a less-than-eight-character password, if that's what we want. Legoktm (talk) 01:24, 27 September 2022 (UTC)Reply[reply]
  • I do hope that if an admin account was compromised multiple times that they would lose adminship for good. --Rschen7754 01:25, 27 September 2022 (UTC)Reply[reply]
    • I also hope that a higher standard would be applied to users with rights beyond admin, especially those that can access private data. --Rschen7754 02:55, 27 September 2022 (UTC)Reply[reply]
  • In an ideal world (such as the one TNT refers to), the WMF would fully support 2FA software properly, and the software would be up to international standards. Asking an admin to say they have 2FA enabled is security theatre of the worst kind: absent being confirmed by a steward that it is, in fact, turned on, nobody on this project would be able to verify. (Stewards for whom this is the home wiki aren't supposed to carry out tasks related to this wiki.) And even if they verified at that time, it's just a step or two to turn it off. I'd much rather ask for a longer mandatory password that is enforced on all admin accounts, and regularly verified, with mandatory desysop if the account fails the verification, as Legoktm suggests. It's entirely reasonable to ask that an annual verification that admin accounts meet minimal password standards be carried out. But let's not go down the security theatre rabbit hole. Risker (talk) 02:57, 27 September 2022 (UTC)Reply[reply]
  • My point is poorly made without spilling some beans, so here goes — the vast majority of account compromises we see are the result of password reuse. This occurs when you use the same email and password here as you do at some other poorly secured website which then goes and gets hacked. Often, these credentials are leaked/sold/otherwise made available and attackers will just try the lot of them — sometimes they're lucky and get an admin account. 2FA in this case would prevent them from logging in. Something I suggested in the above task was routine auditing of passwords against known leaked credentials (something which https://haveibeenpwned.com offers), which would let us combat some of these common compromise vectors without using 2FA. I don't want to derail this discussion, but this feels like the enwiki security review RfC all over again — deciding to not take reasonable precautions to protect your account is not a valid excuse, yet it's quite clear we've made it one as our policy is unenforceable — TheresNoTime (talk • they/them) 03:27, 27 September 2022 (UTC)Reply[reply]
  • Hard cases make bad law; I would not see a compelling reason to have a blanket policy that you might not find makes sense later. That said, anyone getting compromised twice probably needs to go back to RFA. Stifle (talk) 08:27, 27 September 2022 (UTC)Reply[reply]
  • We'd achieve a lot more security by implementing technical best practices (many suggested above) rather than trying to regulate human behavior: long minimum lengths, checking against password breaches, throttling failed login attempts, disallowing reused passwords and common words/patterns, etc., and of course that includes 2FA. For example, see the NIST standards (summary); there are others, too. We don't need to create rules and then monitor humans for compliance with those rules, we can make compliance a technical requirement: as in, if your password isn't good enough, you can't log in at all. That'll save volunteers a lot of compliance/enforcement work. Whatever our password policies are, I support arbcom in sanctioning admins who repeatedly fail to comply, e.g. by desysop. Levivich (talk) 15:01, 27 September 2022 (UTC)Reply[reply]
  • Without spilling the beans (and tell me if there's no plausible way to answer this question without spilling) - what's the worst case scenario for an admin account compromised by a competent attacker who is hostile or indifferent to Gpedia's integrity? Feel free to answer vaguely or qualitatively so as to not advertise a method. Tazerdadog (talk) 18:31, 27 September 2022 (UTC)Reply[reply]

    [...] there are plenty of things that +sysop allows that are irreparable, either in a PR sense, or unrepairable without a truly stupefying amount of work, or in a few cases literally so. Most of them we don't talk about. One of the most obvious, and one that we can talk about because it's already happened (before we had cascading protection, so it didn't require being an admin at the time), is to put a shock image on the main page disguised in such a way that it takes a long time to remove. [...]
    — Cryptic 16:20, 14 September 2022 (UTC), Gpedia talk:Requests for adminship#Accusing someone of being a sock in an RfA?

    I think I know some of the details involved, but don't feel like it would be a good idea to share more. See also mw:User:MZMcBride/Attacks#Privileged account, although that was written years ago so is somewhat outdated. * Pppery * it has begun... 18:35, 27 September 2022 (UTC)Reply[reply]
    @Tazerdadog: I don't really think there is a way of answering that without potentially saying too much — I suppose if you consider what a rogue admin could carefully do without drawing attention to themselves, that's going to put you on the right track. The bottom line is a fair bit of damage to content, reputation, and the community. — TheresNoTime (talk • they/them) 18:38, 27 September 2022 (UTC)Reply[reply]
    @Tazerdadog worst case is probably along the lines of an identify takeover - compromising an admin account of a really-not-here admin, becoming "active" again - and then doing things that drive away readers or editors. The actual account owner might not even know this has occurred. There are certainly some annoying-to-fix technical BEANSy things, but I'm not going to go in to those - they can be fixed and are mostly a time-sink for other admins. — xaosflux Talk 18:40, 27 September 2022 (UTC)Reply[reply]
    (edit conflict) We know from experience that most admin compromisers either use the tools to cause easily-undoable chaos or don't use them at all, so "what's the worst thing a compromised or rouge admin can do" may not be the right thing to think about. * Pppery * it has begun... 18:40, 27 September 2022 (UTC)Reply[reply]
    Imo, the worst case scenario is very bad. We've honestly been quite lucky so far. But luck is no basis for security. CaptainEek Edits Ho Cap'n! 19:26, 27 September 2022 (UTC)Reply[reply]
  • There is no excuse in 2022 for an administrator having a weak password and not using 2FA and other basic security tools. I would consider a person who does not use proper modern security on an account granted advanced permissions (with access to all kinds of potentially damaging info) to be unworthy of the community's trust. EnPassant♟♙ (talk) 20:00, 28 September 2022 (UTC)Reply[reply]
  • It's not exactly what you are asking, but I would like to ask you to consider amending this clause: If the editor in question requests it, or if the Committee determines that a routine reinstatement of permissions is not appropriate, normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances. This is not what happens in most cases, especially when people are desysopped under level II procedures. It's a case where for a long time the letter of the law has not kept up with current practices. If I had to make a proposal, I'd put forth this one: If the editor in question requests it, or If the Committee determines that a routine reinstatement of permissions is not appropriate normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances, provided that the editor in question requests it; failing that, the removal is permanent. Salvio 20:33, 28 September 2022 (UTC)Reply[reply]
  • I like the idea of having the system require various features of strong passwords, a minimum number of characters, mixed case and or special characters. It doesn't directly address the reuse issue, except that someone who has been reusing passwords might now need a stronger one for Gpedia. If we can set rules that require specific accounts to have 2FA, then I'm OK with doing so as a condition for return of userrights. If your account gets compromised then you have to deploy 2FA to get back the same level of trust. Most of our admins are not active as admins, it would be sensible to add a rule inactive and semi active admins whose accounts are compromised can request return of tools three months after regaining control of their account and returning to a fairly active status (100 edits per month). This removes the need to discuss reinstating tools for compromised semi active accounts until and unless they return to an active status. ϢereSpielChequers 04:28, 3 October 2022 (UTC)Reply[reply]
    I like this idea, but instead of listing the requirements here I'd reference the standard provisions for admin activity so that they are always in sync. Thryduulf (talk) 10:29, 3 October 2022 (UTC)Reply[reply]
  • On one hand, I think admins should be expected to keep their account secure (including using 2FA as mandatory, or at the very least being permanently desysopped if they don't use 2FA and their account gets compromised), and using strong passwords. On the other, even the most conscientious admin could be hit by a zero day attack and compromised, and of course we shouldn't hold that against them. So, require admins to take reasonable measures for account security, but do realize those will never be perfect. Seraphimblade Talk to me 03:35, 13 October 2022 (UTC)Reply[reply]
    While 2FA is fine in concept (and I use it on my important email accounts), I will not support requiring the use of the current implementation of 2FA on English Gpedia. I do have 2FA enabled where required on Wikimedia accounts, but the first such account I had was bricked within a month. If the current implementation of 2FA is ever required for English Gpedia admin accounts, I will resign my adminship rather than risk losing access to my 17-year-old account. - Donald Albury 13:16, 17 October 2022 (UTC)Reply[reply]
    I agree the current implementation is lacking — I'd quite like to understand (not just from you, but 'across the board') what the primary concerns are, so that we can get them addressed. — TheresNoTime (talk • they/them) 13:29, 17 October 2022 (UTC)Reply[reply]
    @TheresNoTime from the back of my head - my biggest concern was around the fallback issue. If a user loses access to their token (and scratch codes) they cannot get access to their account without going through T&S and T&S are not set up for a significant volume of these. WormTT(talk) 13:45, 17 October 2022 (UTC)Reply[reply]
    I agree with that, though I would also say that this is the same for a lot of 2FA implementations (i.e., if you forget your scratch codes for your Google account, you're going to have to go through Google support to recover your account — admittedly, Google support is pretty well set up to handle an influx of such requests, but there's a fairly good chance they can't prove your ownership of the account..) — TheresNoTime (talk • they/them) 13:50, 17 October 2022 (UTC)Reply[reply]
    My experience was that my password and/or transmitted code didn't work, nor did the codes from the scratch pad. I have no idea what went wrong, although I suspect I made a mistake somewhere along the way. There was no problem establishing my identity through other channels, but I was issued a new account rather than restoring my access to the original account. Losing access to that original account was not a big issue, but losing access to my primary user/en-admin account on Gpedia would be. In my experience, I have never had an account hacked, but I have lost one to 2FA, whatever the cause. A very poor sample, but all I have. I do use a unique, complexly constructed password for my WP account, and do change it ocassionally. I also have 2FA implemented on the email account linked from my WP account. Donald Albury 14:31, 17 October 2022 (UTC)Reply[reply]
  • I already said this back in March but I suppose I'll say it again. We can probably assume that those who seek to hack another editor's account are those who're already within the wiki community ("Would anyone else try to track down random stranger's login and password on some random forum?" Probably not). As much as we put in stringent password requirements or making 2FA mandatory, there is no accountability or punishment for any editors to attempt hacking another's account. To repeat my analogy, the current community and ArbCom approach is to punish those who have weak doors (passwords), not the thief that's studying the kind of lock on the door (trawling through haveibeenpwned and other leaked password sites) and picking the locks for these doors. It should be standard practice to run a CU the moment an account is compromised and check if there's any associated accounts. If there is, sure the compromised account is at fault and needs to be desysoped at level 1, but the hacking person revealed through CU should also be banned. Until we see some accountability and actions that punish the hacker, the hacking will continue because there's no consequence for the hacker to stop. OhanaUnitedTalk page 03:48, 17 October 2022 (UTC)Reply[reply]
    @OhanaUnited: it is standard practice to, as you wisely suggest, attempt to determine who compromised an account. Best, KevinL (aka L235 · t · c) 04:27, 17 October 2022 (UTC)Reply[reply]
    Good to hear that it's now standard practice. Cause it didn't seem like it back in 2015 when my account was compromised (or at least the findings weren't communicated to me, even if it's "sorry we don't have any result") OhanaUnitedTalk page 14:00, 17 October 2022 (UTC)Reply[reply]
  • Require 2FA for administrator and above accounts. A prerequisite is that WMF needs to provide technical support to resolve the inevitable lockouts. Having to chase down a developer to recover from a lost authenticator device is far from ideal. Jehochman Talk 19:51, 17 October 2022 (UTC)Reply[reply]
    Even though it wouldn't strictly be necessary, any requirement of 2fa for Admin accounts should probably go through a well-publicized RFC, to address community concerns.Jackattack1597 (talk) 21:17, 18 October 2022 (UTC)Reply[reply]
    That might be a way to show WMF the importance of supporting users who lose their authenticator device (loss, theft, electronic failure). Jehochman Talk 01:40, 19 October 2022 (UTC)Reply[reply]
  • NIST guidelines quoted above by Levivich are, if you look closely, Active Directory specific. More thorough discussion of current best practices is here. While back-end checking the hashed passwords against dictionaries of known compromised and easy to crack passwords is popular and appropriately cinematic, in my experience the best countermeasure against password hacking (once the hashed passwords are secure against observation) is failed login notification and limited login attempts--10 before being locked out per the above link, for example. Secure login methods reduce availability, as comments above have noted, and hard limits on failed logins create an opportunity to disable known accounts, so some automatic unblocking is a necessary relief valve. One novel method recently implemented in one of my university accounts is an image-based "something ELSE you know" that picks one of three user-selected images and shuffles it in amongst ~40 others, requiring no other hardware or communication channel. I cannot emphasize enough how simple a 2FA solution really needs to be in order to be effective. Microsoft and Apple pushing 2FA everywhere clearly provide a help-desk full employment program for organizations following their recommendations. Jclemens (talk) 06:14, 19 October 2022 (UTC)Reply[reply]
    Limited login attempts can cause a denial of service for the account who a bad actor attempted to compromise, which you note. My understanding is that WMF has declined to implement that option accordingly. I suppose it would be possible to implement on some sort of IP basis, but that's easy enough to get around for the motivated bad actor.
    As for images, that is essentially a CAPTCHA, which is already known to be an issue, so I'm not sure it's meaningful to chase that. Izno (talk) 21:36, 2 November 2022 (UTC)Reply[reply]
    It's not really a captcha, because only the editor knows which image is the one they selected. I've used a similar system before, and you get a panel of six images and you select from that panel the image you've already chosen. You then have to identify the image with the label you've provided for it.
    You log in as normal, with your name and password and if successful you see a panel of images, one of which you've chosen and labeled as your 2fa. The panel contains a train, a duck, a walrus, a table, a hat, and a telephone. You select the duck, which is the image you've chosen prior, and enter the label you've signed to it, e.g. Donald. Then you're successfully logged in.
    An attacker would then need your password, knowledge of which image you've selected, and the label you've applied to the image. Locking out an account with multiple failed logins at the image selection avoids the problem of using failed logins as a dos attack, since if they've gotten that far the password is already compromised and the account should be locked. ScottishFinnishRadish (talk) 22:25, 2 November 2022 (UTC)Reply[reply]
    This does not solve almost all of the accessibility issues with captchas for those who are unable to see images for whatever reason, e.g. a disability. Thryduulf (talk) 10:21, 3 November 2022 (UTC)Reply[reply]
    It's an anti-phishing mechanism that works equally well with a pre-selected phrase. Note, though, it's a knowledge-based authentication mechanism, so it can't be combined with a password to implement a two-factor authentication system. isaacl (talk) 15:43, 3 November 2022 (UTC)Reply[reply]
    Limited login attempts can cause a denial of service for the account who a bad actor attempted to compromise, which you note. My understanding is that WMF has declined to implement that option accordingly. Given the choice, I'd choose a locked-out admin account over a breached admin account every time. The WMF chose wrong here. Levivich (talk) 21:28, 15 November 2022 (UTC)Reply[reply]
    No, the WMF chose correctly. Some abusive character (as is common these days at WP:RFA, for a specific and already-known example) would lock out every account that participates there. That sure sounds like fun for both the WMF and each and every one of those people. And that doesn't even end the disruption. There may be a world in which a lockout is a feasible end-state, but it's not today's with such a naive approach. Izno (talk) 22:02, 15 November 2022 (UTC)Reply[reply]
    As Izno alludes to, the lockout would have to apply for all accounts, to avoid information leaking. So while it could be done, it potentially has far-reaching effects: someone could lock out large swaths of editors. isaacl (talk) 22:07, 15 November 2022 (UTC)Reply[reply]
    Nah, because security software would prevent all accounts from being locked, or even many accounts from being locked within a short time. Just like security software would alert if there were many login failures across many accounts. There's DOS and there's also DOS protection. It ain't the 90s internet anymore, and this is one of the world's busiest websites, I'm sure our $3M/yr hosting includes some firewall protection stuff. We can lock accounts for too many failed passwords without risking locking out all (or even many) accounts in a lockout attack. Levivich (talk) 22:44, 15 November 2022 (UTC)Reply[reply]
    Sure; the point is that it's not a choice between a locked-out admin account and a breached admin account. All accounts would be affected, and as you point out, measures other than locking out the account could be used to diminish the chances of a compromised account. isaacl (talk) 22:54, 15 November 2022 (UTC)Reply[reply]
    All accounts would not be affected. It's quite possible to have extra security measures (such as auto-lockout after a certain number of failed login attempts) that only apply to some accounts (such as those with advanced permissions). Levivich (talk) 23:35, 15 November 2022 (UTC)Reply[reply]
    In general, it's not desirable to leak information in that manner about what accounts have advanced permissions. In the specific case of Gpedia, though, true enough that the information is already publicly visible. isaacl (talk) 23:43, 15 November 2022 (UTC)Reply[reply]
    If you lock out accounts then you need to have a process by which those who have been locked out through no fault of their own can get back in to their accounts without letting back in those who should not be, and this process needs to be resilient enough and resourced enough to deal with the maximum number concurrent requests in a timely manner with the minimum possible number of false positives and false negatives. Neither MediaWiki nor the WMF have a process that can reliably deal with the current tiny numbers of 2FA lockouts, let alone anything greater than that. Thryduulf (talk) 13:19, 16 November 2022 (UTC)Reply[reply]
    I suspect this is much closer to the real reason why the WMF chose not to have failed-login lockouts: ultimately, they'd need to spend $$$ on account recovery. The usual recovery procedure (click "forgot my password," optionally answer a security question, get emailed a password reset link) would require requiring users to provide an email address (which seems to me to be a good idea anyway for certain advanced-permission accounts, like admins and functionaries). But meh, this is instance #23408957 of me being perplexed as to why the usual method that the rest of the world uses is not good enough for the WMF. Although I think the explanation, as always, is that they just don't want to spend the money (even though they have the money to spend). Levivich (talk) 17:09, 17 November 2022 (UTC)Reply[reply]
  • Have the potential returning admin clearly and explicitly confirm that their password is at least 10 characters and not used anywhere else and explicitly agree to continue that practice. Maybe add a few more things like it's not on a sticky note on their monitor. Heck, it would be good & needed preventive medicine and very reasonable to have all admins confirm that. I don't think that people are going to lie about that. 2FA schemes have lots that can go wrong or impair things. Sending to RFA sounds like a bad idea....sounds like it would only be deterrence/punishment. RFA is structured for other things, not community judgement on password issues. Sincerely North8000 (talk) 22:01, 2 November 2022 (UTC)Reply[reply]
    An admin can claim his/her password meets certain criteria; unless either he/she is stupid enough to use an obvious password, or tells ArbCom what the new password is (the latter certainly shouldn't be encouraged), it's impossible to enforce. Unless ArbCom know the password, it's impossible to check out the admin's statement that the same password isn't currently being used elsewhere. A password manager can be used on a private computer, but not on a shared one (even shared only by family). Most users who use 2FA probably do it on a device they leave logged in to their Gpedia email, and stealing or hacking the device may allow them to break into an account. These are all issues a former admin can lie about, and probably will if they believe that is the only way to get their adminship back. Animal lover |666| 19:33, 20 November 2022 (UTC)Reply[reply]
    This is obviously an issue, but if (for example) there is a database dump (I think "Have I Been Pwned" has been mentioned above) and a username matching a compromised admin account appears on such a list, then it is reasonably likely that the password was reused. Yes, the admin could lie, but we do take evidence like that into consideration when looking at the possibility of a resysop. Primefac (talk) 19:39, 20 November 2022 (UTC)Reply[reply]

Discretionary sanctions

The Arbitration Committee's procedure on modification of procedures requires all [s]ignificant or substantive modifications of the Arbitration Committee's procedures to be made by way of formal motions on the Committee's public motions page. The Committee will soon vote on the proposed decision for discretionary sanctions review, which if enacted will result in substantive modifications to the Committee's procedures. Therefore, to comply with the requirements of the procedure, I am transcluding the proposed decision below. (The procedure also contains notification requirements, which have been met in this case.) KevinL (aka L235 · t · c) 03:18, 17 November 2022 (UTC)Reply[reply]

Status as of 04:26 (UTC), Monday, 5 December 2022 (Purge)

  • The proposed decision has been posted following the Phase I and Phase II community consultations.
    • The Proposed Decision voting phase has now opened.
    • Any interested editors are invited to comment on the proposed decision talk page.
    • This page reflects the merged revised text in the event that all proposals in the proposed decision pass without amendment.
  • To be notified about updates, subscribe to the update list.

The revision process will be conducted in four phases:

  1. Phase I community consultation (March – April 2021) (closed)
  2. Phase II community consultation (September – October 2022) (closed)
  3. Proposed decision (November 2022)
    Taking into account the feedback from the Phase I and II community consultations, the drafters will release a proposed decision revising the current discretionary sanctions procedure.
    • Public review (November 13 – 18, 2022): Before any votes are cast on the proposed decision, the community will have a five-day period in which to provide comment on the proposed decision talk page. During this time, the proposed decision will undergo further linguistic and stylistic revisions and arbitrators may post additional proposals and amendments.
    • Committee vote (following public review): Each proposal within the proposed decision will receive a vote. Proposals that receive an absolute majority will be enacted.
  4. Implementation: The drafting arbitrators will implement the Committee's decision in conjunction with the Committee's clerks and interested volunteers designated by the Committee.

All dates listed here are approximate and are subject to significant change. The revision process will be managed by drafting arbitrators designated by the Arbitration Committee (CaptainEek, L235, Wugapodes).

On this page, arbitrators will consider proposals for the outcome of the review process. After all the proposals have been voted on, the process will conclude with a motion to close.

Comments are welcome on the talk page. The proposed decision will be posted for five days of community review and comment before arbitrators vote on the proposals in order to allow the Committee to receive suggestions for stylistic or typographical amendment.

For these motions there are 12 active arbitrators. 7 support or oppose votes are a majority.

Majority reference
Abstentions Support votes needed for majority
0 7
1–2 6
3–4 5

Name

Proposal summary

The discretionary sanctions (DS) system will be renamed "contentious topics" (CT), and restrictions placed within the DS system will be referred to as "contentious topic restrictions".

Consultation rationale and comments
Language

The language in subsequent proposals reflects the "contentious topics" and "contentious topic restrictions" language. In the event that an alternative name proposal is passed, the wording will be substituted as appropriate.

Vote (Name)

Support
  1. I support a change for the reasons given at the consultation under "Rationale". I think contentious topics is a better name than arbitrated topics because arbitrated topics creates extra ambiguity with the community GS version of this system. I think I could still be convinced to support a name like "heightened scrutiny topics" but I think contentious topics is (1) better than DS and (2) has reasonably high support. Best, KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
    Reasons to oppose the current Other suggestion should probably be in the context of the other suggestion so people who support Another Name don't have to discuss it in two different places. This proposal is only discussing whether 1) to change the name and 2) whether to change the name to CT. Anyway, regarding your creates extra ambiguity with the community GS version of this system, I don't see how. At all. Is "ambiguity" actually the word you intended? I would levy contentious topics as a far worse offender on the point if indeed you mean "ambiguity", categorically. Izno (talk) 18:06, 21 November 2022 (UTC)Reply[reply]
  2. A name change is in the cards. Izno (talk) 18:06, 21 November 2022 (UTC)Reply[reply]
  3. Second choice (at least among the current two we're considering). --BDD (talk) 01:26, 22 November 2022 (UTC)Reply[reply]
  4. First choice. A new name is a must for me and I think this is slightly better than AT. Barkeep49 (talk) 22:37, 22 November 2022 (UTC)Reply[reply]
  5. Only choice, although I can still live with the status quo of "discretionary sanctions". Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  6. First choice. I prefer this to DS, and Arbitrated topics. WormTT(talk) 14:45, 23 November 2022 (UTC)Reply[reply]
  7. First choice Wug·a·po·des 00:13, 25 November 2022 (UTC)Reply[reply]
  8. Cabayi (talk) 12:08, 28 November 2022 (UTC)Reply[reply]
  9. A name change is long overdue. "Discretionary sanctions" was esoteric and arcane, and did not tell the average editor what it meant. While I understand "Contentious Topic" in and of itself is a term of art, it is the clearest, most simple term we imagined. I don't like Arbitrated topics because it is simply not evident at a glance what that means. CaptainEek Edits Ho Cap'n! 18:11, 29 November 2022 (UTC)Reply[reply]
  10. There are so many things on this project that got named years ago and the name doesn't really fit with the process but we seem to be stuck with it (I don't personally think "Arbitration" is actually what the committee does at all, but I'm not even going to try and fix that) and I've always felt "discretionary sanctions" was vague and somewhat intimidating. We're trying to get people to understand that when they show up in one of these topic areas, they are not the first, and will not be the last, who are there to Right Great Wrongs. "Contentious topics" expresses that much better than "discretionary sanctions." Beeblebrox (talk) 20:56, 1 December 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
The name is something I'm still having trouble with, and I think a number of arbs are still thinking through. Best, KevinL (aka L235 · t · c) 22:12, 13 November 2022 (UTC)Reply[reply]
Also, another open question is whether Contentious Topic Restrictions should be capitalized or not – the draft currently does not title-case it, Best, KevinL (aka L235 · t · c) 19:57, 14 November 2022 (UTC)Reply[reply]
You might think that because I am replying to this comment that I care, even just a little, about whether or not we capitalize "Contentious Topic Restrictions" but you would be wrong. Whatever our grammar mavens in the community and on the committee prefer is great by me. Barkeep49 (talk) 19:59, 14 November 2022 (UTC)Reply[reply]
I continue to think that if we go with this term, it should be capitalized unless we mean the more general sense of topics which are contentious. That may be a reason to prefer the alternative. --BDD (talk) 16:43, 21 November 2022 (UTC
Whether it is capitalized or not, it will become a term of art and it will used in the lowercase. This is another reason I oppose the name contentious topics and why I think you should also. Izno (talk) 18:06, 21 November 2022 (UTC)Reply[reply]
Per this comment, I've changed "individual restriction" to "editor restriction" to hopefully make it more clear. It's a bigger change, so if an arb disagrees I'll revert it and start a separate amendment vote. Best, KevinL (aka L235 · t · c) 10:23, 19 November 2022 (UTC)Reply[reply]
I'm sorry, but I have not felt engaged in this process. I am abstaining on each question to make it easier for the committee to find a consensus. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]

Amendment: Arbitrated topics

In place of "contentious topics", the new name will be "arbitrated topics", and the text of all the proposals will reflect that new name.

Support
  1. As discussed at the most recent consultation in addition to the talk page of this decision, I firmly believe that contentious topics as a name will become a term of art comparable to notability and everyone voting in this decision knows how bad that was (we've had two decades of arguing with people who don't understand how Gpedia's notability isn't the rest of the world's). Contentious topic will do the same, and be more likely, not less, to confuse editors new to editing, and new to editing about both contentious topics and contentious topics, and may indeed (as mentioned at this PD's talk page) lead to support for more, not fewer, restricted topics as people misjudge contentious topics to merit contentious topic restrictions simply due to the area of interest. That's bad. If we're going to make a term of art, and we have to do that regardless of whether we want to or not, it should be a term of art that is sufficiently plain English that you can ferret out what's going on, but insufficiently plain English to overrun the common use of the name we end up picking. Contentious topic falls in the too plain pile for me.

    I am happy to discuss or support other terms of course, but over several weeks nothing seems to have grabbed anyone's happiness, and the discussion that should have happened on the point between arbitrators basically hasn't. --Izno (talk) 18:06, 21 November 2022 (UTC)Reply[reply]

  2. First choice. Consider me convinced. While terms of art may be unavoidable in some circumstances, the cardinal sin of "discretionary sanctions" was the lack of information it conveyed, whereas "arbitrated topics" does very well in the regard. --BDD (talk) 01:25, 22 November 2022 (UTC)Reply[reply]
  3. Second choice. A new name is a must for me and I think this is slightly worse than CT. Barkeep49 (talk) 22:37, 22 November 2022 (UTC)Reply[reply]
  4. Second choice. WormTT(talk) 14:45, 23 November 2022 (UTC)Reply[reply]
  5. Second choice. Agree with Izno that the alternative is likely to become a term of art, but at least the term is more transparent than the original. I think "arbitrated topics" is likely also to become a term of art in that "arbitrated" is not particularly transparent to those unfamiliar with the committee, especially since it will be administered by non-arbitrators. It also doesn't have the benefit of being exdtensible to the GS regime. The community can theoretically apply "contentious topic restrictions" to anything it wants in the same way lots of GS bootstrap DS policy. But what would the community correlary to AT be? Community topics? I think either is fine, but slight preference for the alternative. Wug·a·po·des 00:19, 25 November 2022 (UTC)Reply[reply]
Oppose
  1. It makes it sound like content decisions in a given topic are being done by arbitration. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  2. per Maxim's logic. Cabayi (talk) 12:09, 28 November 2022 (UTC)Reply[reply]
  3. I prefer Contentious Topics per Wugapodes. Best, KevinL (aka L235 · t · c) 02:16, 29 November 2022 (UTC)Reply[reply]
  4. Per my vote on CT. CaptainEek Edits Ho Cap'n! 18:11, 29 November 2022 (UTC)Reply[reply]
  5. I understand the intent but I think CT is a more direct term and therefore easier for newcomers to understand. Beeblebrox (talk) 20:57, 1 December 2022 (UTC)Reply[reply]
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
  • I'd like to suggest that arbitrators in this section supporting this name as a 2nd choice instead oppose the amendment, as this section means to modify the original proposal, not be a separate proposal to be enacted. It would do two things that I think are beneficial: 1) it makes it clear to clerks, and 2) it makes it obvious that this choice needs its own separate majority to the originating proposal for the remaining arbs who have not voted. Izno (talk) 22:38, 28 November 2022 (UTC)Reply[reply]

Nutshell

Proposal summary

Clarify the "in a nutshell" box.

Consultation rationale and comments
Language
Extended content

Contentious topics are specially-designated topics that have attracted more persistent disruptive editing than the rest of the project. Administrators are allowed to impose editing restrictions on editors who do not follow project expectations within contentious topics. Administrators are also allowed to set special rules on pages within a contentious topic to prevent inappropriate editing.

Vote (Nutshell)

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:08, 21 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 01:28, 22 November 2022 (UTC)Reply[reply]
  4. Cabayi (talk) 14:26, 22 November 2022 (UTC)Reply[reply]
  5. One of the ways to make DS (AT/CT) more accessible for non-experts. Barkeep49 (talk) 22:40, 22 November 2022 (UTC)Reply[reply]
  6. Primefac (talk) 13:22, 23 November 2022 (UTC)Reply[reply]
  7. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  8. WormTT(talk) 14:45, 23 November 2022 (UTC)Reply[reply]
  9. Wug·a·po·des 00:20, 25 November 2022 (UTC)Reply[reply]
  10. CaptainEek Edits Ho Cap'n! 18:13, 29 November 2022 (UTC)Reply[reply]
  11. Beeblebrox (talk) 21:08, 1 December 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators

Lead section

Proposal summary

Add a lead section that describes the ArbCom contentious topics system and describes expectations of editors.

Consultation rationale and comments
Language
Extended content

A special set of rules applies to certain topic areas, which are referred to as contentious topics (abbreviated CT). These are specially-designated topics that have attracted more persistent disruptive editing than the rest of the project and have been designated as contentious topics by the Arbitration Committee.[a] Not all topics that are controversial have been designated as contentious topics – this procedure applies only to those topics designated by the Arbitration Committee (list). When editing a contentious topic, Gpedia's norms and policies are more strictly enforced and Gpedia administrators have additional authority to reduce disruption to the project.

Editing a contentious topic

Within contentious topics, you must edit carefully and constructively, refrain from disrupting the encyclopedia, and:

You should err on the side of caution if you are unsure whether making a particular edit is consistent with these expectations.

Within contentious topics, administrators have the ability to set editor restrictions (restrictions on editing by particular editors) and page restrictions (special rules on how particular pages can be edited). Some of these abilities may be exercised by a single administrator while others require a consensus of administrators. All editor and page restrictions may be appealed.

Vote (Lead)

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:09, 21 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 01:29, 22 November 2022 (UTC)Reply[reply]
  4. Cabayi (talk) 14:27, 22 November 2022 (UTC)Reply[reply]
  5. I think this makes the topic understandable to a wide range of editors in a way that's very important to me. I consider this LEAD to be policy as much as the text that follows, not just a summary as we would expect in an article. Barkeep49 (talk) 22:42, 22 November 2022 (UTC)Reply[reply]
  6. Primefac (talk) 13:22, 23 November 2022 (UTC)Reply[reply]
  7. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  8. WormTT(talk) 14:47, 23 November 2022 (UTC)Reply[reply]
  9. Wug·a·po·des 00:21, 25 November 2022 (UTC)Reply[reply]
  10. CaptainEek Edits Ho Cap'n! 18:13, 29 November 2022 (UTC)Reply[reply]
  11. Beeblebrox (talk) 21:09, 1 December 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators

Awareness

Proposal summary

The current awareness criteria are replaced with an appealable presumption of awareness following an initial alert. The use of the standard template alert becomes optional after a user's first alert.

Consultation rationale and comments
Language
Extended content

When an editor first begins making edits within any contentious topic, anyone may alert the editor of the contentious topic designation using [CT/TOPICNOTICE] template. Only the officially designated templates should be used for an editor's first contentious topic alert, and these templates may not be placed using a bot or other form of automated editing without the prior approval of the Arbitration Committee. When alerting an editor who has previously received any contentious topic alert, the [LINK] template may be used, but any message that conveys the contentious topic designation is acceptable.[b]

If the enforcing administrator believes that an editor was not aware that they were editing a designating contentious topic when making inappropriate edits, no editor restrictions (other than a logged warning) should be imposed.[c] Once alerted to a specific contentious topic, editors are presumed to remain aware but may attempt to refute this presumption on appeal.[d]

Draft template language

Edits to the templates may be approved by the clerks following consultation with the Arbitration Committee.

First-time CT alert recipients

You have recently made edits related to [CT code], which is a designated contentious topic. This standard message is designed as an introduction to contentious topics and does not imply that there are any issues with your editing.

A special set of rules applies to certain topic areas, which are referred to as contentious topics. These are specially-designated topics that tend to attract more persistent disruptive editing than the rest of the project and have been designated as contentious topics by the Arbitration Committee. When editing a designated contentious topic (full list), Gpedia's norms and policies are more strictly enforced and Gpedia administrators have additional authority in order to reduce disruption to the project.

Within contentious topics, you must edit carefully and constructively, refrain from disrupting the encyclopedia, and:

adhere to the purposes of Gpedia;
comply with all applicable policies and guidelines;
follow editorial and behavioural best practice;
comply with any page restrictions in force within the area of conflict, which are described in editnotices on affected pages; and
refrain from gaming the system.

You should err on the side of caution if unsure whether making a particular edit is consistent with these expectations. If you have any questions about contentious topics procedures you may ask them at the arbitration clerks' noticeboard or you may learn more about this contentious topic [LINK TO TOPIC-SPECIFIC CT PAGE]. You may also choose to note which contentious topics you know about by using the {{Ct/aware}} template.

CT alert templates for those previously alerted to DS

Information icon You have recently made edits related to [CT code]. This is a standard message to inform you that [CT code] is a designated contentious topic. This message does not imply that there are any issues with your editing. Contentious topics are the successor to the former discretionary sanctions system, which you may be aware of. For more information about the contentious topics system, please see [LINK]. [MAYBE: For a summary of the differences between discretionary sanctions and contentious topics, see WP:CTVSDS].]

Subsequent CT alert templates

Information icon You have recently made edits related to [CT code]. This is a standard message to inform you that [CT code] is a designated contentious topic. This message does not imply that there are any issues with your editing. For more information about the contentious topics system, please see [LINK].

Vote (Awareness)

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:09, 21 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 02:41, 22 November 2022 (UTC)Reply[reply]
  4. Cabayi (talk) 14:29, 22 November 2022 (UTC)Reply[reply]
  5. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  6. It would be unfair that an individual is sanctioned for something they were not aware about, but I feel the above is sufficient awareness requirement and has a refutation optionWormTT(talk) 14:50, 23 November 2022 (UTC)Reply[reply]
  7. I find this much preferable to the "well I guess I get my annual DS notice for XYZ today" yearly requirement that currently exists. Primefac (talk) 15:24, 24 November 2022 (UTC)Reply[reply]
  8. Per Primefac. Barkeep49 (talk) 19:03, 24 November 2022 (UTC)Reply[reply]
  9. Wug·a·po·des 00:30, 25 November 2022 (UTC)Reply[reply]
  10. Awareness should not be so bureaucratic. This is a step in the right direction. CaptainEek Edits Ho Cap'n! 18:14, 29 November 2022 (UTC)Reply[reply]
  11. The alert/awareness system has long been one of the most needlessly over-complicated things on WP. This is surely a step in the right direction. Beeblebrox (talk) 21:12, 1 December 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
One outstanding question is whether information currently found in the notes should be moved into the body of the text. I am leaning toward keeping it as is but think I could still be convinced. Best, KevinL (aka L235 · t · c) 22:12, 13 November 2022 (UTC)Reply[reply]
Clarified that the footnote criteria are independently valid ways to be aware, per @Vanamonde93's comment. Best, KevinL (aka L235 · t · c) 09:49, 19 November 2022 (UTC)Reply[reply]
I've changed these templates may not be placed using a bot or other form of automated editing. to these templates may not be placed using a bot or other form of automated editing without the prior approval of the Arbitration Committee. per the discussion below. Please revert if you disagree. Best, KevinL (aka L235 · t · c) 18:16, 29 November 2022 (UTC)Reply[reply]
I do disagree but I'm not prepared to revert because that feels like a large reaction to something this small. The reason I disagree is that it feels like we're adding "wikilaw" for something no one has asked for. This runs counter to the overall simplification goal. Barkeep49 (talk) 18:57, 29 November 2022 (UTC)Reply[reply]
Thanks to Procrastinating Reader who pointed out on the talk page a 2018 RfC which absent an ArbCom motion feels like it would have gained consensus. That said I think that discussion does show the difficulties any bot oriented proposal will take. However, the past demand is enough for me to not care so much about the particular bold change Kevin did. Barkeep49 (talk) 19:06, 30 November 2022 (UTC)Reply[reply]

Amendment: removing bot prohibition

Amend the previous proposal by striking the following: and these templates may not be placed using a bot or other form of automated editing.

Support
  1. Awareness should be a mere statement of fact. A bot which hands out the templates impartially is inherently less confrontational/adversarial than having another editor place the template. Cabayi (talk) 14:32, 22 November 2022 (UTC)Reply[reply]
  2. Speaking while holding my BAG hat in hand, bot requests are not approved until there is a clear plan and a consensus that the task should be run; a user with a plan still needs to have community consensus before filing a BRFA, especially if it is a task for automated notification such as this. If we do not strike this prohibition, then any proposal to create a bot-assisted notification system would need a willing bot operator with a plan, consensus from the community, and a motion from a future ArbCom to strike the prohibition. If we strike this prohibition, the only step that is not being taken is the final one; would a future ArbCom decline to strike this prohibition if there was community consensus that a bot to deliver notifications was acceptable? I cannot think of a reason for them to do so.
    In other words, I do see Izno's point, and largely agree with it, but that particular "needle" will be threaded either way, and this saves a future Committee time and effort. This is not necessarily a hill I feel a strong need to defend, though. Primefac (talk) 15:24, 24 November 2022 (UTC)Reply[reply]
  3. I support Kevin's amended wording. If someone wishes to make a bot, I'd be excited, but they will need to work with the Arbs. CaptainEek Edits Ho Cap'n! 18:19, 29 November 2022 (UTC)Reply[reply]
Oppose
  1. I don't think I can support removing this prohibition without also making it clear what an automated system would be required to do to deliver alerts. At a minimum, the name of an editor must be associated with each specific notice so as to prevent abuse. It doesn't need to be in the text of the talk page as delivered, but I think that requirement still makes it difficult to see a benefit of allowing bot or semi-automated editing that some espouse (namely, that people think these can be "revenge"-driven). Maybe others can think of other requirements or other ways to thread the needle; I'd be happy to see an amendment laying out some of those requirements. Izno (talk) 18:18, 21 November 2022 (UTC)Reply[reply]
  2. Per Izno. Barkeep49 (talk) 22:44, 22 November 2022 (UTC)Reply[reply]
  3. A bot would lack nuance. Do minor AWB edits—think of a simple, unambiguous typo fix like tpyo->typo—really merit an awareness notice? Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  4. To be clear, I support bot notificaiton - however, I do not feel this should be achieved by simply removing the text. I'd rather an actual plan for how bot notification should work was put in. WormTT(talk) 10:36, 24 November 2022 (UTC)Reply[reply]
  5. I do ultimately think bots should be able to do this, but see the merits of having a plan first. We should also consider whether to disentangle bot and automated editing in this regard. --BDD (talk) 15:50, 24 November 2022 (UTC)Reply[reply]
  6. I see Primefac's point, but ultimately I think the implementation of a bot should be subject to primarily committee oversight. Striking this line essentially means BAG gets the final say on how the bot runs, but given the issues at stake, I don't think BAG is structured in a way that makes me comfortable delegating. Wug·a·po·des 00:27, 25 November 2022 (UTC)Reply[reply]
  7. Count me as a vote for "yes, someone can propose a bot, but ask us first". Best, KevinL (aka L235 · t · c) 12:52, 25 November 2022 (UTC)Reply[reply]
    One possible compromise is and these templates may not be placed using a bot or other form of automated editing without the prior approval of the Arbitration Committee. Best, KevinL (aka L235 · t · c) 12:54, 25 November 2022 (UTC)Reply[reply]
  8. I am also not opposed to the very idea of a bot doing this, but I do support the idea that both the committee and BAG need to be on board with it. Beeblebrox (talk) 21:15, 1 December 2022 (UTC)Reply[reply]
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
  • Cabayi's argument seems convincing. Could we lift this prohibition and leave it for a later bot request to refine the parameters? Perhaps that doesn't answer the point about non-bot automated editing. --BDD (talk) 22:30, 22 November 2022 (UTC)Reply[reply]
    I'd personally rather prohibit until someone comes up with the set of requirements. This is something sufficiently severable from the rest of the procedure that I anticipate a future ArbCom could look at a proposed bot in relative isolation at A/R/M if the community proposed the specific requirements or if an ArbCom worked on the requirements itself. Izno (talk) 22:49, 22 November 2022 (UTC)Reply[reply]
    I agree with everything Izno wrote here except I would see it as eligible for proposal at ARCA. Best, Barkeep49 (talk) 22:51, 22 November 2022 (UTC)Reply[reply]
  • I don't see anybody putting in the work on a bot task if it's prohibited by our ruling. The door needs to be eased open somehow, and this is the first step. Cabayi (talk) 12:12, 28 November 2022 (UTC)Reply[reply]
    Would adding "without the prior approval of the Arbitration Committee" work to open the door? Best, KevinL (aka L235 · t · c) 19:09, 28 November 2022 (UTC)Reply[reply]
    I'd be fine with adding that. I don't think I'm too worried about Cabayi's concern, but the additional clause does nothing to harm and probably saves time for someone in the future. There's always a wikihistorian available to point to the vote-taking and the fact that most of the opposition is along these lines, but that takes some time. Izno (talk) 22:45, 28 November 2022 (UTC)Reply[reply]
    Done. KevinL (aka L235 · t · c) 18:17, 29 November 2022 (UTC)Reply[reply]

Appeals and amendments

Proposal summary
  • Lowers the level of consensus required for a successful appeal from "clear and substantial consensus" to "clear consensus"
  • Provides clear standards of review on appeal
Consultation rationale and comments
Language
Extended content

All contentious topic restrictions (and logged warnings) may be appealed. Only the restricted editor may appeal an editor restriction. Any editor may appeal a page restriction.

The appeal process has three possible stages. An editor appealing a restriction may:

  1. ask the administrator who first made the contentious topic restrictions (the "enforcing administrator") to reconsider their original decision;
  2. request review at the arbitration enforcement noticeboard ("AE") or at the administrators' noticeboard ("AN"); and
  3. submit a request for amendment ("ARCA"). If the editor is blocked, the appeal may be made by email.

Changing or revoking a contentious topic restriction

Administrators have the authority to revoke or change a contentious topic restriction if and only if:

  • The administrator who originally imposed the contentious topic restriction (the "enforcing administrator") affirmatively consents to the change, or is no longer an administrator;[e]
  • The contentious topic restriction was imposed by a single administrator and it was imposed or last renewed more than a year ago; or
  • An appeal is successful (see below).

An appeal is successful only if one of the following agrees with revoking or changing the contentious topic restriction:

  • a clear consensus of uninvolved administrators at AE,
  • a clear consensus of uninvolved editors at AN,
  • a majority of the Arbitration Committee, acting through a motion at ARCA.

Any administrator who revokes or changes a contentious topic restriction out of process (i.e. without the above conditions being met) may, at the discretion of the Arbitration Committee, be desysopped.

Standard of review

On community review

Uninvolved administrators at the arbitration enforcement noticeboard ("AE") and uninvolved editors at the administrators' noticeboard ("AN") should revoke or modify a contentious topic restriction on appeal if:

  1. the action was inconsistent with the contentious topics procedure or applicable policy (i.e. the action was out of process),
  2. the action was not reasonably necessary to prevent damage or disruption when first imposed, or
  3. the action is no longer reasonably necessary to prevent damage or disruption.

On Arbitration Committee review

Arbitrators hearing an appeal at a request for amendment ("ARCA") will generally overturn a contentious topic restriction only if:

  1. the action was inconsistent with the contentious topics procedure or applicable policy (i.e. the action was out of process),
  2. the action represents an unreasonable exercise of administrative enforcement discretion, or
  3. compelling circumstances warrant the full Committee's action.

Vote (Appeals and amendments)

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:20, 21 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 02:41, 22 November 2022 (UTC)Reply[reply]
  4. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  5. WormTT(talk) 10:56, 24 November 2022 (UTC)Reply[reply]
  6. Primefac (talk) 15:24, 24 November 2022 (UTC)Reply[reply]
  7. Barkeep49 (talk) 19:04, 24 November 2022 (UTC)Reply[reply]
  8. Wug·a·po·des 00:36, 25 November 2022 (UTC)Reply[reply]
  9. Cabayi (talk) 12:13, 28 November 2022 (UTC)Reply[reply]
  10. CaptainEek Edits Ho Cap'n! 18:20, 29 November 2022 (UTC)Reply[reply]
  11. Beeblebrox (talk) 21:17, 1 December 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators

Amendment: Appeal timeframe

Amend the previous proposal by adding the following text immediately before the "Changing or revoking a contentious topic restriction" header:

A rough consensus of administrators at AE or editors at AN may specify a period of up to one year during which no appeals (other than an appeal to ARCA) may be submitted.

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:20, 21 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 22:30, 22 November 2022 (UTC)Reply[reply]
  4. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  5. I agree with Izno below that this should not be generally the case, but if the user keeps coming back. WormTT(talk) 10:59, 24 November 2022 (UTC)Reply[reply]
  6. Agree with WTT and Izno that "tendentious appeals" should be added in some way to the language to indicate it is a precursor for this sort of moratorium. Primefac (talk) 09:56, 25 November 2022 (UTC)Reply[reply]
  7. Support is conditional on a note or footnote, along the lines of what Izno indicated below, being added. Barkeep49 (talk) 20:01, 25 November 2022 (UTC)Reply[reply]
  8. The Committee occasionally takes this tactic, and I see no reason why the admins of AE shouldn't be able to either. I'm fine with a note pointing out that this shouldn't be general practice. CaptainEek Edits Ho Cap'n! 18:22, 29 November 2022 (UTC)Reply[reply]
  9. This is clearly aimed at serial appellants and people who just can't seem to drop the stick, and that is exactly the sort of thing the committee is here to deal with. Beeblebrox (talk) 21:20, 1 December 2022 (UTC)Reply[reply]
Oppose
  1. Unnecessary. This should not be used routinely, and should be saved only for people who are using the appeal system disruptively. If they are using the appeal system disruptively, they can be sanctioned as needed to stop the disruption under CT anyway. So our process can already do what we want, but the proposed change opens the door to misunderstandings that we could simply avoid by leaving this as something for admins to resolve through practice. Wug·a·po·des 00:39, 25 November 2022 (UTC)Reply[reply]
    The inspiration for this suggested amendment was actually an ARCA request from two weeks ago. While the new language removes the ban on banning appeals, I think I'd rather give the hint here that it may be a potential outcome, rather than relying solely on DS's "anything to ensure the good function of the wiki" which is retained in the new policy. Izno (talk) 04:17, 25 November 2022 (UTC)Reply[reply]
    We could also bump this up from rough consensus to clear consensus if that would be better? Under the revised procedure, those two levels are different. Best, KevinL (aka L235 · t · c) 05:04, 25 November 2022 (UTC)Reply[reply]
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
We can also assign this ability to both AE and AN: A rough consensus of administrators at AE or editors at AN may specify a period of up to one year during which no appeals (other than an appeal to ARCA) may be submitted. Best, KevinL (aka L235 · t · c) 10:47, 15 November 2022 (UTC)Reply[reply]
Done. KevinL (aka L235 · t · c) 10:13, 19 November 2022 (UTC)Reply[reply]
I'd like a note here that says this should generally be used only to prevent users who have posted multiple specious appeals from continuing to appeal. --Izno (talk) 18:20, 21 November 2022 (UTC)Reply[reply]
I agree with Izno and suggest it be accomplished through a footnote. Barkeep49 (talk) 20:44, 24 November 2022 (UTC)Reply[reply]
How's this wording for a note? This authority should generally be exercised only when a user has submitted multiple specious appeals.
I don't know how I feel in substance about this note. Is it fair for us to regularly impose 6-12 month no-appeal periods after a first appeal but require AE to wait for multiple specious appeals? I think I am generally happy deferring to the wisdom of AE admins, with an appeal to ARCA possible if the decision was truly egregious (constituting "an unreasonable exercise of administrative enforcement discretion"). Best, KevinL (aka L235 · t · c) 10:11, 27 November 2022 (UTC)Reply[reply]
I considered that practice of ours before voting in support. I am not sure what my logic was to support it anyway. And if the case is extraordinary, generally isn't applicable. (There's a part of me that says that any extraordinary cases probably won't continue to be able to edit instead as a resolution.)
This may be a point of potential improvement in the future if AE admins are finding that users are abusing the latitude we give them to appeal, but they already have that latitude and haven't particularly abused it. Additionally, as I recall saying elsewhere, we have fallbacks in the appeals system, one of which is now the addition of admins kicking it to ARCA spontaneously. Izno (talk) 22:54, 28 November 2022 (UTC)Reply[reply]
Yeah, I am personally happier with no note. Best, KevinL (aka L235 · t · c) 22:57, 28 November 2022 (UTC)Reply[reply]

Amendment: earlier stages preferred

Amend the previous proposal by adding the following text immediately after the numbered list describing the stages of appeal:

Earlier stages of this appeal process are significantly preferred to later stages.

Support
KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
After some discussion and reflection, I might switch to an abstain or oppose on this amendment. I don't feel strongly that it should be included, and the structure of the section (and the differing standards of review at AE/AN and ARCA) already convey this to the extent that I'd like. Best, KevinL (aka L235 · t · c) 11:30, 25 November 2022 (UTC)Reply[reply]
Moved to oppose. KevinL (aka L235 · t · c) 18:41, 28 November 2022 (UTC)Reply[reply]
Izno (talk) 18:22, 21 November 2022 (UTC)Reply[reply]
  1. BDD (talk) 02:41, 22 November 2022 (UTC)Reply[reply]
Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
Oppose
  1. WTT makes a compelling argument; I would support his wording or similar but agree that the current language is not overly clear. Primefac (talk) 15:24, 24 November 2022 (UTC)Reply[reply]
  2. Per comment below. Barkeep49 (talk)
  3. I would support WTT's wording. Wug·a·po·des 00:40, 25 November 2022 (UTC)Reply[reply]
  4. Moving to oppose. I think the existing wording (under "Standard of review") makes it clear that it is harder to succeed at ARCA than at AE/AN, and that is as much as needs to be said on this point. Best, KevinL (aka L235 · t · c) 18:41, 28 November 2022 (UTC)Reply[reply]
  5. I'm fine explicitly opposing this. Izno (talk) 23:02, 28 November 2022 (UTC)Reply[reply]
  6. CaptainEek Edits Ho Cap'n! 18:29, 29 November 2022 (UTC)Reply[reply]
  7. WormTT(talk) 08:58, 30 November 2022 (UTC)Reply[reply]
  8. Cabayi (talk) 11:40, 1 December 2022 (UTC)Reply[reply]
  9. Beeblebrox (talk) 21:21, 1 December 2022 (UTC)Reply[reply]
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
This is my attempt to capture the spirit of this comment, but I'm not tied to the wording. Best, KevinL (aka L235 · t · c) 10:13, 19 November 2022 (UTC)Reply[reply]
I don't like the wording at all I'm afraid. "Preferred" and "earlier" don't make sense in my head, who's preference for example, and earlier implies time rather than numerically earlier. Could I suggest that we add something prior to the numbered list, like "An editor appealing a restriction may, in order of escalation,:"? Alternatively, "Editors should use the method with the least escalation unless there is a good reason not to"?
I don't oppose this wording I just.. don't like it. WormTT(talk) 11:08, 24 November 2022 (UTC)Reply[reply]
I agree with WTT though I don't love his wording. "Editors are typically expected to go through the stages in order" or "Outside of exceptional circumstances, editors are expected to go through the stages in order" are my 2 attempts. Barkeep49 (talk) 20:41, 24 November 2022 (UTC)Reply[reply]
I prefer that second one but either would be fine. The other thing I'm musing about is that this section kind of wants a link to the standards of review a couple sections down to help an editor make the decision in the context of where the options are presented, but that gets kind of clunky. Izno (talk) 20:46, 24 November 2022 (UTC)Reply[reply]
Hm, I think "preferred" captures my thinking best – we prefer it but we won't force it. If we really just mean "Outside of exceptional circumstances, editors are expected to go through the stages in order", I don't think we need to codify it – the fact that we present it in these three stages says enough. (Also, the standards of review convey this message quite clearly: AE will reverse a sanction for a broader range of reasons than ARCA will.) I'm really quite indifferent as to whether we add this sentence, so I'm happy to let it be dropped. Best, KevinL (aka L235 · t · c) 10:43, 25 November 2022 (UTC)Reply[reply]

Amendment: earlier stages preferred (2)

Amend the previous proposal by adding the following text immediately after the numbered list describing the stages of appeal:

Outside of exceptional circumstances, editors are expected to go through the stages in order.

Support
  1. Izno (talk) 23:02, 28 November 2022 (UTC)Reply[reply]
  2. Barkeep49 (talk) 23:31, 28 November 2022 (UTC)Reply[reply]
  3. I'd support this, but I'd also be fine with no text appearing at all. WormTT(talk) 08:58, 30 November 2022 (UTC)Reply[reply]
  4. As a statement of our preference & expectation, it's an innocuous statement. If you're reading it as a requirement (which I don't) I'd have to oppose. Cabayi (talk) 11:42, 1 December 2022 (UTC)Reply[reply]
Oppose
  1. I've pondered this and I don't think this accurately reflects how I think appeals should work. I don't think one should have to formally appeal to the enforcing admin before appealing at AE (for the same reason that we don't ask folks to appeal their blocks by pinging the blocking administrator and waiting for an answer before using {{unblock}} – there's value in allowing for immediate independent review). And, I think the existing language specifying different standards of review at ARCA vs. AE/AN sufficiently warns people that they're probably going to be more successful at AE absent exceptional circumstances, as I wrote in my oppose for the previous amendment. Best, KevinL (aka L235 · t · c) 05:31, 29 November 2022 (UTC)Reply[reply]
    And just to clarify my preference, my first choice is to have no note at all. Best, KevinL (aka L235 · t · c) 18:15, 30 November 2022 (UTC)Reply[reply]
    @Cabayi: As written here, this certainly doesn't read as just as an unenforceable "preference & expectation". If we really do want it to be unenforceable guidance, I think that should be much more clear. Best, KevinL (aka L235 · t · c) 17:12, 1 December 2022 (UTC)Reply[reply]
  2. This creates an unnecessary gate to appeal. Contacting the unblocking admin is a good start, but not always. What if that admin is no longer an admin? They're on a Wikibreak? They made a bad decision in the first place and are being obstinate about it? I don't think we have to mandate that as the first step. Now, editors can skip that step at their own risk I'd say, but I just don't see how demanding it be first helps. Nor is AE or AN always the second step. If the underlying decision was the result of some fundamental error of process, editors should be able to jump to ARCA. CaptainEek Edits Ho Cap'n! 18:28, 29 November 2022 (UTC)Reply[reply]
  3. Thinking about it more, it means that one would have to appeal to the enforcing admin first, and I can't fault someone for wanting a third party to review the sanction first or instead. Maxim(talk) 19:57, 30 November 2022 (UTC)Reply[reply]
  4. I feel like this just gives people who like to argue about nothing more nothing to argue about. Beeblebrox (talk) 21:23, 1 December 2022 (UTC)Reply[reply]
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
  2. I am fine with this text appearing, but similar to WTT I think I would prefer no text over this text. Primefac (talk) 19:43, 1 December 2022 (UTC)Reply[reply]
  3. BDD (talk) 21:21, 1 December 2022 (UTC)Reply[reply]
  4. I'm fine with no text, and if I'm going to be the hammer vote on adopting this, I'd want some more agreement. As it stands, I don't think we're seeing eye-to-eye here and pushing this through seems ill advised given the opposition concerns. If we feel strongly about this we can work on it on its own and pass a motion that can get more of a consensus later. Wug·a·po·des 01:00, 2 December 2022 (UTC)Reply[reply]
Comments by arbitrators
  • Proposed Barkeep's second suggestion from above, but if someone wants to express a preference for his first option in this context, I'm also fine with that text. Izno (talk) 23:02, 28 November 2022 (UTC)Reply[reply]

Amendment: appeal template

Amend the previous proposal by adding the following text immediately after the numbered list describing the stages of appeal:

Appeals submitted at AE or AN must be submitted using the applicable template.

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:22, 21 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 02:42, 22 November 2022 (UTC)Reply[reply]
  4. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  5. WormTT(talk) 11:10, 24 November 2022 (UTC)Reply[reply]
  6. Primefac (talk) 15:24, 24 November 2022 (UTC)Reply[reply]
  7. The precise format of the template can be worked out later. In general, having a standardized format will make it easier to appeal and help prevent appeals becoming a mess. Wug·a·po·des 00:43, 25 November 2022 (UTC)Reply[reply]
  8. Cabayi (talk) 12:16, 28 November 2022 (UTC)Reply[reply]
  9. I understand Barkeep's concern but we can always modify the template. CaptainEek Edits Ho Cap'n! 18:33, 29 November 2022 (UTC)Reply[reply]
Oppose
  1. I'm opposed to sectioning the people whose opinions will be deciding the appeal. So at AE this is uninvolved Admin and at AN it's uninvolved editors. I strongly support having a template that is approprite to AN as a forum which our current template is not. Barkeep49 (talk) 20:46, 24 November 2022 (UTC)Reply[reply]
    In a sandbox, could you sketch what that might look like? I'm leery of approprite to AN as a forum. :) Izno (talk) 20:49, 24 November 2022 (UTC)Reply[reply]
    @Barkeep49: The intent of this proposal was to bring the template under the jurisdiction of the arbs/clerks. I'm happy to commit to making uninvolved editor comments unsectioned at AN. Best, KevinL (aka L235 · t · c) 01:18, 25 November 2022 (UTC)Reply[reply]
    @Izno my thought is that AN tends to have fewer sections for normal appeals - often just a single section. When someone posts the AE template it stands out at AN vs AE whose table of contents is formatted to support the templates. And AN tends to be a less sectioned venue than AE so it would follow, for me, that the template used there would have fewer overall sections as well. Barkeep49 (talk) 19:57, 25 November 2022 (UTC)Reply[reply]
    To everyone involved in this reform, AN is a mess, and I don't think we should take our cue from that mess. I can see removing some of what is in the current template, but not as much as I think you would prefer. Izno (talk) 00:29, 27 November 2022 (UTC)Reply[reply]
    Agree with Izno here. KevinL (aka L235 · t · c) 05:32, 29 November 2022 (UTC)Reply[reply]
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
  2. Beeblebrox (talk) 21:24, 1 December 2022 (UTC)Reply[reply]
Comments by arbitrators
The template will hopefully be revised to be simpler to use once the clerks gain the authority to do so. The intent of this proposal is to explicitly require the template (and the 500-word limit) to be used at AN, per this comment. Best, KevinL (aka L235 · t · c) 10:16, 19 November 2022 (UTC)Reply[reply]

Amendment: Allow a priori consent

Amend the previous proposal by inserting a note after "...the change,..." reading "The administrator may indicate consent at any time before, during, or after imposition of the restriction."

Support
  1. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  2. I'd prefer admins didn't do this as standard (because if you're working in these area I'd like you to be taking responsibility for the consequences of the additional power you have), but I can see circumstances that it is the right thing for an admin to do. WormTT(talk) 11:13, 24 November 2022 (UTC)Reply[reply]
  3. I can see downsides to this, but I can see this being useful on occasion if only to avoid the extra bureaucracy of needing to track down the original administrator. Primefac (talk) 15:24, 24 November 2022 (UTC)Reply[reply]
    Gave it a think; I see the "edge case" pointed out by Wugapodes happening more than any other detriment, but also to echo Barkeep49: if this becomes an issue ArbCom can quite easily fix it. Primefac (talk) 13:35, 26 November 2022 (UTC)Reply[reply]
  4. BDD (talk) 15:53, 24 November 2022 (UTC)Reply[reply]
  5. I think this is worth trying. If it goes wrong it feels like a thing ArbCom would be able to fix fairly fast. Barkeep49 (talk) 20:35, 24 November 2022 (UTC)Reply[reply]
  6. KevinL (aka L235 · t · c) 10:45, 25 November 2022 (UTC)Reply[reply]
  7. A number of admins do this with regular admin actions, so I think this could be easily extended here to save time and energy. CaptainEek Edits Ho Cap'n! 18:37, 29 November 2022 (UTC)Reply[reply]
  8. I'm not 100% sure this is a good idea, but the risk seems relatively low if it doesn't work in practice we can amend later. Beeblebrox (talk) 21:30, 1 December 2022 (UTC)Reply[reply]
Oppose
  1. I've been sitting on this for a few days since I was not sure. I think where I go is an oppose here. Izno (talk) 22:15, 25 November 2022 (UTC)Reply[reply]
Abstain
Pending resolution of my wording suggestion below. Best, KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
Moved to support. KevinL (aka L235 · t · c) 10:45, 25 November 2022 (UTC)Reply[reply]
  1. I don't think this is a great idea, but there's an corner-case (that I'm only now realizing) where an admin thinks a user restriction is no longer needed but the imposing admin is away. Only the sanctioned user can appeal (so the admin cannot) but the admin can't modify the sanction without affirmative consent (which the absent admin can't give). So this is kinda needed, but I would prefer some other solution. Wug·a·po·des 00:46, 25 November 2022 (UTC)Reply[reply]
  2. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
I think there's a reasonable thing here but it strikes me as somewhat antithetical to DS to allow any admin to provide consent a priori, as noted by ToBeFree on the talk page. Izno (talk) 22:58, 19 November 2022 (UTC)Reply[reply]
How about "The administrator may indicate consent at any time before, during, or after imposition of the restriction."? Best, KevinL (aka L235 · t · c) 11:31, 21 November 2022 (UTC)Reply[reply]
Done. Izno (talk) 18:22, 21 November 2022 (UTC)Reply[reply]
Looking at this, I think I could maybe support with some sketch (note?) of good times to provide such consent. But when I look at some potential cases (help me out here DS admins or Arb colleagues), I can't see the upsides. All decisions? No, I don't think so. You're using the wrong administrative power if so. "I'll be away for a week" -> Are you really the right admin to enforce the decision (see also ADMINACCT)? Izno (talk) 19:42, 24 November 2022 (UTC)Reply[reply]
I saw this as an admin being able to make a statement along the lines of "I am imposing this restriction, but any admin can overturn me if it is appealed." I do agree that it should not be used for every action by an admin, but I can see instances where it might be a borderline case or similar where the administering administrator sees it as some form of "weak" need. Primefac (talk) 19:44, 24 November 2022 (UTC)Reply[reply]
In the scenario of "if appealed", a consensus (AE/AN: admins/editors) can already override that original administrator's judgement. I don't think that gets me to "this is a necessary enhancement to the policies". Izno (talk) 20:06, 24 November 2022 (UTC)Reply[reply]
An appeal will happen one way or another, but if the imposing admin is unable to give consent to modify, a consensus of admins must be found. If the admin has already given a priori consent, any admin can modify the restriction without needing a group consensus. You and Wugapodes have raised some good points, though, so I will give this another think and see how I feel about it. Primefac (talk) 09:28, 25 November 2022 (UTC)Reply[reply]
For those opposing because you think an admin shouldn't be able to consent ahead of time, if this doesn't pass, I'd encourage you to write a separate proposal prohibiting that. Even without this amendment, it isn't clear that it's not allowed. Best, KevinL (aka L235 · t · c) 19:11, 28 November 2022 (UTC)Reply[reply]
I'd personally rather ping all the arbs onlist or elsewhere to tell them to come vote, which might moot the question thereby saving myself time and getting this proposed decision done, since I am the lone actual opposition on this one at this time. ;) It's been public for a couple weeks now and voting-able for over a week at this point. Izno (talk) 23:09, 28 November 2022 (UTC)Reply[reply]

Contentious topic restrictions: imposition, types, duration, use

Proposal summary
  • Individual administrators now have access to a standard set of page and editor restrictions to enact, plus any that are designated for a particular topic area.
  • Some abilities are now restricted to use by a rough consensus of administrators at AE:
    • Taking actions outside the "standard set" of restrictions
    • Imposing restrictions that can't be reversed by any administrator for longer than one year (but page restrictions can be renewed)
Consultation rationale and comments
Language
Extended content
Contentious topic restrictions (level 2 header)

Administrators may impose contentious topic restrictions in contentious topic areas. Those contentious topic restrictions take the form of editor restrictions and page restrictions. Unless otherwise specified, contentious topics are broadly construed; this contentious topics procedure applies to all pages broadly related to a topic, as well as parts of other pages that are related to the topic.[f]

Editor restrictions

Administrators may impose restrictions on individual editors ("editor restrictions") in contentious topics who do not follow the expectations listed in #Editing a contentious topic as a contentious topic restriction.

The restrictions that can be imposed depend on whether the action is taken by a single administrator or by a rough consensus of administrators at the arbitration enforcement noticeboard ("AE").

Any uninvolved administrator may impose the following editor restrictions, which constitute the "standard set" of editor restrictions:

A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any editor restriction from the standard set above and any other reasonable measures that are necessary and proportionate for the smooth running of the project and may do so for any length of time, including indefinitely.

One year after being imposed, editor restrictions imposed by a single administrator may be modified or revoked by any uninvolved administrator like an ordinary administrator action without going through the appeals and amendments process.

Page restrictions

Administrators may impose special rules and restrictions that apply to pages within contentious topics ("page restrictions") to minimise disruption as a contentious topic restriction. These page restrictions apply to all editors editing the restricted page.

The restrictions that can be imposed depend on whether the action is taken by a single administrator or by a rough consensus of administrators at the arbitration enforcement noticeboard ("AE").

Any uninvolved administrator may impose the following page restrictions, which constitute the "standard set" of page restrictions:

  • page protection,
  • revert restrictions,
  • the "consensus required" restriction,[g]
  • the "enforced BRD" restriction,[h] and
  • any other restrictions designated by the Arbitration Committee as part of the standard set of page restrictions for a particular contentious topic.

A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any page restriction from the standard set above and any other reasonable measures that are necessary and proportionate for the smooth running of the project and may do so for any length of time, including indefinitely.

An administrator who imposes a page restriction (other than page protection) must add an editnotice to restricted pages using the standard template ([CT EDITNOTICE]), and should add a notice to the talk page of restricted pages.

One year after being imposed (or renewed), page restrictions imposed by a single administrator may be renewed, modified, or revoked by any uninvolved administrator like an ordinary administrator action without going through the appeals and amendments process.

Renewal of page restrictions

If an uninvolved administrator (including the original enforcing administrator) decides that a page restriction is still necessary after one year, the administrator may renew the restriction by re-imposing it under this procedure and logging the renewal. The administrator renewing a page restriction then becomes the enforcing administrator. This does not apply to page restrictions imposed by consensus at the arbitration enforcement noticeboard.

Procedural summary

Imposed by: Single administrator Rough consensus of administrators at AE
Authorized restrictions
  • The "standard set" of individual or page restrictions; and
  • Any other restrictions designated by the Arbitration Committee for use by a single admin in a particular contentious topic.
  • Any action available to single administrators; and
  • Any other reasonable measures that are necessary and proportionate for the smooth running of the project.
Maximum length Indefinite; reversible by any uninvolved administrator after one year. However, page restrictions may be renewed. Indefinite
Modifications by
  • Any administrator, if the administrator who first imposed the contentious topic restriction (the "enforcing administrator") affirmatively consents to the change, or is no longer an administrator;
  • A clear consensus of uninvolved editors at the administrators’ noticeboard;
  • A clear consensus of uninvolved administrators at the arbitration enforcement noticeboard; or
  • A majority of the Arbitration Committee voting on a motion in response to a request for amendment filed with the Arbitration Committee.

Vote (Contentious topic restrictions)

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:24, 21 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 22:33, 22 November 2022 (UTC)Reply[reply]
  4. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  5. WormTT(talk) 11:30, 24 November 2022 (UTC)Reply[reply]
  6. Wug·a·po·des 00:48, 25 November 2022 (UTC)Reply[reply]
  7. Primefac (talk) 09:56, 25 November 2022 (UTC)Reply[reply]
  8. Barkeep49 (talk) 20:05, 25 November 2022 (UTC)Reply[reply]
  9. Cabayi (talk) 12:17, 28 November 2022 (UTC)Reply[reply]
  10. CaptainEek Edits Ho Cap'n! 18:38, 29 November 2022 (UTC)Reply[reply]
  11. Beeblebrox (talk) 22:04, 1 December 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
One open question: should the "extended-confirmed restriction" (WP:ECR) be added to the standard set of page restrictions, or is it sufficient to allow page protections (which include extendedconfirmed protection)? One argument against including it is that WP:ECR is written to be topic-wide rather than page-specific. KevinL (aka L235 · t · c) 22:41, 13 November 2022 (UTC)Reply[reply]
I think the existing allowance for use of ECP as a form of protection is sufficient. --Izno (talk) 18:24, 21 November 2022 (UTC)Reply[reply]
Agree with Izno. Barkeep49 (talk) 20:05, 25 November 2022 (UTC)Reply[reply]

Amendment: Limiting blocks to one year

Old language

Amend the previous proposal by modifying the second-to-last paragraph of "Editor restrictions" to read as follows: A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any restriction from the standard set above and any other reasonable measures that are necessary and proportionate for the smooth running of the project and may do so for any length of time, including indefinitely. These measures may have any duration, including indefinite, except that sitewide blocks are limited to one year in duration.

New language (1 December)

The proposal titled "Contentious topic restrictions: imposition, types, duration, use", as amended by the amendment titled "Amendment: wording revisions for contentious topic restrictions", is further amended by inserting at the end of the "Duration of restrictions" section the following text:

Additionally, sitewide blocks become ordinary administrator actions one year after imposition, whether or not imposed by a consensus of administrators at AE.

The drafting arbitrators are directed to modify the "Procedural summary" table within the "Contentious topic restrictions: imposition, types, duration, use" proposal and the "Changing or revoking a contentious topic restriction" section of the "Appeals and amendments" proposal for consistency with the changes made by this amendment.

Support
  1. While Kevin notes that a consensus of AN can site-ban indefinitely, after this reform it will take a rough consensus of administrators, so a lower standard among a smaller set of people and for an action that is harder to overturn than a regular site ban. This combination of easier to impose and harder to be appealed (even with the new standard imposed by this reform) is why I think ArbCom should own site bans under its purview directly. It's a serious responsibility and this kind of serious responsibility is important to have community consensus, through our election, rather than who happens to show up to an AE discussion. So I would prefer the current practice of "AE block for 1 year, indefinite as a normal admin action thereafter" to be an appropriate standard that is working and should be kept. I will note that we also seem likely to enact a referral strategy to ARCA which would be another, appropriate, way for AE admins to advance an indefinite ArbCom backed block. Barkeep49 (talk) 19:43, 25 November 2022 (UTC)Reply[reply]
    I think the suggested amendment here does not make it obvious that the indefinite would be as a normal action thereafter and would support with an appropriate (possibly only one or two word) change. Izno (talk) 22:13, 25 November 2022 (UTC)Reply[reply]
    If Amendment: wording revisions for contentious topic restrictions passes, the way to capture this would be adding the following at the bottom of the "Duration of restrictions" section: Additionally, sitewide blocks become ordinary administrator actions after one year, whether or not imposed by a consensus of administrators at AE. The wording is more awkward if that amendment doesn't pass. Best, KevinL (aka L235 · t · c) 10:03, 27 November 2022 (UTC)Reply[reply]
  2. Per Barkeep, and with the drafting changes suggested by Kevin. I'm not comfortable delegating what is essentially our power to issue site bans. We should be the ones taking the fall for those. Wug·a·po·des 06:43, 28 November 2022 (UTC)Reply[reply]
  3. I'm persuaded then. I prefer the idea that an indefinite action can be taken but it becomes a normal admin action after a year if that helps. WormTT(talk) 11:44, 28 November 2022 (UTC)Reply[reply]
  4. Support with L235's addition and per prior comment. Izno (talk) 23:11, 28 November 2022 (UTC)Reply[reply]
  5. Barkeep's thought process is convincing. Better for the Committee to take the blame, especially in edge cases. CaptainEek Edits Ho Cap'n! 18:40, 29 November 2022 (UTC)Reply[reply]
  6. I was set to oppose this, but I find the above arguments compelling. I can't express enough how much I appreciate the work of the admins at AE, but I don't think indefinite site bans that can only be appealed to the committee should come from anywhere other than the committee itself. This is of course with the caveat that the committee should have the back of those AE admins and if a one-year block expires and the user just starts back up with exactly what they were doing before, the ArbCom banhammer should come down swiftly. Beeblebrox (talk) 22:14, 1 December 2022 (UTC)Reply[reply]
    Good point - with the new referral method there's a real way for AE admins to indicate that the 1 year CT + indef admin was insufficient. Barkeep49 (talk) 22:15, 1 December 2022 (UTC)Reply[reply]
Oppose
  1. A consensus of editors at AN can site-ban a user indefinitely. I don't see a problem with allowing consensus of sysops at AE to indefinitely block a user for conduct within a contentious topic. Best, KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
    Just reaffirming my oppose here even with the updated language, per arbcom-en request. Best, KevinL (aka L235 · t · c) 19:05, 1 December 2022 (UTC)Reply[reply]
  2. Arbitration processes have inreasingly moved away from time-limited sanctions. If someone had done something to merit being blocked or sanctioned for a whole year, there are chances that earlier interventions did not do anything to deter the issue at hand. I don't think it's unresaonble to want to have some assurances after a year that such behaviour won't recur, which in practice involves appealing an indefinite sanction. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 19:31, 25 November 2022 (UTC)Reply[reply]
    Also affirming. --BDD (talk) 21:23, 1 December 2022 (UTC)Reply[reply]
  4. There's nothing special about day 365 which will cause the editor to suddenly see the issue clearly. An indef block which allows the editor to articulate their understanding of the issue and resolve to reform sooner, or later, is appropriate. Indefinite is not infinite. Cabayi (talk) 12:22, 28 November 2022 (UTC)Reply[reply]
  5. Primefac (talk) 20:22, 1 December 2022 (UTC)Reply[reply]
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
Barkeep has said he has some rationale here, so I'd like to see that before voting. Izno (talk) 18:26, 21 November 2022 (UTC)Reply[reply]
Now that the other amendment is passing, I've switched out the language above. (ping to @Barkeep49, Wugapodes, Worm That Turned, Izno, and CaptainEek:, please revert if you disagree.) Best, KevinL (aka L235 · t · c) 18:27, 1 December 2022 (UTC)Reply[reply]

Amendment: wording of duration language

Withdrawing this proposal in favor of new revised one below. Any arb who prefers this one, please feel free to revert. KevinL (aka L235 · t · c) 20:43, 25 November 2022 (UTC)Reply[reply]

Amend the previous proposal to read as follows:

Extended content
Contentious topic restrictions (level 2 header)

Administrators may impose contentious topic restrictions in contentious topic areas. Those contentious topic restrictions take the form of editor restrictions and page restrictions. Unless otherwise specified, contentious topics are broadly construed; this contentious topics procedure applies to all pages broadly related to a topic, as well as parts of other pages that are related to the topic.[i]

Editor restrictions

Administrators may impose restrictions on individual editors ("editor restrictions") in contentious topics who do not follow the expectations listed in #Editing a contentious topic as a contentious topic restriction.

The restrictions that can be imposed depend on whether the action is taken by a single administrator or by a rough consensus of administrators at the arbitration enforcement noticeboard ("AE").

Any uninvolved administrator may impose the following editor restrictions, which constitute the "standard set" of editor restrictions:

A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any editor restriction from the standard set above and any other reasonable measures that are necessary and proportionate for the smooth running of the project and may do so for any length of time, including indefinitely.

One year after being imposed, editor restrictions imposed by a single administrator may be modified or revoked by any uninvolved administrator like an ordinary administrator action without going through the appeals and amendments process.

Page restrictions

Administrators may impose special rules and restrictions that apply to pages within contentious topics ("page restrictions") to minimise disruption as a contentious topic restriction. These page restrictions apply to all editors editing the restricted page.

The restrictions that can be imposed depend on whether the action is taken by a single administrator or by a rough consensus of administrators at the arbitration enforcement noticeboard ("AE").

Any uninvolved administrator may impose the following page restrictions, which constitute the "standard set" of page restrictions:

  • page protection,
  • revert restrictions,
  • the "consensus required" restriction,[j]
  • the "enforced BRD" restriction,[k] and
  • any other restrictions designated by the Arbitration Committee as part of the standard set of page restrictions for a particular contentious topic.

A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any page restriction from the standard set above and any other reasonable measures that are necessary and proportionate for the smooth running of the project and may do so for any length of time, including indefinitely.

An administrator who imposes a page restriction (other than page protection) must add an editnotice to restricted pages using the standard template ([CT EDITNOTICE]), and should add a notice to the talk page of restricted pages.

One year after being imposed (or renewed), page restrictions imposed by a single administrator may be renewed, modified, or revoked by any uninvolved administrator like an ordinary administrator action without going through the appeals and amendments process.

Duration of restrictions

Contentious topic restrictions may be imposed for any fixed length of time, or for an indefinite period.

However, one year after being imposed (or last renewed, if applicable), contentious topic restrictions which were imposed by a single administrator may be amended or revoked without going through the appeals and amendments process in the same way as an ordinary administrator action.

Renewal of page restrictions

If an uninvolved administrator (including the original enforcing administrator) decides that a page restriction is still necessary after one year, the administrator may renew the restriction by re-imposing it under this procedure and logging the renewal. The administrator renewing a page restriction then becomes the enforcing administrator. This does not apply to page restrictions imposed by consensus at the arbitration enforcement noticeboard.

Procedural summary

Imposed by: Single administrator Rough consensus of administrators at AE
Authorized restrictions
  • The "standard set" of individual or page restrictions; and
  • Any other restrictions designated by the Arbitration Committee for use by a single admin in a particular contentious topic.
  • Any action available to single administrators; and
  • Any other reasonable measures that are necessary and proportionate for the smooth running of the project.
Maximum length Indefinite; reversible by any uninvolved administrator after one year. However, page restrictions may be renewed. Indefinite
Modifications by
  • Any administrator, if the administrator who first imposed the contentious topic restriction (the "enforcing administrator") affirmatively consents to the change, or is no longer an administrator;
  • A clear consensus of uninvolved editors at the administrators’ noticeboard;
  • A clear consensus of uninvolved administrators at the arbitration enforcement noticeboard; or
  • A majority of the Arbitration Committee voting on a motion in response to a request for amendment filed with the Arbitration Committee.
Support
  1. Weakly support; see my comment below. Best, KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  3. Wug·a·po·des 00:50, 25 November 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators
The changes here are purely stylistic and not substantive. I think this language might be more clear, but I am happy either way. Best, KevinL (aka L235 · t · c) 11:56, 21 November 2022 (UTC)Reply[reply]
The actual repeated phrase that still is inconsistent relative to the draft on arbwiki (A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any restriction from the standard set above and any other reasonable measures that are necessary and proportionate for the smooth running of the project and may do so for any length of time[,] including indefinitely.) isn't adjusted though? :) --Izno (talk) 18:29, 21 November 2022 (UTC)Reply[reply]
Fixed in both the top-level proposal and this one. I think this one could still be worded more clearly... I'll think it over more. Best, KevinL (aka L235 · t · c) 10:48, 25 November 2022 (UTC)Reply[reply]

Amendment: wording revisions for contentious topic restrictions

Summary

This amendment improves the clarity and organization of the "Contentious topic restrictions" section. It reorganizes the section by removing the "Editor restrictions" and "Page restrictions" subsections, which had a significant amount of duplicate text. Those subsections are replaced with "Standard set", "Duration of restrictions", and "Restriction notices".

In addition, this amendment reinstates the requirement that an enforcing administrator notify the restricted user when imposing a restriction. That requirement exists in the DS procedure but got dropped by a drafting error.

Finally, this amendment would harmonize the "Continuity" section, which references the "Contentious topic restrictions" section, with the above changes.

Language

Amend the previous proposal to read as follows:

Extended content
Contentious topic restrictions (level 2 header)

Administrators may are authorized to impose contentious topic restrictions in contentious topic areas. Those contentious topic restrictions take the form of editor restrictions and page restrictions.

Editor restrictions prohibit a specific editor from making edits described in the restriction and may be imposed on editors who do not follow the expectations listed in #Editing a contentious topic in a contentious topic. Page restrictions prohibit all editors on a particular page from making edits described in the restriction and may be imposed to minimize disruption in a contentious topic.

Unless otherwise specified, contentious topics are broadly construed; this contentious topics procedure applies to all pages broadly related to a topic, as well as parts of other pages that are related to the topic.[l]

Single administrators may only impose restrictions in the standard set of contentious topic restrictions. A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any restriction from the standard set and any other reasonable measures that are necessary and proportionate for the smooth running of the project.

Standard set

The following editor restrictions constitute the standard set of editor restrictions which may be imposed by a single uninvolved administrator:

The following page restrictions constitute the standard set of page restrictions which may be imposed by a single uninvolved administrator:

  • page protection,
  • revert restrictions,
  • the "consensus required" restriction,[m]
  • the "enforced BRD" restriction,[n] and
  • other restrictions that have been specifically designated by the Arbitration Committee for use by a single administrator in a particular contentious topic.
Duration of restrictions

Contentious topic restrictions may be imposed for any fixed length of time, or for an indefinite period.

However, one year after being imposed (or last renewed, if applicable), contentious topic restrictions which were imposed by a single administrator may be amended or revoked without going through the appeals and amendments process in the same way as an ordinary administrator action.

Restriction notices

An administrator who imposes an editor restriction must provide a notice on the restricted editor's talk page specifying the reason for the restriction and informing the restricted editor of the appeal process.

An administrator who imposes a page restriction (other than page protection) must add an editnotice to restricted pages using the standard template ([CT EDITNOTICE]), and should generally add a notice to the talk page of restricted pages.

Editor restrictions

Administrators may impose restrictions on individual editors ("editor restrictions") in contentious topics who do not follow the expectations listed in #Editing a contentious topic as a contentious topic restriction.

The restrictions that can be imposed depend on whether the action is taken by a single administrator or by a rough consensus of administrators at the arbitration enforcement noticeboard ("AE").

Any uninvolved administrator may impose the following editor restrictions, which constitute the "standard set" of editor restrictions:

A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any editor restriction from the standard set above and any other reasonable measures that are necessary and proportionate for the smooth running of the project and may do so for any length of time, including indefinitely.

One year after being imposed, editor restrictions imposed by a single administrator may be modified or revoked by any uninvolved administrator like an ordinary administrator action without going through the appeals and amendments process.

Page restrictions

Administrators may impose special rules and restrictions that apply to pages within contentious topics ("page restrictions") to minimise disruption as a contentious topic restriction. These page restrictions apply to all editors editing the restricted page.

The restrictions that can be imposed depend on whether the action is taken by a single administrator or by a rough consensus of administrators at the arbitration enforcement noticeboard ("AE").

Any uninvolved administrator may impose the following page restrictions, which constitute the "standard set" of page restrictions:

  • page protection,
  • revert restrictions,
  • the "consensus required" restriction,[o]
  • the "enforced BRD" restriction,[p] and
  • any other restrictions designated by the Arbitration Committee as part of the standard set of page restrictions for a particular contentious topic.

A rough consensus of administrators at the arbitration enforcement noticeboard ("AE") may impose any page restriction from the standard set above and any other reasonable measures that are necessary and proportionate for the smooth running of the project and may do so for any length of time, including indefinitely.

An administrator who imposes a page restriction (other than page protection) must add an editnotice to restricted pages using the standard template ([CT EDITNOTICE]), and should add a notice to the talk page of restricted pages.

One year after being imposed (or renewed), page restrictions imposed by a single administrator may be renewed, modified, or revoked by any uninvolved administrator like an ordinary administrator action without going through the appeals and amendments process.

Renewal of page restrictions

If an uninvolved administrator (including the original enforcing administrator) decides that a page restriction is still necessary after one year, the administrator may renew the restriction by re-imposing it under this procedure and logging the renewal. The administrator renewing a page restriction then becomes the enforcing administrator. This does not apply to page restrictions imposed by consensus at the arbitration enforcement noticeboard.

Logging
This part in italics will go here in the merged procedure but is separately voted on at #Logging.

Contentious topic restrictions must be recorded in the arbitration enforcement log by the administrator who takes the action.[q] Administrators who renew, change, or revoke a contentious topic restriction must append a note recording the amendment to the original log entry.

Administrators should clearly and unambiguously label their actions as contentious topic restrictions (such as in the block summary, page protection summary, edit summary, or talk page message announcing the action, whichever is appropriate).[r]

Procedural summary

Imposed by: Single administrator Rough consensus of administrators at AE
Authorized restrictions
  • The "standard set" of individual or page restrictions; and
  • Any other restrictions designated by the Arbitration Committee for use by a single admin in a particular contentious topic.
  • Any action available to single administrators; and
  • Any other reasonable measures that are necessary and proportionate for the smooth running of the project.
Maximum length Indefinite; reversible by any uninvolved administrator after one year. However, page restrictions may be renewed. Indefinite
Modifications by
  • Any administrator, if the administrator who first imposed the contentious topic restriction (the "enforcing administrator") affirmatively consents to the change, or is no longer an administrator;
  • A clear consensus of uninvolved editors at the administrators’ noticeboard;
  • A clear consensus of uninvolved administrators at the arbitration enforcement noticeboard; or
  • A majority of the Arbitration Committee voting on a motion in response to a request for amendment filed with the Arbitration Committee.

Additionally, to maintain consistency in linking and wording, the "Continuity" proposal is amended by changing the two bullet points to read as follows:

Extended content
  • Previously-enacted single-admin page restrictions are now subject to renewal, modification, and revocation by uninvolved administrators in the same way as ordinary administrator actions after one year in accordance with #Page restrictions #Duration of restrictions and #Renewal of page restrictions.
  • Previously-enacted single-admin editor restrictions do not, as a result of #Duration of restrictions, lose their status as "contentious topic restrictions" become subject to modification and revocation in the same way as ordinary administrator actions after one year.

Vote (Amendment: wording revisions for contentious topic restrictions)

Support
  1. I might suggest the obvious-to-me additional header above The following editor restrictions constitute the standard , but otherwise this is an improvement organizationally. It may have been wise to ensure the more substantive changes to wording and the re-addition of a previous requirement were proposed separate to this one, but I think the latter is fine since it's retaining a good part of the status quo.

    I also think this suggested amendment could plausibly be part of the above now-boxed amendment which has some support already. Izno (talk) 00:57, 27 November 2022 (UTC)Reply[reply]

  2. As proposed now, the wording here is better than the original proposal: it adds clarity and organizational strength without changing the substance. If both this and "Amendment: Limiting blocks to one year" pass, I'm sure we can insert the appropriate language under the new "Duration of restrictions" section. Best, KevinL (aka L235 · t · c) 09:11, 27 November 2022 (UTC)Reply[reply]
  3. Wug·a·po·des 06:44, 28 November 2022 (UTC)Reply[reply]
  4. BDD (talk) 00:55, 29 November 2022 (UTC)Reply[reply]
  5. Barkeep49 (talk) 02:04, 29 November 2022 (UTC)Reply[reply]
  6. CaptainEek Edits Ho Cap'n! 18:42, 29 November 2022 (UTC)Reply[reply]
  7. WormTT(talk) 10:11, 30 November 2022 (UTC)Reply[reply]
  8. Maxim(talk) 19:58, 30 November 2022 (UTC)Reply[reply]
  9. Cabayi (talk) 11:47, 1 December 2022 (UTC)Reply[reply]
  10. Primefac (talk) 20:32, 1 December 2022 (UTC)Reply[reply]
  11. One of the main goals of this extended reform process is to make this system less byzantine and easier to understand, and I feel this does that. Beeblebrox (talk) 22:16, 1 December 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Arbitrator comments

Here's what a revision (more textually extensive but does not change the substance) that wholly eliminates the repeated phrases would look like – @Izno: What do you think? Best, KevinL (aka L235 · t · c) 11:25, 25 November 2022 (UTC)Reply[reply]

Oh, this text would actually add one substantive requirement, which is a requirement for notifying restricted users that currently exists (with different wording) in WP:AC/DS but missed the consultation: An administrator who imposes an editor restriction must provide a notice on the restricted editor's talk page specifying the reason for the restriction and informing the restricted editor of the appeal process. An administrator who imposes a page restriction (other than page protection) must add an editnotice to restricted pages using the standard template ([CT EDITNOTICE]), and should generally add a notice to the talk page of restricted pages. Additionally, administrators must log all contentious topic restrictions. Best, KevinL (aka L235 · t · c) 11:27, 25 November 2022 (UTC)Reply[reply]
The one outstanding awkward phrasing here is "the action is taken" (which is also in the parent proposal). I guess it's OK, but I'd still like something that flows better. How about "the decision to impose the restriction is taken"? More lengthy but also more clear? I'm not sure. Best, KevinL (aka L235 · t · c) 11:38, 25 November 2022 (UTC)Reply[reply]
I think the problem you're having is that the action is a phrase that has no clear referent, being that it's the first time 'action' is used in this context (and maybe this whole page?). While I think you could remove the entire sentence without particular loss of clarity, here's a suggestion for rephrasing: Whether a restriction is imposed by a single administrator or by a rough consensus of administrators at the arbitration enforcement noticeboard ("AE") changes what that restriction can be. Or possibly do a better job of summarizing, using the notion of level of consensus: The level of consensus changes what kinds of restrictions can be imposed. Izno (talk) 00:57, 27 November 2022 (UTC)Reply[reply]
@Izno: I've removed the sentence and added a "Standard set" header per your suggestions. I've also added a section harmonizing the "Continuity" proposal, which references this one, because the new language has new sections and does not use the terminology "lose [] status as contentious topic restrictions". Best, KevinL (aka L235 · t · c) 08:55, 27 November 2022 (UTC)Reply[reply]
@Maxim and Wugapodes: I've withdrawn the previous proposal in favor of this one, but if you prefer the previous one please feel free to revert it. Best, KevinL (aka L235 · t · c) 20:43, 25 November 2022 (UTC)Reply[reply]

Enforcement

Proposal summary

Clarifies how restrictions are enforced.

Consultation rationale and comments
Language
Extended content

Editors must comply with contentious topic restrictions. Editors who disagree with a contentious topic restriction may appeal it, but the restriction remains in effect until it is revoked or modified by an administrator.

Edits that breach an editor or page restriction may be reverted.[s]

Editors who breach an editor or page restriction may be blocked or subjected to further editor restrictions.

However, breaches of a page restriction may result in a block or editor restriction only if:

  1. The editor was aware that they were editing in a contentious topic, and
  2. The restricted page displayed an editnotice ([CT EDITNOTICE]) specifying the page restriction.

Vote (Enforcement)

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:29, 21 November 2022 (UTC)Reply[reply]
  3. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  4. WormTT(talk) 11:37, 24 November 2022 (UTC)Reply[reply]
  5. BDD (talk) 15:55, 24 November 2022 (UTC)Reply[reply]
  6. Wug·a·po·des 00:51, 25 November 2022 (UTC)Reply[reply]
  7. Primefac (talk) 09:56, 25 November 2022 (UTC)Reply[reply]
  8. Barkeep49 (talk) 20:08, 25 November 2022 (UTC)Reply[reply]
  9. Cabayi (talk) 12:24, 28 November 2022 (UTC)Reply[reply]
  10. CaptainEek Edits Ho Cap'n! 18:43, 29 November 2022 (UTC)Reply[reply]
  11. Beeblebrox (talk) 22:17, 1 December 2022 (UTC)Reply[reply]
Oppose
Abstain
  1. Donald Albury 22:21, 29 November 2022 (UTC)Reply[reply]
Comments by arbitrators

Warnings

Proposal summary

Makes explicit that

  • Warnings may be logged
  • Logged warnings may be appealed
  • Logged warnings may be imposed even if the editor was not previously aware of CT
Consultation rationale and comments
Language
Extended content

Administrators may warn editors for conduct that falls short of the expectations in a contentious topic. Administrators may choose to log warnings in the arbitration enforcement log. Warnings that are logged in the arbitration enforcement log may be appealed like other editor restrictions. An editor may be warned even if the editor was not previously aware that their editing occurred in a contentious topic.

Vote (Warnings)

Support
  1. KevinL (aka L235 · t · c) 14:47, 21 November 2022 (UTC)Reply[reply]
  2. Izno (talk) 18:30, 21 November 2022 (UTC)Reply[reply]
  3. BDD (talk) 22:34, 22 November 2022 (UTC)Reply[reply]
  4. Maxim(talk) 13:46, 23 November 2022 (UTC)Reply[reply]
  5. WormTT(talk) 11:38, 24 November 2022 (UTC)Reply[reply]
  6. Wug·a·po·des 00:52, 25 November 2022 (UTC)Reply[reply]
  7. Primefac (talk) 09:56, 25 November 2022 (UTC)