Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.

Before creating a new section, note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for 10 days.

« Archives, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82

Sanger's grand reforms: a post-mortem?

Catharsis. After a long drawn-out discussion, Larry Sanger's community ban, and the closure of WikiProject Intellectual Diversity, it seems as if a chapter has come to an end. And, in the broad strokes, I would agree: most of the theses were, as proposed, far from net improvements, and more often than not actively detrimental if implemented as such.

However, I do believe there are still some nuggets of truth in some of these ideals. Not changes we should adopt right off the bat, of course, but springboards to broader community discussion, observations that we can collaboratively refine into concrete proposals. Two in particular come to mind: reforming indefinite blocking, and ANI discussions. Chaotic Enby (in solidarity · talk · contribs) 09:35, 29 June 2026 (UTC)

More broadly, i think some version of a wikiproject intellectual diversity could have been worth it had larry sanger been willing to cooperate. (I am under no illusions who such a project would be for, but additional voices do improve wikipedia in the long term, even voices i disagree with) User:Bluethricecreamman (Talk·Contribs) 15:46, 29 June 2026 (UTC)

I agree with the core purpose, although I feel like working with the existing Wikipedia:WikiProject Countering systemic bias would be a more durable solution against WikiProject fragmentation. But that is definitely something that can be worked on! Chaotic Enby (in solidarity · talk · contribs) 17:23, 29 June 2026 (UTC)

I think the “wikiproject intellectual diversity” (WPID) banner is slightly different than the countering systemic bias banner. The latter is more all encompassing of fighting systemic underrepresentation of women, the global south, minorities. Its strange bedfellows with WPID members.

wpid probably targets conservative voices who feel shirked by wikipedia. I do think that deserves its own community (if they can agree to behave and not canvas, which wpid under larry sanger probably would not have), and hypothetically we could harness them to help improve articles. User:Bluethricecreamman (Talk·Contribs) 18:30, 29 June 2026 (UTC)

There are some interesting subpages in this project. Like this one. Where did this come from? Sesquilinear (talk) 23:32, 3 July 2026 (UTC)

I think it's a really good point, relating to undisciplining, siloing, and the overemphasis on Western academic divisions. It probably comes from the same place my feeling on the matter comes from. — Preceding unsigned comment added by ~2026-41211-85 (talk) 21:12, 22 July 2026 (UTC)

• I think that the fundamental problem is that intellectual diversity is a very loaded term due to its extensive use in a variety of contexts by people who feel that American conservativism, in particular, is not prominent enough in a particular space. And the problem with that is that while there are certainly some perspectives and viewpoints that are not well-represented among editors, American conservatism is not one of them. If you glance at the talk page for almost any WP:AP2 article you'll find it well-represented (after all, the fact that both the major strands of mainstream American politics are well-represented and at odds with each other on AP2 pages is the entire reason we have AP2 as a WP:CTOP.) More generally, the adherents of any nationalist or religious ideology are always going to feel they are under-represented on Wikipedia (note how Sanger also attempted appeal to Indian nationalists, who, again, already have a heavy presence, which is obvious just by looking at the relevant talk pages), because in their own country they're usually at or near a majority. But Wikipedia is an encyclopedia with a broader view; even though these views are comparatively well-represented, the people holding those views feel oppressed because to log onto Wikipedia is to go from being comfortably within the majority and mainstream of their own country, to being a minority in an international community. And this is compounded by the fact that many of the movements for such views have taken a perspective that is bluntly unencyclopedic (ie. rejecting expertise, academia, the entire mainstream news, and so on.) The reason why eg. our article on the 2020 election presents its outcome as not in doubt, or why our article on Fascism describes it as a right-wing movement, isn't because either article lacks for people who drop in and try to argue that they should be changed; it's because they've staked out a position those topics that is genuinely unencyclopedic, in that it's unsupported by any high-quality sources. That's not the result of a lack of intellectual diversity. --Aquillion (talk) 02:59, 5 July 2026 (UTC)

  To add to this: to the extent Sanger has any kind of point about the political lean of Wikipedia, it's not because we have a POV but exactly because we follow WP:NPOV, and WP:V. Political opinions, unlike what Sanger seems to think, are not pure fact-free endeavors. Sometimes, in fact often, a commonly held political opinion will clearly contradict reliable sources, and in that case we go with the reliable sources and not try to make the facts fit some kind of view-from-nowhere like Sanger seems to want.

  In cases where the conservative point of view is the one supported by the sources, our articles reflect the conservative point of view. Go look at our article on rent control for an example. The reason our articles on, say, race or gender are not particularly friendly to the conservative point of view is mostly because the sources aren't either. Loki (talk) 18:12, 5 July 2026 (UTC)

This is not a forum to discuss the effectiveness or otherwise of rent control. Thryduulf (talk) 20:04, 6 July 2026 (UTC)

• I think that is a weird example. The entire purpose of rent control is to make housing affordable, not address the criticism that it reduces housing quantity and quality. The limited studies mentioned in Rent control#On low income renters have one against and two for the claim that rent control makes housing stably affordable. In solidarity, Aaron Liu (talk) 20:51, 5 July 2026 (UTC)

  Housing quantity itself makes housing more affordable, so rent control reducing housing quantity ultimately makes housing less affordable for anyone who doesn't directly benefit from it. At least, under the mainstream economic reasoning we're talking about here. Loki (talk) 22:04, 5 July 2026 (UTC)

  That's not quite right. It depends on circumstances.

  Hawkeye7 (discuss) 04:16, 6 July 2026 (UTC)

  The price ceiling meaning it's impossible to make it less affordable (unless said ceiling is higher than the price without said ceiling) aside, the law of supply and demand you're talking about only applies if supply exceeds demand. Meanwhile, the US has for a long time had a housing shortage for decades, New York's City has had a housing shortage since the end of White flight, and California since the '70s; there's 6 US states with localities enacting rent control and that's 2 of them. A lot of that quantity from lack of rent control you're talking about might come from the law of supply: it's the fact that the price is high that's drawing more to enter this market and supply more quantities. Since this is economics there's a ton of other factors that I omit and do not know but IIRC this is the picture in broad strokes. In solidarity, Aaron Liu (talk) 19:47, 6 July 2026 (UTC)

I proposed, but nobody took me up on it, to create a new taskforce within the systemic bias project. Andre🚐 20:53, 5 July 2026 (UTC)

I wouldn't be against it, although this taskforce should also, as part of its responsibilities, ascertain whether there is such bias to begin with. Compared to geographic bias or gender bias, ideological bias can be much tougher to quantify, especially when the expert consensus and the general public can be at odds. Chaotic Enby (in solidarity · talk · contribs) 21:01, 5 July 2026 (UTC)

I think there is likely all types of bias. For and against anything you can name. I think it makes sense given that most Wikipedians are younger and more liberal/left-leaning that there may be blind spots. Andre🚐 21:03, 5 July 2026 (UTC)

While its true that there is likely bias, you (generic) need to show that there is actually bias in some identifiable form for or against a given thing, and that this is systematic (i.e not just a single biased article) before it can be countered. A project to counter systematic bias against music by blonde musicians would at best be pointless unless you can show that there is a systematic bias against such music, at worst it could make things worse if it turns out that there is actually a bias for such music. Thryduulf (talk) 21:19, 5 July 2026 (UTC)

I think it would be a job for the taskforce, as Enby says, to through a neutral, non-canvassy process, solicit internal info about the extent and directions of various biases. For example Sanger mentioned Hindu topics. Not an area of my expertise. But, going to my wheelhouse, preliminary thoughts would be that we could easily find structural bias in hot-ticket American politics articles. We all hate Trump (I sure do) and Wikipedia should not pull any punches, but fairly following NPOV and sourcing policies should strengthen, not weaken coverage about politics and help educate readers, while defusing the critics. For example there was recently a consensus that we need to overhaul the Steele dossier article due to an overreliance on primary sources. I have been working on the article but there is still tons more to do there, and I really think TNT is disrespectful to past contributors and PRESERVE so I have been working to trim, rewrite, and incrementally improve it without reducing it to a stub even though it still has a lot of problems, some of which relate to how NPOV should work in current events articles. Another example would be the recent RSN discussion about CBS News under the Bari Weiss era. I know several of my Jewish family members that would call Bari Weiss a Nazi. The point of mentioning that is to say that she is a divisive figure and that there are lots of factions within different voting blocs (see also, the discussion about whether DSA is a party). But the invective and vitriol for and against her should not color the neutral, factual measurement of whether the source is now unreliable. Andre🚐 21:35, 5 July 2026 (UTC)

Agreed, there is at least a few philosophical views that bias is inherent to everything but im not a philosopher and am not licensed to know how valid/invalid views are

agree that what is and isnt objective bias is besides the point, having more editors coming from different avenues of life is usually better, and allowing them to organize within wiki principles to find and correct blindspots seems a good thing. User:Bluethricecreamman (Talk·Contribs) 21:21, 5 July 2026 (UTC)

It is clear though that Neutral Point of View has drifted a long way from what Langer Sanger envisaged when he wrote the policy. We should revisit it. Maybe a Multiple Points of View Policy would be better. Hawkeye7 (discuss) 04:11, 6 July 2026 (UTC)

Its drift, which happened fairly shortly after LS left, was honestly for the better; look up what the Citizendium article on homeopathy was before it was pointed out and the CZ community overrode Sanger. Sesquilinear (talk) 04:16, 6 July 2026 (UTC)

But why keep it when we abandoned it for Consensus Point of View long ago? Hawkeye7 (discuss) 04:21, 6 July 2026 (UTC)

I think if folks want to debate if WP:NPOV needs to be changed, they may do so on that talk page. They need to be here first to have a voice, which was the point on LS’s wpid though i suspect that npov is unlikely to change as a useful and very good policy User:Bluethricecreamman (Talk·Contribs) 12:04, 6 July 2026 (UTC)

@Hawkeye7 I think that multiple points of view were among the ideas that LS championed. I think there was even talk of allowing competing articles (with different viewpoints, which seems to mean that you are picking from a different set of RS), and letting readers vote the articles up or down.

This is not the place to revisit or re-discuss that idea, but I wanted to mention it, since you brought it up. David10244 (talk) 05:08, 8 July 2026 (UTC)

I think thats a pretty good idea. User:Bluethricecreamman (Talk·Contribs) 21:10, 5 July 2026 (UTC)

What about disabling TAs and requiring an account to edit? Iirc, that was somewhere in there too. Asking someone to register before they can edit doesn't go against the spirit of "anyone can edit", because it's a quick process, which doesn't require an email or any kind of confirmation, that anyone is able to do. TurboSuperA+_[talk] 16:05, 29 June 2026 (UTC)

It's definitely on the feasible side, and some Wikipedia editions already do it, but the cost/benefit has to be considered, as there are many good edits from TAs and requiring an account can put an engagement barrier in front of editing. Most prospective editors won't take the time to do it if they want to, say, just fix a typo.

I don't think this one is necessarily a non-starter either, but it's very situational and depends on whether the larger priority is anti-vandalism or editor retention. Chaotic Enby (in solidarity · talk · contribs) 17:26, 29 June 2026 (UTC)

It's a non-starter. This is because it's probably the most rejected perennial proposal of them all, and because m:Limits to configuration changes forbids changes that "Remove editing permission from a user group", because "Anyone can edit" is a non-negotiable principle of Wikimedia projects. Full revocation of editing permissions from any user group will not be enabled.

Portuguese Wikipedia does restrict TAs from editing articles, but still allows them to edit talk pages and other namespaces. SuperPianoMan9167 (talk) 17:46, 29 June 2026 (UTC)

Either way, I think we're pretty clearly in agreement that this is not a helpful direction for the English Wikipedia as our priorities are much more aligned with editor retention than with restricting a little bit of vandalism. Chaotic Enby (in solidarity · talk · contribs) 17:53, 29 June 2026 (UTC)

If it's one of the "perennial no" proposals then I can drop it. Just re: editor retention; why would an editor who can edit as a TA ever create an account? Conversely, if an editor creates an account, they might be more likely to stick around and edit more. If someone only fixes typos as a TA on articles they read, are they an editor or an engaged reader? Food for thought. TurboSuperA+_[talk] 17:59, 29 June 2026 (UTC)

There are many benefits to creating an account, including the ability to save preferences. This feature alone probably convinces at least some readers to make an account because then they can customize how the site looks. SuperPianoMan9167 (talk) 18:09, 29 June 2026 (UTC)

If you ban TAs you're not going to see people accounts stick around more. You'd just be funneling the original TA base under an "account" sticker. In solidarity, Aaron Liu (talk) 20:33, 29 June 2026 (UTC)

@TurboSuperA+, past surveys of experienced editors show that about half of us (including me) started editing as IPs/TAs. If there were really no reason to create an account, none of us would have. See Wikipedia:Why create an account? for some of the reasons why being a registered editor is better than editing as a TA. WhatamIdoing (talk) 17:04, 3 July 2026 (UTC)

I think the ability to edit unauthenticated is useful for wikipedia mantra of the encyclopedia anyone can edit. User:Bluethricecreamman (Talk·Contribs) 17:46, 3 July 2026 (UTC)

Sure, whatever Larry proposed may appear to be unfinished business. However, the ideas here are either time-sinks or doomed to failure, IMO. I don't need to explain further, do I? Meanwhile, the following draft may need some improvements, especially from those wanting to raise awareness or even rejecting its existence: Draft:Intellectual diversity (edit | talk | history | links | watch | logs). —George Ho (talk) 17:49, 29 June 2026 (UTC)

Indefinite blocks

The impetus for reforming indefinite blocks doesn't just come frome Sanger's theses, but also from this study on millions of blocks published in The Conversation. The gist of it is: as our admin corps has been dwindling, blocks have trended towards being more harsh, and simultaneously less clear. This creates a hostile environment for newcomers: not all of them will be willing to navigate our unblock interface – even with more accessible tools – or ask admins for explanations about their blocks.

So, what? Should we do away with indefinite blocks entirely? Most likely not. Some users, like long-term abusers, certainly require it, and keeping track of the latest sockpuppet's block expiry would be unfeasible. Shared or role accounts will remain blocked, even though each person behind them may be invited to create a separate account. However, there is certainly a case for most run-of-the-mill blocks to expire naturally. This philosophy mirrors that of WP:TRYUNPROT: the best way to check if page protection is still necessary is really just to lift it and see what happens. In the same vein, a user returning after six months or a year can usually be afforded a second chance.

To be fair, this isn't as far from accepted practice as it might seem. The standard offer is already a thing in many situations, and showing that one understands why they were blocked usually goes a long way towards being unblocked.

The psychological effect of selecting a block duration also comes into play. Is a block for "regular" vandalism worth a full year? Two? Five? And yet, these blocks can also all be appealed ahead of schedule if the blocked user shows adequate understanding. In this sense, they are less harsh than an indefinite block, despite the latter being psychologically easier to set as we aren't facing a definite scale, but focus more on the possibility of appeal. This paradox means that we can often set blocks that are much harsher on the user than what would be proportionate, despite not seeing it as such.

Formalizing this, by figuring out which "regular" blocks (e.g. vandalism-only accounts) can be time-limited by default, is the next natural step, especially if we assume that a big part of the bottleneck (understanding the reasons for the block) may be solved with more precise communication. Of course, we can't cover every specific situation, but having an indicative reference chart for block durations can go a long way. In fact, Italian Wikipedia already does this! Chaotic Enby (in solidarity · talk · contribs) 09:35, 29 June 2026 (UTC)

Personally I think blocking for a year is almost always going to be better than indef for first-time blockees that aren't overtly malicious. This would work especially well if we could get a "probation" recent changes feed that showed all edits from recently-unblocked accounts. -- LWG ^{talk (VOPOV)} 20:44, 29 June 2026 (UTC)

Agreed, I really like the idea of time-limited blocks for all except WP:ZT cases, socks, and CBANs, but will defer to others Kowal2701 (talk, contribs) 22:10, 29 June 2026 (UTC)

Copyright issues, serious source-text integrity issues, and good-faith POV pushing are the sorts of blocks that often need to be indefinite (not infinite!), especially if the original errors are made in good faith, and especially so if they're hard to catch. Otherwise, the editor risks coming back, not fully understanding the issue, engraining more bad habits, then blocked forever and all unblocks denied because they fucked their previous second chance up.

