Wikipedia talk:Arbitration Committee

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

Wikipedia:Contentious topics#Renewal of page restrictions and Wikipedia:Arbitration Committee/Procedures#Renewal of page restrictions are modified as follows:

Wikipedia:Contentious topics#Logging and Wikipedia:Arbitration Committee/Procedures#Logging 2 are modified as follows:

Wikipedia:Arbitration Committee/Procedures#Logging is modified as follows:

Enacted – HouseBlaster (talk • he/they) 20:55, 25 September 2025 (UTC)[reply]

Support:

1. I think with the bot and the language above this will be a significant process improvement and save oodles of time. ScottishFinnishRadish (talk) 14:19, 8 September 2025 (UTC)[reply]
2. Daniel (talk) 18:35, 8 September 2025 (UTC)[reply]
3. This does seem like it will be an improvement. - Aoidh (talk) 12:43, 10 September 2025 (UTC)[reply]
4. Primefac (talk) 18:42, 14 September 2025 (UTC)[reply]
5. Seeing as we didn't wrangle up an obvious tech solution, this is a fine enough solution. CaptainEek ^{Edits Ho Cap'n!}⚓ 05:56, 23 September 2025 (UTC)[reply]
6. Worm^TT(talk) 12:58, 23 September 2025 (UTC)[reply]

Oppose:

Abstain:

1. I place about 100 of these protections per year. I should perhaps abstain from deciding if I need to continue to log these. ~ ToBeFree (talk) 20:52, 17 September 2025 (UTC)[reply]

Going to leave this up for discussion for a bit before I vote, on the (fairly high) chance that I'm missing an obvious reason to make people manually maintain a redundant log, and because I probably missed somewhere else these procedures are mentioned. In my view, the time investment of manually logging an enormous amount of page protections isn't worth the effort as we can just search the protection log for the CTOP name, and clearly see it in page histories. There might be some benefit to a specific language to use for the protection reason, so that's probably worth a discussion, too. ScottishFinnishRadish (talk) 11:36, 21 August 2025 (UTC)[reply]

I like this idea, though like Thryduulf I'd want to specify exactly how this needs to be noted in the log summary (my thought is a link to a specific shortcut for each topic) to make it so automated tools could comprehensively find each such protection. A bot that would then make a logpage from these somewhere would help alleviate concerns about this making the information harder to find. Elli (talk | contribs) 16:30, 21 August 2025 (UTC)[reply]

the thing about in-summary logging is that if an administrator forgets, they need to undo and redo the protection because you can't modify a log entry after you've hit the button. so, it adds some logistical complexity. not a dealbreaker, but something that needs to be anticipated – and lots of AE admins are old hands that wouldn't necessarily love using an automated tool to pre-fill the edit summary. theleekycauldron (talk • she/her) 17:36, 21 August 2025 (UTC)[reply]

That's still less work than opening up a new tab, heading over to AE/Log, finding the right section, and logging it there. Especially if they're on a phone or tablet. ScottishFinnishRadish (talk) 17:43, 21 August 2025 (UTC)[reply]

maybe a template that hails a bot to come over, do the protection, do the logging, and remove the template? or a work-order page? theleekycauldron (talk • she/her) 17:56, 21 August 2025 (UTC)[reply]

My hope is to make it take as little effort as possible. One thing that became clear when I got access to revdel, and has been made crystal since I got oversight is that if something takes more than 3-10 seconds it's probably not getting done. I don't think having to change the protection on a page if you forgot to use the right reason in the initial protection is terribly onerous. ScottishFinnishRadish (talk) 17:59, 21 August 2025 (UTC)[reply]

• I'd prefer a technical solution if we can wrangle one up. CaptainEek ^{Edits Ho Cap'n!}⚓ 18:15, 21 August 2025 (UTC)[reply]

  I'm no technological wizard, but my first thought would just be "button in Twinkle page protection gadget that allows you to add page to relevant AE log." CaptainEek ^{Edits Ho Cap'n!}⚓ 18:17, 21 August 2025 (UTC)[reply]

• I support this change generally, and further support Kevin's proposal here. As Tamzin notes here, a bot-generated log allows the right balance of still tracking the records (and allowing manual adjustments where needed), while still making it lightweight for those protecting pages. Daniel (talk) 19:11, 6 September 2025 (UTC)[reply]

  I'm also satisfied with the bot Kevin put together. Just need to wordsmith the motions above, which Kevin has also helpfully provided some input on. I hope to get that taken care of in the next couple days. ScottishFinnishRadish (talk) 22:49, 6 September 2025 (UTC)[reply]

