Wikipedia talk:Arbitration Committee

Contentious alert template doc suggestion

I had to dig down to a footnote on a separate page to figure out if I needed to re-alert someone who had gotten previous DS alerts. So, I'd like to suggest adding (If an editor has previously been alerted to the presence of discretionary sanctions, they may be presumed to be aware of the contentious topic.) at the end of the first paragraph of Template:Contentious topics/alert/doc#Usage, per the wording at Wikipedia:Contentious_topics#cite_note-14. Thanks. --SarekOfVulcan (talk) 14:33, 12 September 2025 (UTC)

On that note - the template doc is at odds with the approved language from the actual text of the CT Reform - Wikipedia:Contentious topics/2021-22 review#Awareness, ”Only the officially designated templates should be used for an editor's first contentious topic alert..” - which says the template “should” be used, not “must” - that’s an important distinction that could otherwise be used by someone to WP:WIKILAWYER their way out of “I wasn’t alerted with this exact template”. Raladic (talk) 15:37, 12 September 2025 (UTC)

This is why I think we've gotten too far up our own asses about trying to write this stuff as legalese. This stuff is normally done by whole teams of professionals who make a pile of money and still mess it up. I think that awareness requirement is silly enough, but having to use Arbcom Approved^tm templates is even sillier. We should scrap the whole awareness thing and replace it with Generally, editors should be made aware that they're editing in a CTOP with an explanation and link to the applicable CTOP page before they are sanctioned with CTOP powers. Egregious behavioral violations can be sanctioned without any prior communication. ScottishFinnishRadish (talk) 16:47, 12 September 2025 (UTC)

Agreed, the strict wording could use a small dose of common sense application.

It's one thing if some editor is very new and may genuinely never have seen it, so giving them some heads up on CTOPs is reasonable and sure, the template has more info than an editor may manually link to. But when we have AE or ANI threads where admins are forced to say "sorry, can't ban this user who has never gotten this template, so best I can do is a warning", while editors have 5k+ (or I've even seen cases of 10k+) edits and have been around for a few years seems entirely implausible that they have not come across CTOPs conceptually. Raladic (talk) 17:35, 12 September 2025 (UTC)

I've previous written that I'm not completely convinced that a process to formally make an editor aware of the contentious topic framework is necessary, particularly if the usual warning-before-action principle is followed by admins. Editors face the risk of sanctions for the same type of behaviour on non-contentious topics; it would just take a community discussion. So the editors to which an awareness alert makes a difference are ones who are unaware of how to identify that a page is in the scope of a contentious topic, deliberately choose to act disruptively, and are counting on the community not to reach a consensus on sanctions. I'm not sure the benefit/tradeoff ratio is sufficiently high. isaacl (talk) 21:33, 12 September 2025 (UTC)

As it stands the alert is often given as the warning before action (or request for action), which is contrary to the wording and intent of the alert templates, making the whole exercise even more silly. Everyone knows that getting hit with that template is essentially saying "keep it up and I'll see you at AE". ScottishFinnishRadish (talk) 22:28, 12 September 2025 (UTC)

I've been thinking about this, and while SFR is correct about it really being "keep it up and I'll see you at AE", I'm not sure that that's worse than someone finding themselves at AE without ever before being told that getting there was a possibility. Perhaps a more honest way of going about it would be to have a one-time informational template about the process, sort of like what the first-alert template does now, followed by something like a series of uw-ctop templates based on the existing uw- templates. --Tryptofish (talk) 21:54, 16 September 2025 (UTC)

Is more templates really the solution? ♠PMC♠ (talk) 22:55, 16 September 2025 (UTC)

Perhaps not, unless they are better than what we have now. And no templates may not be the solution, either. --Tryptofish (talk) 23:20, 16 September 2025 (UTC)

It also occurs to me that there could be a single uw warning, so as not to have a proliferation of templates. So there would be a standardized first-time notification that CTOPs exist, and a single template that "you are violating CTOPS, so stop or we go to AE" (but worded more diplomatically than that). --Tryptofish (talk) 23:58, 16 September 2025 (UTC)