The data on "what are the most common indef block reasons" def. seems like something quarryable; I think I tend to trend a bit laxer than the rest of the community when it comes to indef bans for other forms of disruption (I think I've only ever actually supported... oh, man, I think one block/CBAN?) GreenLipstickLesbian💌🧸 22:51, 29 June 2026 (UTC)

Yes, copyright issues should remain indefinite. Tbh I think that sort of POV pushing can often be put down to immaturity, which I hope a time limit might be good for, but who knows Kowal2701 (talk, contribs) 00:47, 30 June 2026 (UTC)

Re: immaturity: yes, that's a good point. I suppose this is a point where community and admin discretion come in useful. GreenLipstickLesbian💌🧸 01:16, 30 June 2026 (UTC)

I think what we need to do is a combination of:

• Making it clearer that indefinite does not mean infinite (both for blockees and those evaluating unblock requests).
• Making guidance about how to write successful appeals more prominent in block messages and easier to find generally.
• Becoming better at offering advice and explanations before someone is blocked.
• More often assuming good faith of those who don't get things right first time.

In many cases people should be blocked until they understand why they were blocked. Sometimes that takes only a day or so, sometimes it never happens, but we should be more willing to unblock when it's clear regardless of how long they have been blocked (WP:NOTPUNITIVE and all that). Thryduulf (talk) 02:21, 30 June 2026 (UTC)

@Kowal2701 Blocks for copyright issues should be indefinite only if the editor persists. New editors often just need some education in the matter. David10244 (talk) 10:02, 8 July 2026 (UTC)

My opinion on the blocks that should be indefinite as a baseline are as follows:

• Blocks where the subject has an extensive history of prior blocks, including a 1yr block.
• Blatant or Checkuser-confirmed sockpuppets of already-banned users. (for sockmasters, see the bullet above.)
• Sealioning in a contentious topic (especially the intractible ethno-political hellholes and GS)
• Username blocks, with a detailed explanation of why and how to appeal for usernames that aren't trying to be profane or harassing
• Blocks for blatant and unrepentant copyvio. (Accidental/unwitting copyvio should be given a mid-term block and an explanation)
• Any block related to a functionary's (CU/OS) investigation.
• Autocon- or excon-busting if done to involve oneself in a contentious topic (again, especially GS or the hellholes).
• Instances of harassment where the harasser contacted their target offline (such as with Jytdog).
• all-CTOPs% speedrun attempts (Riposte97 as an example)
• Open support for paedophilia and similar.
• Open support for hate groups and hateful ideologies.
• Arbitration sitebans that are explicitly indefinite in length or are conditional (such as in BC3).

—Jéské Couriano v^_^v ^{Object Class: Drygioni} 01:40, 2 July 2026 (UTC)

Does a block with a finite, but completely unreasonable expiration period (e.g. 1000 years) count as indefinite? If yes, then does a block with 20 years expiration period count? Or 10 years? There are cases of people returning to editing after being blocked for more than 20 years. Currently most admins jump from 3 months to indef (if 3 months wasn't enough), does that make any block longer than 3 months unreasonable? In short, that would be a lot of bureaucracy for no good reason. sapphaline (talk) 22:59, 29 June 2026 (UTC)

a lot of bureaucracy for no good reason for this reason I think block durations should remain subject to admin discretion, but I'd like to see a culture shift to tune that discretion towards editor retention. -- LWG ^{talk (VOPOV)} 23:21, 29 June 2026 (UTC)

Nice Sorites paradox. SuperPianoMan9167 (talk) 00:09, 30 June 2026 (UTC)

Well, that's what I touched on with the psychological effect of the matter. If you have the option to indef, then an indef doesn't necessarily seem disproportionate for, say, a vandalism-only account. But if your only options are time-limited blocks, will any admin really say it is worth 10 or 20 years? Chaotic Enby (in solidarity · talk · contribs) 07:50, 30 June 2026 (UTC)

I don't impose a lot of blocks (I tend to be slower to block than some admins), but 8 out of the 11 I have imposed in the last 6 months have been on TAs, and for a TA any block of 90 days or more is equivalent to permanent. The blocks on TAs included one of 24 hours for edit warring; the rest were indefinite for vandalism-only accounts, spam/advertising-only accounts, and a blocked user seeking proxy edits (2 different TAs). For the three named accounts I blocked, one was a soft block for a username violation, one indefinite for a spam/advertising-only account, and a 31-hour block for disruptive editing. Although 8 of the 11 blocks were indefinite, I have trouble seeing how those blocks would be too harsh and harmful to recruitment of new editors. Donald Albury 14:59, 30 June 2026 (UTC)

The problem is that, besides soft blocks, permanent blocks prevent editors from coming back to the project years later, having most probably changed. Should a user have to appeal a block from an old TA they don't even have access to, or a spam block from a company they don't even work at anymore, just to not be counted as a sockpuppet? These weren't great editors now, but we're blocking ourselves from having them as better editors down the line, without much of a reason. Chaotic Enby (in solidarity · talk · contribs) 15:20, 30 June 2026 (UTC)

"prevent editors from coming back to the project years later" - nothing prevents them from coming back years later. CU data is only retained for 3 months, and if there's no disruptive activity on the new account, no one's going to block them for disruptive activity on the old one. Wikipedia is not a bureaucracy and rules shouldn't be enforced for the sake of enforcement. sapphaline (talk) 15:27, 30 June 2026 (UTC)

Maybe not prevent, but at least dissuade. If your only path towards contributing requires breaking the rules and hoping they don't get enforced, you're much less likely to actually want to contribute (I know I wouldn't, for starters), and there's a problem with the rules to begin with. Chaotic Enby (in solidarity · talk · contribs) 15:31, 30 June 2026 (UTC)

Most one-off violators don't know anything about the rules, and sockpuppetry in 2020s' Internet is much less frowned upon than sockpuppetry in 1990s' (or even 2000s') Internet. LTAs, spambot operators, globally banned users, etc. are a whole other can of worms, though, and what I described obviously doesn't apply to them, because going this far into disruptive editing generally means that you're not compatible with the project's values and simply cannot edit constructively, even if you want to. sapphaline (talk) 15:40, 30 June 2026 (UTC)

I don't agree that sockpuppetry is less frowned upon now. With Wikipedia's current consensus-based decision-making traditions, the number of supporters for a viewpoint is used as a rough proxy for strength of support, for better or worse. Thus pretending to be multiple people or getting people otherwise uninvolved with Wikipedia to show up and support your viewpoint undermines Wikipedia's decision-making. isaacl (talk) 21:24, 3 July 2026 (UTC)

I think she means on the Internet in general, not on Wikipedia or enwiki. In solidarity, Aaron Liu (talk) 01:09, 4 July 2026 (UTC)

It's not clear to me that how other sites deal with undisclosed alternate accounts is a significant factor when a blocked user considers making a clean start. In any case, sites based on ongoing collaboration generally benefit from contributors having a persistent, known label to identify them. isaacl (talk) 01:46, 4 July 2026 (UTC)

If your only path towards contributing requires breaking the rules and hoping they don't get enforced, you're much less likely to actually want to contribute...I'm not sure how true this is, although the reality of evasion related behavior is obviously complicated and opaque. I've said all this before, but in the Arab-Israeli conflict topic area where a) people are strongly motivated to contribute based on personal beliefs (about the world and Wikipedia) and b) the likelihood of receiving an indefinite ban or block is elevated, choosing the rule-breaking path (over the standard offer path) is popular. It has many advantages. The rule-breaking accounts that employ evasion contribute a lot of content, they are often focused, dedicated, experienced, hard-working, and the community more often than not retains their content after the accounts are identified and blocked. So, from their perspective, as people subject to indefinite bans or blocks (that they often view as unjustified barriers to addressing what they see as content issues), rule-breaking via evasion is a rational choice with a better payoff combined with reduced risk (people who employ disposable accounts are unsanctionable in practice). For me, this is one of the arguments against the current harsh strategies for handling 'disruptive' editing. The application and effects are asymmetric. They split the community into sanctionable and unsanctionable classes which breaks the enforcement system. Sean.hoyland (talk) 06:02, 1 July 2026 (UTC)

@Sean.hoyland, surely WP:BANREVERT is the solution to this? Kowal2701 (talk, contribs) 08:34, 7 July 2026 (UTC)

@Kowal2701, I don't think so. Maybe it would be a solution of sorts if there were no human editors in the loop for BANREVERT decisions, if it was automatic and implemented by machines that don't care about the content being removed or the impact on articles. Sean.hoyland (talk) 13:55, 7 July 2026 (UTC)

The lifecycle of tokens in the PIA topic area and elsewhere added by accounts employing deception via sockpuppetry is something that interests me, but unfortunately, I don't have enough time to look at it properly. Nevertheless, it is interesting to look at aspects of how the community deals with content created by ban/block evading actors. See User:Sean.hoyland/authorshiptesting#10 for example. Back in April I was testing some (WP:G5 related) code that looks at authorship stats for articles created by socks (with additions from other accounts, socks and non-socks). I took a snapshot for a particular sock, and I've just taken another one to see what has changed. As you can see, most of the content has survived. I'm guessing that this is not unusual, sock created tokens have a decent chance of surviving, despite the existence of WP:BANREVERT. Sean.hoyland (talk) 15:38, 7 July 2026 (UTC)

