Establishing a no personal attacks noticeboard

An editor has proposed a no personal attacks noticeboard. Please feel free to comment (or volunteer for making this initiative work) on the talk page. Dormskirk (talk) 17:36, 5 May 2026 (UTC)

Did the editor say why such a noticeboard was needed? Is there enough confusion about what counts as a personal attack to merit one? Darkfrog24 (talk) 16:46, 10 May 2026 (UTC)

Integrating WP:YEARS with WP:ITN, with regard to "Main Year Articles"

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia proposals Wikipedia policies and guidelines When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

If an event was featured as a blurb on WP:ITN, should that merit automatic inclusion for WP:YEARS' "Main Year Articles", such as 2022, 2026, and 2018? InvadingInvader (userpage, talk) 00:57, 7 May 2026 (UTC)

• Support as proposer, and the primary two reasons are firstly for for centralizing discussion, and as of a result, reducing and defracturing content disputes. Notably I feel like there have been quite a few content disputes with regard to inclusion on WP:YEARS articles often known as "the main year articles", such as 2022, 2026, and 2023, have had a lot of debate, and heated debate, within the past five years. As a party to many of them, I do feel like that having one issue debated in one place and another on an another page when so many of them. I don't exactly believe it helps for us to have one inclusion standard when it comes to one set of news and another on a separate set. Ideally, I'd like to reduce the amount of unnecessary discussion, and repeated ones too. The leading idea in my mind, as mentioned in the title, is to integrate the main year articles with ITN in some way (since these are among the most news-y articles we have on Wikipedia), but I'm not exactly sure where a proposal should land. I also want to avoid going too heavily into WP:NOTNEWS territory - which I am concerned of treading into, and my line of thinking is if ITN is the boundary for what can be considered compliant with NOTNEWS, then it's fair to apply this to the inclusion criteria. I also believe that a single centralized place for discussion can reduce the amount of differing interpretation on WP:DUE, which was originally the solution as presented after a 2023 ANI with regard to long-term ownership on WikiProject Years, though has quickly started to degrade in reference to While I do have some other concerns about how many years articles save for 2001 as mostly rewritten by @Thebiguglyalien are generic lists of events, I think this is too big of a problem to sort out now. For the more immediate term, though, I do think that having a more centralized method of inclusion, though not the only one to do at it, is the better way forward unless and if so until a less-listy solution in general is proposed. InvadingInvader (userpage, talk) 00:57, 7 May 2026 (UTC)
• Weak oppose, as the years articles benefit from a lot more hindsight (and can do with some secondary sources), while ITN doesn't necessarily have the time to do so with its one-week window, leading to some events like minor accidents taking the stage over longer-term trends throughout the year. On the other hand, this could also add a quality bias, as articles are frequently declined on the basis of quality alone. Chaotic Enby (talk · contribs) 01:44, 7 May 2026 (UTC)

  I think those are fair points - I would suggested that this would only apply to recent-ish years such as the past three years - and also that entires declined to be featured on ITN solely for article quality reasons wouldn't prevent it from inclusion on a year page. InvadingInvader (userpage, talk) 02:24, 7 May 2026 (UTC)

• Oppose. In general it seems against our ethos to base content on our internal processes, and that's before the process in question is ITN, an area so fractious and unpredictable that there have been proposals to abolish it. CMD (talk) 01:59, 7 May 2026 (UTC)

• Comment my first thought is that it would be easy for this to turn into (de jure or de facto) a requirement that events were posted to ITN (or at least those items nominated must have been posted). I would be strongly against that as there are many reasons why something may be significant to the year but not posted to ITN, including article quality issues at the time, unclear significance in the immediate aftermath, no one clear most newsworthy point (e.g. a series of recurring protests of varying scale occurring over several months is more notable in the aggregate than at any one point), etc. Thryduulf (talk) 02:12, 7 May 2026 (UTC)

• Oppose. Reliable sources decide what is included per WP:BALASP. If people are making inclusion arguments without citing sources, then their input might need to be ignored. And in terms of those who I trust to evaluate whether something is a so-called "significant" event, I'd rank ITN's judgement at around the same level as a primary school classroom's judgement, or maybe of that one octopus that predicts the future. Thebiguglyalien (talk) 02:38, 7 May 2026 (UTC)