Currently, there is a first alert template that must be used, and an alert template that can be used to tell an editor about a specific designated contentious topic area, but any message conveying this info is fine. Personally, I feel this covers your use cases. isaacl (talk) 05:22, 17 September 2025 (UTC)

I think there's a distinction to be made, between the intended use of a template, and how well the template is formulated in terms of whether or not it achieves its intended use. The non-first alert is intended, often, to tell someone to cut it out, but it isn't written that way. --Tryptofish (talk) 23:27, 18 September 2025 (UTC)

The point is that nothing prevents anyone from doing this right now, since any one can write any message they desire to tell someone about a designated contentious topic area, and anyone can create a warning template that others can choose to use if they find it appropriate for the particular circumstances. isaacl (talk) 14:30, 19 September 2025 (UTC)

As long as they use alert/first the first time. Currently that must be done. That has led to me including the alert/first after each use of {{welcome-arbpia}}, which kinda defeats the purpose of the welcome message. ScottishFinnishRadish (talk) 14:38, 19 September 2025 (UTC)

Yes, I mentioned that. isaacl (talk) 15:17, 19 September 2025 (UTC)

I think my suggested replacement covers that. Generally, editors should be made aware that they're editing in a CTOP with an explanation and link to the applicable CTOP page before they are sanctioned with CTOP powers. Egregious behavioral violations can be sanctioned without any prior communication. Still letting people know, just without having to cast the right magical ritual. ScottishFinnishRadish (talk) 23:18, 16 September 2025 (UTC)

Yes, that's a good point. I suppose an argument (not sure how valid it is) could be made that it's better to have defined language for letting them know, instead of leaving that up to anyone who does the letting know. --Tryptofish (talk) 23:23, 16 September 2025 (UTC)

Having a single, rigidly-defined way of defining awareness was how it used to work with Discretionary Sanctions, but that was (rightly imo) loosened with the change to Contentious Topics.

The point of awareness is to avoid people being sanctioned for do things they genuinely didn't know weren't allowed, especially if that thing is allowed more generally (e.g. a second revert on a page covered by a 1RR restriction). It also functions to alert editors that there will be both less leniency and potentially harsher repercussions in this topic area than more generally on Wikipedia.

If things aren't working in a way that is ideal currently, then I suggest we start by agreeing what principles we are trying to ensure and progress from there rather than adding yet more layers on top of what exists already. IMO the basic principles should be

• Behaviour/actions that would be unacceptable anywhere on Wikipedia should be dealt with (including in terms of severity of consequence) as if it had happened in a non-CTOP area unless it is clear that the editor in question unambiguously knew that there were additional/more severe consequences before doing whatever it was they did.
• Behaviour/actions that would be acceptable elsewhere but is not acceptable on a given page should result in a warning at most (and awareness for the future) unless it is clear that the editor in question unambiguously knew that there were additional/more severe consequences before doing whatever it was they did.
• Purely informational notices should be routinely given to every editor making substantive edits in a CTOP area as a matter of routine, unless they are clearly already aware. A warning of potential AE action should only be given before the user's first edit after receiving an informational notice for egregiously bad behaviour that would be sanctionable outside a CTOP area. Thryduulf (talk) 23:53, 16 September 2025 (UTC)

Well, there's also the fact that the move from DS to CT quietly lost the stern "Any editor who issues alerts disruptively may be sanctioned." which used to be part of DS procedure, because while yes, of course there may be some people that may be entirely unaware of CTOPs, primarily newer editors, and in that case, letting them know is useful. But that is often not just how DS/CTOP alerts have and are often being used, which is as a sort of disruptive/abusive intimidation by users who are in a discussion or edit with some other user and have been issuing them precisely as the intimidation/threat as SFR called out (while not checking if the user has been aware of them per the many reasons of why an editor may be aware of a CTOP which are not covered by the edit-filter of the CTOP alert (or the scarcely used {{DS/aware}} which was birthed during the the 2019 Clarification/Amendment discussion.