yeah, sometimes doing LLM cleanup I come across socks who still have live creations (where they're the only signif. contributor) let alone edits. What'd be brilliant is if editors in a topic area banded together to cleanup after socks (regardless of ideological leaning), that'd increase collegiality and largely resolve it. But I doubt that's possible in PIA atm, and it doesn't help that socks are mostly on one 'side'. Regardless, expecting SPI admins to do the cleanup is wrong, that ought to change, their time is better spent analysing reports etc. Kowal2701 (talk, contribs) 15:56, 7 July 2026 (UTC)

I think for something like BANREVERT to work at scale, maybe there needs to be more willingness to go backwards, to degrade content, to reduce quality, to reduce completeness, to take a longer-term view that building articles is a long march, that some temporary setbacks to articles to enforce evasion related policy may be worth it in the long run. The community seems to treat existing content with perhaps more respect that it deserves given that it's all a work in progress. Sean.hoyland (talk) 13:37, 8 July 2026 (UTC)

I can't really follow this. Those who know how to organize it have something to look forward to and want to do their small part of forming a very secure system that looks at what's been getting attacked and guards it and not how we got there. They will decide that their one tiny little part is enough and when it is their tiny little part, they can do a very strong and powerful job of it. Once they've done their tiny little part, if the rest of us can't self organize how to work within that limitation of power, there's nothing more they can do for them. I skimmed this section. I took in bits and pieces of it. I only just arrived here and this section looked appealing to me due to the title. The plan might look something like the sand bubbler crab pattern in the video https://www.youtube.com/watch?v=NlPkoG50zeQ. More details can be found in my new user page. There was also a show called "The Middle" where the middle kid Sue was left behind, forgotten, invisible. Now that I'm struggling to get very much attention, I will use the fact that I used to be a good unicyclist who went to Darren Bedford's unicycling club. People pay attention to that and can see other things by first showing them how it is like that. I could maybe unicycle in bits and pieces now. Now that I'm older, I no longer have so much child like God of everything potential but do a really good job of making a lot of computations then really heavily reducing the end result then exploring more options in what it's been reduced to unlike young people and it feels normal now. I know longer like the big plan with the standardized testing system of Darren Bedford's unicycling club. Also, look how many times my old username appears in the page https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/IncidentArchive1220#h-Blackbombchu_is_WP:NOTHERE-20260416004900. ¬¬¬¬ Douglas Conquistador (talk) 14:20, 30 July 2026 (UTC) —  Confirmed sockpuppet of Blackbombchu.

If we have rules which we deliberately do not enforce because doing so would harm Wikipedia, we should modify those rules. If it's acceptable for an indef-blocked editor to return with a false moustache after n months then let's say so or, better still, block them for n months (instead of indefinitely) so they can edit openly with their known account. I'm sure we've lost a lot of good editors who made an out-of-character mistake. I'm thinking of one former colleague with a six-figure edit count who directed a single insult at a loudly litigious opponent and was instantly and permanently blocked, but I'm sure there are many other cases. Certes (talk) 09:56, 7 July 2026 (UTC)

A reference chart for block lengths would be nice. WP:BLOCKLENGTH is quite open ended. ARandomName123 (talk)^{Ping me!} 17:38, 2 July 2026 (UTC)

Copying my comment from the closed discussion below: I think this could be an opportunity to reform how bans are conducted on long term editors. For example, we could establish a "tenure" system where after an editor has demonstrated they are able to contribute to the encyclopedia (say, 1,000 edits and two years of consistent edits). For such accounts, instead of blocks with indefinite timelines, we could default to ones that end in a defined manner, like 3 months for a "first offense," followed by a one year "probation" where limits can be placed on an account. Punishment could escalate if infractions occur during the probation, or within a certain time/number of edits from the initial infraction. After a certain number of years, an account can return to "Good standing" automatically. All could be done without needing the offending editor to ask for permission. Indefinite blocks on the first offense could be reserved for vandals with few edits. The main issue for older editors is as they edit, they have positive/negative interactions. Over several years, it is increasingly likely that an editor will end up in a dispute. These stack up, and more established editors are more likely to have a few salty enemies watching ANI. One bad day ends with an editor being blocked after possibly decades of service. GeogSage ^{(⚔Chat?⚔)} 04:45, 4 July 2026 (UTC)

I don't like this. It thresholds all disruption of different severity into "offense" and treats long-term editors very differently from newbies. How long a block is show be determined on how preventative it would be, not whether the "blockable" has some 1000 edits and two years. I also vaguely remember "Probation" being something enwiki has tried before. In solidarity, Aaron Liu (talk) 20:58, 5 July 2026 (UTC)

I also vaguely remember "Probation" being something enwiki has tried before. "Article probation" evolved (via intermediate steps) into what is now WP:Contentious topics (CT). In terms of editors, things like "civility probation" were tried but broadly they didn't work (there is a lot of nuance missing in that though), other attempts evolved into things like topic bans, revert restrictions, partial blocks, etc. We also have suspended (topic) bans, usually as an unblock condition, where a single admin can (re)impose a (topic) ban/block if some condition is met/not met. Escalating blocks are already a thing as part of various editor restrictions/CT restrictions, etc. Thryduulf (talk) 21:10, 5 July 2026 (UTC)

Long-term editors should be treated differently from newbies. Newbies deserve some grace as they attempt to learn the system, long-term editors have demonstrated that they are capable of contributing. A long term editor should be able to point to their track record as evidence. Our current system is lazy, and banishes people far to quickly. GeogSage ^{(⚔Chat?⚔)} 21:16, 5 July 2026 (UTC)

How does this give newbies grace? All I see is enabling long-term editors to always shorten their blocks, no matter what it is for. In solidarity, Aaron Liu (talk) 02:46, 6 July 2026 (UTC)

If anything, the whole point of WP:BITE is that we shouldn't treat newbies as harshly as they're still learning the ropes. Giving long-term editors more leeway but not newbies goes against this.

Also, I'm doubtful of the narrative of ANI leading to pile-ons from everyone who got in a dispute with an editor. It is true that ANI discussions often tend to raise a pattern of behavior going back years, but, from experience, this is usually a pattern of sanctionable behavior, not individual disagreements or grudges. I haven't seen any case of an editor getting blocked just because their enemies were watching ANI, without any sanctionable behavior on their end.

If anything, being a long-term editor also means you'll have allies watching ANI and ready to defend you! Chaotic Enby (in solidarity · talk · contribs) 12:57, 6 July 2026 (UTC)

Comment: Newbies are already covered by BITE, as noted, although I think we're pretty quick to BITE and need to chill with them too. I'm saying that over a certain number of edits and time spent as an editor, the track record should be heavily considered. @Chaotic Enby, there is certainly a lot of editors who have allies defending them on ANI, however look at the bans of long term editors and from what I've seen, people will bring up slights from long before the main issue being discussed. Say every 1,000 edits a hypothetical editor isn't their best self and gets in a dispute where they are in the wrong on a talk page somewhere. Each one of these disputes can leave a bad impression with multiple editors in the discussion, so when something comes to ANI, there could be several people jumping in voting not on the issue at hand, but on the track record of edits that stood out to them over the years. If they mostly focus on building an encyclopedia and don't build many relationships many other individual editors, they are unlikely to have strong allies. WP:TIAC, but we should formalize safety nets for long time editors who are not part of one. GeogSage ^{(⚔Chat?⚔)} 03:45, 7 July 2026 (UTC)

There is a massive difference between being in the wrong in an argument (which happened to me many more times than I can remember) and actually showing behavior that isn't conducive to encyclopedia-building. The vast, vast majority of Wikipedia editors aren't trying to get anyone they disagreed with once banned.

I'll note that many of the points made at WP:TIAC, like Closed decision-making structures – like invite-only IRC channels and mailing lists – are used, are just not true anymore, and these structures are viewed as inappropriate canvassing nowadays (WP:DISCORD, for example, has strong rules against any kind of off-wiki decision-making). Chaotic Enby (in solidarity · talk · contribs) 13:03, 7 July 2026 (UTC)

Wikipedia policies are designed in a way that makes it really easy to make a small local majority, and silence minority opinions. Specifically WP:BLUDGEON and WP:TENDENTIOUS can be used to effectively tell an editor with a minority opinion to shut up. Pile-ons, baiting, and WP:SMEAR are a outgrowths of the status quo. Just threatening in a discussion to bring it to ANI can be enough to make someone leave, even if they did nothing wrong, as it isn't worth the trouble/risk. As for WP:TIAC, I don't think rules involving canvassing are really going to stop people, and even if they do for higher levels like admin discussions, the various Wikiprojects all have cliques that can coordinate to keep articles their way. GeogSage ^{(⚔Chat?⚔)} 05:53, 8 July 2026 (UTC)

Off the top of my head I can't think of any subset of indef blocked editors who I think we are too harsh on. Except maybe edit warrers, who are probably best dealt with by restricting their ability to edit the article they are edit warring on. Oh and inappropriate names I think would be better addressed with a compulsory name change so the next time they log in they are forced to choose a new name (yes this needs a software change). However I'm happy to see this tested, if someone designs a proper AB test for say vandals or spammers and we monitor a thousand vandals blocked indef v a thousand blocked for 12 months to see how many come back and cause trouble and how many turn over a new leaf. It shouldn't take many years to see which route is better for us. If we do this I'd also like to see a study on blocking after 3 warnings rather than 4. My hypothesis is that if we start blocking vandals indef after the third warning if the first three warnings were given by three different accounts, we will find ourselves dealing with vandals more efficiently without losing any vandals who take the warning and reform. ϢereSpielChequers 23:14, 23 July 2026 (UTC)

Regarding the last point, while the hypothesis certainly deserves testing, a foreseeable issue is that blocking after a strict number of warnings (whether 3 or 4) doesn't make a difference between deliberate vandals, editors failing to learn and repeating the same issues, and editors learning the ropes and making several unrelated mistakes. I don't think these three groups should be dealt with in the same way at all.

I do, however, really like the "three different accounts" provision, or at least making sure that the blocking admin isn't the only person who issued warnings to always have a second pair of eyes on any decision. Chaotic Enby (in solidarity · talk · contribs) 02:11, 24 July 2026 (UTC)

Streamlining ANI

It is no secret that ANI cases can often end up as a free-for-all, or devolve in long threaded discussions between the parties, without meaningful administrative discussion, and that providing some structure to the threads could help. Here, I don't have a specific answer (which is, after all, the purpose of the idea lab), but a lightweight hybrid between the current free-form discussions and the more structured ArbCom case filings could be interesting to consider. Something along the line of:

• List of parties
• Statement by [filing party]
• Statement by [accused party]
• Case discussion
• (Optional) Discussion on [proposed sanction]

In which the parties would be invited to provide clarification inside the case discussion when asked by uninvolved users, but to refrain from back-and-forth discussions with each other.

This also ties into the suggestions of an ANI wizard to help format filings, as well as the fact that the unfolding of ANI discussions can often be quite confusing for unfamiliar users. The latter point not only puts them at a structural disadvantage compared to a more explicit, easier to navigate case structure, it can also lead to a chilling effect. As these effects are notoriously hard to measure, data is sadly lacking, but I believe they should nonetheless be taken into consideration.

Meanwhile, I don't think that putting structure on cases would complicate filings. New users shouldn't be blamed for not getting everything right, of course! And that is even without considering the wizard, which I might just code if we land on a consensus on this matter (even if it is the status quo). Plus, a "raw" filing can quite easily be structured by whichever admin processes the case first, allowing everyone down the line to save some reading time.

Again, this is just one example of how a discussion could be structured, and we could intentionally leave some flexibility! Chaotic Enby (in solidarity · talk · contribs) 09:35, 29 June 2026 (UTC)

Given how often an ANI case winds up bringing in additional editors than the original filing, and how often different aspects that are uncovered might entail different remedies (especially with early comment on remedy not knowing about later posted comments), I oppose this structure. I do think it would be helpful if the original poster included userlinks/articlelinks. But the given structure suggests the relationships and scope are known at the instant of filing an unchanging or that the original comments know about later-added/changed details to them. Neither of those are valid assumptions in ANI. The nature of ongoing evidence, discussion, remedy-proposal, and remedy-!vote is the nature of ANI, and while it could be made less messy, it's nowhere near the staid, phases/rules-of-order ArbCom. DMacks (talk) 18:42, 29 June 2026 (UTC)

Once more, I'm not saying this is a rigid structure, but broad strokes on how the conversation can be organized. Sections can be added if more remedies are suggested, if more parties are brought into the case, but this is more of an attempt to structure the discussion. Probably, the proposed remedies won't be known from the start, and different editors might open sections to discuss different remedies.

My point is that encouraging editors to set them up clearly is superior to confused discussions where users might !vote "support" or "oppose" without even making clear what they're voting for. Chaotic Enby (in solidarity · talk · contribs) 19:12, 29 June 2026 (UTC)

I can certainly see the benefit to requiring sections to be opened with a clear statement of the dispute and of who is accusing who of what, and a clear section for the accused parties to respond so it's immediately clear whether they have or have not done so and if they have what that response is. Thryduulf (talk) 20:24, 29 June 2026 (UTC)

I did not "oppose" the idea. In fact, I said I support some of its goals and even perhaps specific aspects. But I did not agree with this way of organizing it, regardless of the specifics, and instead mentioned certain specifics that could be implemented regardless of if/whether the whole thing is structured. And I helped distinguish how I see the natures of two different WP: pages that various editors might generally be considering as analogous, which could help workshop a method here that does not necessary match what happens there. DMacks (talk) 17:48, 30 June 2026 (UTC)

ANI would also benefit from non-admin "clerk/advocates" who engage with parties and facilitate the process. I often see ANI cases end in sanctions that have more to do with combative doubling-down of parties during the ANI discussion than by the actual original issue. -- LWG ^{talk (VOPOV)} 20:48, 29 June 2026 (UTC)

You're not wrong, but this would be difficult. Something like this, WP:AMA, was tried a long time ago, and in practice people who self-selected into the role seemed to view it as an opportunity to play Perry Mason. I think, in part because of the "face" issue you mention below, inexperienced users are often unwilling to take advice even from friendly third-parties, because their position is based on a fundamental misunderstanding of community practices and they don't want to concede it. Choess (talk) 15:26, 1 July 2026 (UTC)

Another thought that touches on both ANI and block policy (and might deserve a full discussion thread of it's own): an observation that I and others have made in the past is that Wikipedia's culture and processes do not function well when applied to people from shame cultures, where the concept of face is very important. People from these cultures often respond to scrutiny of their behavior in ways that Anglo-Dutch-German people view as dishonest, and are likely to quit the project entirely rather than face the shame of ANI or an unblock request. More thought is needed on how we might modify our processes or at least how we might provide better guidance for people from shame cultures navigating Wiki culture, and how we might provide better guidance for our Anglo-Dutch-German editors for interacting in a way that leads to more constructive outcomes in these cases. -- LWG ^{talk (VOPOV)} 23:38, 29 June 2026 (UTC)

Yes, ANI especially specialises in public humiliation, not great considering we’re all volunteers Kowal2701 (talk, contribs) 08:54, 30 June 2026 (UTC)

Good point indeed. Maybe putting the emphasis more on "coming forward to discuss/solve the issue" can be the way? Encouraging editors to not necessarily propose sanctions as remedies, but alternatives like, say, moderated discussions, voluntary mentoring, etc. In general, a remedy on which parties voluntarily agree is superior to one that has to be forced on them by the community. Chaotic Enby (in solidarity · talk · contribs) 08:58, 30 June 2026 (UTC)

LWG I'm not sure I follow this argument, as my understanding is that we as Wikipedia actually operate more on a shame basis than on a guilt basis: our means of social control are based on enforced ostracism, performative humility and calling people to account before the community, rather than individual moral responsibility or guilt resolved through punishment. _signed, Rosguill ^talk 14:10, 1 July 2026 (UTC)

Yeah by the time folks end up at ANI, its usually because they know they are right and everyone else is wrong. Not much guilt to work with there when dealing with such absolute beliefs. User:Bluethricecreamman (Talk·Contribs) 16:42, 1 July 2026 (UTC)

Oppose; arbcom cases are virtually impossible to make any sense of because of this structure and the 100 unrelated piecemeal "cases" by various people on 5 separate pages, compared to, you know, a discussion Gnomingstuff (talk) 16:57, 30 June 2026 (UTC)

I think I agree both ANI and AE turn into indecipherable pile ons easily, especially with ideological/contentious topic areas User:Bluethricecreamman (Talk·Contribs) 17:26, 30 June 2026 (UTC)

Why are we allowing votes on this "Idea lab" page, which is intended to incubate and then develop ideas? George Ho (talk) 17:38, 30 June 2026 (UTC)

Gnomingstuff's comment isn't a simple '''Support''' ~~~~ or '''Oppose''' ~~~~. sapphaline (talk) 17:42, 30 June 2026 (UTC)

I doubt anyone is gonna count the votes anyways, so who cares? Its just gaging suport. User:Bluethricecreamman (Talk·Contribs) 17:54, 30 June 2026 (UTC)

I dunno, I have a bad habit of lurking AE and ANI, and in my opinion the former functions much better than the latter.

I think a structure where the involved parties can only comment in their own sections while everyone else can do a normal discussion would be worth trying. InfernoHues (talk) 17:47, 30 June 2026 (UTC)

I wonder if the reason AE functions better than ANI isn't the structure, but who is allowed to directly participate in the consensus building process at each function. ANI allows for anyone to participate (excluding other circumstances), while AE restricts it to administrators. 45dogs (they/them) (talk page) (contributions) 20:21, 30 June 2026 (UTC)

The AE participation restriction helps as well. SuperPianoMan9167 (talk) 20:26, 30 June 2026 (UTC)

Looking at that may also be a good idea. I've complied a list of what I believe is every thread that has used the restriction, though its possible I missed something. 45dogs (they/them) (talk page) (contributions) 20:54, 30 June 2026 (UTC)

To date, the community has chosen to keep the responsibility for handling behavioural disputes, with the exception of when it has delegated authority to the arbitration committee for situations it hasn't been able to manage. Although it's possible consensus has shifted, my personal guess is that there's still a consensus to try to deal with behavioural issues first through community discussion, rather than delegating to admins. We can see what people think. isaacl (talk) 03:06, 1 July 2026 (UTC)

I think this is relatively true, but I'm unsure of how strong consensus is here considering the consensus around letting community CTOPs be actioned at AE. Though it could be a CTOP vs standard behavioral issue. But mainly I don't think comparing AE to ANI is too fair of a comparison, at least without considering that the productivity of AE is due to consensus being admin-only. The most direct comparison between the proposed idea is looking at RfC closure reviews using {{RfC closure review}}, and comparing productivity (though this isn't a perfect comparison). 45dogs (they/them) (talk page) (contributions) 09:22, 1 July 2026 (UTC)

I feel there are significant voices who think that the community and the arbitration committee should be wary of designating too many contentious topic areas, in part due to concerns about retaining such decisions within the general community. I have, however, long discussed that English Wikipedia's consensus-based decision-making traditions do not scale upwards well, beyond a fairly small number of people. I've been more concerned about content-dispute resolution, which I think could forestall behavioural problems if made more effective, but it's possible the community might move towards this same conclusion first for behavioural dispute resolution. isaacl (talk) 12:58, 1 July 2026 (UTC)

I broadly agreed with DMacks and Gnomingstuff. I think the idea of streamlining ANI is attractive but I struggle to see how it would work in practice. The nature and purpose of ANI doesn't lend itself to the structures of ArbCom—which is not to say there can be no improvements. I think perhaps some of ANI's greatest strengths are also its greatest weaknesses. When it works, allowing just about anybody to surface evidence, opinions, additional parties, and extended issues clarifies the problem and produces appropriate remedies that often are not evident at the time of the initial filing. I confess don't have extensive ANI experience, and much less with ArbCom, but it strikes me that ArbCom's structure is in part facilitated by the messiness of ANI. Complex ANI discussions give rise to more focused ArbCom questions and identified parties. —Myceteae‍🍄‍🟫 (talk) 23:30, 1 July 2026 (UTC)

Sorry for not making it clear, but the suggestion was that this structure would be dynamic, i.e. people could later be added as parties, suggest new remedies, etc. Something like the ANI wizard would provide the core structure, but it would evolve down the line as more evidence surfaces. I'll try to make a more intuitive and accessible demonstration of what I have in mind. Chaotic Enby (in solidarity · talk · contribs) 15:37, 2 July 2026 (UTC)

Is an "ANI wizard" really that good of an idea? It seems to me it would encourage people to file more ANI reports over lesser matters, which doesn't seem productive. ANI being intimidating probably prevents some disputes from escalating unnecessarily. 45dogs (they/them) (talk page) (contributions) 15:59, 2 July 2026 (UTC)

I think ANI being intimidating probably stops newer editors from reporting actionable conduct. InfernoHues (talk) 16:07, 2 July 2026 (UTC)

Yeah, ANI being more intimidating doesn't necessarily filter for more important issues, but rather for other unwanted criteria, such as: Is the person familiar enough with the workings of the noticeboard? Do they have enough social capital? Are they on good terms with ANI regulars?

And, unsurprisingly, this can very easily create a self-selected two-tiered system. Chaotic Enby (in solidarity · talk · contribs) 18:10, 2 July 2026 (UTC)

Yeah, I think it's intimidating enough and the goal should not be to increase that. More structure could help or hinder. I don't have a clear concept of how an "ANI wizard" would operate but if it allows for relatively low-barrier reporting and then adds structure then perhaps it could be helpful. I have participated in an ANI that had some elements of this. It was a bit of a mess and not something I would hold up as an example but the ad-hoc "clerking" by admins who were previously uninvolved with the underlying issue was helpful in facilitating and structuring the discussion. I remain open to the concept but have trouble picturing it. —Myceteae‍🍄‍🟫 (talk) 19:21, 2 July 2026 (UTC)

Guess I'll have to make a prototype then! Chaotic Enby (in solidarity · talk · contribs) 20:51, 2 July 2026 (UTC)

The biggest, most obvious, cruelest, and most unnecessary type of stupidity that happens at ANI is that the filee is required to maintain a stiff upper lip, not only with respect to the statements of the initial filer, but also with respect to the dozen or so random unrelated editors we permit to drop in during the proceedings and needle them about minor issues, or make expansive claims about some past incident, or just straightforwardly antagonize them.

There may be a benefit to people participating in threads, but there is not really a reason why people need to throw rotten fruit at the accused.

The most obvious solution to this — please, for the love of God, prior to the responses that this is dumb, please understand that I am not proposing this, but saying that it is a thing which would make it stop, there may be others which work better — is to authorize some sort of higher threshold for conduct in noticeboard bystander comments, such as exist for AE and ARBCOM, wherein there is a generally understood expectation that rolling by to make snide barbs will result in a very bad time for anybody who does it, and as a consequence people there do it far less. jp×g🗯️ 02:29, 2 July 2026 (UTC)

ANI is not a great forum, but I've yet to see a good idea on how to reform it. Making it overly bureaucratic isn't the way to go, new editors who may now little about how to edit aren't helped by struggling to find there way through understanding where there comments should go. -- LCU ActivelyDisinterested «@» °∆t° 11:33, 2 July 2026 (UTC)

I don't think this is overly bureaucratic: the structure itself could easily be built with the ANI wizard, and having a clear "discussion" section is better than the jumble of threads we currently have. Chaotic Enby (in solidarity · talk · contribs) 15:35, 2 July 2026 (UTC)

My thinking is a sort of hybrid of rigid and flexible. Start with a formal statement of the issue, a list of parties involved, and a space for an initial response by each of those parties, followed by a free-form discussion section that functions similarly to now. Adding another editor as a party would I think work best by someone saying "I think X should be added as a party here because..." and then if at least one uninvolved editor agrees, that uninvolved editor adds them to the list of involved parties and copies the statement explaining why they should be a party and creates a space for a single initial response by the new party. Thryduulf (talk) 16:00, 2 July 2026 (UTC)

Making it overly bureaucratic isn't the way to go
Why not? Governments run on bureaucracies. FaviFake (talk) 22:44, 31 July 2026 (UTC)

One of the advantages of ANI is that it is lightweight and adaptable to many different kinds of cases. As I noted on JimboTalk recently: ANI is really good for dealing with obvious trolls, and medium difficulty behavioral challenges. But it's a known issue that ANI struggles to deal with unblockables and complex matters. That's one reason ArbCom retains relevance. In the other direction, it is easy for discussions at ANI to become a pile-on/trainwreck/hot mess. So the question is: how can we preserve ANI's agility for lighter cases, but give structure to the beefier ones? I think the answer may be a sort of ANI+ or ArbCom Lite. I.e., once a discussion reaches a certain length, an administrator (and it has to be an admin, lest we have overzealous clerking) can graduate/escalate the matter to ANI+ (or AE perhaps?) where more formal structural rules kick in. CaptainEek ^{Edits Ho Cap'n!}⚓ 08:38, 13 July 2026 (UTC)

A thought: the pile-on factor could be mitigated if admins were more decisive about sanctioning and closing discussions, which they would be more free to do if sanctions were seen as less permanent and more reversible. Which leads to another thought: what if we changed the name of "blocked" to something that better reflects their non-punitive nature like "restricted from mainspace" "restricted from talk pages" "restricted from user pages" etc? Or even introduced levels of blocking - a lot of problem users would be mitigated pretty well by being restricted to say, 1 mainspace and 1 talk space edit per day until their behavior improves. -- LWG ^{talk (VOPOV)} 14:04, 13 July 2026 (UTC)

Having a separate page might lead to the impression of a two-tiered justice system, but getting admins to enforce structured discussion once a certain threshold is reached (or even inviting editors to do it themselves when starting discussions they expect to become sprawling) could absolutely be worth it. Chaotic Enby (in solidarity · talk · contribs) 15:01, 13 July 2026 (UTC)

I think that could work too, fellow CE. CaptainEek ^{Edits Ho Cap'n!}⚓ 17:52, 13 July 2026 (UTC)

Now we just need to get @The C of E on board! Chaotic Enby (in solidarity · talk · contribs) 18:03, 13 July 2026 (UTC)

What's this? @Chaotic Enby: I don't know anything about this discussion. The C of E God Save the King! (talk) 18:16, 13 July 2026 (UTC)

Sorry, I was just following @CaptainEek's joke by finding someone else with our initials! Chaotic Enby (in solidarity · talk · contribs) 18:20, 13 July 2026 (UTC)

One idea I had to try to avoid discussions escalating rapidly is having a round-robin discussion phase. Each editor can make one comment per round, and a moderator decides when each round ends and when it is time to end the round-robin phase. I think this would allow time for more voices to heard in each round, and help prevent a few commenters from swamping discussion. However, it would be require active management by a moderator. isaacl (talk) 16:31, 13 July 2026 (UTC)

A thought: I think ANI could be made a lot better for very little extra effort if there was a split between the place where the parties discuss the case and the place where everyone else does. We already do this at close reviews with an involved/uninvolved split, and every RFC is already split into a survey/discussion section, so a simple two-way split should be easy to accomplish. Loki (talk) 16:21, 13 July 2026 (UTC)

That could be great, although the only worry I'm having is that it might be hard to avoid a back-and-forth between the parties... Maybe put limits on replies there? Chaotic Enby (in solidarity · talk · contribs) 16:24, 13 July 2026 (UTC)

I don't really like the idea of more structure than this at ANI, at least not as a regular thing. The point of splitting it is not really to avoid a back-and-forth between the parties, it's to avoid a pile-on and to make the most relevant information (what the parties are saying) clearer. Loki (talk) 16:33, 13 July 2026 (UTC)

Who gets to decide how the work is done

Although this situation initially brought this to mind, it's not limited to just Sanger. The purpose of editing is to create and maintain an encyclopedia, and that work takes many forms. We're all volunteers here, and we collectively decide how that's done. We entrust some editors with additional rights, but even those rights never include any special privilege in deciding policy or guidance. Anyone who edits is part of the community, and should have a say in how the work is done. But what of people who don't do the work, should they have a say in how the work is done? As I said this goes beyond Sanger, it's applicable to anyone trying to decide how we as volunteers should do the work, when they don't take part in it. I have no issue with people from different groups helping with the work and bringing different perspectives, it's something I've encouraged even if I may disagree with their perspective. But it doesn't seem right that people who don't do the work get to try and tell the people who do the work how the work should be done. This doesn't mean ignoring external perspectives on the state on Wikipedia, but that internal processes should be something reserved for the volunteers creating or maintaining the encyclopedia. -- LCU ActivelyDisinterested «@» °∆t° 11:55, 2 July 2026 (UTC)

There's a tricky balance to maintain. If, for example, opinions were weighted by some metric measuring contributions, it would provide incentive for editors to become expansive in what is included in Wikipedia (which includes a significant category of paid editors), since more contributions means more influence to shift towards loosening standards of inclusion. A relatively low threshold for some contribution metric, without weighting, would help avoid this incentive, and would guard against new editors showing up and swamping a discussion to influence its outcome. It might not have much effect otherwise, though. Although personally I think it's a good idea for editors to gain experience with Wikipedia and gradually accumulate experience and respect, I also appreciate that there have been significant situations where long-time editors have fallen out of step with evolving community norms, and so generally the community has been reluctant to codify any specific deference mechanism. isaacl (talk) 16:46, 2 July 2026 (UTC)

I wouldn't suggest some kind of weighted metric or codified mechanism, more just an understanding that you need to take part in creation or maintenance of the encyclopedia to be part of discussions about how that should be done. -- LCU ActivelyDisinterested «@» °∆t° 12:51, 3 July 2026 (UTC)

I think there are many editors who have this understanding... but also a significant number who feel empowered to weigh in on topics in which they have not previously participated. This can be good to bring cross-fertilization of ideas, or to provide a broader view. It can also be ineffective, such as when the same proposal is made for the N-th time. Also sometimes editors, in good faith, think they're going to participate and so are eager to make many new suggestions, but end up not participating. It's tricky to encourage new editors to join in, while also tempering expectations that just because they said "let's do X!", people volunteering to do X may not appear. isaacl (talk) 16:37, 3 July 2026 (UTC)

I think the biggest argument in favor of hearing from non-contributors is that Wikipedia is an institution, and the vast majority of the people who interact with it are non-contributors. If we assume that our output is of infinite utility and will always outweight the discontents of outsiders, we will probably caught by surprise when outsiders withdraw support or turn to alternatives that are useful enough; it has happened to other institutions.

That said, I think it's hard to make detailed proposals for reform without having made some attempt to engage in the current process. I get the impression that Larry's theses, like a lot of external criticism, were based largely on the second-hand narratives of the disaffected filtered through a lot of armchair philosophy and so wind up going in impractical directions. Frankly, I think the same problem occurs with some of our internal discussions: editors who have minimal experience with, or interest in, actually delivering knowledge to our readers deciding that their contribution to the encyclopedia will be middle-managing those who do. Or to put it in a kinder way, when I feel like I'm spending too much time yapping about "how things should be", I try to go back and work on something reader-facing for a while, to ground me. I think that's good advice for just about everyone. Choess (talk) 20:17, 3 July 2026 (UTC)

I think the key thing to remember is that discussions about how things are done should always consider all of the following:

• What readers want
• What editors want
• Why things are currently done the way they are
• What can and cannot be done (in practical terms)

It's difficult if not impossible for any one person to know all of the above, particularly it's hard for someone who is an editor to know what readers who are not editors want and very difficult for someone who isn't an editor to know what editors want. It's sometimes tricky for those who are not programmers/template editors/similarly technical to know what changes are or are not practical, and sometimes nobody knows why things are currently done the way they are. It is also easy to fall into a trap of assuming that as someone who does know one of these things that this is common knowledge and/or that those who don't know that thing shouldn't have a seat at the table. Thryduulf (talk) 21:30, 3 July 2026 (UTC)

This is, in part, why I added "and that work takes many forms". Wikipedia is a varied community of people with differing abilities and ideas. And a community that should be open to new ideas from external sources. My point was that external sources shouldn't get to ultimately decide if those ideas are taken onboard, or how the work is done. -- LCU ActivelyDisinterested «@» °∆t° 10:24, 5 July 2026 (UTC)

Any all-volunteer project can't sustain too much meddling by outsiders (or insiders), because as onerous rules accumulate, people eventually just decide to find something more fun to do with their spare time. With that said, our consensus process as it is doesn't weigh every voice equally, even if we are institutionally equal, because the more respect and goodwill you command in the community, the more likely it is that others will be persuaded by your words and join in doing and advocating for similar actions. I don't know about other people, but one of the factors that affects how seriously I take someone is what percentage of their edits are to mainspace. -- LWG ^{talk (VOPOV)} 02:14, 5 July 2026 (UTC)

Rename all userbox categories

The subcategories of Category:Userboxes have been organized by topic of the user templates for a long time. The subcategories are mostly called "Foobar user templates" for topic "foobar", with occasional variations like "Foobar-related user templates". These categories are not called "Foobar userboxes" because sometimes they contain topical user namespace templates, which aren't userboxes. Examples: Template:WikiProject Animals topicon (part of Category:WikiProject user templates), Template:The Malta Barnstar (part of Category:Malta user templates).

Corresponding to the practice of mixing userboxes with non-userbox templates, the category header template {{Template category}} treats parameters |type=user and |type=userbox as synonyms (since Special:Diff/1039882654), outputting text The pages listed in this category are meant to be user templates, including userboxes.

This makes Category:Userboxes to be very confusing in itself. It is called "Userboxes", but almost none of the subcategories in its tree have the word "userboxes" in the name (this search shows 17 examples). Category:Userboxes contains userboxes, but also a random assortment of user namespace templates not related to the template {{Userbox}}.

I propose a plan for a big renaming of the subcategories of Category:Userboxes:

1. Through one giant CfD nomination, rename all template categories with |type=user or |type=userbox from "Foobar user templates" to "Foobar userboxes" or equivalent, depending on the naming scheme.
   • This will inevitably cause miscategorization for topical templates which aren't userboxes. We'll live with it for a bit until the new category structure is established.
   • One good example of a local naming scheme are subcategories of Language user templates, which are named "User templates ISO language code".
2. Update template {{Template category}} to support two separate values |type=userbox and |type=user. The wording will be something like:
   • |type=userboxes: The pages listed in this category are meant to be userboxes
   • |type=user: The pages listed in this category are meant to be user templates, including award templates, top icons, userboxes etc.
3. Replace |type=user with |type=userbox in the renamed categories.
4. After the renaming, create a new structure under Category:User namespace templates. That way, all non-userbox templates can be grouped together with similarly themed userbox templates. This new structure doesn't need to be deep at the start of the process. Just the standard 10 topical categories (same as in Category:Wikipedia templates by topic) + Category:Wikipedia-related user templates would be enough for the purposes of this plan.
5. Move miscategorized non-userbox templates from userbox-specific categories into the new category tree. At this step, the miscategorized templates can be found using WP:QUARRY requests and using WhatLinksHere, like Special:WhatLinksHere/Template:Top icon.

A rough draft of the proposed structure of the category tree using award templates, barnstars, and userboxes as examples:

• User namespace templates
  • User namespace templates by topic
    • Arts and culture user templates (new after renaming)
      • Arts and culture userboxes (renamed)
      • Wikipedia arts and culture award templates
        • Arts and culture barnstar templates
    • ...
    • Science and nature user templates (new after renaming, also will be under Science and nature templates by task)
      • Wikipedia science and nature award templates
      • Science and nature userboxes (renamed)
      • The aforementioned Template:WikiProject Animals topicon will probably end up here as an nature-related top icon template.
    • Wikipedia-related user templates (new after renaming)
      • Wikipedia-related userboxes (renamed)
      • WikiProject user templates (new after renaming)
        • WikiProject userboxes (new after renaming)
        • The aforementioned Template:WikiProject Animals topicon will also fit here, as a WikiProject-related top icon template.
  • Wikipedia award templates
    • Wikipedia barnstar templates
    • Wikipedia arts and culture award templates
    • ...
  • Userboxes
    • Arts and culture userboxes (renamed)
    • ...
    • Science and nature userboxes (renamed from current Science user templates, the "topic" part of which is inconsistent with the rest of Science and nature templates by task)
    • Wikipedia-related userboxes (renamed)

Do you have any suggestions regarding this plan? Do you think it is a good idea overall? What are the possible alternatives beside the status quo?

If there is a general consensus that this is a good idea, I plan to start a bigger discussion after workshopping it for a bit. The plan is to mark all the relevant categories into one giant CfD nomination using semi-automatic tools (wAwB, maybe with some help from WP:AWBREQ). If CfD regulars know a better way of doing such a nomination, please let me know. —⁠andrybak (talk) 15:24, 26 July 2026 (UTC)

Why not rename Category:Userboxes to Category:User templates and be done? It appears that 20 years ago, that was the name of this category. I don't have the detective skills to figure out why or when the current name came to be used. – Jonesey95 (talk) 00:26, 28 July 2026 (UTC)

If I understood your suggestion correctly, this would mix userboxes with all other kinds of User namespace templates, like top icon templates, block-related templates, award templates – all very disparate, unrelated to each other templates. Such a CfD nomination won't succeed.

As an example, a couple of years ago I suggested merging barnstart templates with user award templates – two closely related kinds of templates, one is a subset of the other – and it was rejected: Wikipedia:Categories for discussion/Log/2020 May 22#Subcategories of Wikipedia barnstar templates. —⁠andrybak (talk) 00:36, 28 July 2026 (UTC)

They are already mixed; nearly every subcategory of Category:Userboxes is called "XX user templates". My suggestion would just fix the parent category name. You said in your original post: The subcategories are mostly called "Foobar user templates". Hence my suggestion for renaming the parent category. It appears that 20 years ago, that was the name of this category. See also (historical pages): Wikipedia:Simple userbox solution; Wikipedia:Help_desk/Archives/2007_July_22#Userboxes (they were still in Cat:User templates in July 2007); Wikipedia:Administrators'_noticeboard/IncidentArchive351#User:Babelious_keeps_editing_my_user_page (Jan 2008). Here's a 2008 CFD that may have resulted in the current mixed-up situation. And here's a 2020 RFPP request from an editor who was later blocked at ANI for all sorts of disruptive editing; that editor created the current redirect. – Jonesey95 (talk) 00:44, 28 July 2026 (UTC)

Sorry, I missed the intervening edit before posting my reply above. I guess in these twenty years, the weird naming scheme of the subcategories of Category:Userboxes weren't scrutinized enough. The increasing amount of kinds of user templates somehow didn't affect this naming scheme.

They are already mixed – at least right now the topical user templates are separated from the rest of User namespace templates, and we don't have a category Category:User templates by topic or Category:User namespace templates by topic. But not every subcategory of Category:Userboxes is based on a topic, like Utility user templates. What I'm trying to say is that the status quo seems like a better situation than dumping all existing userbox categories into Category:User templates/Category:User namespace templates.

The userboxes are an overwhelming majority of the user namespace templates. Splitting the userboxes from the rest will be similar to how Navigational boxes are split from the rest of templates (mostly in the realm of topical templates). —⁠andrybak (talk) 00:56, 28 July 2026 (UTC)

Rename to Category:Userboxes, etc. because that is the standard term which distinguishes it from other user templates. –LaundryPizza03 (dc̄) 01:00, 29 July 2026 (UTC)

Support – Per nom, explained pretty well and would make it consistent. FaviFake (talk) 22:33, 31 July 2026 (UTC)

Support Category:Userboxes and its sub categories should only be for userboxes, and not for other templates. In the past I removed many that were not userboxes, but I was not able to remove the ones that were protected. I asked for them to be moved to another category and my request by an administrator was denied. Catfurball (talk) 17:12, 3 August 2026 (UTC)

FYI, I've asked for some advice regarding CfD process at Wikipedia talk:Categories for discussion § Any best practices for giant CfD nominations, with 2700+ proposed renamings? —⁠andrybak (talk) 20:23, 7 August 2026 (UTC)

A page for emotional support for experienced editors

I firmly believe that Wikipedia needs a concrete space where experienced editors who feel quitting, taking a Wiki Break, or just really upset need a space where they can talk to other editors to guide them through tough times when editing Wikipedia. CostalCal (talk) 19:57, 28 July 2026 (UTC)

I smiled at that because there was an article today on BBC about attachment theory. I guess you want "detachment theory". I am no expert on those things, but let us make sure both parties in the counseling do not end up leaving. But it would be interesting to do a survey of "why are you frustrated" reasons among users before you start. The sad part is something I read somewhere long ago: Wikipedia is a fight club, but do not say that to newcomers. Sigh. Yesterday, all my dreams... (talk) 21:00, 28 July 2026 (UTC)

Wikipedia shouldn't be known for a fight of flight culture. CostalCal (talk) 23:01, 28 July 2026 (UTC)

I agree, it should not. That was not my saying, but something I read. So some people feel that way. And theoretically there should be no need for ANI. Anyway how about Wikipedia:WikiProject_Editor_Retention for this. It is not very active but maybe you can jumpstart it. I will leave it in your hands now. Yesterday, all my dreams... (talk) 00:08, 29 July 2026 (UTC)

Got it. CostalCal (talk) 02:06, 29 July 2026 (UTC)

Good luck. But please give the counseling users some type of procedure to follow rather than random advice. I know nothing about Grief counseling except that it exists. It may help you figure out what to do, because you are ineffect dealing with Wiki-grief. I will say no more. Have a good day. Yesterday, all my dreams... (talk) 02:15, 29 July 2026 (UTC)

Trust me, we find out soon enough if we hang around for long. ChompyTheGogoat (talk) 18:55, 29 July 2026 (UTC)

I wonder about WP:Discord. In solidarity, Aaron Liu (talk) 14:23, 29 July 2026 (UTC)

This does seem aligned with Wikipedia:WikiProject Editor Retention, as has been suggested. I'm not on Wikipedia:Discord, but I can see the appeal of some place off-wiki that is closely associated with the project. I imagine various pros and cons to having all of these conversations on-wiki. I think there is something to this, just not sure what is should look like. —Myceteae‍🍄‍🟫 (talk) 19:32, 29 July 2026 (UTC)

The editor retention wikiproject was not set up to provide emotional support to editors or to discuss specific situations, but as a place for editors to discuss ideas regarding editor retention. isaacl (talk) 22:09, 29 July 2026 (UTC)

I wasn't suggesting using the editor retention project for emotional support, though I see now that I was unclear. Rather, I was suggesting folks there might be interested in or might already have ideas about this. I think it also makes sense to discuss here, and is more visible. I'll place a notice of this discussion on that project's talk page. —Myceteae‍🍄‍🟫 (talk) 22:57, 29 July 2026 (UTC)

How about this, I feel as if this is the best concept.

The name can be something like Wikipedia:Editor Support Circle

A peer space for editors going through a hard stretch (burnout, a permission loss, conflict, or just feeling discouraged) to talk it through with others who've been there.

Post under a new section with your username, saying how you're feeling and roughly what happened.

Example: "I lost my NPP flag after months of warnings. I know I moved too fast, but it still really hurts, and I don't know if I want to keep going."

Volunteers who've opted into the project reply. At first acknowledging the feeling, then (if the person wants it) help build a realistic game plan together.

A reply example reply: "That sounds rough, losing something you worked hard for. A lot of us have been through a version of this. Want to talk through what getting back on track might look like, when you're ready?"

The main goal for this is to give editors a space with no admin escalation, no policy citations unless asked for. This isn't a noticeboard.

Any user who meets Semi-protection (10 edits and 4 days) can post on here. CostalCal (talk) 22:25, 29 July 2026 (UTC)

A key challenge I see is finding enough people to provide support in a productive manner, without taking sides. Perhaps you can run a trial for a period of time and evaluate how helpful it was. Personally, I don't think any restrictions are needed on who can seek support. isaacl (talk) 22:44, 29 July 2026 (UTC)

On a related note, I think new editors can be encouraged to talk to their assigned mentor about any challenges they are facing regarding participation. I do think expectations need to be set (both with a support venue and with mentorship): personal emotional issues that go beyond interactions on Wikipedia aren't within the scope of Wikipedia editors to handle. isaacl (talk) 22:48, 29 July 2026 (UTC)

I think hosting it off-Wiki would be better, so that people can post anonymously if they don't want to be linked to their account (without any fear of socking accusations). ChompyTheGogoat (talk) 22:50, 29 July 2026 (UTC)

That sounds rough, losing something you worked hard for. A lot of us have been through a version of this. Want to talk through what getting back on track might look like, when you're ready?

I can't speak for anyone else, but I would find this incredibly obnoxious. If I wanted to get canned therapy-style responses then I'd just pay an actual trained therapist. Gnomingstuff (talk) 15:02, 31 July 2026 (UTC)

That phrasing honestly sounds like AI chatbot therapy. ChompyTheGogoat (talk) 15:15, 31 July 2026 (UTC)

@CostalCal: I'm sorry you're having a tough time, and thank you for bringing this up. We really can't afford to lose good editors who make some mistakes and get burned. As noted, the editor retention wikiproject isn't a place for support, but mentors are there to help editors one-on-one, and I think in theory, everyone who's created an account in the past few years is assigned a mentor, even if they never need one. What you're describing is a bit beyond the kinds of help that mentors usually provide, so I think we'd need to hear from some active mentors and I'm going to mention this discussion at the new mentorship noticeboard.

I also think that having these discussions on-wiki is maybe not the best idea, as editor support of this nature could go into territory that you don't want preserved indefinitely in revision histories. Maybe after an initial post requesting support, this could be followed up off-wiki, though everyone has our own preferences regarding email, Discord, or other communication channel. —ClaudineChionh (she/her · talk · email) 23:24, 29 July 2026 (UTC)

I think we need to be cautious about private communication channels. As I alluded to, I think there is a risk of a volunteer being given information that they'd rather not be privy to, or for which they aren't willing to provide support. isaacl (talk) 00:12, 30 July 2026 (UTC)

It would be "use at your own discretion", of course, and a disclaimer would probably be a good idea - something describing that the intended purpose is to discuss matters related to Wikipedia and expecting people to more or less follow TP guidelines here, just with anonymity to keep their concerns separate from their account - not a free for all/substitute for therapy. I wouldn't recommend Gmail - I think Discord is probably the best option for limited fully anonymous support. No records or tracking. ChompyTheGogoat (talk) 07:15, 30 July 2026 (UTC)

I think that private communications have problems, but public communications are terrible, and on-wiki comments are subject to Anything you say can and will be used against you forever. WhatamIdoing (talk) 20:01, 31 July 2026 (UTC)

Indeed. I would not suggest that anyone do this kind of thing on-wiki. @ChompyTheGogoat, Discord does have records - anyone can join and search back through all the posts in public channels. There's no simple way to delete a direct message thread, either. But I do agree that it's much better than having that kind of discussion fully in public.

I would encourage editors to make offwiki wikifriends wherever they can - via in-person meetups, chat programs, email, whatever. People with strong social bonds are more likely to stick around. But I'd also advise anyone feeling burnt out to go rant about it to someone who isn't a Wikipedian. It's a different kind of therapeutic. Also, they're quite likely to tell you that whatever you're mad about is a dumb thing to be mad about, in the grand scheme of things, which can be a necessary reality check. In solidarity, asilvering (talk) 22:18, 31 July 2026 (UTC)

My mistake - I must have confused it with something that has vanishing messages.

I agree that it's important to have off-wiki friends to talk to as well, but I think there may be times that people want to talk about specifics that are too difficult to explain to anyone who isn't an editor. ChompyTheGogoat (talk) 00:03, 1 August 2026 (UTC)

@ClaudineChionh, @ChompyTheGogoat, and @Isaacl I hear your suggestions. I agree that posting anonymously on an off-wiki is a serious possibility. I want this to be how your behavior/thoughts affects your Wikipedia life, not a fix my entire life platform. User:ClaudineChionh, thank you for putting this on the Wikipedia:Mentorship noticeboard talk page. @User:Isaacl brings up a good point when saying that brining this to Discord or Gmail may hurt privacy and may hurt engagement with user. This project will probably need some time and attention to sort out. I proposed this less than 30 hours ago. CostalCal (talk) 00:37, 30 July 2026 (UTC)

I think we're asking for trouble with this. What we want is to encourage editors to detach their personal emotions from Wikipedia, providing this kind of support only does the exact opposite; it encourages people who have let onwiki business affect their real mental state to stay in the ecosystem instead of disconnecting.

The main thing that stressed editors need to hear is that if you're at a point where business on Wikipedia is causing you real mental distress, you are far too invested in Wikipedia, and you need to log off, touch some grass, pet a cat, hug somebody, go for a run; whatever. Leave for however long you need to leave until you can return with a level head. There is literally not a single thing on Wikipedia worth getting yourself in real-life stress over. Athanelar (talk) 13:02, 30 July 2026 (UTC)

I think that it's okay if experienced editors want to take a WikiBreak. I don't think they should feel obligated to talk it out first. Sometimes people want to step away, for a short time or a long time, and that's okay. SomeoneDreaming (talk) 14:38, 30 July 2026 (UTC)

I have now looked at what people have said and see 3 different barriers to this attempt:

• 1. Grief counseling can not be done in public. It must be private. But no mechanism for that has been suggested.

• 2. Finding enough counselors will be a challenge. And who said they know how to counsel?

• 3. Informing all experienced users that the project exists and convincing them to open up and use it may be difficult.

So unfortunately I do not have high hopes for the success of this project, unless a dramatic new suggestion is made. Yesterday, all my dreams... (talk) 15:26, 30 July 2026 (UTC)

This isn't intended to replace real therapy. Community support is important for mental health too - I think it should be peer to peer interaction, not something with self designated "counselors". I'd see this as an intermediate step, when people are just frustrated and need to get things off their chest. Knowing when to walk away is important too, but they're different solutions depending on the situation. Sometimes venting and feeling heard is all it takes for someone to move on from something. Getting outside input might help people recognize when a break IS called for too - I agree that "stay at all costs" wouldn't be a healthy mindset to base it on. ChompyTheGogoat (talk) 05:42, 31 July 2026 (UTC)

I agree. Yesterday, all my dreams... is the only editor in this thread to interpret this, or to refer to this as, "counseling" and specifically "grief counseling". There are plenty of valid concerns expressed and limitations identified throughout this thread, but I don't think it's helpful to put the entire idea under the "grief counseling" umbrella. Also, support or guidance might include recommendations to step away or limit participation, even if temporarily. —Myceteae‍🍄‍🟫 (talk) 20:33, 31 July 2026 (UTC)

@Yesterday, all my dreams..., @ChompyTheGogoat, and @SomeoneDreaming Wiki-break suggestions are mostly effective. I also agree, that telling people to stay without a doubt is sometimes not the best advice. Honestly, with how this has been going, I am starting to doubt if my plan will succeed. It looks to be too logistically challenging, and the off-wiki/on-wiki privacy concerns are valid. However, I am a firm believer in a change to Wikipedia's culture. We can't just expect everyone to know what they are doing 100% of the time. CostalCal (talk) 23:58, 31 July 2026 (UTC)

I agree that it is logistically challenging. May be you want to write an essay that helps people calm down. As for "changing Wiki culture" the word challenging would be too mild. But please do consider the essay route. Have a good day. Yesterday, all my dreams... (talk) 23:51, 1 August 2026 (UTC)

Thanks for the idea. CostalCal (talk) 02:48, 2 August 2026 (UTC)

But please let us accept that a single essay will not help everyone. So you must use 3 or 4 questions upfront that allows them to click and get 3 or 4 essays. So you have a brief top level page that leads to different types of advice. Good luck. Yesterday, all my dreams... (talk) 04:21, 2 August 2026 (UTC)

By the way in the essays add a few nice and calm images, flowers, lak3s, mountains etc. That always helps. Yesterday, all my dreams... (talk) 04:22, 2 August 2026 (UTC)

I want to add that if Grief counseling were to be private, that means that the counselors actions could not easily be reviewed. Editors depend on each other to hold each other accountable and if it were private, you could have somebody offering very bad advice go undetected for some time. - Otherwise (Antibacklog Aktion!) (talk?) 21:49, 31 July 2026 (UTC)

Yeah, that kind of one on one interaction is best left to real therapists. I definitely think this would need to be more of a group environment (if it happens at all) so you can potentially get input from multiple people. ChompyTheGogoat (talk) 00:00, 1 August 2026 (UTC)

Back-to-top button

I like browsing through talk pages and noticeboards, and this means that I often have to scroll for a long time to get to the top. I think a back to top button would help everybody. This may need to be implemented as a change to the MediaWiki software and APIs, because a link will be too hard to add, or it will at least take a very long time to update pages and articles on the English Wikipedia, let alone all languages. Fence127 (talk) 16:38, 29 July 2026 (UTC)

For reference regarding currently available methods: on desktop, you can use the home button on your keyboard. The default browser on Android devices unfortunately doesn't have the tap-on-status-bar shortcut offered by iOS to scroll to the top, so you'd have to install an extension that implements this functionality (or use another browser; reportedly the Samsung web browser provides a method to scroll to the top). isaacl (talk) 16:51, 29 July 2026 (UTC)

I am not asking for help; I am asking for this to be a feature on Wikipedia itself as it would help lots of editors and readers, not just for me. Fence127 (talk) 17:04, 29 July 2026 (UTC)

I thank you for the info though. Fence127 (talk) 17:06, 29 July 2026 (UTC)

You're welcome. I provided this info for all editors and readers, as it will help them on all web sites, not just Wikipedia. isaacl (talk) 17:22, 29 July 2026 (UTC)

What about it being added to Wikipedia for accessibility and convenience purposes? Fence127 (talk) 17:23, 29 July 2026 (UTC)

Personally, I think universal methods that apply to all web sites are more useful and satisfy both accessibliity and convenience. isaacl (talk) 17:28, 29 July 2026 (UTC)

I don't have this issue on most websites, because they don't hide my notifications and other important links at the top when I'm miles down a discussion page. Most that do involve that much scrolling have set up a sidebar or some such workaround. We already have "Return to reply"; it shouldn't be that difficult to implement a comparable "Back to top" option. Even on desktop it can be mildly annoying since my user menu won't appear if I'm 1mm shy of the very top of the page. (I'd prefer a floating menu TBH, but presumably that would take more work.) ChompyTheGogoat (talk) 19:01, 29 July 2026 (UTC)

FWIW I have no less than three browsers on my phone, and none of them have that function. It's just not native to the environment because we don't need it. A lot of extensions don't work on mobile either, so you're asking people to track down a custom one built specifically for Android phones to solve a problem we don't have on most websites. ChompyTheGogoat (talk) 19:04, 29 July 2026 (UTC)

Hell, I've got a floating Add Topic on upscroll already on discussion pages (replaced by the Return to reply once a comment is started). Just drop Back To Top next to that. Solved. ChompyTheGogoat (talk) 19:39, 29 July 2026 (UTC)

Wikipedia:Back to top allows you to add a back to top button alongside section headers. Apparently it only works on pages you can edit, although that is likely to be most of them. Thryduulf (talk) 18:29, 29 July 2026 (UTC)

I believe that its unlikely to ever be added to core MediaWiki. In my opinion, it has potential to be an optional gadget at best. I did try making a userscript here though and it is a pretty nice feature to have. FlammablePizza (talk) 16:53, 30 July 2026 (UTC)

For me, the script doesn't work. Fence127 (talk) 17:19, 30 July 2026 (UTC)

I just checked and it looks like you didn't install it. You have to copy that installation line found in the script's instructions and put it in your common.js file at User:Fence127/common.js FlammablePizza (talk) 17:26, 30 July 2026 (UTC)

Ok. Fence127 (talk) 17:30, 30 July 2026 (UTC)

Nada. ChompyTheGogoat (talk) 23:08, 30 July 2026 (UTC)

@Fence127: A template for this exists, {{skip to top}} (as well as the oppposite, {{skip to bottom}}). It's used, for example, at Wikipedia:Help desk. However, a past discussion at Wikipedia talk:Village pump (technical) § Skip to top and bottom showed that some editors really dislike these template and objected to their addition to village pump pages. I imagine doing this for all editors by default via some other method may see similar objections.

Regardless, some editors do like these templates and wanted them on every page, and one of the participants made a script to accomplish that. See User:Qwerfjkl/scripts/skipToTopAndBottom.js. – Scyrme (talk/solidarity) 23:27, 30 July 2026 (UTC)

Why not make it an optional setting? Trying to fix everything with user end scripts is both annoying and problematic (I've already installed two that failed - this makes at least three created for the same purpose). ChompyTheGogoat (talk) 23:43, 30 July 2026 (UTC)

Make sure you forcibly reload the page after installing a user script (ctrl+f5). There are quite a few userscripts, but its because many people prefer different styles or functionality. The default script is the most unintrusive and adds it to section headers, but doesn't work on all pages. Qwerjkl's adds both skip to top and bottom buttons. I made mine to match the built-in theme closer (both light and dark modes) than some other scripts and also be unintrusive. FlammablePizza (talk) 23:52, 30 July 2026 (UTC)

That's not a thing on mobile. I have to manually clear my cache - which makes script workarounds extra annoying - which I did, and they still don't work. Even in desktop mode. ChompyTheGogoat (talk) 00:27, 31 July 2026 (UTC)

Totally agree. Fence127 (talk) 06:44, 31 July 2026 (UTC)

Much testing later:
I got Back to top working (after modifying the script). It only shows on expanded section headers, and NOT on any discussion pages that I tried, including ones like here and Teahouse as well as Talk pages. That's where I really need it, so it's effectively useless.

I got FP's Scroll to top working - in desktop mode only, and my default browser on my phone refused to recognize it. Once again, useless where I need it most.

Finally, Skip to top and bottom more or less works in both mobile and desktop on all pages using my default browser on my phone. The float action is a bit funky, and there's a duplicate pair in desktop mode on Teahouse, which appears to have it installed manually (which created confusion while I was testing). I appreciate having both options, since I frequently have to scroll down as well to toggle in and out of desktop mode for the sake of functionality (this could stand to be easier too).

It took me three scripts and three browsers across two devices to find a reasonably workable solution for something that could be as easy as a single preference checkbox. This is how a lot of things on Wikipedia are, and it gets extremely frustrating just trying to force the website to be reasonably functional. Don't even get me started on how difficult editing is from mobile in the first place. At least now I can stop accidentally reloading the page and being autoscrolled back down when I'm attempting to scroll to the top just to access my menu. ChompyTheGogoat (talk) 09:52, 31 July 2026 (UTC)

Oh, cool - they like to randomly disappear on my actual desktop computer. At least I have a mouse and scroll wheel here. ChompyTheGogoat (talk) 09:55, 31 July 2026 (UTC)

FYI, I can't use my account on my PC. Fence127 (talk) 10:02, 31 July 2026 (UTC)

I can, but mostly use my phone these days for reasons. And it appears these buttons vanish as soon as I submit a comment on either device, making it only semi-functional. Sigh ChompyTheGogoat (talk) 10:07, 31 July 2026 (UTC)

Sub-referencing

WMF intends to roll out sub-referencing this year, which in my view will make {{sfn}} and {{rp}} obsolete. Should we think about deprecating and converting them to the new citation format? voorts (talk/contributions) 00:06, 30 July 2026 (UTC)

I think this is a really good change; it will make citing books, journal articles, etc. so much easier. voorts (talk/contributions) 00:07, 30 July 2026 (UTC)

Oh good - I just stumbled across an article badly in need of such a thing. ChompyTheGogoat (talk) 07:06, 30 July 2026 (UTC)

Maybe, but not until sub-referencing has been established here for a while such that there is clear evidence that it works in practice on the English Wikipedia for various types of articles (including large lists that make extensive use of the same publication). Only when editors can clearly see whether it is actually a significant improvement over the alternatives will any discussion about deprecating any type of referencing style have a chance of being productive, especially as there was a lot of scepticism at Wikipedia talk:Citing sources#Support or oppose deprecation that subreferencing is an improvement over {{rp}}. Thryduulf (talk) 09:41, 30 July 2026 (UTC)

I support this in principle (and in general think we should make citations more consistent) but IMO it is best to hold off on determining this until subreferences have been enabled and we’ve had a few months to battle-test them. Mir Novov (contribs | talk) 12:12, 30 July 2026 (UTC)

I agree with Thryduulf and Mir Novov. I'm looking forward to sub-referencing, and plan to convert several articles that I created to that style when it's rolled out, but we need to put it through its paces and demonstrate that it's both workable in practice and is an improvement on sfn/rp before proposing widespread conversion. Schazjmd (talk) 13:11, 30 July 2026 (UTC)

What is there to test? It's already active on several wikis and there's full documentation of how it works/what it looks like. voorts (talk/contributions) 13:17, 30 July 2026 (UTC)

It isn't in use on the English Wikipedia yet. Editors don't know how it works in practice with the articles they read and write on this wiki in combination with all the policies, style guidelines, templates, conventions, etc. that we use on this wiki. There is no experience of how much effort it takes to convert from either sfn or rp to subreferencing. I don't understand why you're in such a rush here? Thryduulf (talk) 14:41, 30 July 2026 (UTC)

I'm not in a rush. I figured I'd get the conversation started since it should be coming over here soon. I'm also not sure how any of this could possibly conflict with any PAGs. It looks like a very straightforward system. voorts (talk/contributions) 15:14, 30 July 2026 (UTC)

However likely it may or may not seem, until I've seen it actually stress tested I'm not going to say that can't possibly conflict with anything. Thryduulf (talk) 15:26, 30 July 2026 (UTC)

This looks promising, but mandating sub-referencing and deprecating {{sfn}} and {{rp}} would be a major departure from WP:CITEVAR. —Myceteae‍🍄‍🟫 (talk) 14:58, 30 July 2026 (UTC)

There's some precedent in the deprecation of parenthetical referencing. Anomie⚔ 15:02, 30 July 2026 (UTC)

Good point. I don't think we can't deprecate these but it would be a big change. It's reasonable to have some discussion now though I agree with the sentiment many have expressed that we can't fully anticipate the impact until these go live. —Myceteae‍🍄‍🟫 (talk) 18:53, 30 July 2026 (UTC)

Thinking about it probably wouldn't hurt, but actually pushing for deprecation needs to wait until editors here have some experience with the new mechanism, as others above have already stated. Personally, I suspect that {{rp}} would be easy to bot-convert the majority of uses (assuming we could get consensus to actually do it), but {{sfn}} would likely need human attention and people discussing trade-offs between conversion using inline refs versus LDR. {{r}} possibly also needs some consideration; it seems to be a kitchen-sink that tries to do everything, so someone would need to re-plumb the {{rp}}-like parts of it.

When the time comes to have the deprecation discussions, I suspect we might get better results by tackling {{rp}} and {{sfn}} separately instead of trying to discuss both in the same discussion. In particular, I'd expect a combined discussion to get bogged down with people arguing to keep {{sfn}} (e.g. people who really like having a "bibliography" section ordered alphabetically by author, while sub-refs would order it by first use) while ignoring {{rp}}. Anomie⚔ 15:01, 30 July 2026 (UTC)

How does this make {{sfn}} "obsolete" when it doesn't produce an alphabetical list of sources? I could understand if you just think an alphabetical bibliography is redundant and unnecessary, so prefer other referencing styles, but that's a personal preference; it doesn't make {{sfn}} obsolete, it just makes it not to your taste.

My main problem with sub-referencing compared to {{sfn}} is not actually the lack of bibliography. It's that subrefs are less concise in the source code than {{sfn}} citations and that, like "main references", subrefs still use entirely arbitrary labels instead of consistently using last names and years like {{sfn}}. As with typical <ref>...</ref> references, that often results in duplication of references as well as making it easier to provide incomplete references (missing authors, missing dates) without any warnings, error tracking, or pushback.

Compare: <ref name="ARBITRARYLABEL" details="p.&nbsp;23." /> to {{sfn|Johnson|Smith|2005|p=23}}. The subref doesn't seem any easier to use, is less concise, may require finding the arbitrary label a previous editor decided to give your source, and doesn't handle the   for you. My point isn't that sub-referencing is bad actually. My point is only that it's not a straight upgrade to {{sfn}}, which handles some things better and other things (like, eg, references that don't use {{cite}} templates) worse.

If you like sub-referencing, great, but by itself it won't make {{sfn}} obsolete. – Scyrme (talk/solidarity) 17:15, 30 July 2026 (UTC)

I use sfn only because I have to and rp absolutely sucks. It would've been great if this feature existed when I started editing. I'm less concerned about wiki text. voorts (talk/contributions) 17:20, 30 July 2026 (UTC)

It's not just wikitext though. Tracking down where short refs came from when the labels are arbitrary is more difficult. A lot of <ref>...</ref> references have labels like ":0", ":1", ":2". For a subref with such a label, it would be impossible to track down where it came from if content is copied from one article into another without copying in the mainref. You can try a search for the text itself, but sometimes the copied text comes from an old revision (so does not appear in search results). WikiBlame can help, but only if the edit summary provides attribution. {{sfn}} has similar problems, but at least with {{sfn}} there's a chance you can find the source again even without finding the original article the content was copied from. While Wikipedia requires copied content to be attributed, in practice this isn't always done. – Scyrme (talk/solidarity) 17:55, 30 July 2026 (UTC)

The ":0", ":1", ":2" references names are going to be going away too. See meta:WMDE_Technical_Wishes/References/VisualEditor automatic reference names. --Ahecht (TALK
PAGE) 18:09, 30 July 2026 (UTC)

Unless I'm misunderstanding something, those proposals would still produce extremely vague labels eg. "olympics" or "web_reference_1". Some participants on its Talk page supported author+year based labels; hopefully that that approach is what ends up being applied (where feasible, obviously). Even if the new automated system turns out to be excellent, a lot of articles already exist with weird and vague ref labels so I'm still concerned about the arbitrary labels. – Scyrme (talk/solidarity) 18:37, 30 July 2026 (UTC)

It may not produce an alphabetical bibliography, but it's also not as incredibly fragile as {{sfn}} which fails in any number of hard-to-debug ways on a regular basis due to things like two sources with the same last name in the same year, nested citation templates that require explicit whitelisting, etc. If you look in the WP:VPT archives, 8 out of the last 10 have someone seeking help with a Harv/Sfn no-target error. --Ahecht (TALK
PAGE) 18:03, 30 July 2026 (UTC)

Do people actually object if you change the "arbitrary label" to a systematic one? Anomie⚔ 18:38, 30 July 2026 (UTC)

I've never seen anyone object, but how many editors actually do that rather than copying whatever ref names are already there? – Scyrme (talk/solidarity) 18:52, 30 July 2026 (UTC)

The ones like you who care about it? Like everything else around here? 🙂 Anomie⚔ 19:05, 30 July 2026 (UTC)

Outnumbered by the editors who don't and continue to call references things like "ReferenceA2" (What does the "A2" even mean? There is no "A1"), or "PSSOM" (A partial acronym of the title; useless out of context), or "moved" (not an author, not a keyword from the title, just vague topical word association). These are real examples.

Maybe more editors will care if the rollout of subrefs results in the equivalent of sfn no-target errors because of content being copied around. Or maybe I've misunderstood something and subrefs are immune to this problem somehow, idk. – Scyrme (talk/solidarity) 20:35, 30 July 2026 (UTC)

I have a similar objection to replacing rp with this until the old extends= syntax is added. In solidarity, Aaron Liu (talk) 00:09, 31 July 2026 (UTC)

While I also wish they'd have gone with the extends syntax, I doubt they'll change course now when they haven't already. What exactly do you prefer about {{rp}}, that would be solved by the extends syntax? Anomie⚔ 14:00, 31 July 2026 (UTC)

It doesn't really present much of an advantage: <ref name="label" details="p.&nbsp;42." /> vs. <ref name="label" />{{rp|p=42}}, it's not much of a difference and the latter seems much easier to type. I feel like at least once I'd forget to add that period in the details attribute (yeah I'm still not over the semantics of content inside an attribute...). Stylistically, I also prefer seeing the page number as a superscript. (If the concern is that "[1]:42" is so obtuse that we're better off deleting the template, why not deprecate the colon style instead and change it to "[1] p. 42" or AMA style?)

Extends would've offered irreplaceable value of reusing <ref name="h2g2" extends="label">p. 42</ref> like normal references:<ref name="h2g2" />. In solidarity, Aaron Liu (talk) 14:52, 31 July 2026 (UTC)

{{rp}} doesn't work well with visual editor. This change is meant to make it easier to subreference for everyone. I think we need to move away from the idea that everything needs to be built for power users who edit in wikitext, unless we want editorship to continue declining. voorts (talk/contributions) 15:08, 31 July 2026 (UTC)

Could you elaborate on "doesn't work well"? I see no problem with it for me (except that it adds the full template name, which I don't think is a problem). I started out editing mainspace with visual editor for everything but tables, (and now I edit with the wikieditor for everything but tables), and I don't remember any difficulty with RP either. In solidarity, Aaron Liu (talk) 16:11, 31 July 2026 (UTC)

Personally, If the concern is that "[1]:42" is so obtuse that we're better off deleting the template is indeed the main problem I have with {{rp}}. Now that I look into AMA style, I at least see why some people may like {{rp}}: is not terribly different from AMA's ^1(p42). But I think the subref style still makes more sense for hypertext. Anomie⚔ 17:53, 31 July 2026 (UTC)

Agreed. Editors (particularly new ones) using virtual editor shouldn't need to use multiple templates for a single reference. It's clunky both for editors and readers. voorts (talk/contributions) 17:57, 31 July 2026 (UTC)

FYI, I was referring to the reading experience rather than the editing experience. Anomie⚔ 22:54, 31 July 2026 (UTC)

Besides my proposal to replace the colon with "p. ", rp actually already supports AMA style, too: I guess the encyclopedia would still be well (and dandy, even) if we replaced rp with hovered footnotes. A small problem I have with the current implementation is that you need to go down the references section to see the parent of the subreference and then click the correct link to go back up, but that is a very fixable implementation detail. In solidarity, Aaron Liu (talk) 21:55, 31 July 2026 (UTC)

Seems to work fine with the mw:Help:Reference Previews feature when I try it on testwiki. Wikipedia:Tools/Navigation popups does have the problem you describe. I don't know about mw:Reference Tooltips, that doesn't seem to be installed on testwiki to try it. Anomie⚔ 23:07, 31 July 2026 (UTC)

Oops, I had that installed so long I forgot it wasn't default :) You're right. In solidarity, Aaron Liu (talk) 19:24, 1 August 2026 (UTC)

I'm looking forward to seeing subreferencing being used on enwiki, but this is a conversation to have once it's been in use for awhile and editors have had experience of it. -- LCU ActivelyDisinterested «@» °∆t° 19:07, 30 July 2026 (UTC)

I agree, and I add that the most important part of 'experience' isn't necessarily the bit where some edge case only appears in one in a million articles, and therefore seven times here; the mist important part is people having seen this "weird" (aka "new") thing a few times. WhatamIdoing (talk) 01:22, 1 August 2026 (UTC)

It's just going to end up like that "15 competing standards' XKCD comic. PARAKANYAA (talk) 20:07, 1 August 2026 (UTC)

Link to the '15 competing standards' XKCD for anyone not familiar. Thryduulf (talk) 20:18, 1 August 2026 (UTC)

Unfortunately, this feels spot on. —Myceteae‍🍄‍🟫 (talk) 21:18, 1 August 2026 (UTC)

We'll get a new, shiny cite style to argue over. Wondrous. PARAKANYAA (talk) 05:30, 2 August 2026 (UTC)

The true "one universal standard that covers everyone's use cases" hasn't even been mentioned in this discussion yet: {{r}}. (Actually, it has been mentioned once.) Ah, blessed {{r}}, when they finally figured out how to do all the citations. Somehow it can even already do sub-references. Although, the current way to do that looks extremely confusing. Anyway, I just hope all the citation styles have fun. Dingolover6969 (talk) 19:44, 4 August 2026 (UTC)

R is the worst template. Trying to use that in visual editor is like pulling teeth. Also, the thing about R is that you can do like 6 different cite styles with R - it doesn't exactly solve the issue. PARAKANYAA (talk) 23:03, 4 August 2026 (UTC)

I find all of the citation templates cumbersome to use. Sometimes I just free text the citation side of <ref>...</ref> tags. I usually muddle through trying to do it the right way and I find the experience quite aggravating. —Myceteae‍🍄‍🟫 (talk) 23:11, 4 August 2026 (UTC)

Yeah, this is why I don't think adding sub-referencing will solve the problem, because each of us as individuals have our own preferences that may not work with another's. That is the principle of citevar. I really dislike plaintext citations and like CS1 but other editors like plaintext and hate CS1. Hell, we couldn't even come to consensus on suggesting templates rather than text alone.

Even though I mostly use sfn and will continue to use sfns, am still glad about sub referencing, as it may free me personally from {{rp}}, which I have always hated using but still had cause to use in certain situations, so hey. And I am sure on the other hand people will use sub referencing as they see it as better than sfns (while continuing to use rp). PARAKANYAA (talk) 23:15, 4 August 2026 (UTC)

Talk Pages

Hi all,

I have an idea ( I know nothing about code so it might not work).

I was thinking should we not have the latest comments at the top of article talkpages as then the latest would be the most prominent?

Thanks for your feedback. Equivalent-Text2598 (talk) 21:23, 30 July 2026 (UTC)

I think that would get confusing due to how nested discussions are formatted. This comment needs to go below yours so that people know who I'm replying to. ChompyTheGogoat (talk) 23:46, 30 July 2026 (UTC)

I think they mean that replies should be left in a newest-to-oldest order instead of oldest-to-newest (like I've done right now). Honestly, I think that's a software problem. We could have long had a button to sort comments in either order if there was normal machine-readable metadata of discussions, if that metadata wasn't so easy to break, if the indentation wasn't so easy to break, etc. sapphaline (talk) 11:05, 31 July 2026 (UTC)

I'm not a fan of that within discussions. It gets messy (and as you noted, breaks easily). I'd be open to it as a sorting option for top level threads (which I think could handle metadata better via NTT). If implemented I would suggest also adding an option to either sort by Topic Started or Latest Comment, as well as being able to toggle between Z>A or A>Z. There'd be far too much pushback against just changing it automatically. ChompyTheGogoat (talk) 11:20, 31 July 2026 (UTC)

I think individual topics should remain as is and the wiki text remains as is (for purpose of mass archiving/editing) but an option to visually sort the view of topics from chronological/reverse chronological by topic creation and or “newest comment” would satisfy different people’s needs. For example on a long talk page where I read everything I’d love to quickly find the 4-newest comments either within one topic or across multiple topics. ~ In solidarity 🦝 Shushugah (talk) 11:49, 31 July 2026 (UTC)

Yeah, that's what I was getting at - I may not have explained it well. ChompyTheGogoat (talk) 12:24, 31 July 2026 (UTC)

@Shushugah, you might find commons:User:Jack who built the house/Convenient Discussions useful. It highlights all new comments ("new" since your previous visit) on talk pages. In the sidebar, it tells you how many new comments there are and you can use the arrows to quickly go from one to another. Huge timesaver. Schazjmd (talk) 13:39, 31 July 2026 (UTC)

Only works in desktop mode. Also tends to bog down my browser. Definitely useful overall, but this sort option would be a lighter/more convenient solution, especially on mobile. ChompyTheGogoat (talk) 14:00, 31 July 2026 (UTC)

I use CD on a phone and a tablet all the time, in fact I'm replying with CD on a phone right now. —ClaudineChionh (she/her · talk · email) 00:35, 1 August 2026 (UTC)

In desktop mode. I have it installed, it doesn't work in mobile mode, and bogs down in desktop. Like I said. Desktop is bulky and doesn't behave well on a small screen, but I have to swap back and forth sometimes because mobile doesn't have as much functionality - particularly when a discussion thread is umpteen levels of nesting deep and it tries to feed me comments in columns that are a single character wide, because everything here is built for desktop and often not well adapted to mobile. The app somehow manages to be even worse. ChompyTheGogoat (talk) 03:29, 1 August 2026 (UTC)

Oh, I see – I should have noted that I always use desktop mode (with the Timeless skin) and only use the app under duress. —ClaudineChionh (she/her · talk · email) 03:34, 1 August 2026 (UTC)

I'd just forgotten to uninstall it. Gone now. This might be the first time I've ever encountered a mobile website that's more functional than a single purpose app. ChompyTheGogoat (talk) 04:18, 1 August 2026 (UTC)

Yep that is pretty much my idea. Equivalent-Text2598 (talk) 12:56, 31 July 2026 (UTC)

Sorry, I meant threads. Equivalent-Text2598 (talk) 23:57, 30 July 2026 (UTC)

Some of you younger folk may not be aware that these arguments have been occurring in various places on the internet since before Wikipedia was born (I blame Microsoft Outlook). —ClaudineChionh (she/her · talk · email) 00:33, 1 August 2026 (UTC)

I pre-date Wikipedia as well. Amazingly, technology has progressed somewhat in the interim, and most websites tend to update functionality occasionally in order to improve the user experience. ChompyTheGogoat (talk) 03:33, 1 August 2026 (UTC)

Current events coverage

Every time an event pops up in the news, editors rush to create an article. Most AfDs end up as no consensus because many editors insist that such events are notable. In my opinion, most such articles are not encyclopedic and Wikipedia should not be a place to create articles in the rush of current events that will more likely than not not be covered in any history books. For most of these articles, if you look at the article 6 months or a year later, it'll still be sourced to primary news sources from around the time the event occurred and routine updates from government officials making statements or releasing reports, and if you look for secondary sources, you won't find any. voorts (talk/contributions) 19:10, 31 July 2026 (UTC)

This is a perennial proposal, should we really have waited six months to cover things like 2025 Potomac River mid-air collision? Editors shouldn't rush to create articles about breaking news events, but equally they should not rush to nominate them for deletion either. My preference would be that any AfD whose rationale is or significantly includes things like NOTNEWS or recency would be speedily closed if initiated less then 5 days after the event (the speedy close would be completely without prejudice to a nomination once the event is 5 days or more old, the first AfD would simply be treated as if it never happened). Thryduulf (talk) 20:13, 31 July 2026 (UTC)

Some things will obviously continue to be notable, like that plane crash. Other things, like most of the crimes that get articles created about them, will not. voorts (talk/contributions) 20:20, 31 July 2026 (UTC)

I'm going to give into the urge for once, and provide a copy of NOTNEWS for anyone who hasn't read it in, oh, say, ever:

In principle, all Wikipedia articles should contain up-to-date information. Editors are also encouraged to develop stand-alone articles on significant current events. However, not all verifiable events are suitable for inclusion in Wikipedia. Even when citing recent news articles as sources, ensure the Wikipedia articles themselves are not:

1. Original reporting. Wikipedia should not offer first-hand news reports. Wikipedia does have many encyclopedia articles on topics of historical significance that are currently in the news, and can be updated with recently verified information.
2. News reports. Wikipedia considers the enduring notability of persons and events. While news coverage can be useful source material for encyclopedic topics, most newsworthy events do not qualify for inclusion and Wikipedia is not written in news style. For example, routine news coverage of announcements, events, sports, or celebrities, while sometimes useful, is not by itself a sufficient basis for inclusion of the subject of that coverage (see Wikipedia:Notability (events) § Routine coverage for more on this with regard to routine events). Also, while including information on recent developments is sometimes appropriate, breaking news should not be emphasized or otherwise treated differently from other information.

I suspect that the main difficulty is editors having differing opinions of what constitutes a "significant" current event. For example, I remember someone arguing that 2025 conclave should not have been created until after it was over (or was it until the first scholarly papers had been published?), whereas other editors might draw the line much lower, at approximately two different newspapers covering the same crime. WhatamIdoing (talk) 01:30, 1 August 2026 (UTC)

Arguing that we shouldn't have an article on the conclave is incredibly silly. If you use a modicum of common sense, it's obvious that a papal election meets NEVENT. voorts (talk/contributions) 02:07, 1 August 2026 (UTC)

I think the underlying principle that people struggle with (or forget entirely) is that there should be a reasonable expectation of continuing coverage and discussion beyond the immediate future. Will people still care about this in six months? A year? Five? Ten? It's often impossible to predict with certainty, but that should be the thought process before deciding whether an article is justified. The more sure of it you are, the more likely it is that the article passes NOTNEWS. Major elections with near-infinite international coverage? Beyond any doubt. Small town petty crimes? Not so much. Between those extremes is lots of grey area, but checking similar past events to see whether they've stood the test of time can often be helpful. ChompyTheGogoat (talk) 04:05, 1 August 2026 (UTC)

I understand the concern, but I do not think it can be resolved simply through rules and regulations. The creation of such articles is part of the organic way in which Wikipedia has developed. It began as an encyclopaedia, but it has also become a unique and invaluable record of (very) recent history. Rather than resisting that reality, I think we should accept it and think about what to do with the mass of older current-event articles that may not be very notable. Lova Falk (talk) 10:26, 1 August 2026 (UTC)

I'm not proposing additional rules, just to keep that general concept in mind when debating over whether an article is justified, or if we should hold off to see how it develops. How much coverage it gets immediately isn't the point. And no, I don't think there's much additional value in just immediately restating what regular news sources are saying. That's the whole point of NOTNEWS. ChompyTheGogoat (talk) 11:29, 1 August 2026 (UTC)

Fair enough. I understand that you are not proposing new rules, but arguing that the existing principle behind NOTNEWS should carry more weight when articles are created or discussed. My point was mainly that we should embrace the reality of how Wikipedia has developed. Lova Falk (talk) 15:16, 1 August 2026 (UTC)

That's not "the whole point of NOTNEWS". The first point of NOTNEWS is that Wikipedia editors should "restate what sources are saying" and not go interview eyewitnesses themselves to create an original news report.

I realize that for people who've grown up with Wikipedia that this is basically unthinkable, but in 2002, editors thought it was worth noting that Wikipedia is not "A news report. Wikipedia should not offer news reports on breaking stories. However, creating background encyclopedia articles on topics currently in the news is an excellent idea" because it was "thinkable".

Later, that general comment developed into an item in WP:IINFO saying (e.g., in 2006) "Wikipedia should not offer first-hand news reports on breaking stories (however, our sister project Wikinews does exactly that). Wikipedia does have many encyclopedia articles on topics of historical significance that are currently in the news", got longer (e.g., in 2008), eventually split into its own section, and in 2009, swiped the shortcut NOTNEWS from Wikipedia:News articles (which in turn had swiped it from NEVENT). WhatamIdoing (talk) 18:31, 1 August 2026 (UTC)

"No original reporting" is basically just restating WP:NOR. Nothing new there. The second section provides most of the substance, including most newsworthy events do not qualify for inclusion and while including information on recent developments is sometimes appropriate, breaking news should not be emphasized or otherwise treated differently from other information. ChompyTheGogoat (talk) 09:56, 2 August 2026 (UTC)

It was new then, because NOR wasn't created until 2003.

I wonder how many editors have looked at the statement most newsworthy events do not qualify for inclusion with an actual paper copy of a newspaper in hand. I like to use Kansas as an example, because it's in the geographic middle of the US. The Wichita Eagle is the biggest daily newspaper in that state, and they very conveniently have a news reader that lets you see which things are on which pages. Here's the contents of the first few pages of last Friday's paper:

Page 1:

• Red Cross blood supply crisis (USA Today Network)
• A state agency will open an office in a small town
• Latest strikes in the Iran war (NYT News Service)
• Meet the candidates for county judge elections

Page 2:

• Town irritated by county fire-prevention rules
• (continuations of articles that started on the front page)

Page 3:

• Regional update on the Cyclopspora outbreak
• RFK Jr. said something about the outbreak (USA Today Network)
• Groundbreaking ceremony for a local hotel

Page 4:

• Rumor that a local restaurant might close (false; only the building will be sold)
• Consumer spending up in Q2 (Reuters)
• Trump using Todd Blanche's nomination as a way to force support for an unrelated tax cut (NYT News Service)
• Routine "FYI" about open container laws

Page 5:

• Iran objects to US using military bases near them (Reuters)
• Local man arrested for crime
• (continuation of article that started on the front page)

Page 6:

• City gives developer a tax cut in return for building apartments
• Local restaurant will reopen next week
• Zoox robotaxis approved (Reuters)

Page 7:

• Caller threatened mass shooting
• Teenager with BB gun chased someone
• Fatal motorcycle crash
• Rape reported
• Dulles Airport to be redesigned (NYT News Service)

I count 22 news articles. I count zero subjects that qualify for a Wikipedia:Separate, stand-alone article. American Red Cross doesn't even mention their recently declared crisis in the blood supply. We've got articles about the Iran war, but not a separate article about the individual events mentioned here. The election for the county judges probably doesn't merit a whole article; certainly "we interviewed the candidates" doesn't. The "explosive diarrhea" outbreak gets two articles in Friday's paper, but it only gets one section in Cyclosporiasis#2026 United States summer outbreak. There are eight articles (35%) about local businesses or local crimes, and none of them will even get half a sentence in Wikipedia.

In other words: Yes, I agree that most newsworthy events do not qualify for inclusion. But the thing you need to remember is that nobody's trying to put "most newsworthy events" in Wikipedia. WhatamIdoing (talk) 20:01, 2 August 2026 (UTC)

It's often impossible to predict with certainty Not really, and that's part of the problem here. It is sometimes obvious that an event won't make it past a news cycle, but editors insist we keep an article and wait. voorts (talk/contributions) 15:26, 1 August 2026 (UTC)

Oh, I'm sure some are obvious, but plenty aren't. In those cases I think it's better to wait at least a little while to see how it plays out rather than creating it and then taking it to AfD later (if anyone remembers to). It's not the end of the world for us to not have an article immediately, since events with questionable notability aren't going to be as major (and news coverage exists for that reason). ChompyTheGogoat (talk) 15:40, 1 August 2026 (UTC)

I'm not sure that you have to "remember"; anyone who really disliked this kind of article could just go to Category:2006 or Category:2016 and systematically sort through the articles to figure out which ones were probably worth deleting. WhatamIdoing (talk) 18:34, 1 August 2026 (UTC)

Doing that for all event articles ever created is straight up insanity. ChompyTheGogoat (talk) 09:49, 2 August 2026 (UTC)

Doing that while the event is fresh in people's minds has proven to be ineffective.

Besides, the work doesn't have to be done by one person. For example, your account is about seven months old, and you've made 89 non-deleted mainspace edits. So let's say 200 a year is possible for you. If you told me an interest area, I could probably generate a list of 100 or 200 articles about events that you could review. If you looked at just a few each week, it wouldn't take much more time than you're already doing. Just run down a basic mental checklist with each one and see what you think. For example, I'd ask this:

• Subjectively speaking, is there any chance of this getting deleted at AFD? If the answer is "People will yell at me if I send this to AFD", then you're done, so move on.
• Does a good WP:BEFORE check show sources not presently in the article? Be sure to check local media directly, if the event had a local or regional focus; this is especially important for events in non-English-speaking countries. If the answer is "yes", then add them.
• If the available sources (not just the cited ones) seem weak, then consider whether WP:NEVENT or other guidelines might be met. If the answer is "yes", then you're done, so move on. If "maybe not", then tag with {{notability}}. If "definitely not", then send it to AFD.

Personally, I'd do some copyediting while I was there, but not everyone finds copyediting as quick and easy as I usually do, and it doesn't affect whether the subject is notable. WhatamIdoing (talk) 19:20, 2 August 2026 (UTC)

Wikipedia talk:Speedy keep/Archive 7#Speedy close for recent events of unclear notability is a year old RFC which may be related/give the community's broad temperature on recently created articles. Tazerdadog (talk) 16:26, 1 August 2026 (UTC)

I'm sympathetic to the idea that we shouldn't rush to make event articles but no matter what the policy says if no one is going to vote delete it does not matter. Notability ultimately is what you can get people to agree on at AfD, nothing more. The case that I assume spawned this request had literally 0 delete votes. As someone with experience editing about it, I also disagree with the assertion that it is easy to predict what will and won't receive sustained coverage; in this case the article that is being asserted as non-notable especially, while I'd rather us not have an article currently, it is very similar to the Death of Kendrick Johnson, which received years and years of coverage and has scholarly coverage. PARAKANYAA (talk) 18:05, 1 August 2026 (UTC)

This wasn't spawned by any particular AfD, just reflections on my experience at AfD. voorts (talk/contributions) 18:28, 1 August 2026 (UTC)

I agree with @PARAKANYAA that Notability ultimately is what you can get people to agree on at AfD. This is not apparent to everyone, but it is true. WhatamIdoing (talk) 18:35, 1 August 2026 (UTC)

Consensus is based on strength of argument, not counting heads. voorts (talk/contributions) 18:50, 2 August 2026 (UTC)

Yes, and that is not inconsistent with what Parakanyaa and I have said. WhatamIdoing (talk) 19:21, 2 August 2026 (UTC)

Its going to be hard to stop people creating articles on events when they happen, but we can require better demonstration somwhere between 3 and 6 months after the event happened that the event has demonstrated long-term notability, either via GNG or NEVENT. And the problem is that at AFD, many of these attempts get slammed by editors that reply "lots of news sources in the article, its notable", not addressing the issue that most of those are primary or that they are a burst of coverage rather than enduring. We need to make sure AFD admins are not swayed by those arguments when others are pointing out the GNG/NEVENT issues. Masem (t) 18:20, 1 August 2026 (UTC)

"We need to make sure AFD admins are not swayed by those arguments when others are pointing out the GNG/NEVENT issues" - they're not even swayed by blatant GNG failures now. If there are enough votes for something, that is how it will be closed, even if it is not a vote. PARAKANYAA (talk) 22:36, 1 August 2026 (UTC)

Maybe that indicates that the GNG isn't the only way to qualify for a Wikipedia:Separate, stand-alone article on the English Wikipedia.

Maybe that indicates that there's a range of interpretations of the GNG, with the result that stricter people perceive admins as not following the GNG, when the admins are following (a laxer interpretation of) the GNG.

Maybe that indicates that there's something wrong with the GNG. (The written rules are supposed to follow the community's practice; when practice diverges from the written rule, the written rule needs to change.)

Maybe that indicates that the GNG isn't what admins are supposed to be following. After all, we elect them at RFA on the basis of their ability to interpret consensus rather than on the basis of their views on the GNG.

In other words, there are lots of reasons why an admin might decide "X" when another editor might believe that a specific section of one guideline should result in "not-X". That doesn't mean the admins are wrong. WhatamIdoing (talk) 18:47, 2 August 2026 (UTC)

I think in general the preservationist attitude that we should keep an article if it might hypothetically be a better article in the future really needs to change.

We should be less shy about deletion; an article shouldn't exist if nobody's willing to make half an effort at writing a decent one. I've had multiple corporate articles that I nominated for AfD be voted as keep because there's some crumb of notability out there somewhere; even if the current article is a total mess riddled with routine coverage. At best somebody maybe pares it down to a stub, but otherwise we vote "keep" and move on and the article stays in bad condition.

Same goes for these event articles. If a year has passed and the article still looks like it was written 2 days after the event happened, get rid of it unless somebody's willing to actually commit to bring it to proper encyclopedic standard. Otherwise we end up with one big bystander effect; "we should keep this article because WP:SOMEONEELSE (not me though, of course, I'm busy editing things that actually interest me) might be able to make it into a decent article. Eventually." Athanelar (talk) 08:37, 2 August 2026 (UTC)

I'd like to see WP:TNT invoked more often. Notability alone does not an article make - I could find a reliable subject, add sources, and then fill the body with gibberish. We have WP:CSD for a reason, and similar logic should apply for creation and WP:XFD even when something doesn't meet those limited criteria. There needs to be a bare minimum standard for articles to have any encyclopedic value. A well formed stub is better than a bunch of WP:PROMOslop. If no one else cares to expand it correctly, is it really that notable?
Along the same lines, if no one cares enough to go back and write a breaking news article after the event is over, it probably fails based on WP:RECENTISM. In most cases where it isn't immediately obvious that the subject will have persistent notability, there's no harm in a WP:DELAY to see how it plays out. I maintain that it's better to hold off than to create it based on a coin flip and rely on it getting deleted later if it flops. Lord knows we have enough cleanup to do as it is. Notability standards exist for a reason - while I don't believe in any hard limit on the scope of Wikipedia, we don't need to fill it with a bunch of low quality cruft either.

I wonder if it would be helpful to set up a project/noticeboard/something to try to establish a group of editors with a particular focus on this - not an introduction of new rules, but an attempt to apply existing standards consistently instead of relying on majority rule. Editors who are making those determinations on a regular basis on subjects they're uninvolved with can be more objective. ChompyTheGogoat (talk) 09:47, 2 August 2026 (UTC)

I think it'd be nice to have a kind of "article bounty" system looped into this via AfD. If you nominate an article for TNT deletion (with solid reasoning) then somebody has to claim the article and pledge to work on getting it in better condition. If nobody volunteers or if they don't improve it in a reasonable amount of time then it gets soft-deleted as if it were an uncontested deletion. Athanelar (talk) 15:34, 2 August 2026 (UTC)

But why? PARAKANYAA (talk) 16:00, 2 August 2026 (UTC)

Quoting myself above; an article shouldn't exist if nobody's willing to make half an effort at writing a decent one. If an article's in TNTable state I don't think we should keep it just because the topic is notable if there's nobody actually willing to write the article to an acceptable standard. Athanelar (talk) 16:45, 2 August 2026 (UTC)

Then we'd just have disputes over what constitutes "an acceptable standard". For example, looking at Wikipedia:Articles for deletion/Dover Corporation (2nd nomination), you nominated an article that, at the time of your nomination, had these qualities:

• 83 refs – more than twenty times the median Wikipedia article (which has a total of four)
• a "readable prose size" of 2,495 words – more than seven times the median Wikipedia article (which has about 350 words)

It appears that most editors consider that an article that is above the 90th percentile on both these scores to already be "acceptable". WhatamIdoing (talk) 19:01, 2 August 2026 (UTC)

I'm talking more about stuff like Academy 360, Sunderland which was closed as keep last year because the school apparently had significant coverage under its previous name. Did anybody go on to add any of that to the article? Of course not, so it's still a short blurb entirely sourced to the school's own website. Athanelar (talk) 19:20, 2 August 2026 (UTC)

Why didn't you add the sources to the article? You were given some sources in Wikipedia:Articles for deletion/Academy 360, Sunderland. Aren't you part of the "anybody" who didn't "go on to add any of that to the article"?

I wish you had found a different way to describe this problem, because my impression from this comment is that you think you're better than the rest of us. We peons might have to do boring work like putting sources in articles, but you are so important that you shouldn't have to do anything more than tap your foot impatiently while your servants scuttle around to meet your demands. I doubt that's the impression you wanted to make, but it's the one I formed. WhatamIdoing (talk) 20:21, 2 August 2026 (UTC)

Aren't you part of the "anybody" who didn't "go on to add any of that to the article"? Yes, I am, that's precisely the point I'm making. Nobody, myself included, wants to take the time to make an article about this random secondary school to an acceptable standard. So instead of just getting rid of it, it's going to languish in its current state for god knows how long. Nobody wants to delete it becsuse it's notable, but nobody wants to improve it either.

because my impression from this comment is that you think you're better than the rest of us. We peons might have to do boring work like putting sources in articles, but you are so important that you shouldn't have to do anything more than tap your foot... Ridiculous. My point is that, as I said explicitly, if nobody (which includes me; I am in fact 'body') wants to write the article, then maybe it's better that we have no article, and maybe we shouldn't maintain the culture of people being able to prevent deletion by gesturing toward the existence of sources without actually doing something to improve the article. If an article is in a demonstrably bad, unencyclopedic state (which that article is), then if somebody really wants to keep it they should hold the burden of doing the work to improve it, rather than stopping it from being deleted and leaving it in its poor state in perpetuity. I'm not arguing, and I never once said anything resembling, that somebody else should do this thing which I don't want to. I'm in fact arguing the opposite; people vote "keep" in these discussions in the belief that some other person at some other time will do the actual work to improve the article. Rather than hoping for that hypothetical person to come, again, to quote myself above, "an article shouldn't exist if nobody's willing to make half an effort at writing a decent one." Athanelar (talk) 20:47, 2 August 2026 (UTC)

You're confirming my impression: You don't want to do the work, and you're here on this page complaining that nobody else has done work that you refuse to do yourself. If neither the subject nor the article are important enough for you to do any work at all, then I suggest that it's probably also not worth you complaining about it.

Editors aren't voting "keep" at AFD "in the belief that some other person at some other time will do the actual work to improve the article". They're voting "keep" because our rules say that the decision about whether to have an article should be based on whether sources are available and not on the basis of whether anybody has put those sources into the article yet.

I don't know what kinds of articles you tend to read, but for a lot of school/organization/business articles, many of our readers are really only looking for a single basic fact. In the case of a school, I expect that there are only three questions that really need to be answered: What kind of school? (This one takes students of any age.) Where are they located? (That's going to be a long drive.) What's their official website? (Right there on the page. NB that the official link to the subject's website gets clicked on more often than any other link in any article, by a very large margin.) Most readers don't need the article that's up "to an acceptable standard", and especially not one that's up to your standards. They need an article that meets their immediate need, and this one likely does that for most readers. A red link won't meet their needs. I suspect that the only entity on Earth (present company excepted) that really wants a polished Wikipedia article is the school's marketing department. WhatamIdoing (talk) 22:27, 2 August 2026 (UTC)

WP:NEXIST exists. PARAKANYAA (talk) 15:59, 2 August 2026 (UTC)

Just a reminder that {{user imm}} and Category:Immediatist Wikipedians exist, and proponents of m:Immediatism may wish to put them on their User: pages. WhatamIdoing (talk) 18:49, 2 August 2026 (UTC)

I've previously thought that something like WP:WikiProject Current events should be repurposed/created where articles on recent events are listed as drafts for people to work on (basically an incubator), and they can be moved to mainspace when there's consensus they either meet WP:NEVENT or WP:GNG with secondary sourcing. But let's be honest, readers like the current events articles that are basically just a synthesis of primary sources, and readers first. Maybe someone could request a new project which'd be like Wikipedia but specifically for current events and breaking news, idk what we'd call it, Wikinews or something Kowal2701 (talk, contribs) 18:51, 2 August 2026 (UTC)

I think Wikinews failed because it tried to be an open source media outlet. Newsrooms need structure. Maybe if it had been basic news analysis, like most of our current events articles, it would've survied. voorts (talk/contributions) 18:53, 2 August 2026 (UTC)

I think there were a lot of reasons why Wikinews failed, including muddled purpose (supposed to be creating news articles, which means things like 'interviewing people' and 'writing things that can't be verified by reading a news article at a different website', or just rehashing other news stories?) and the wrong structure (too slow, too rigid, too little support, too little training, too failure-prone). But above all, I think what doomed them was too much competition, leading to no demand from readers.

I think that most readers and many editors (especially the kind of editor who doesn't spend all day on pages like this one) want the articles we write about current events. WhatamIdoing (talk) 19:07, 2 August 2026 (UTC)

I agree that they're valuable, I just don't find many of them particularly encyclopedic. voorts (talk/contributions) 19:14, 2 August 2026 (UTC)

If you believe Wikipedia:Five pillars (and many newer editors seem to believe that it's the most important page ever), Wikipedia isn't just an encyclopedia. In that model, it wouldn't matter if they're really encyclopedic. WhatamIdoing (talk) 20:23, 2 August 2026 (UTC)

perhaps Wikipedia could have cross-project redirects to these Wikinews articles, like we do with Wiktionary sometimes? Idk, seems too wikt:pie in the sky Kowal2701 (talk, contribs) 19:59, 2 August 2026 (UTC)

We don't limit Wikipedia:Soft redirect to Wiktionary. However, there's never been enough interest in redirects to Wikinews to even bother creating the usual template (see Category:Interwiki soft redirect templates). The problem is the lack of decent articles at the English Wikinews. Can you name even a handful that you'd want to do that with? I can't. WhatamIdoing (talk) 20:27, 2 August 2026 (UTC)

I was talking about a potential new Wikinews like that described above, but having messed about with the Random article on Wikinews, I can't either Kowal2701 (talk, contribs) 21:01, 2 August 2026 (UTC)

Nonexistent page creation prompt on mobile

Hi! When I'm using mobile view and search a term with no page, it doesn't ask me if I want to create a page with that name but it does ask me that if I'm using Desktop. Is this a known feature mismatch that's being worked on? — ♠ Ixtal ^{( T / C )} ⁂ Non nobis solum ♠ 17:58, 1 August 2026 (UTC)

Can you show an example? I just clicked around and every page I tried in either mode had some kind of option to do so, albeit sometimes buried amongst other suggestions. I do not appreciate when I follow a redlink in mobile and it autoloads the editor, because that version takes over the entire screen and I have to back out of it to access other options. That appears to only happen with redlinks though, not search or a direct URL. ChompyTheGogoat (talk) 23:14, 1 August 2026 (UTC)

When I search for "corticolimbic", for example I get the following message at the top of the results using desktop:

The page "Corticolimbic" does not exist. You can click on "Corticolimbic" to create the page directly, or you may create a draft and submit it for review, but consider checking the search results below to see whether the topic is already covered..

This message does not appear when using Mobile view. — ♠ Ixtal ^{( T / C )} ⁂ Non nobis solum ♠ 23:24, 1 August 2026 (UTC)

Ohh, I see - the actual search function ignores the nonexistent article for that exact title and only searches within live articles. You can still navigate directly to https://en.wikipedia.org/wiki/corticolimbic, but I can see how it's useful to offer that option on searches. ChompyTheGogoat (talk) 01:26, 2 August 2026 (UTC)

More than anything I just think it would help drive in new editors whose primarily (or only) way of accessing Wikipedia is via their mobile device and encourage them to create pages (or redirects). — ♠ Ixtal ^{( T / C )} ⁂ Non nobis solum ♠ 08:32, 2 August 2026 (UTC)

I'm not sure we really want to encourage brand new editors to dive in with entire articles. In fact, we specifically discourage it on Teahouse, although it's not a rule. More often than not they just don't know enough to make one that's passable, regardless of how well intentioned they are. A redirect wouldn't hurt in most cases, but I don't think many people are going to be inclined to start editing for the first time just for that.

Regardless, I do think it should probably be consistent on mobile vs desktop - the reasoning doesn't change. ChompyTheGogoat (talk) 09:06, 2 August 2026 (UTC)

I'm sure that the merits of encouraging page creation where discussed at length when that message was added to the desktop experience so I'm not really feeling it necessary to rehash that debate, my main concern is like you pointed out, ChompyTheGogoat: the experience should be consistent on mobile and desktop. — ♠ Ixtal ^{( T / C )} ⁂ Non nobis solum ♠ 00:25, 3 August 2026 (UTC)

Discussion at WT:ITN § Brainstorming reforms

 You are invited to join the discussion at WT:ITN § Brainstorming reforms. Left guide (talk) 09:26, 2 August 2026 (UTC)

Auto-purging

CAT:EXLLM seems to be perennially backlogged because the category fails to auto-update when an nomination under {{llmprod}} expires. I'd suggest sending a bot to purge all pages with PROD tags every six hours or so, same as WP:PRODSUM. Any other ideas? –LaundryPizza03 (dc̄) 13:58, 3 August 2026 (UTC)

I think the problem is that the general PROD categories are dated, whereas there aren't any specific LLMPROD dated categories, and LLMPRODs expire earlier than normal PRODS. I think we do need seperate LLMPROD dated cateogries. I guess a bot is also fine since it won't even require an account, see this button that will purge all LLMPROD pages (only works if there are less than 500 such pages though): Purge LLMPROD pages (click 'Make Request' after this) Alpha Beta Delta Lambda (talk) 21:28, 4 August 2026 (UTC)

That first one is a good idea. {{prod-blp}} could use such categories as well. This can likely be handled with a simple edit request on each page, plus updating the list of maintenance categories for Hazard-Bot (talk · contribs) to date. –LaundryPizza03 (dc̄) 17:11, 5 August 2026 (UTC)

Replace fundraising banners with 'we need more editors' appeal

With the WMF having almost $300m in assets and another $100m in the Endowment we are less desperate for donation and more desperate for new editors, which has significantly decreased in the last 10 or so years. So I propose to replace the fundraising banners and replace it with a 'Wikipedia needs your editing help' banner, maybe suggesting them to register an account or point to the category of pages that need cleanup. Alpha Beta Delta Lambda (talk) 17:43, 3 August 2026 (UTC)

Let's ignore your comments about the WMF's Reserve (accounting), as it's both misleading and irrelevant. $300M as the economy teeters on the brink of a recession is how much actual experts recommend the WMF to have in their operating reserves.

Let's instead talk about getting more editors. I'm in favor of the goal. I've got some suggestions about the order in which we do things.

Here's the graph for the last 10 years of "active" editors. Here's the graph for the last 10 years of "new" accounts. I agree that this is an area of weakness, but the "active" editors are the ones who are around long enough to become good editors. We need to turn the newbies into active editors.

If we wanted to make a difference in this area, the research-backed approach might be an education campaign aimed at highly active editors. Specifically, we know that editor retention is improved when patrollers and other editors follow the rule to Wikipedia:Revert only when necessary, and whenever possible to build on an imperfect contribution (e.g., replacing their bad source with a good one, removing only part of an addition while keeping some visible fraction of it, adding a clearer explanation, etc.).

There's not much point in recruiting new editors if we're going to run them right back off again by reverting their attempts to contribute.

Therefore, I suggest that we first look at ways to improve retention of newcomers. After we think we can retain a decent fraction of the newbies, we can look into trying to get more newbies. WhatamIdoing (talk) 21:05, 3 August 2026 (UTC)

The active editor graph suggest that it's stable over 10 years, while the new editor graphs is going down. Of course I agree that we need to be more friendly, but I don't think most of Wikipedia are so bad that it scares newbies off. Most newbie contributions are not reverted. Anyways I might be overly thinking about a Signpost article that suggests that the number of new users is decreasing (admitedly not by a lot annually), although that might not be a huge deal. Alpha Beta Delta Lambda (talk) 21:27, 3 August 2026 (UTC)

I think it's a big problem, and I agree with the goal. I think that we need more than a banner to solve the problem. WhatamIdoing (talk) 21:36, 3 August 2026 (UTC)

This is of course a big problem, but I think we might be trying to find the perfect solution. It might not make a huge difference, but it'll still (hopefully) make a positive difference. Alpha Beta Delta Lambda (talk) 21:54, 3 August 2026 (UTC)

WhatamIdoing, as always graphs need context. Please also show a graph of the number of articles. Let me put it this way, if the number of doctors in a country remains stable, but the population goes up five fold, quality of care will go which way? That is the issue. Yesterday, all my dreams... (talk) 12:03, 4 August 2026 (UTC)

Our editors-per-article ratio has been declining at the same time that our article quality has been improving. Doctors-per-capita is at best an imperfect analogy. WhatamIdoing (talk) 20:24, 4 August 2026 (UTC)

Do you have a graph of editors per article ratio? Is it scary? Yesterday, all my dreams... (talk) 20:37, 4 August 2026 (UTC)

Honestly, I don't think the declining number of editors is a big deal. You'd expect to see numbers declining since the low-hanging fruit of article drafting has been harvested aggressively, and wide swathes of the encyclopedia's articles on topics that fundamentally aren't changing are in a pseudo-maintenance mode at this point. CoffeeCrumbs (talk) 01:08, 9 August 2026 (UTC)

On the other hand, I have a long list of articles I want to write, more than I will get to in the time I have left, I am regularly returning to articles I worked on in the past to add to them (I just enlarged a B-class article by 25% in the last 3 days), and most articles in Wikipedia are still far too short. Half-a-dozen new regular editors in the areas I work in would help. Donald Albury 01:23, 9 August 2026 (UTC)

Yes, but... As I said below, it is not just "writing" but updating. Some articles have had no meaningful updates for 15 years. That requires knowledgeable editors. Alas I have no idea how to get them. Yesterday, all my dreams... (talk) 03:48, 9 August 2026 (UTC)

How, indeed, to recruit new editors who are at least as interested in updating and expanding existing articles as they are in creating new articles? I see new editors that seem interested in working on existing articles in areas I work on, but most do not stay around for very long. So retention is also a problem. I have not been interested in mentoring, and was disappointed by the lack of response from student editors when I worked with the education program more than a decade ago. So I don't have an answer, either. Donald Albury 13:35, 9 August 2026 (UTC)

We are in agreement. I keep looking at the activities of editors, like this. He knew the subject, then just evaporated away. Some of his speculations persisted for long. Also this user. They come and go and because we have so many articles no one has time to check or update what they have done, and material gets outdated year after year. Yesterday, all my dreams... (talk) 17:49, 9 August 2026 (UTC)

I would love it if we could do both. This ought to be tested if it hasn't been already Kowal2701 (talk, contribs) 21:46, 3 August 2026 (UTC)

Yeah, I'm not sure why do I think it has to be one of the other, of course it can be both "please donate" and "please edit". Alpha Beta Delta Lambda (talk) 21:54, 3 August 2026 (UTC)

Can suggest it at the WP:FUNHUB btw, though tbh I'd like to see testing of it on its own as well Kowal2701 (talk, contribs) 22:44, 3 August 2026 (UTC)

This isn't a criticism of your suggestion, there's nothing wrong with it; that being said there's currently an elephant in the room that the WMF unionizing conflict is getting worse, and depending on how that goes it might affect what is done with donation banners. Gnomingstuff (talk) 06:50, 4 August 2026 (UTC)

I guess this idea could also be a replacement of the fundraising banner. Alpha Beta Delta Lambda (talk) 09:55, 4 August 2026 (UTC)

(A bit off-topic, I'm sorry.) I think much more is needed than a banner. When I joined, nineteen years ago, so many editors were encouraging: "Be bold! Make an edit!" I rarely read this any more. Lova Falk (talk) 10:12, 4 August 2026 (UTC)

I absolutely agree, this is a big issue. Perhaps we can throw that phrase more. The idea though is that the banner would encourage readers to make an edit or ten. Alpha Beta Delta Lambda (talk) 10:29, 4 August 2026 (UTC)

It's not just the words. We need to back up the words with action, or people will feel like we lied to them. WhatamIdoing (talk) 20:25, 4 August 2026 (UTC)

Of course, but I'm not sure we're breaking a promise. Wikipedia promises to be "the free encyclopedia that anyone can edit", and as far as I can tell we aren't lying about that. If you meant that we semi-constantly revert their edits, I'm not sure what could be done other than to remind experienced editors to revert only when necessary. Alpha Beta Delta Lambda (talk) 21:00, 4 August 2026 (UTC)

I've previously written about English Wikipedia's structural issues that make it unattractive to many co-operative editors. They essentially make content-dispute resolution ineffective and provide incentive for poor behaviour. Any edit one makes, no matter how small, has a sword of Damocles hanging over it: another editor can vociferoously object, and one has to decide if it's worth getting into a discussion about it or not. Either way the outcome is often poor: one can just move on, with a constant irritant that aggressive behaviour typically wins out, or one can end up spending an unbounded amount of time trying to find common ground with an editor not interested in co-operating. Even if most interactions aren't like this, just a few can suck all the joy out of editing. For better or worse, though, the portion of the community that likes to discuss these matters generally places a higher priority on the ability for everyone to weigh in, which is enabled by the current decision-making traditions. isaacl (talk) 22:29, 4 August 2026 (UTC)

Isn't co-operation required? If one consistently can't co-operate isn't that blockable? Alpha Beta Delta Lambda (talk) 10:21, 5 August 2026 (UTC)

By English Wikipedia's decision-making traditions, in the absence of clear disruption, whether or not one is being co-operative or just engaging in vigourous discussion is decided upon by a consensus-based discussion. So every disagreement requires a weighing of options: is the worth the effort to build a consensus for one's point of view? Since discussion participants are self-selected amongst those who happen upon the discussion, the outcomes are frequently uncertain. It's a constant drag on enthusiasm that can wear editors out. isaacl (talk) 16:54, 5 August 2026 (UTC)

I have heard that WP:HEAR can be used to pull people's ears, so to speak. Yesterday, all my dreams... (talk) 23:09, 6 August 2026 (UTC)

I created a prototype banner. Feel free to improve it. Alpha Beta Delta Lambda (talk) 10:52, 4 August 2026 (UTC)

There are two issues here. One is that we need more editors, and a banner may be a good way to help with that. The other is that aggressive fundraising is not universally popular with readers or editors. Those two points are almost orthogonal, the overlap being that they might compete for the same screen space. The current reaction to union developments may be relevant here. Although I don't think it's being proposed, one way to deliver a message to the WMF would be to interfere with fundraising banners, leaving a free slot which could be used to recruit editors. Certes (talk) 11:14, 4 August 2026 (UTC)

Agreed, in fact it might be useful here. Alpha Beta Delta Lambda (talk) 11:19, 4 August 2026 (UTC)

My unhelpful comment on the subject is that we generally need better editors, not more editors. Of course, since I don't know a way to get better editors that's hardly actionable. Except of course by getting more editors and hoping that the better ones remain. (Certainly, regular Wikipedia users are typically pretty good!) Dingolover6969 (talk) 19:57, 4 August 2026 (UTC)

I've given up on trying to get "better" editors, because trying to find "the one" in 100,000 is needle-in-haystack region for me. WhatamIdoing (talk) 20:26, 4 August 2026 (UTC)

I would say we need "knowledgeable" editors. Please consider the talk page Talk:Reason maintenance. The last discussion was 15 years ago before I commented today. The last meaningful edit to the article was also 15 years ago by an editor who left long ago. Many articles are way out of date and not enough editors who understand the subject well enough to do anything. Yesterday, all my dreams... (talk) 09:21, 8 August 2026 (UTC)

Merge PROPSPLIT into AfD?

Okay, admittedly I am not a great ideas person, nor am I the most familiar with Wikipedia as a whole or what I consider as a hardcore editor or anything, so everything here is admittedly based on vibes. Please correct me if I'm wrong on anything.

But I was curious, with the merging of WP:PAM into WP:AfD not too long ago now, that got me thinking. Has anyone ever proposed merging WP:PROPSPLIT into AfD? To me, while splitting isn't really deletion like merging is in a sense (especially with the RfC to rename AfD failing), in a sense, PROPSPLIT was essentially the inverse of PAM. From what I've seen, PROPSPLIT also seems to suffer from the same issues of inactivity and invisibility that PAM did (which was part of the motivation with merging it into AfD). In fact, I'd probably argue that PROPSPLIT probably has it worse off since AfD at least ostensibly acted as an occasional, inadvertent alternative, and it seems to me like a lot of actual split discussions aren't displayed on PROPSPLIT, leading to most of them being inactive. Splits honestly don't seem as common as merges are, so it probably won't really dominate AfD anyhow, even to the same extent as merges do. But yeah, I'm not sure if it's a good idea. I just wanted to get the ball rolling; maybe others have better ideas than I. Please, feel free to be brutally honest! OrdinaryScarlett (talk) 10:21, 6 August 2026 (UTC)

It's been suggested a few times. Most recently the general consensus was to wait and see how well folding mergers into AfD works in practice and I think it's still a bit early to get a feel for that tbh. Thryduulf (talk) 10:43, 6 August 2026 (UTC)

Ah, I see, thanks! In that case, I'll defer to that, then. OrdinaryScarlett (talk) 10:49, 6 August 2026 (UTC)

As I've mentioned during the Merger discussions, that wouldn't work since—when compared to Deletion arguments—Split discussions have very different arguments while Merger discussions have very similar arguments. In solidarity, Aaron Liu (talk) 14:04, 6 August 2026 (UTC)

AfD is not (or should not be) a forum to discuss what content decisions should be made about a merge. What's next, a binding decision at AfD as to how to organize the content in the article? Katzrockso (talk) 14:08, 6 August 2026 (UTC)

Merging has always been one of the results for failing inclusion criteria, whose appilcability is exactly what AfD discusses. See WP:RFCMERGEAFD. In solidarity, Aaron Liu (talk) 15:58, 6 August 2026 (UTC)

I'm not talking about the PM-AfD merger, as I both participated in that discussion and in post-RfC discussions about it. Please reread my comment - I am talking about content decisions being made at AfD - AfD is not the forum to decide if we should include/exclude content, how to title an article, whether to rescope the article to be about another topic, etc. Many of these do incidentally result from an AfD consensus, but people cannot and should not be bringing articles to AfD for that purpose. Bringing in mergers, while a mistake in my opinion, is much more consistent with the purpose of AfD than any run of the mill talk page discussion that people seem to increasingly want to bring to AfD. Katzrockso (talk) 18:25, 6 August 2026 (UTC)

I don't think the process for having merger discussions at AfD is working very well. I would not support any other additions to AfD (recognizing that there could be multiple outcomes of an AfD). --Enos733 (talk) 18:14, 6 August 2026 (UTC)

Merging at AfD is already terrible, but at least in that case 1. merge was sometimes already an AfD result and 2. merging ultimately results in the loss of a page. Splitting is a decision on whether to make a new article - a decision that has never been made at AfD. Absolutely not. PARAKANYAA (talk) 18:51, 6 August 2026 (UTC)

And the problem with inactivity in splits is that it requires writing a whole new article; this is not a problem that AfD can solve because writing a whole new article is a bit much of anyone to ask. I have a split suggestion that achieved consensus in 2024 that no one has bothered to do, not because it has lacked for comments, but because no one has stepped up to write the article. PARAKANYAA (talk) 18:53, 6 August 2026 (UTC)

The issues involved in a split proposal seem sufficiently different from deletion and merging that I don't think this makes sense to add to AFD, although I take your point that a split is the inverse of a merger. There are obvious notability considerations with respect to the new page(s) to be split off, and anyone arguing or a split must take these into account, but other than that the work and the issues at play are distinct. The fundamental challenge with splits is that it takes a lot of work both to make a determination and, especially, to carry it out. It's one thing to make a determination that a topic is in and of itself non-notable, or that there's not enough to say about it to warrant its own article. Seeing the potential for a split is perhaps not difficult but actually going through a very long article and identifying two or more distinct, notable topics and exactly which content should go where, and achieving some level of consensus for the content organization is a heavier lift. —Myceteae‍🍄‍🟫 (talk) 19:02, 6 August 2026 (UTC)

We should split out proposed merges from AfD and merge them with proposed splits. That way the shortcut for both could be WP:SPLERGE. "This article needs splerging!" will become the rallying cry of the next generation. I am very smart  — Hex • talk 20:30, 6 August 2026 (UTC)

MeatPuppet Investigations

Wikipedia could honestly have a MeatPuppet Investigations for detecting meat puppets. It is a major issue, and it still isn’t handled with a MeatPuppet Investigations. plus, the shortcuts could be WP:MPI, WP:MEATReport, and WP:MEATFIND ~2026-43379-50 (talk) 22:45, 6 August 2026 (UTC)

how does anyone think of this? Duodeca 12 (talk) 16:08, 7 August 2026 (UTC)

answer Duodeca 12 (talk) 18:59, 7 August 2026 (UTC)

Isn't meatpuppetry already a form of sockpuppetry? ⠀⠀⠀⠀ .n the homo 04:04, 8 August 2026 (UTC)

Redaction of username from all edits and logs when blocking

Moved from Special:Permalink/1368178108 § Redaction of username from all edits and logs when blocking

Hi everyone! I'm moving this discussion here because I accidentally posted it on the village pump (policy) page. :-)

I've mentioned this idea before, and I recently noticed that an open discussion was held regarding the bureaucrat role on this page. It inspired me to start this discussion and see what others think. Like the bureaucrat discussion, this one is intended to be open-ended; it does not come with any specific proposal attached.

A little background: currently, oversighters can suppress the username of an account from all edits and logs when applying an indefinite block, which also removes the account from the list of users. This option also extends to stewards, who can do the same thing on a global level.

I originally suggested extending a similar option to administrators (and likewise expanding it for stewards globally) a few years ago after noticing that stewards would sometimes globally suppress accounts whose usernames, while extremely disruptive and clearly inappropriate to leave publicly visible, (in my opinion) did not rise to the level that warranted suppression. I reached out to them about this — not to complain or start a riot or anything like that, but as a precursor to present this idea as a possible solution.

Now, let me say this: I totally get it. I completely understand why global suppression would become an attractive option in situations where a username clearly should be redacted but does not actually require suppression. It would be ridiculous to expect a steward to manually redact the username on every project, one at a time, simply because there is no equivalent option available when globally blocking an account. I don't have the examples with me at the moment, but I included a handful of them when I first reached out about this, and I think most people would agree that there would be no argument for keeping those usernames publicly visible, but they did not warrant suppression.

That brings me to my idea: what are your thoughts on extending a version of the suppression option to administrators when applying an indefinite block to an account? It would do the exact same thing but would use revision deletion rather than suppression to redact the username from edits and log entries. My initial thought is that it would not hide the account from the list of users like the suppression option does, but like I said: this is an open-ended discussion, and I'm interested in hearing other ideas and perspectives.

Likewise, a similar option could be extended to stewards when applying global blocks. Rather than relying on global suppression, they could apply global revision deletion to redact usernames from edits and logs across all Wikimedia projects while still allowing local admins to review and manage any issues according to their own policies and processes.

I know that many admins have different levels of involvement in dealing with LTA disruption and abuse, but I often encounter situations where an LTA creates numerous accounts with blatantly abusive usernames that need redaction. Having the ability to redact those usernames from edits and logs at the time of an indefinite block would be extremely useful as well as much more efficient. It can be tedious and sometimes very time-consuming to manually remove the username from every edit and log entry, especially when one or two more abusive accounts created by the same LTA appear in the account creation log and start causing disruption while you're still cleaning up after the first mess!

Overall, I think this option would be very useful for administrators and would allow them to respond much more efficiently to blatant username violations and blatant LTA username abuse. Just like with all other administrator actions, its use would be publicly logged and easily reviewed and scrutinized, and the potential for abuse of it would be very low. An administrator who wanted to misuse revision deletion could already do so using the existing tools they already have access to; this option would simply streamline a process and take the tediousness (as well as the possibility of accidentally leaving the username public in some areas and missing a few places) out of the equation.

That's my idea, and I'd like to open the floor for discussion.

So... what are your thoughts? :-) ~Oshwah~^{(talk) (contribs)} 13:47, 7 August 2026 (UTC)

amazing idea. It is simply the most magnificent idea. Plus it could revolutionize Wikipedia Duodeca 12 (talk) 16:04, 7 August 2026 (UTC)

This seems like it would be a benefit. In practice, we already do this, it just requires a run of manual RD2/RD3 rev-deling after the block. _signed, Rosguill ^talk 16:07, 7 August 2026 (UTC)

I just want to say that the block log probably shouldn't be included by default. Additionally user talk pages usually disappear with suppression - I don't know if that's automatic - and probably shouldn't be included by default (I'm not saying they should necessarily remain). Another thing, accounts created by a bad username should probably be blocked before their account creation logs are redacted. I often take the view that removing usernames from conspicuous histories is sufficient (ie mostly just article histories). A little visibility can help with anti-vandalism efforts. I can't say that such a tool wouldn't be occasionally useful, with the type of adminning I usually do. I just wonder if there's enough demand for it as a standard option. After all, "potential for abuse" will also be "streamlined". And there will still be plenty of other places to clean up. -- zzuuzz ^(talk) 22:22, 7 August 2026 (UTC)

Do you have any experience of usernames that require this level of suppression? Sometimes I deal with promotional usernames, offensive usernames, attack usernames or fakers. Usually blocking is enough, and revision deletion is seldom needed, even less is log redaction rquired. If any edits are kept then the user and edit summary are legally required to be kept. But under what circumstances should a username need to be made completely invisible? Graeme Bartlett (talk) 08:37, 8 August 2026 (UTC)

Some usernames require suppression, probably most commonly they are attacks on another user ("User:Example is a paedophile" sort of thing) but there are reasons, but revdel would not be suitable for those. I don't work WP:UAA but there is nothing there currently that would need hiding. Thryduulf (talk) 09:39, 8 August 2026 (UTC)

Admins can get some idea of what is being rev-deleted at this log link. -- zzuuzz ^(talk) 10:23, 8 August 2026 (UTC)

Wish I had seen this before I wrote up my comments. I still struggle with a policy basis there; RD2 is the only acceptable non-OS to redact a log, and at a quick glance a decent percentage of those are RD3 that I don’t really think should be hidden. Not going to make a case of it, but I do see benefit to leaving some of those there in public to help with anti-abuse efforts. The RD2s that don’t rise to the level of OS seem reasonable enough, but imo, those really should be handled by a steward as a lock-hide and local RDing of logs doesn’t serve much purpose. TonyBallioni (talk) 06:32, 9 August 2026 (UTC)

The line between RD2 and RD3 has always been incredibly fuzzy. Most of those RD3 might as well be RD2s. -- zzuuzz ^(talk) 09:09, 9 August 2026 (UTC)

• Not to be the Debbie downer, but I don’t really see the benefit here. block-suppress is infrequently used because lock-suppress is such a stronger tool and it’s usually easiest to flag a steward. There are cases where block-suppress is useful, but those are the most extreme cases where it can’t even wait for a steward and damage control needs to be done now.
  What I’m struggling with is I can’t think of any example where I would want the account creation log and block log hidden if it doesn’t meet the suppression criteria. I don’t think there’s currently a policy basis for it. The log redaction policy is Log redaction (outside of the limited scope of RD#2 for the creation, move, and delete logs) is intended solely for grossly improper content, and is not permitted for ordinary matters. I don’t think there’s something that would meet that for blocking an account that isn’t already covered under the oversight policy.
  I think most people would agree that there would be no argument for keeping those usernames publicly visible, but they did not warrant suppression.
  I guess I’m not most people . I can’t think of a single reason I would support hiding an LTA username that isn’t suppressable. OS criteria 4 gives us this ability locally for attack usernames, and the other OS criteria gives it to us for libel and PII. Globally stewards don’t have to lock-suppress, they can lock-hide as well (unless that’s changed recently.) So what is the target of usernames were revdeling here where all logs need to be redacted? I’m just not seeing the purpose here or where this helps. I can also think of several potentially negative things that could come out of this, so I’d want to have a very strong reason to support first. TonyBallioni (talk) 06:06, 9 August 2026 (UTC)

  Perhaps this would be a good idea for spam/promo usernames? Not sure. Toadspike [Talk] 08:10, 9 August 2026 (UTC)

  TonyBallioni - Let's say that the option would redact the username from all edits and logs except for the block log, and it wouldn't hide the username from the list of users. Would that change your opinion on whether or not you'd think the option would be useful? ~Oshwah~^{(talk) (contribs)} 10:15, 9 August 2026 (UTC)

In that case I likely wouldn’t view it as a negative, but I’m not sure what it accomplishes that’s positive still, to be honest. There’s already a mass revdel script that gives more precision level control over these type of cases. I’m just not seeing this as a tool that could be both policy compliant and useful at the same time. TonyBallioni (talk) 11:59, 9 August 2026 (UTC)