My first thought is that as CTOPs are (or at least should be) periodically reviewed to determine whether they are still required there needs to be an easy way to determine whether actions are being taken under it (some even have automatic sunset clauses if they aren't used). That doesn't have to be a manual log of page protections of course, but there needs to be some alternative if it isn't. My first thoughts are some sort of template for the talk page and/or standardised wording for the protection log that could be easily found by a bot or script. In "busy" ctop areas it wouldn't matter too much if 100% of page protections aren't recorded this way as there will be plenty of other actions that demonstrate its continuing need, but for quieter ones it is important because page protections might be the only actions being taken. Thryduulf (talk) 12:11, 21 August 2025 (UTC)[reply]

I do think that we need to retain some log of this (and it could be automatic, as Thryduulf notes), particularly for CTOP that are not ECR by default, as these logs will later be what is evaluated to determine if the CTOP is still needed. For ECR-by-default topics, this is perhaps less important, as the protections will not necessarily be indicative of persistent disruption. There’s an edge case there as well, which is protection of Talk pages in ECR topics, especially when such protection is less than extended-confirmed. I’ve personally found temporary semi protection of high traffic article talk pages to be quite helpful for tamping down disruption without totally shutting the door on editors who have not hit XC _signed, Rosguill ^talk 13:38, 21 August 2025 (UTC)[reply]

I think this is a generally good idea, but it does extend to blocks as another example pretty trivially, so it needs support in a way that separates it from some kinds of editor restrictions.

Additionally, "searching the log" is a non-trivial point e.g. for metrics, as noted above. Consider ensuring you have the infrastructure in place to support that before passing a motion like this. There are a lot of ways a log summary can point to a CTOP. Izno (talk) 15:37, 21 August 2025 (UTC)[reply]

There are far fewer editor and page restrictions than page protections, so that's a pretty significant separation. Wikipedia:Arbitration enforcement log/2025/Arab–Israeli conflict#Page sanctions (CT/A-I) is a tremendous waste of editor time and effort for very little gain. CT/SA is going to be the same. Blocks also fall in the high end of escalation of user sanctions, so it's good to have those logged alongside with warnings and such. Page protection is generally either ECR enforcement or the lightest touch to end disruption at a contentious article. ScottishFinnishRadish (talk) 15:49, 21 August 2025 (UTC)[reply]

Administrator time is already a precious resource for AE. Making better use of it is always advisable. But the data a log provides is very useful, as others observe. In an ideal world the log would be entirely automated. We're not there yet, but perhaps there's a way to make logs automated for blocks and protections? I imagine we'd need to add some drop-down options to twinkle, which could add a tag that could be logged? Not my area of expertise, perhaps it's more complicated than that. But we had a bot maintain a list of ECR pages for a while, perhaps we still do, so this feels like it should be within reach. Vanamonde93 (talk) 15:56, 21 August 2025 (UTC)[reply]

There's a lot of ways this can reasonably be done. Could add an edit filter that tags protection with CT/(whatever shortcut) to any protection that includes CT/(whatever shortcut) in the edit summary. Then you can look at the protection log and select a tag. Shabam, instant log. That just requires the protecting admin add CT/SA to all South Asian CTOP protections, or CT/A-I for Arab/Israel conflict protections to the edit summary. ScottishFinnishRadish (talk) 16:11, 21 August 2025 (UTC)[reply]

I would say that protections should stay in the centralised log, provided they are not ones put in place across an entire topic area due to a remedy (i.e. no ECPs for the Arab-Israeli conflict, South Asian social strata, or Indian military history topic areas should go to AELOG). Those ones can very easily get away with a link to the relevant remedy in the protection log and nothing in the centralised one. —Jéské Couriano v^_^v ^{threads critiques} 16:10, 21 August 2025 (UTC)[reply]

I think an automated replacement for page protections would be a good idea, but there would need to be a proper tool for it. On one side you'd have to enforce a machine-readable syntax. WP:CTOP, WP:AE, etc., might occasionally still be mentioned by reference, so I'm thinking something like [[WP:CTOP/<code>|Arbitration enforcement]] being the magic thing we look for. Policy could also note that any admin can update a protection to use that syntax if the protecting admin indicated an intent to invoke CTOP but used defective syntax. That part's all something ArbCom could mandate right now, but for the other side you'd need an easily available tool that can be used to search the protection logs for that magic string and refine by the relevant code, ideally such that we can do prefilled links to search results at the top of AELOG sections. That's not super hard, but it's also not like five lines of Python.

Sadly, I've already done my ArbCom tool development mitzvah for the year, but maybe someone else can come forward and take that on here. If not, though, perhaps this should be withdrawn until the technical infrastructure can be first set up—or passed as a suspended motion, pending that development.

Also, in any case, two edge cases that come to mind: One, what about salting? Strictly on a technical level that's title protection, not page protection, and it often coincides with deletion, which still would be logged manually. Two, if this goes the direction of only applying to ECR enforcement as some have suggested, in addition to Rosguill's point about discretionary protection of talkpages, what about ECR enforcement that intentionally underdoes it, e.g. semi-protection due to IPs violating an ECR on a related-content page? Do the exceptional nature of these protections merit a manual log? -- Tamzin^{[cetacean needed]} (they|xe|🤷) 16:20, 21 August 2025 (UTC)[reply]

I like Kevin's idea of an automated detection system that writes directly to the AE log (or a subpage thereof), with admins having the option to manually remove false positives or add false negatives. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 09:42, 29 August 2025 (UTC)[reply]

In response to this motion, I wrote a bot that produces this table of all CTOP protection actions. It uses edit summary heuristics to identify which CTOP applies, but the table can also be easily manually edited. If the committee desires, I can run this regularly (say, daily), and this can replace the logging of protections. (It can also be extended to blocks and partial blocks if desired, and any other AE actions that are fairly standard MediaWiki logged actions.) Best, KevinL (aka L235 · t · c) 00:05, 22 August 2025 (UTC)[reply]

Thanks for that, looks good! I don't think blocks are a good use case because they often include diffs, either to behavior or AE threads. ScottishFinnishRadish (talk) 00:08, 22 August 2025 (UTC)[reply]

L235, what triggers this logging? Is it CTOP or Arbitration enforcement in the protection reason? If so I'm fine with setting some standard language and rolling with the bot. ScottishFinnishRadish (talk) 15:42, 28 August 2025 (UTC)[reply]

@ScottishFinnishRadish: It's a kludge of various heuristics. Currently, the protection is assumed to be an AE action if one of the following trigger phrases appears (case insensitive): "arbitration", "arbcom", "ctop", "ct/", "30/500", "contentious topic", "blpct", "blpds", "arbpia". Then, sorting into various CTOPs relies on some more heuristics, largely here: [1].

If you were to impose some standard mandate, my preference would be to ask admins to link to the CTOP page for the specific topic, for example WP:CT/BLP (or Wikipedia:Contentious topics/Biographies of Living Persons), which will allow for easiest extraction of both the AE nature and the specific topic associated with the protection. Best, KevinL (aka L235 · t · c) 15:58, 28 August 2025 (UTC)[reply]

You could, by the way, incorporate this into the text of the procedure. For example, something approximately like:

All sanctions and page restrictions, except page protections, must be logged by the administrator who applied the sanction or page restriction at Wikipedia:Arbitration enforcement log. Page protections must clearly note in the protection reason that the protection action is an arbitration enforcement action and link to the applicable contentious topic page (e.g., WP:CT/BLP), which will cause the action to be automatically logged at Wikipedia:Arbitration enforcement log/Protections.

KevinL (aka L235 · t · c) 01:06, 29 August 2025 (UTC)[reply]

@ScottishFinnishRadish: FYI, I've updated the bot such that it is also capable of notifying admins when they've made AE protection actions that need to be categorized because it wasn't apparent which CTOP they related to. It's currently dry-running it, but an example is available here. Best, KevinL (aka L235 · t · c) 23:10, 12 September 2025 (UTC)[reply]

That's a great feature. Thanks for your work on this. Is the source for the bot available? ScottishFinnishRadish (talk) 23:28, 12 September 2025 (UTC)[reply]

@ScottishFinnishRadish: it's publicly available at [2]. Thanks! KevinL (aka L235 · t · c) 23:30, 12 September 2025 (UTC)[reply]

if the manual logging of CTOP page protections gets removed, I would definitely like to still have an automated way that produces a table or page like the current log is so I can follow a very easy shortcut like going to WP:AELOG/2025#GG as a simplified overview. Having to do a manual search over edit summaries is not going to be useful for referring back to which pages were protected when. I find myself going to the AE log often enough when I need to check when certain CTOP pages were protected as it’s pretty good to have a very short list for each year to see patterns which can be helpful for SPI related investigations sometimes as they will sometimes go to similar pages. Raladic (talk) 06:24, 22 August 2025 (UTC)[reply]

@SFR - Should the new modified part, which notes that adding the WP:CT/X will automatically log it, assumes that this will happen in every case, but we're still humans and accidental omission is all but guaranteed, at least sometimes, so should there be an additional remedy for if that happens be noted explicitly?

E.g. "If an administrator accidentally forgets to include the applicable topic page (e.g. WP:CT/BLP), which would result in the page protection not being automatically added to the Wikipedia:Arbitration enforcement log/Protections page, they must manually amend the protection page by doing X"

Where X is either direct edit, or causing a bot to do so from some manual auxiliary page like the WP:CFD/W procedure? Raladic (talk) 19:34, 8 September 2025 (UTC)[reply]

We don't outline every way that an enforcing admin can remedy a mistake with logging now so I don't think we need to get that far into the weeds in this case either. ScottishFinnishRadish (talk) 12:04, 9 September 2025 (UTC)[reply]

Great, thanks for the explanation :) Raladic (talk) 02:46, 10 September 2025 (UTC)[reply]

I got used to logging these; it doesn't take much of my time. As long as a bot does the logging, we'll still have an overview of which contentious topic designations are used or unused by administrators, so there's probably no downside in removing the need for logging. Making the process less complicated is probably a good idea. ~ ToBeFree (talk) 20:57, 17 September 2025 (UTC)[reply]