Motions

CTOP/AE page protection logging

CTOP/AE page protection logging: Clerk notes

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

Motion: Remove requirement for logging CTOP/AE page protections

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

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 noting the CTOP invoked in the protection reason. 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.

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

Contentious topic restrictions, excepting page protections, must be recorded in the arbitration enforcement log by the administrator who takes the action. Page protections must clearly note they are CTOP/arbitration enforcement and the CTOP being invoked in the protection reason.

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

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 they are CTOP/AE enforcement and the CTOP being invoked in the protection reason.

A central log of all page restrictions and sanctions (including blocks, bans, page protections or other restrictions) placed as arbitration enforcement (including contentious topic restrictions) is to be maintained by the Committee and its clerks at Wikipedia:Arbitration enforcement log.

For this motion there are 12 active arbitrators. With 0 arbitrators abstaining, 7 support or oppose votes are a majority.

Support:

Oppose:

Abstain:

Arbitrator views and discussions

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]

Community discussion

Statement by Thryduulf

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]

Statement by Rosguill

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]

Statement by Izno

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]

Statement by Vanamonde

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]

Statement by Jéské Couriano

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]

Statement by Tamzin

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]

Statement by L235

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]

Statement by Raladic

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]