The template docs themself were not adjusted in DS->CTOP move, so it still contains the "Alerts ensure a user knows what is expected of them. Alerts are a neutral courtesy; never use them to intimidate, coerce, or shame another editor", but with the backing at the actual WP:CTOP page no longer making a mention of it, some people have seen it as an excuse to use is to intimidate others they are not agreeing with. Raladic (talk) 02:46, 17 September 2025 (UTC)

I think there are opportunities for ArbCom to move towards "AWARNESS being a defense" rather than an admin stopper that the move from DS to CT started. I do urge the committee be careful about what ends up in the body which was written to be readable and useful by Wikipedians of all knowledge levels. Best, Barkeep49 (talk) 16:19, 16 September 2025 (UTC)

Ok, now that we've had a huge discussion over the meaning of alert templates, does anyone have an opinion on the question I actually asked? :) --SarekOfVulcan (talk) 16:38, 17 September 2025 (UTC)

Done. ScottishFinnishRadish (talk) 17:05, 17 September 2025 (UTC)

Gracias. :) --SarekOfVulcan (talk) 17:13, 17 September 2025 (UTC)

I tucked it in a different paragraph that was talking about when not to give an alert, rather than the first paragraph, but I figured it was close enough. ScottishFinnishRadish (talk) 17:16, 17 September 2025 (UTC)

Yeah, thought that made sense. SarekOfVulcan (talk) 17:53, 17 September 2025 (UTC)

Awareness template

There is no template I could find that signalled awareness for all topics, so I created one. {{Ct/aware/all}} Is there a way to integrate this into the main one or put it as an option for a template? I would like others to be able to use it. Metallurgist (talk) 04:17, 19 September 2025 (UTC)

Note that your template is purely text, so it requires readers actually reading your page.

The actual {{ct/aware}} template invokes {{#invoke:Contentious_topics/aware|listToText}} for each ct, so that the automatic filter 602 can cross-check an attempt by a user to give a particular CT alert and whether it was given (I think, not 100% if the filter just hits if any alert was given for any topic).

Which in turn Module:Sanctions/AlertHelper and {{tlx}Contentious topics/table}} and {{Gs/topics/table}} are responsible for.

Long story short, Likely a change to the abuse filter 602 to specifically read your template as a universal "don't ever warn me about any CT, just assume I know" and just always matches, rather than trying to unravel the current logic might be easiest?

But I also know that @HouseBlaster is currently doing some stuff around the CT table templates, so maybe he wants to use it as an opportunity to outsource the {{for loop||call=Contentious topics/table/usageline|a-a|a-i|ab|ap|at|blp|cam|cc|cid|covid|ee|fg|gc|gg|gmo|horn|irp|kurd|ps|r-i|rne|sa|tt|ya}} sauce from the {{Contentious topics/table}} into something more generically parseable so it could be reused? Raladic (talk) 09:34, 19 September 2025 (UTC)

I'll start by saying that I consider myself aware of all contentious topics, so I understand the impulse. Where I struggle with this idea is that, by creating such a template, editors who use it are committing to being aware of any and all changes to CT designations, for as long as you use that template. I don't know if I want to give that the official seal of approval. (I am not sure how easy it would be to get filter 602 to recognize the awareness, but we can cross that bridge when we get there.) I will raise this on clerks-l, but I would personally say you should manually list all of them. Perhaps we can create an easy prefilled awareness template, which would make it possible to specify you are aware of all CTs currently in force? Best, HouseBlaster (talk • he/they) 12:41, 19 September 2025 (UTC)

CTOP/AE page protection logging (September 2025)

Original discussion

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

---

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. 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. 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 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.

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 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.

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 and Wikipedia:Arbitration enforcement log/Protections.

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

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

Majority reference

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

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)
2. Daniel (talk) 18:35, 8 September 2025 (UTC)
3. This does seem like it will be an improvement. - Aoidh (talk) 12:43, 10 September 2025 (UTC)
4. Primefac (talk) 18:42, 14 September 2025 (UTC)
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)
6. Worm^TT(talk) 12:58, 23 September 2025 (UTC)

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)

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)

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)

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)

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)

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)

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)

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

  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)

• 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)

  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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

@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)

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)

@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)

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)

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

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)

@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)

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)

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

Statement by ToBeFree

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)

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