comment I don't think we need a specific rule for this. It does seem like a good trend. If we post something as in the news, there is a high likelihood that it will have been suitable to be in an article about that year. But I'm sure that there are things that don't meet that criteria. It's not really a thing about ITN either, it's more how YEARS handles information posted at ITN. Lee Vilenski ^{(talk • contribs)} 12:01, 7 May 2026 (UTC)

Oppose Content inclusion should be based on sources not internal wiki processes. -- LCU ActivelyDisinterested «@» °∆t° 17:57, 7 May 2026 (UTC)

Show edit checks to slightly less new editors too?

Currently, new editors who have switched to WP:Visual Editor get shown WP:Edit checks. Edit checks remind them not to copyvio / LLM on certain pastes, and remind them to use references when adding new text in most type of sections. This is turned off when they reach 100 edits, but we can change this default onwiki (either in general or per check type). I suggest we change this to about 200 edits, as new editors might start with adding links in their first 100 edits, edit in namespaces that don't have edit check yet such as draft, or make a later switch to VE. Curious what other folks think. —Femke 🐦 (talk) 19:37, 7 May 2026 (UTC)

We should link this and other milestones to WP:XC where possible, instead of creating a new set of milestones for each technical change. CMD (talk) 02:15, 8 May 2026 (UTC)

This is probably the best approach, if only because it keeps things simple. Thebiguglyalien (talk) 03:09, 8 May 2026 (UTC)

Definitely support linking it to XC too, both so we can stay consistent and to have a higher bar (as issues like copyvios and LLMs aren't limited to the first 500 edits). Chaotic Enby (talk · contribs) 03:56, 8 May 2026 (UTC)

I'm open to extending it even further, but do we need this across the board? I think it's quite plausible for editors to start editing with a human touch and move to LLM editing later. Therefore, paste check makes sense to extend quite a bit. On the other hand, at some point people do understand references, right? Are there annoying false positives we should be thinking about when making this decision? I tried asking about performance at yesterday's Annual Plan meeting (does VE slow down measurably with edit check?), but I don't think my question was clear enough. Maybe User:Skdb-WMF knows the answer about performance? WMF has not yet studied how much edit check is still triggered for editors with 80-100 edits. —Femke 🐦 (talk) 07:18, 8 May 2026 (UTC)

In that case, would it be possible to disentangle both, so paste check is kept until a later edit count, or even for everyone? Copyvio has been an issue even for more experienced users, and so has LLM editing, and it doesn't make sense to tie them to the same level as teaching newcomers to add references. Chaotic Enby (talk · contribs) 10:09, 8 May 2026 (UTC)

We, can yes. We could do 200 as a default, and 500 for the paste check? Open to other numbers too of course. Not sure if SuggestionMode will use the same default value in the future, and if we should change the defaults there (I can imagine that there is more subjectivity, so leaving it for newer editors might make sense). —Femke 🐦 (talk) 10:28, 8 May 2026 (UTC)

Do we even need a limit for the paste check, for that matter? Chaotic Enby (talk · contribs) 10:30, 8 May 2026 (UTC)

Having seen this in action I am skeptical that this really does anything to dissuade people. I know there's no way to prove the negative here but there sure is a lot of "Edit Check (paste) shown" in the feed of articles with AI-generated citations. Gnomingstuff (talk) 16:57, 8 May 2026 (UTC)

We've only recently changed the default wording from 'pls no copyvio' to 'pls no copyvio or AI slop'. We know that the reference check has a massive effect, but the paste check A/B test was underpowered to show whether the decrease in revert rate was significant.

Decision making under uncertainty..

My gut feeling: I think it's quite likely this has a small effect in line with the nonsignificant findings of the a/b test (order of -8% reverts). I'll take that. —Femke 🐦 (talk) 17:10, 8 May 2026 (UTC)

Good thing is that it also prevents the excuses of "I didn't know" down the line. Chaotic Enby (talk · contribs) 17:17, 8 May 2026 (UTC)

Revert rate is kind of meaningless here, stuff slips through the cracks all the time. At this point I feel that people get reverted more often for pointing out AI, because no one ever fucking believes you. Gnomingstuff (talk) 05:36, 15 May 2026 (UTC)

You mean when you're patrolling, your reverts get reverted, as people assume (too much) good faith for the editors using AI? Given that paste check (and soon the LLM-specific paste check) tags when people decline, wouldn't it make the job of recent changes patrollers easier as they have more solid evidence of copy-pasta? How do you feel about raising the edit count for which this is shown? —Femke 🐦 (talk) 06:44, 15 May 2026 (UTC)

Personally I'd show AI paste check to everyone regardless of how many edits they have. * Pppery * _{it has begun...} 07:18, 15 May 2026 (UTC)

That does also happen all the time (even tags get reverted, and at least one person has threatened to remove tags even if there is a rationale), but I'm referring to stuff that just never gets caught. The majority of the articles currently tagged for AI-generated content were not tagged until months or years later. Gnomingstuff (talk) 07:19, 15 May 2026 (UTC)

I think you meant to link to Wikipedia:Village pump (policy)/Archive 212 § Clarifications on the applicability of NEWLLM. --Gurkubondinn 15:22, 16 May 2026 (UTC)

I don't usually participate in this type of discussion but just chiming in to say that tying it to XC seems very sensible. 100–200 edits is just not that many. No real opinion about applying this to paste check only. —Myceteae‍🍄‍🟫 (talk) 01:16, 10 May 2026 (UTC)

Based on the discussion here, I think there seems to be interest in:

1. Raising the max edits for reference check to be shown to 200
2. Raising the max edits for paste check to 500
3. When LLM-paste comes out and becomes configurable, having it shown to everyone.

Any objections to this? (I might need help implementing this) —Femke 🐦 (talk) 07:33, 15 May 2026 (UTC)

That looks good to me, as long as it's clear that these numbers are not set in stone and we explicitly anticipate reviewing them in the light of experience. Particularly LLM-paste which we've yet to see in action both in terms of error rate and editors' reaction to it. Thryduulf (talk) 11:29, 15 May 2026 (UTC)

restore mapframe on infobox concentration camp

Based on my bold edits in July 2025 (almost a year ago), the {{Infobox concentration camp}} template has had the possibility to show a map thumbnail for every infobox that had a specified set of coordinates, but did not have another map specified. Because of a bug, it also happened to be shown in some cases that had a slightly different syntax of specifying the {{location map}}, but I fixed that the other day. But then, @Buidhe noticed this and reverted the whole thing (not just the details of the implementation but all of it). This left the template in the last year's state where only a {{location map}} could be autogenerated from coordinates.

We discussed it a bit at Template talk:Infobox concentration camp, and made some progress. I restored the base functionality, but left the defaults disabled while the discussion is ongoing. However, as the template talk page only has 2 active watchers in the last 30 days, i.e. the two of us 🙂 it probably makes sense to discuss this in a wider forum, such as this one.

For context, that template is used in about 221 articles - Special:WhatLinksHere/Template:Infobox concentration camp lists them.

I still think there wasn't anything particularly wrong with showing a thumbnail in addition to the coordinate numbers by default when no other map was present. If we think of the reader contingents:

• Most readers who are interested in the geographical location do not know how to understand coordinates without visualising them on a map, so those readers would have been clicking these coordinates to get to the GeoHack or the MiniAtlas anyway.
• Readers who aren't interested in the location aren't really negatively impacted by being shown a bit more of that - it's easy enough to scroll past it for those who don't care.
• For the ambivalent readers, the little picture may catch the attention of some who might care, and impart some more information visually.

A lot of this also corresponds to how location maps are used, but they required a manual editor intervention, on a case-by-case basis. At the same time, the mapframes also allow the readers to click on them, see a bigger map and explore further.

The infobox mapframes have been deployed to probably tens of thousands of articles so far via various templates, cf. Wikipedia:Mapframe maps in infoboxes. They're not generally controversial, as they usually show a small amount of extra information compared to location maps. There have been cases where people have complained about them, and most of these have revolved around the geographical location component of an infobox being less than relevant in those cases (IOW the coordinates themselves there may be weird).

Buidhe has raised the issue of it being controversial to show concentration camp locations on modern-day maps. This already happens with pushpin location maps, though - most location maps are based on modern-day maps. Likewise for most of GeoHack. And, it's also not clear why this would be generally controversial. Most readers should be able to discern the idea of a historical event and how it relates to a modern-day location. And wherever a historical map is already provided, this mapframe default will take that into account and keep the extra thumbnail hidden.

I think we should bring back the default behavior that was there since last July (plus the recent bug fix obviously). --Joy (talk) 15:11, 11 May 2026 (UTC)

I believe that editors should make the choice to display a certain map, rather than it being pushed out stealthily and the change is only noticeable and able to be contested by the very few people who have templates on their watchlist. As noted in previous discussions the way that you are rolling these out also makes it really difficult for editors to figure out how to remove them if they are inappropriate to the article.

I oppose any maps being displayed by default especially when they are misleading, historically inaccurate, and/or anachronistic in most cases. (t · c) buIdhe 22:51, 11 May 2026 (UTC)

I disagree with the notion that there's anything stealthy here - the readers are seeing the thumbnails in a subset of the 221 articles, and by and large they're not complaining (I didn't even hear anyone say anything about the two map situation that I corrected earlier).

While I don't really agree that editing by way of reading documentation is very hard, we can and should make it easier - in this case, we can start by adding TemplateData so that the visual editor can start to function. --Joy (talk) 06:56, 12 May 2026 (UTC)

No. Applying by default to an existing template gives no account to the to the nature of the article, what maps already exist and whether it is appropriate to use a modern map. The choice to use mapframes in the infobox should be left to the discretion of editors on a page-by-page basis. I also note that the close of the 2020 RFC by Wugapodes was "mapframes should not be on by default". Cinderella157 (talk) 23:26, 11 May 2026 (UTC)

I agree with Buidhe and Cinderella157 and in particular with the well said statement The choice to use mapframes in the infobox should be left to the discretion of editors on a page-by-page basis. There are many articles on old historical events in which a modern google-like map at the infobox would be out of place. A.Cython(talk) 00:51, 12 May 2026 (UTC)

OK, but no one is suggesting adding them to all historical events. And in fact, no one is suggesting adding them to events at all, but to a small class of places. Jahaza (talk) 03:00, 12 May 2026 (UTC)

Err, did you read the comments before and the code? This code does check what maps already exist. Why are we arguing strawmen? --Joy (talk) 06:47, 12 May 2026 (UTC)

I am not sufficiently familiar with the code to see where and how it does such a check, though I am curious enough to want to know. I would presume it is somehow looking within the infobox for another map that is generated using Module:Location map? You are aware of the discussion at Template talk:Infobox military conflict#OpenStreetMap Mapframes should be default-no, not added to pages using this infobox without editor intervention that resulted because maps in that infobox had been turned on by default - I presume that this was a result of an action by yourself. Maps which may occur in the infobox and elsewhere in an article are most often image files, even if they may have been generated by use of Module:Location map. My observation from what happened in conflict infoboxes is that there were instances where an additional map appeared when there was already a map as an image in the infobox. Furthermore, what I said above was: Applying by default to an existing template gives no account to the to the nature of the article, what maps already exist and whether it is appropriate to use a modern map. I was not just referring to maps in the infobox but what maps already exist [anywhere within the article]. My comments here are informed by the cluster this caused when maps became default in the military conflict infobox.

To the comment, We don't expect someone interested in visiting the site of ..., WP is not a travelguide. There are many infoboxes that are already way too bloated and adding by default a chunk of information only exacerbates this problem. Cinderella157 (talk) 02:45, 13 May 2026 (UTC)

This case is different from that one because over there we have a Lua implementation that caused a different set of circumstances, and nobody seems to understand it enough to fix it - cf. March discussion.

In this case, this was the change: diff - we detect instances where another map is in the infobox. This code does not currently try to detect anything elsewhere in the article, because that is open-ended - how would we know if a particular image is a map, only with some heuristics like checking the file name or caption for the term 'map'?

With regard to what readers may learn from the article, this wasn't meant to encourage writing articles as travel guides, but to illustrate that we shouldn't try to guess what the readers may want as geographic information - maybe some of them want a historical map, maybe some want a modern-day map, maybe some want both. It's not clear why we would have to opt for historical map or nothing. --Joy (talk) 13:04, 13 May 2026 (UTC)

The cause may have been different but the effect was the same - maps were being added by default. So, the code checks for a map of the same type in the infobox but it doesn't check for maps in the infobox created differently (ie image files) or elsewhere in the article. That was my point and it is not a strawman. My reasons for saying no remain. Cinderella157 (talk) 00:20, 15 May 2026 (UTC)

Hard no. Historical maps should be used in most cases for historical articles. Modern maps are pretty much useless if the location being discussed in the article no longer exists. Page-by-page works best for this, not a stealth overlay that (as has been pointed out) isn't going to widely noticed unless you're actively watching templates. Intothatdarkness 00:58, 12 May 2026 (UTC)

But we do want to know where the site of some historical event or place is today. We don't expect someone interested in visiting the site of Oświęcim concentration camp to also travel in time, do we? Ponor (talk) 01:42, 12 May 2026 (UTC)

Page-by-page works best for this, not a stealth overlay that (as has been pointed out) isn't going to widely noticed unless you're actively watching templates. Well, it seems we could solve that objection by discussing it on a widely read noticeboard first. Jahaza (talk) 02:57, 12 May 2026 (UTC)

Or simply leave it to a page-by-page editor decision instead of making it some kind of bizarre opt-out. It feels like the decision has already been made, frankly. Intothatdarkness 11:52, 12 May 2026 (UTC)

That's may feel like that because an editor in each of those cases already added a set of coordinates. --Joy (talk) 14:44, 12 May 2026 (UTC)

No...it has to do with the way this is being presented. @Cinderella157 makes good points above, and the earlier RFC said these should not be used by default. Both these things appear to be being ignored in favor of the next great shiny thing. Historical maps also present the geographical context of an event. How useful is a modern map going to be, for example, if the article is about a location that has been flooded by the construction of a reservoir (to give one example)? Modern maps also won't accurately represent settlement patterns or locations in their historical context. However, context usually loses in favor of the next shiny thing. Intothatdarkness 14:59, 12 May 2026 (UTC)

Oh, speaking of the RFC, that's another red herring. In the meantime we had another discussion, where we asked the RFC closer about that, and this was the response, explaining what the actual meaning of that closure was.

With a modern map only being a default, if it is better replaced with a historical one, it's easy enough to do so. The moment someone adds a historical map, the modern one gets hidden. Even if 'shiny', it doesn't stay. --Joy (talk) 15:09, 12 May 2026 (UTC)

Not a red herring. It simply said there wasn't enough for a sweeping consensus. One could take many things from that response, actually (including that supporters of the change simply outlasted everyone else in the discussion). And you still have to take action to replace the shiny map...and many users may not know how to do that or assume the maps are automatic in some way. And you still don't address how a modern map is helpful in many cases for establishing historical context of events. Intothatdarkness 15:26, 12 May 2026 (UTC)

Disregarding for the moment the RFC thing, I don't really understand where this level of fear is coming from.

If a default map isn't good enough, it can be replaced through the same mechanism of editing that works elsewhere - the reader has to become an editor by clicking the edit buttons and learning a little about template syntax. It's pretty easy to learn to delete bad coordinates= parameters, or to type in mapframe=no in the right place, esp. compared to learning to draw a historical map.

And it's all theoretical anyway, as I've yet to see a single example of where we'd expect to actually do that. --Joy (talk) 18:49, 12 May 2026 (UTC)

I don't really understand where this level of fear is coming from. It should be obvious why editors would want to make sure our coverage (including maps) of the sites of industrialized genocide are accurate, in proper context, and sensitive to the modern geopolitical landscape. More broadly, these editors have been explaining their concerns to you for at least 6 months across dozens of pages. If you genuinely cannot understand, then you should not be editing this template.

If a default map isn't good enough, it can be replaced through the same mechanism of editing that works elsewhere - the reader has to become an editor by clicking the edit buttons and learning a little about template syntax. Have you considered that your stated plan of "someone else will clean up after me" is why the editors doing the work are complaining? Have you considered that your attitude towards errors about the holocaust might make other editors think that you don't really care about encyclopedic quality? Given what you may know about antisemitism and holocaust denial in the world, do you think potentially spreading inaccurate information about concentration camps is a net negative or net positive for society? These are rhetorical questions, of course, but hopefully they illustrate why there seems to be a lack of trust regarding your project.

Joy, please reconsider this project to add default-on maps to infoboxes. 6 months ago when your behavior was being discussed at ANI, I said you looked like you were still trying to build consensus. Each time I get a ping about that old 2020 RfC close, I've become less confident about that. You need to take a step back and listen before things continue to escalate. — Wug·a·po·des 06:54, 13 May 2026 (UTC)

But all this time it's not me who is adding the map. The coordinates are already there. If we're misleading readers with them, we are already doing it. How is this unclear? --Joy (talk) 07:53, 13 May 2026 (UTC)

Beyond that, the edits that were reverted were from last year. There was absolutely no new functionality added recently - in fact my recent technical edit that seems to have triggered Buidhe's revert was removing some maps. There was in general very little new activity on this matter - this is not a long, still ongoing discussion where there's a failure to build consensus - we just stopped discussing things from back then (like the military conflict template or the behavior of the Wikidata ingestion).

I understand the idea that visualising existing errors makes those errors worse. Still, I don't see how this makes sense in the grand scheme of things, because if we generally thought that hiding issues was a good principle, we would not be editing Wikipedia in the open. All of the errors in Wikipedia are very visible already - it's all out there. Any broken coordinates in those articles are already being shown on very similar modern map layers, it's just barely hidden behind a click or two. --Joy (talk) 08:33, 13 May 2026 (UTC)

@Joy, you really should reconsider the use of "fear" when you're describing people who don't agree with your position. It appears to be an attempt to both minimize and diminish opposition to your position. People HAVE provided reasons why they don't agree with this, and you continually ignore them or try to minimize them by using words like "fear" in the context you did. Intothatdarkness 23:12, 13 May 2026 (UTC)

I'm sorry, but this little bit of automation has been described as 'stealthy' and 'bizarre' already, and you didn't seem to have any complaints about language then. I can't explain to myself why so much emotional language is used for a feature that really isn't that obfuscated or uncommon. Nobody's identified a single coherent example of where these supposed problems would actually manifest, beyond an apparently inapplicable example of Poles not liking a map of Nazi camps within the modern-day borders. It's hard to agree when the reasons seem to be largely speculative. --Joy (talk) 08:02, 14 May 2026 (UTC)

The difference is those terms were applied to a coding change that seems to have been made with little discussion or notification, not to you personally. You're using the word "fear" to dismiss concerns and minimize those who have them. That you don't seem to understand that is troubling. Intothatdarkness 17:21, 14 May 2026 (UTC)

As I mentioned before in the earlier linked talk, modern maps are not pretty much useless - they can help readers orient themselves in geographical terms and in this case with historical concentration camps it can help them ponder where the memorial area is. It's like learning about any other historical topic - just because it's no longer there that doesn't mean it's not interesting to readers to figure out how to get there. --Joy (talk) 06:51, 12 May 2026 (UTC)

There is a real issue where you just ignore and /or bludgeon all of the content editors when making sweeping backend changes without a community consensus. (t · c) buIdhe 20:06, 12 May 2026 (UTC)

I did not ignore anyone. I do expect people to follow the policy and argue with reasons, not just assertions (WP:CONS). I find it sad that you feel ignored, yet when I ask for simple examples where the actual issue is, few to none are provided. It would improve the discussion if we focused on the factual matter at hand, instead of arguing that my good-faith efforts to improve articles for the readers are disruption. --Joy (talk) 08:09, 13 May 2026 (UTC)

1-way interaction bans

Replace one-way interaction bans (Ibans) with final warnings to prevent stonewalling and revenge editing, which occur when protected editors oppose changes without a right of reply. This final warning formally lowers the evidence threshold for future harassment, streamlining administrative enforcement and treating subsequent violations like standard Iban breaches, while still allowing reformed editors a path to successful appeal. Administrators can combine this warning with a recommendation for voluntary self-isolation or context-specific restrictions such as a one-week two-way Iban for immediate issues, a ban on mentions in unrelated threads, or banning editor X from editing articles that editor Y is already editing to stop them from following them around the site, but still allowing interaction on pages that editor Y came to after editor X had already started editing there. NorthernWinds ❄️ (talk) 22:38, 13 May 2026 (UTC)

• Oppose original proposal to replace 1-way I-bans. Please note that this original proposal was condensed by NorthernWinds (her... right?) (diff). Shall I explain further about this? Undecided if proposed as NOT a replacement but some sort (of a non-replacement, obviously). --George Ho (talk) 20:38, 15 May 2026 (UTC)

The proposal includes active 1-way iBans, right? --George Ho (talk) 20:39, 15 May 2026 (UTC)

@George Ho It is a replacement. If implemented, it would mean that 1-way Ibans no longer exist. It proposes adding other guardrails which I believe are sufficient replacements. NorthernWinds ❄️ (talk) 20:59, 15 May 2026 (UTC)

What about ones passed by the ArbCom then? George Ho (talk) 21:39, 15 May 2026 (UTC)

@George Ho We can leave the old ones in place but it will no longer be an tool in the administrators' toolkit NorthernWinds ❄️ (talk) 07:27, 16 May 2026 (UTC)

This week's article for improvement

I did not AI generate this, I'm just detailed. It'll be worth reading.

Projectspace page for election voter guides?

At the information page for the ongoing admin election, there is a section on voter guides:

A list of unofficial voter guides may be found at Category:Wikipedia administrator elections May 2026 voter guides. Voter guides may be mentioned in passing and directly linked from candidate pages and talk pages. There will be no official voter guide, nor should voter guides be linked from the election's header template.

This is clear that editors are permitted to produce or seek out voter/candidate guides. My issue is this link is a pain to remember/find within the page, especially on mobile. If I want to locate relevant voter guides, I should be able to type WP:VOTERGUIDE and have immediate access. If the reason we don't have that is "we want less people to use voter guides so we are going to make it tedious to access, even though we permit it", I think that is irritating and patronising.

I have put a proof of concept at User:Whonting/Voter guides. Alternatives may include a WP:VOTINGGUIDE to a subsection of Wikipedia:Elections with a link to candidate/voter guides of any ongoing elections, or straight to the category page.

I wanted to check if this aligns with community sentiments before moving such content to projectspace. Whonting (talk) 11:37, 15 May 2026 (UTC)

Strongly oppose. Voter guides are something we should not be permitting at all, let alone endorsing in projectspace. They are always (although occasionally not intentionally) a way to push the author's POV about what is/isn't important and their subjective opinions about candidates. Every voter should always be doing their own research into the candidates and voting based on that, not outsourcing their thinking to someone else. If you don't have both the time and interest to do your own research then you should not be casting a vote. Thryduulf (talk) 11:53, 15 May 2026 (UTC)

I am uninterested in relitigating whether voter guides should or shouldn't be permitted. At this time, they are permitted, and they are linked (?endorsed) in projectspace. This does not change that, it only makes access for those seeking them out as permitted less tedious. If you have issues with a standalone projectspace page, I have listed alternatives. Whonting (talk) 12:10, 15 May 2026 (UTC)

They are presently permitted, and permitted to be linked from but not endorsed in project space. This is, imo, already far too accepting and your proposal moves things in completely the wrong direction. We should at minimum be discouraging voter guides and making those that do exist harder to find not easier. Thryduulf (talk) 13:03, 15 May 2026 (UTC)

Oppose per Thryduulf. We don't want voter guides to appear to be authoritative reference points, or be given any more official standing than "a user's personal thoughts". Permitting something doesn't mean it has the community support that such a projectspace page would imply it has – more broadly, editors are given wide latitude to present their thoughts in userspace, even if they are not aligned with broader community consensus, but that doesn't mean userspace essays should be given any extra visibility. Chaotic Enby (talk · contribs) 12:07, 15 May 2026 (UTC)

As a workaround, perhaps you can save a bookmark to Category:Wikipedia administrator elections voter guides in your browser, or save a link to the category page on a page in your user space. isaacl (talk) 16:58, 15 May 2026 (UTC)

• Mixed / support I oppose the stated proposal to put voter guides into a dedicated space. Our current infrastructure puts these in userspace, and we have a regulatory system for userspace, and keeping them in userspace indicates that voter guides are personal views. I like that system.

@Whonting: I encourage you to develop Wikimedia democratic processes more and support your intent to encourage more user participation. Now is a great time for this. One starting place could be developing the documentation at Wikipedia:Elections. We do not have a central place to alert Wikimedians of elections, and that could be a landing page for alerts, instructions, and descriptions of elections. Besides elections on English Wikipedia, many readers here may be interested to vote on Commons:Commons:Picture of the Year, meta:Stewards/Elections, or any of the other votes which are off-Wikipedia, but which affect Wikipedia. The most organized elections now all use voting software, usually meta:SecurePoll.

Besides elections, there are other democratic processes which could use more attention. The Wikimedia Foundation has an annual budget of US$200 million and there are places where community input sets priorities for how to spend that. The meta:Community Wishlist takes votes and directs money, and the WMF every year asks for feedback on the annual plan, as with meta:Wikimedia Foundation Annual Plan/2026-2027. At a lower level, the WMF awards grants for regional and thematic programming, and these go out on the idea that Wikimedia editors support them. In practice there could be more review, see meta:Grants:Programs/Wikimedia Community Fund/Review/2025-26. Comments on programs are a sort of vote for what to develop.

Good luck, please do whatever you can. Bluerasberry (talk) 19:05, 15 May 2026 (UTC)

There is a category for election guides, I can't see a pressing need for anything else. Also your mock up mentions an official voter guide, but that was rejected repeatedly in the AELECT RFCs. -- LCU ActivelyDisinterested «@» °∆t° 19:10, 15 May 2026 (UTC)

Bot to create arbitration enforcement editnotices

(previous discussion on this idea was held at Wikipedia:Bot requests#Arbitration enforcement editnotices)

I am seeking consensus for a bot/bot task that automatically creates editnotices for articles protected as arbitration enforcement actions.

I believe these editnotices should be created in the spirit of awareness, especially for topics under 1RR sanctions by default (WP:CT/PIA, for instance). Currently, breaches of a page restriction may result in a block or editor restriction only if [...] [t]he restricted page displayed an editnotice [...] specifying the page restriction. Adding an editnotice to applicable pages standardises enforcement and would reduce the workload required of administrators.

User:ClerkBot currently logs such protections at Wikipedia:Arbitration enforcement log/Protections, pursuant to an ArbCom motion enacted in September 2025, on a daily basis. As proposed, the new bot would review additions to that page each day and create editnotices, if not already present, for newly indefinitely protected mainspace pages. It will also retroactively work through the logs and apply editnotices to pages previously protected, if still applicable (manual example). Thus, articles receiving new editnotices would already have been deemed within scope by the protecting administrator.

I am open to any questions, comments or criticisms you may have; thanks for your consideration. Best, Staraction (talk · contribs) 06:19, 16 May 2026 (UTC)

Notified: Wikipedia talk:Arbitration/Requests/Enforcement, Wikipedia talk:Arbitration Committee, Wikipedia:Bot requests and Wikipedia talk:Requests for page protection. Staraction (talk · contribs) 06:25, 16 May 2026 (UTC)

Also notifying, via ping, previous participants in the discussion: @Bunnypranav, @Isaacl, @Valereee, @ScottishFinnishRadish. Staraction (talk · contribs) 06:34, 16 May 2026 (UTC)

Anything that can efficiently and correctly automate the paperwork at AE would be great. Valereee (talk) 11:05, 16 May 2026 (UTC)

Agree: less work hopefully attracts more admins to AE work. —Femke 🐦 (talk) 12:22, 16 May 2026 (UTC)

Anything that cuts down on all the paperwork is good. ScottishFinnishRadish (talk) 00:31, 17 May 2026 (UTC)