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, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81

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)

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)

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)

Moratoriums

At the moment, explicit moratoriums are usually !voted on locally at the relevant article talk pages. I'd like to propose in an RfC that they only be initiated at WP:AN, and that people involved in the dispute label their !votes as such (like WP:CBAN). This is basically to serve as a check to prevent local capture of an article, and people involved in the dispute are poorly placed anyway to decide on whether there should be a moratorium and what length (similar reasoning to WP:INVOLVED). It also reduces the appearance of procedural weaponisation re people who've just 'won' a dispute locking in their preferred version. Trouble is, WP:MORATORIUM is currently part of an essay, and there are no mentions of "moratorium" or "moratoriums" in our PAGS. I'm not really seeing a good place to add it other than maybe WP:DE#Dealing with disruptive editors. Would be interested in hearing some thoughts (both about the proposal and the PAG issue) Kowal2701 (talk, contribs) 13:34, 5 July 2026 (UTC)

Honestly, after thinking about it, that actually sounds like an alright idea. Moratoriums are currently quite the grey area as they are essentially unregulated applications of local consensus, as there is no broad consensus to go off other than the basic ideas of WP:CONSENSUS, and it's unclear what the relation between WP:CCC and moratoriums are. It stands to reason a consensus can be formed to remove a moratorium just as one was formed to put one in place, but all of this is murky. I think giving them to AN is a good idea. They're rare enough that I don't think it would just be creating more paperwork for little to no benefit.

As for where to put information about it, uhhh.. good question. It would make sense at WP:CCC, but I hesitate to suggest clogging up a policy as central to Wikipedia as WP:CON with procedural information that is rarely relevant. Usually such info would just be placed at a page explaining the procedures of the process that the info pertains to, but moratoriums can come out of pretty much any formal discussion. That seems to leave a guideline as the best fit, and for that I think the options are WP:DE#Dealing with disruptive editors or outright making a short new guideline page. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 18:55, 5 July 2026 (UTC)

I've previously written about the value of what I called a revisit respite (see User:Isaacl/Community/Content dispute resolution toolbox § Revisit respite). As I think it's probably best done as part of an RfC about the underlying dispute, I'm not sure it would be efficient to restart conversation about a respite elsewhere. I do think it's probably a good idea to have a standard set of criteria for ending a respite period early. On my content dispute resolution toolbox page, I suggested that the closer of the discussion (or anyone to which they delegated responsibility) can decide if a significant new consideration has been introduced. (If none of the designated people are available, then a discussion at the administrators' noticeboard can decide.) isaacl (talk) 22:03, 5 July 2026 (UTC)

How widespread is the problem of moratoriums being imposed and enforced by a small group of editors like this? I encounter them almost exclusively on pages that have been subject to repeated, well-attended RMs proposing the same or nearly the same title in a short period of time. I more frequently encounter closing comments that suggest a moratorium be considered without imposing one, or the opposite case where the closer declines to impose one despite some editors requesting a moratorium. Maltazarian also states that moratoriums are rare. Requiring a separate discussion at AN on the heels of multiple disruptive WP:WALLOFTEXT repeat discussion prolongs the misery and is likely to generate more of the same counterproductive contributions and devolve into a rehash of the original problem. Moratoriums should be applied sparingly, and my sense is that they are. AN would be a good venue to request overturning a moratorium. —Myceteae‍🍄‍🟫 (talk) 00:30, 7 July 2026 (UTC)

The current forum for overturning a moratorium is Wikipedia:Move review. There was one overturned a few years ago in the Israel/Palestine topic area, and there is currently an open request to overturn one in the Wikipedia:GENSEX topic area. Why would AN be a better forum? Katzrockso (talk) 00:40, 7 July 2026 (UTC)

You're right, I agree it should generally be move review. I have participated in at least one MRV that was seeking to challenge a moratorium as a basis for a closure. I was thinking of what to do in a situation where it needs a wider audience, per the OP's concern about moratoriums only representing local consensus, but in my experience that's not been the case so there is no need to bypass MRV. —Myceteae‍🍄‍🟫 (talk) 01:05, 7 July 2026 (UTC)

Are moratoriums outside of Wikipedia:Requested moves really all that common? I know there are occasionally RfCs that say something along the lines of "until new sources arise" or "until something changes" but not explicit moratoriums. I'm not saying they don't happen, but do they happen at a frequency that explicit guidance is necessary? Katzrockso (talk) 01:44, 7 July 2026 (UTC)

I've only ever seen them applied to RMs, and then only a handful of times. —Myceteae‍🍄‍🟫 (talk) 14:11, 7 July 2026 (UTC)

They get applied to RfCs as well, but imo they shouldn't be happening at local talk pages at all because of the issues raised above (namely the optics, but the time length on some of them is extraordinary and that probably comes from it being decided by involved editors). I don't think MRV makes much sense since these aren't move discussions themselves? I'll list some recent non-RM discussions below (the most notable have been Talk:Zionism/Archive 35#Moratorium proposal and Talk:Gaza genocide/Archive 42#Moratorium proposal, ofc):

• Talk:Armenia#Moratorium proposed
• Talk:Donald Trump/Archive 48#Moratorium on infobox image
• Talk:Imane Khelif/Archive 5#Proposal: Moratorium on discussions related to Imane Khelif's gender
• Talk:Reform UK/Archive 5#End of moratorium?
• Talk:Taiwan/Archive 35#Moratorium on "is it a country"

Kowal2701 (talk, contribs) 14:35, 7 July 2026 (UTC)

Again, MRV is only the correct venue to challenge an RM that was closed with the imposition of a moratorium. If an RFC was closed with a moratorium, AN is the venue to challenge the close. I still see article talk pages as the best place to hold discussions about moratoriums related to the article's content. If there is concern about local consensus or ownership, neutrally worded notifications should be placed at appropriate venues. It may occasionally be appropriate to escalate the decision to AN but moratorium discussions should not start there as a matter of course, and editors should take care not to add fuel to the fire and to avoid the appearance or reality of forum shopping. —Myceteae‍🍄‍🟫 (talk) 14:56, 7 July 2026 (UTC)

none of the above discussions were part of an RfC themselves, they're all completely local discussions AFAICT Kowal2701 (talk, contribs) 15:02, 7 July 2026 (UTC)

And again, I find the talk page to be the correct venue for these. I've expressed my opinion about which types of discussions should go to which venues, a view which is consistent with our usual practice, and I've suggested approaches to bring in outside input. An additional approach would be starting a formal RFC is one has not been held (recently) on the matter. This would of course include widespread notification to various discussion boards, which is one of the strategies I suggested for any talk page discussion that would benefit from more perspectives. —Myceteae‍🍄‍🟫 (talk) 16:15, 7 July 2026 (UTC)

I'd be fine with moratoriums continuing to work as they currently do, but I still think Kowal is onto something with adding a line about it to the guidelines. It's a pretty significant measure and I think having some guidelines as to how it actually works is desirable considering it affects something as fundamental as having discussions. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 15:25, 7 July 2026 (UTC)

Maybe. I'm still not clear on what the guidance should be, and I disagree with the suggestion that only AN should impose them. Guidelines are, for the most part, supposed to be documentation of existing consensus. Consensus per this relatively small sample size of linked discussions and opinions appears to be that they should continue in the forums where they currently occur. I've suggested options to generate new eyes on a discussion, which can happen through the normal editorial process. Of course in practice, we often establish new consensus to invent new guidelines. I oppose the only suggestion that's been offered (that they only be initiated at WP:AN). —Myceteae‍🍄‍🟫 (talk) 16:02, 7 July 2026 (UTC)

I'm thinking at least something basic like "Where repeated relitigation of the same issue using the same arguments has become disruptive, a moratorium on further discussion can be imposed." and a wikilink WP:MORATORIUM, which can be turned into an explanatory essay. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 16:53, 7 July 2026 (UTC)

What problem does this solve? Moratoriums are used sparingly, which seems appropriate. —Myceteae‍🍄‍🟫 (talk) 17:09, 7 July 2026 (UTC)

The lack of information? I don't quite understand the point being made with the second sentence in that reply. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 17:30, 7 July 2026 (UTC)

I worry that making a vague reference to a little-used intervention with no real guidance might inspire more moratoriums and disputes about the practice. Just mentioning that the practice exists seems at best useless, arguably WP:CREEPy although there is no actual "instruction" given, and more likely to create problems than to help resolve them. —Myceteae‍🍄‍🟫 (talk) 17:46, 7 July 2026 (UTC)

How is it CREEPy? It's documenting 'best practice'. Limiting them to 6 months, rather than the ridiculous 12 months we sometimes see, would potentialy be CREEPy but an improvement imo. Kowal2701 (talk, contribs) 17:48, 7 July 2026 (UTC)

It's borderline CREEPy in spirit, in that adding more stuff guidelines is unhelpful unless they address recurring disputes and reflect widespread consensus. But we can forget CREEP and the rest of my objections still stand. The suggested addition is problematic either way. Vaguely waving at the existence of moratoriums without guidance (or "instruction") is unhelpful and imposing a bunch of guidance is a flawed approach to an occasional practice that is fundamentally a case-by-case determination arising from disputes particular to an article and its talk page. —Myceteae‍🍄‍🟫 (talk) 18:13, 7 July 2026 (UTC)

There is an instruction there, it tells you when moratoriums should be used. They are not for locking in consensus or in any situation where there have been many discussions, but only those that concern relitigation. It also, crucially, lets editors know that it exists as an option for dealing with issues, which we cannot assume they know, especially if they are new to Wikipedia and have not seen the rare moratorium in the wild before, which is currently how people learn about it (the essay on moratoriums not being linked anywhere in the PaGs as far as I know). –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 18:23, 7 July 2026 (UTC)

I agree that discussion of article content should remain in the most appropriate location for it, regardless of whether or not the participants are also discussing a revisit respite as one of the associated outcomes. (Matters specific to a page are best discussed on that page's talk page; matters affecting a general set of pages might be better discussed on an active WikiProject's talk page; matters affecting a broad set of pages might be better discussed at a village pump.) If broader input is needed for the discussion, then it's needed for all aspects, including the underlying content dispute, and appropriate notification or moving to a broader venue should be done for the whole thing. isaacl (talk) 16:15, 7 July 2026 (UTC)

For a page rename respite, sure. Other content revisit respites would have to be discussed elsewhere. Personally I think the talk page of the article in question should be the initial starting point. isaacl (talk) 01:34, 7 July 2026 (UTC)

If a moratorium was imposed as part of an RfC or really any other discussion on the talk page of an article, the forum for challenging a closure (which would implicitly include moratoriums) would indeed be WP:AN per WP:CLOSECHALLENGE Katzrockso (talk) 01:42, 7 July 2026 (UTC)

Sorry, I wasn't thinking about challenging the evaluation of consensus, but determining if the appropriate conditions had been met to end a revisit respite. isaacl (talk) 02:07, 7 July 2026 (UTC)

I agree that the correct forum for that would be the talk page. There were several discussions at Talk:X (social network) about the moratorium there (I believe here at AN and MR too). Katzrockso (talk) 02:37, 7 July 2026 (UTC)

I largely agree with both of you. I've struck my original statement that AN would generally be a good venue for these. AN should be reserved for challenging RFC closures and possibly other situations where talk page discussions have failed. Of course when a talk page or MRV discussion about a moratorium has descended into chaos that may in fact be confirmation that the topic is loaded and that the moratorium or respite should continue. In the case of X (social network) and several cases I've seen where there was no formal moratorium, a respite was ultimately beneficial to the cause. —Myceteae‍🍄‍🟫 (talk) 14:38, 7 July 2026 (UTC)

I like the idea of limiting moratorium-imposing discussions to well-trafficked central noticeboards. A moratorium intrinsically circumvents PAGs about consensus, like WP:Consensus can change, and it puts a procedural roadblock in front of editors who just want to see if consensus has changed. First they need to first gain consensus to overturn the moratorium, and only then to seek consensus on their change. That's basically an unsurmountable burden.

That's not to say we should never have a moratorium - I've supported at least one. Sometimes it's a valid way of dealing with a disruption without going after particular editors, and that's welcome, but they should still be applied sparingly and with scrutiny, and they should be explicitly provided for in PAGs. Apart from the AN location, and the 6-month limit (which I also like), one idea would be to codify when a moratorium might be lifted. E.g. if more editors want to lift it than participated in the discussion that imposed it. Samuelshraga (talk) 11:11, 9 July 2026 (UTC)

I don't see moratoriums as necessarily circumventing our PAGs. It's true that the practice is not described and it is certainly true that they can be implemented against the letter and spirit of PAGs. The second sentence at WP:CCC is: On the other hand, proposing to change a recently established consensus can be disruptive. WP:DISRUPTIVE and WP:GAMING are behavioral guidelines that characterize individual editor behavior related to repeatedly raising the same issue or trying to push a point of view against current/prior consensus. It's not unreasonable to extend the spirit of this guidance to say that the same or substantially similar repeat proposal by different editors can be disruptive. We have talk page banners like {{Consensus}}, {{FAQ}}, and {{Round in circles}} which are intended to limit repeat discussions. —Myceteae‍🍄‍🟫 (talk) 22:55, 9 July 2026 (UTC)

If the discussion is well advertised (e.g., as an RFC or at WP:CENT), then I don't think the location of the discussion is important. We all know how to click a link and join a discussion. Anyone concerned about a discussion needing more eyes should be advertising it by following the usual advice in (e.g.,) Wikipedia:Requests for comment#Publicizing RfCs and Wikipedia:Canvassing#Appropriate notification.

I also think there should be some distinction made between the 'ordinary' moratorium on repetitive discussions about article titles and the rarer instances involving other subjects (e.g., which image should be in the infobox). Looking around for instances of non-move moratoriums last year, I found Talk:Zionism/Archive 35#Moratorium proposal and Talk:Reform UK/Archive 3 and Talk:Republican Party (United States)/Archive 37#Moratorium. There were a few non-move-related comments that talked about a moratorium, such as Talk:Canada/Archive 34#Speaking of the coat of arms and Talk:Christopher Columbus/Archive 19#RFC: Use of "Italians" in the article, but these generally did not gain support. Mostly they were about contentious political content (e.g., should we label this political party "far right"?). WhatamIdoing (talk) 17:08, 15 July 2026 (UTC)

What pattern(s) are you seeing in the non-move moratorium discussions that differentiate them from the move discussions? How would the distinction be described and what guidelines would apply differently? I did a quick scan of a few that you linked, so I likely missed details, but at least superficially they look similar to move moratorium discussions I have seen and participated in. Sometimes moratoriums are proposed and get little support, and sometimes they are imposed. Repetitive proposals to change the article title or change a word or phrase used in the body strike me as being more similar than not. I do agree that notification/advertisement matters more than venue if the concern is getting representative participation. Most article content discussions should live on that article's talk page, but of course there are exceptions. —Myceteae‍🍄‍🟫 (talk) 18:36, 15 July 2026 (UTC)

I think that frequent, repetitive proposals are the main trigger, though since personal tolerance levels vary, sometimes repetitive means "the second time in Wikipedia's entire history that someone has suggested this" and frequent means "every few years".

Mostly, the non-move discussions were along the lines of the discussions I linked:

• political labels (e.g., should the infobox say this group is far-right?),
• highly contentious content that realistically isn't going to be changed, no matter how much it's discussed (e.g., proponents of Zionism on their ideal boundaries for Israel), and
• someone's personal pet project/pet peeve (e.g., adding/removing a coat of arms).

They are mostly political in some way, and they're mostly reasonable-ish but rejected proposals. For example, there are a lot of discussions that amount to "I read something that called this political organization 'far-right' this morning, so I think we should say far-right in the infobox", followed by the OP being surprised when everyone yells at him.

If I were to give advice on the subject, I'd suggest:

• A moratorium should almost never be for longer than six months.
  • Logical conclusion: Imposing a moratorium on a subject that is naturally being discussed less often than once every six months is a waste of time.
  • Putting that in practice: I'd suggest that no such discussion be started unless it can be proved, with links, that a significant discussion on the same point has happened at least three times during the previous 12 months. For comparison, a newbie saying "How about we remove every instance of the word woman in the article Pregnancy?" followed by one or two experienced editors saying "No" isn't a significant, moratorium-worthy discussion.
• Any decision, including a moratorium, can be overturned by consensus because we have Wikipedia:No binding decisions by policy, so if we're going to impose one, it should have a strong consensus behind it. I'd recommend an RFC.
  • Putting that in practice: Since the median RFC gets (if memory serves) nine editors commenting, a discussion imposing a moratorium should probably have a minimum of 10 participants.
• Before proposing a moratorium, editors should consider posting a {{FAQ}} at the top of the page about perennial proposals.
  • A neutral way to say this might sound like "Prior discussions have decided to _____. Before proposing a change, you should read and be prepared to address the concerns raised in the past discussions such as [link], [link], [link]" or "This page says 'right' instead of 'far-right' because that's what most sources say. Editors are unlikely to support a change unless you can provide multiple, high-quality sources that address the subject directly (e.g., peer-reviewed scholarly papers whose main subject is how to classify this political group) or evidence that 'far-right' has become the most common description in mainstream media, rather than an occasional or qualified claim used by a small minority of sources."

WhatamIdoing (talk) 19:51, 15 July 2026 (UTC)

I agree with a lot of this. Overall, I think much of this pattern is similar at RM. Editors should use a variety of strategies, instead of and in addition to moratoria, to limit disruptive discussions. At Talk:Sean Combs there is currently a one-year moratorium on RMs and the page makes good use of {{FAQ}} in addition to the {{Old moves}} template. I find this to be a good example, but also an outlier due to the sheer number of proposals in calendar year 2025, during with Diddy was very much in the news. —Myceteae‍🍄‍🟫 (talk) 18:00, 19 July 2026 (UTC)

Also, I've already said this, but a moratorium, which is by definition temporary, is not at odds with WP:No binding decision (aka WP:CCC). We're all in agreement that they should be used sparingly. —Myceteae‍🍄‍🟫 (talk) 18:03, 19 July 2026 (UTC)

I think that having discussions about whether to overturn a moratorium would be just as disruptive as having the discussion about the point of the moratorium. If we have an "obvious consensus" (i.e., a fairly large number of people firmly agreeing), then I think we're more likely to get people to just wait out the temporary situation rather than opening a discussion about whether they should overturn the moratorium so they can have another discussion. WhatamIdoing (talk) 19:18, 19 July 2026 (UTC)

That's going to be fine in most cases, but what happens when (someone thinks) there has been a very significant real-world change that means the previous consensuses might not still hold? When change is major and unambiguously relevant very few people will object to just ignoring the moratorium, and in cases where it's unambiguously trivial to nearly everyone then that's the point of the moratorium and attempts to ignore it will be quickly shut down. However what happens with the significance is not clear, there needs to be some method of discussing whether it is or not, independent of whether to move or not move. Thryduulf (talk) 21:18, 19 July 2026 (UTC)

I agree. We could have a moratorium on changing the first sentence of an article, but what if the subject dies during the moratorium?

That's why I suggest that any moratorium that is imposed should be done so with an obviously strong consensus. A strong consensus should discourage people from trying to overturn it under ordinary circumstances but still leave that as a realistic possibility under extraordinary circumstances. WhatamIdoing (talk) 22:53, 19 July 2026 (UTC)

I just think that the legitimacy of a moratorium which is enacted by the 'winners' of a dispute is always going to be protested, imo it should be enacted by those uninvolved in the dispute, whether through RfC, AN, or MR idm Kowal2701 (talk, contribs) 22:58, 19 July 2026 (UTC)

@WhatamIdoing that all works fine when it's clear whether the change in circumstances is unambiguously significant or trivial, but still doesn't address situations where it isn't clear one way or the other. Thryduulf (talk) 23:50, 19 July 2026 (UTC)

>I think that having discussions about whether to overturn a moratorium would be just as disruptive as having the discussion about the point of the moratorium.

>However what happens with the significance is not clear, there needs to be some method of discussing whether it is or not, independent of whether to move or not move.

I've seen this go one of three ways a majority of the time. Either the meta-discussion about whether or not there is a significant change proceeds with little controversy, or it is quickly shut down without much controversy, or it erupts into yet another disruptive and repetitive discussion. I've seen folks go ahead and launch the repeat RM (or RFC or whatever), in apparent violation of the moratorium, by making an explicit argument as to why they think the situation has changed, and let editors hash out there. None of these are super common, since moratoriums aren't that common in the first place. I don't know that there is a one-size-fits-all approach to addressing these. I have seen at least once instance, I think at Talk:X (social network), where a subpage was created specifically to workshop a fresh RM proposal once the moratorium was lifted. This approach has downsides but I thought it was productive to allow for a thorough "BEFORE" while segregating the discussion from the main page. —Myceteae‍🍄‍🟫 (talk) 23:00, 19 July 2026 (UTC)

Here's a fresh example where a moratorium was proposed at RM, did not gain consensus, and it was ultimately not imposed: Talk:Myocardial infarction#Requested move 10 July 2026. —Myceteae‍🍄‍🟫 (talk) 17:50, 19 July 2026 (UTC)

Retention of editors who've been caught using LLMs

Often what happens is a newbie will add LLM-generated content to the wiki, eventually get 'caught', and reported at AINB. Best case scenario they own up, cleanup after themselves, and go on to be productive, but this is very rare (best you can hope for is that they own up and stop using LLMs). But if they ignore a warning or avoid giving a question a straight answer, they'll often end up blocked, and criticising or removing someone's contribs is a sure-fire way to discourage them. Obv editors at AINB try to avoid biting, but patience wears thin such that people rarely have the energy to patiently and compassionately explain and spell things out over many comments, and cushion what's a pretty terrible experience (there is also the odd blatantly-disingenuous editor who wastes everyone's time and exhausts patience). Most often, if a newbie is reported to AINB, they'll stop editing or get blocked.

Longshot, but what would be ideal imo would be if there were a handful of editors who focussed on retaining good-faith newbies reported to AINB (allowing others to focus on cleanup), which'd probably involve what I said above about explaining and basically being a friend, helping/supporting them to cleanup their previous contribs (rather than someone else nuking them), pointing them to a Wikipedia in their native language, maybe even mentoring. A bit like what CoffeeCrumbs and Blue Sonnet do at ANI. Worth saying that the current proposal to make VE the default editor would help a lot with this type of thing, but idk if this might be worth exploring? Kowal2701 (talk, contribs) 18:47, 7 July 2026 (UTC)

notified WP:WER, WP:MENTOR, WT:AIC Kowal2701 (talk, contribs) 18:47, 7 July 2026 (UTC)

This is an interesting idea. I would like to see these users become productive. Would it be possible to get insight from users who have been found to use AI, apologized, and become regular editors? SenshiSun (talk) 19:00, 7 July 2026 (UTC)

honestly it's so rare, but there have been a few times where a regular editor has been brought to AINB for past AI use. The only person I can think of is CostalCal (hope you don't mind being pinged), most editors who apologise stop editing. But for example there are several with great potential, like User:Michelle904 atm Kowal2701 (talk, contribs) 19:28, 7 July 2026 (UTC)

I'm aware of a handful of users like this, Aldorwyn of Rivendell is worth mentioning here. ‑‑gurkubondinn 17:28, 8 July 2026 (UTC)

for some examples there's AlferedNobel who was carrying out much needed WP:SPLITs but generating the leads (last edited 9 June), Tired Carrot attempting cleanup (last edited 24 June), several more Kowal2701 (talk, contribs) 20:01, 7 July 2026 (UTC)

also Boomgaarden93 Kowal2701 (talk, contribs) 20:59, 7 July 2026 (UTC)

PeepeeDino has been doing some cleanup as well Gnomingstuff (talk) 20:01, 7 July 2026 (UTC)

PeepeeDino deserves a statue, I'll go make a wish Kowal2701 (talk, contribs) 21:01, 7 July 2026 (UTC)

I definitely like this idea! Anything that focuses on editor rehabilitation is a big plus in my book. I'm not sure if we need it to be a formal program or not: bureaucracy can be daunting, but a light-weight think like a "this user helps former AI-using editors" userbox, or a mentor list with an invitation to get in touch, could go a long way. Chaotic Enby (in solidarity · talk · contribs) 19:43, 7 July 2026 (UTC)

This might be a being a good use case for this Mentorship feature: Wikipedia:Mentorship#How can I select mentees, instead of having them randomly assigned to me? -- KStoller-WMF (talk) 23:11, 7 July 2026 (UTC)

If the mode of operation is intended to be that the editor has to contact the mentor for more guidance, then I don't favour getting them to switch mentors. Based on anecdotal data, the biggest hurdle with the mentoring initiative is just making that initial contact, so I'd rather not ask them to switch mentors, and in any case, I hope that any mentor will be able to give them appropriate guidance.

That being said, if we do want to have a specialized "AI-free retention team" (or some other catchy name), I think for it to be effective, it would have to reach out to the editors in question. On top of the usual reticence editors have shown regarding contacting their mentors, these editors have just been told that their writing approach isn't accepted on English Wikipedia, which I think is going to make them even more hesitent to contact anyone. isaacl (talk) 01:44, 8 July 2026 (UTC)

these editors have just been told that their writing approach isn't accepted on English Wikipedia

Then it is their responsibility to suck it up and deal with it. We don't do this for anything else. "It's OK poor baby you can have a little spam as a treat"? Gnomingstuff (talk) 01:59, 8 July 2026 (UTC)

@Gnomingstuff I find that attitude disgusting tbh (that's a strong word, I think it is appropriate here). There are many people who use AI in daily life, for many different reasons, and simply won't have thought about whether we do or do not allow it. Our goal should always be to try and convert potential editors into actual good-faith editors who understand and follow our rules and culture, but to do that we need to accept that not everybody gets that right first time and need a second chance. Nobody is suggesting this is applied to spammers or similar, but to editors about who we have no reason not to assume good faith. Thryduulf (talk) 02:07, 8 July 2026 (UTC)

It's not assuming bad faith to expect people to actually follow the guidelines. Their "writing approach" isn't accepted here, and if they can't accept that, they 'shouldn't be here and we do not need to bend over backward to accommodate their inability to deal with the fact that they don't get to do whatever they want. Gnomingstuff (talk) 02:12, 8 July 2026 (UTC)

Put another way, assuming good faith is not banning someone immediately for breaking guidelines they may not know about. But once they do know what the guidelines are, then a prerequsite for them being here is that they deal with the fact that yes, they have to follow them. Gnomingstuff (talk) 02:17, 8 July 2026 (UTC)

but to do that we need to accept that not everybody gets that right first time and need a second chance. Yes, that is the entire point of this thread. Gnomingstuff's suggestion only rewords the original premise of giving them a second chance to learn and follow our policies (instead of a full exemption from them), and calling it "disgusting" is blatantly out of line, especially since there isn't even much difference in approach between the two of you. Chaotic Enby (in solidarity · talk · contribs) 20:02, 8 July 2026 (UTC)

Once upon a time, I wrote that ideally we would figure out which new editors show promise and which do not, and spend more time trying to help those who show promise. I don't think we should waste time on those who don't show promise, whether that is because they really want to use program-generated text, or have other disagreements with following community norms, such as English Wikipedia's standards for having an article or the due weight guidance. (I am, though, somewhat more hardline than established community consensus on how quickly we should be showing editors the door, and on how permanent the exit should be.) On the flip side, if an editor does show promise, I think it's worth some effort to nurture that potential. isaacl (talk) 02:29, 8 July 2026 (UTC)

I think that's the biggest issue. I'm fairly new myself, but I see a huge amount of time and resources wasted dealing with what essentially amounts to vandalism (broadly construed - whether intentional or not) by new accounts who are some combination of clueless, self promotional, POV pushing, UPI, socking, and frequently using AI to achieve their ends. Many seem to have no remorse and no interest in editing without using it, and the ones who truly had no idea are often incapable of editing competently on their own even if they wanted to. Obviously there are exceptions, but it's easy to get discouraged by making an honest effort to help people who don't want it, so to avoid even more wasted time I think it would have to be up to the editor involved to reach out if they do. Maybe the AI warning template could include an additional link to do so.

I understand why others are concerned about scaring off new editors, but honestly it's the amount of behind the scenes drama - that included - that's made me hesitant to get more involved. I think too much WP:ROPE is often given, and the community would be better served by stricter protocols for bad actors so more resources can be focused on supporting editors who truly are here to make valuable contributions. On the technical side, maybe a more extensive new user walk through (including what not to do) would help show those who are here in good faith how to get started on the right foot, and also minimize plausible deniability for violations. ChompyTheGogoat (talk) 06:32, 9 July 2026 (UTC)

For better or worse, everyone draws their own line when deciding how to best spend their time. Personally, I'm not interested in reaching out to anyone who doesn't seem amenable to feedback and willing to collaborate. Others are more willing to offer assistance to new editors based on a lower threshold of promise. As English Wikipedia's strength is a diversity of editors working together towards common goals, the community has generally been reluctant to impose rules on how volunteers choose to work with others. Although I think having more general guidance on signs of promise might be helpful for some editors, I think that's probably a very limited audience. I suspect most experienced editors will continue to rely on their own instinct regarding how to proceed. isaacl (talk) 16:41, 9 July 2026 (UTC)

Yes, I didn't mean to imply any strict rules, just putting more onus on the violator in terms of how things are structured. Mentors could still jump in at any time if they think they can be helpful; plenty of people already do so outside the formal mentorship program. I do think that more automation would be helpful, such as the walkthrough - more tools that can help new users understand the basics and common issues, with the opportunity to reach out for clarification if they need it. You can find help pretty much anywhere as long as you're asking in good faith; even if it's in a completely unrelated location there's a good chance someone will stumble on it and either try to answer or direct you to a better venue. Anyone who's interested in learning and being a constructive contributor can do so, but they have to be willing to make SOME effort. That could help them be less intimidated and not feel like they're nagging, while also optimizing the time of volunteers to help those who are truly interested in contributing and willing to work within established guidelines. ChompyTheGogoat (talk) 19:11, 9 July 2026 (UTC)

Like the idea a lot (but am 100% not remotely the right person to do it, respect to those who are)

The main issues I can think of:

• How to actually link people up, since by default someone whose article got flagged is going to be communicating with the person who flagged the article. The uw-ai template currently directs people to the talk page of whoever used it.
• The thing about "someone else nuking them" is that it gets harder to fix AI stuff the longer it sits around, and the most expedient way of making the encyclopedia better is to just fix it. I don't really think we should let things sit around to prevent hurting people's feelings.

Gnomingstuff (talk) 20:11, 7 July 2026 (UTC)

Hopefully better than me; my success rate of talking LLM editors off their position is depressingly low. CoffeeCrumbs (talk) 21:16, 7 July 2026 (UTC)

I think this is a nice idea. Chaotic Enby has some good suggestions for how his could operate. I confess I'm not optimistic about the prospects, but I'd be happy to be proven wrong. —Myceteae‍🍄‍🟫 (talk) 21:33, 7 July 2026 (UTC)

Thanks so much for this. My recent discussion at Wikipedia:Writing articles with large language models was prompted (so to speak) by how we were responding to a newbie. I’m not sure how to help but I’ll try to pitch in where I can. It might be helpful to create a form asking why the newbie decided to use an LLM. Just one thought but I’ll follow along. Thanks so much. Dw31415 (talk) 22:21, 7 July 2026 (UTC)

You could be forgiving towards them, but there is little hope: once one is used to LLMs doing the thinking for them, they are lost. tgeorgescu (talk) 02:53, 8 July 2026 (UTC)

I think there's some hope for the ones who just use it to try to clean up their own writing, but at the end of the day if they can't write an article they can't write an article. ChompyTheGogoat (talk) 06:36, 9 July 2026 (UTC)

possibly; there was an instance a week or so ago where someone was doing a bunch of AI copyedits (actually localized rewrites) that had the usual issues that they always do, they said that they don't know how to copyedit stuff without AI, and though I didn't say this to them, my reaction was "...then learn? nothing's stopping you from learning."

like, I don't know what to say here. I probably couldn't contribute to something like the Linux kernel without using Claude, and as a result I simply... don't contribute to the Linux kernel. if I really wanted to I could study low-level programming, but otherwise it is not within my skillset. it's very possible to either improve one's skills or accept one's limitations, and lowering standards to accommodate people who won't is just infantilizing them. Gnomingstuff (talk) 14:20, 9 July 2026 (UTC)

it's very possible to either improve one's skills or accept one's limitations, and lowering standards to accommodate people who won't is just infantilizing them. this, so much. There's things we can do to help people get where they need to be, but we can only do that if they want to get there. -- LWG ^{talk (VOPOV)} 14:52, 9 July 2026 (UTC)

Yes, that's what I was getting at. Learning to use the tools here is one thing, but if they don't have the English skills to fix spelling and grammar on their own, that's not really our problem, and they shouldn't be trying to improve the work of others if they aren't willing to improve their own abilities. Old school spellchecks just helped us FIND minor errors that our brains might miss, and suggest the correct version without having to look it up in a dictionary - they didn't try to think for us, and if you didn't have said English skills the end result would still be poor. ChompyTheGogoat (talk) 19:19, 9 July 2026 (UTC)

As far as article creation or adding significant new content to existing ones, I think it could be helpful if there was somewhere that's easier to collaborate - people who understand the subject and can write well enough to be understood but not on par for an encyclopedia could present their content for others to help with copyediting and formatting. That might help them feel like they're contributing without feeling the pressure to use automation to get it where it needs to be for live articles. Some sort of draft workshop area. ChompyTheGogoat (talk) 19:25, 9 July 2026 (UTC)

Article talk pages are where users can seek help with contributing to a specific article. (Although its name matches your inquiry, the Draft namespace isn't a good place to look for help, as it's unlikely someone with the corresponding set of interests will find it (or, really, anyone at all; I only know of one editor who used to go through the Draft namespace looking for articles to assist on, and they stopped.) If you've already found a group of interested editors, though, then you could collectively choose to use the Draft namespace.) isaacl (talk) 02:21, 10 July 2026 (UTC)

That's kind of my point - it might be useful to have a place specifically to ask for that kind of help, especially on things like drafts that might require significant back and forth before being ready for mainspace. As of now it usually seems to result in a repetitive cycle of AfC submission where editors don't really understand the brief advice given by reviewers, and both parties get increasingly frustrated. A collective list of drafts or extensive edits that people are asking for help with, grouped by category, would provide them with more resources to make constructive improvements and help volunteers interested in that kind of work find them more easily, instead of just stumbling across them. Face (sociological concept) has also been mentioned in other comments, and I think this collaborative approach would help in that regard, whereas having drafts declined or major changes made by someone they didn't approach for help can feel insulting, and many ESL editors turn to LLMs specifically for that reason. ChompyTheGogoat (talk) 02:51, 10 July 2026 (UTC)

I'm not sure I understand your point. Talk pages for related pages or associated active WikiProjects are already used for this purpose, and of course you can always ask your assigned mentor for assistance. isaacl (talk) 04:41, 10 July 2026 (UTC)

WikiProjects which are often defunct (or nearly so), and mentors who may not have knowledge in the subject matter or the inclination to spend a lot of time helping one on one with specific tasks. I'm picturing a centralized location with a sorted list of requests, along the lines of how AfC is set up. People could post the link to the article (whether draft or mainspace) with a brief description of what kind of help they're looking for (copyedit, formatting, citations, etc) and add sorting categories. For proposed changes to live articles they could also link to a temporary copy in their sandbox or maybe another subpage. Volunteers can then look through the lists for ones they're interested in helping with, and ideally continue assisting until they either think it's ready to publish or that they can't be of more help (for whatever reason) - more of a temporary partnership instead of doing drive-by edits/suggestions.

It could also be useful for more experienced editors who are trying to find help with something specific, but they usually have a better idea of where they can ask than newbies do. It might be helpful to add a link to it in AfC decline notices, although I could easily see it getting clogged up by a bunch of WP:SNOWBALL requests, so maybe at reviewer discretion when they think a draft shows promise. Plus expirations for requests unless manually renewed so abandoned ones get cleared out.

I don't have either the experience or technical ability to handle any of this, just ideas. Would take a good deal of workshopping to come up with a viable proposal. ChompyTheGogoat (talk) 05:26, 10 July 2026 (UTC)

The best way to reach interested editors is to post on pages they're already watching, rather than trying to get all editors to watch some new location. Mentors aren't expected to knkow everything, but they can help point you to the right place to look for help (such as finding appropriate article or WikiProject talk pages). The anecdotal feedback I've read is that mentors get very few actual questions and even fewer responses, so they have capacity to do what they've signed up for: to engage in dialogue to help their assigned users. isaacl (talk) 06:07, 10 July 2026 (UTC)

Not ALL editors - ones specifically interested in that kind of work, like I said. How are new users supposed to know which pages the people who might be able to help them are already watching? (I already alluded to that when I mentioned experienced editors in need of specific help who CAN do so, by the by). I haven't reached out to my own mentor and in fact I'm not even sure who it is, because I found the Teahouse a more helpful venue for most questions - I can ask a group of volunteers, who go there by choice for that purpose, and likely receive an answer quickly, instead of bothering one individual who may or may not know the answer in the first place and not knowing when they might respond. Additionally, the Teahouse is more public so I feel like other people can benefit from the questions there too. I certainly have, and it gets plenty of traffic. I'd consider that a successful implementation of a newbie tool.

All the same logic applies to improving content as well. WikiProjects were an attempt to increase collaboration by subject matter, but they appear to have largely failed - I also dropped a question in one shortly after joining, which was subsequently archived with no response. (Conversely, my Teahouse questions are often answered in minutes - hours at the most.) Centralizing it this way would allow people to peruse a wider range of requests they might at least be competent at helping with, even if it's not a special interest they'd specifically seek out.

And it's entirely possible this might end up failing too, as is true of any new idea, but if you were to poll new users I suspect an awful lot of them would find something like this helpful. I've managed to muddle through, but I have relevant experience in other forms of content creation (and moderation), a high capacity for self teaching, and countless hours over 25 years spent reading content that's built on the guidelines I'm now learning about. All of that has made it easier to overcome a not-insignificant learning curve, but I'm not surprised that many find it insurmountable. Assuming attracting and retaining new editors is still considered desirable I think people have to at least be open to the idea of doing so in new ways, instead of just saying "screw them if they can't figure out the existing tools". A lot of the structure here is fairly antiquated compared to most of the modern internet, so for younger editors especially things that make sense to those who've been here for years might not seem obvious, and a bit of initial hand holding seems worth it for those who do have the potential to become productive contributors. (As I've also mentioned elsewhere, differentiating those to avoid wasting time on ones who don't is a very real concern, and adding structure and tools that require initiative but not technical ability is s good way to so at a global level.) ChompyTheGogoat (talk) 08:29, 10 July 2026 (UTC)

The editors most interested in helping others are generally mentors and those participating at the Teahouse (sorry, I forgot to mention it earlier). (See Wikipedia:Mentorship for how to find out more about your assigned mentor.) Buddying new organization members with an experienced one to help them out with their questions is a common approach. I think this type of personalized interaction is a better fit for most people than adding a request to a queue, which will only get processed if enough interested editors can be found to watch and sift through yet another queue. isaacl (talk) 17:00, 10 July 2026 (UTC)

I'm not proposing that it replace mentorship, only supplement it as a different place to request a certain kind of help - just like Teahouse does. If it's the same editors finding more ways to help out that's still a win. We have be editors that help out in AfC, AfD, NPP, and plenty of other places - not just one or another, because they all serve different purposes and people can pick and choose where they feel the most useful. Teahouse is great, but it's mostly for brief questions that can be handled in a couple messages, not teaming up towards an end goal. And as already discussed mentors may not have the skillset to help with specific requests - in those cases all they can do is guide the user into posting to ask for help elsewhere, and we'd be streamlining that while encouraging more to ask in the first place. This isn't Ye Olde Small Business where you can stay with them on their first day, show them around the building, and introduce them to Bob the ESL guy who helps with translation requests and Jill who's the office citation guru. Shepherding this many people - especially clueless newbies - requires structure.

Your overall objections seem to be that the existing tools work fine (they don't), and that anything new is doomed to failure so why even try. ChompyTheGogoat (talk) 17:35, 10 July 2026 (UTC)

No, that's not a correct interpretation. The top problem with any new initiative is getting volunteers to participate on an ongoing basis. I'm not optimistic that a new page where editors can ask for help will be any more successful at attracting participants than the existing methods. I also don't see why the new page would attract editors more able to direct users to the right places to seek help than their mentors can. I'm raising these concerns because any attempts to try something new should consider how the new approach will address the problem in question, and how it will engage volunteers to participate. Mentors aren't just used in mom-and-pop businesses; large tech companies use them because it gives people a starting point in their support network and provides real-time personalized support on what help is immediately needed. English Wikipedia has had help venues for a long time, so creating a new page is more of same-old, same-old, than trying to further improve the mentorship network, which is fairly new. isaacl (talk) 21:37, 10 July 2026 (UTC)

But that WOULD be the right place - volunteers would reach out if they're interested in helping with the request directly, not to tell the editor to go somewhere else and ask the same thing. That's kind of my point. They would hopefully help see it across the finish line if it's viable, unless they run up against something specific that's outside of their knowledge base and need to loop in a third party, plus they could maybe have better luck convincing editors to drop drafts that aren't going to get anywhere than a canned AfC decline notice does.

Wikipedia has other help venues THAT MOST NEWBIES CAN'T FIND OR USE (at least not correctly). They're reluctant to ask mentors for all the reasons I've stated, which is a known problem just like wikiprojects and newcomer tasks are. Teahouse is successful. If we want new tools to be successful, we should look at existing ones that are and try to replicate what makes them work. And again, I'm not saying we replace mentorship. If the user DOES ask their mentor, and the mentor doesn't have the time or requisite knowledge to help out themselves, they could help set up the request in such a way that it's likely to get seen - but the tool itself needs to be user friendly enough for newbies who don't have assistance to fill it out themselves. ChompyTheGogoat (talk) 22:08, 10 July 2026 (UTC)

I appreciate you think that the editors that need help and the right volunteers to help them will find their way to this new page you propose, and that for some reason, it won't face the same limitations that existing pages and methods face. Personally, I think that anyone implementing this proposed initiative will have to think of ways to make this happen, rather than assuming it will. isaacl (talk) 22:24, 10 July 2026 (UTC)

I don't have the technical ability for implementation, but I'm more than willing to continue workshopping the overall concept. Obvious links that new users can find easily would definitely need to be a priority, because that's one of the biggest issues right now. There's no introduction process; no FAQ, no obvious sources for help, just kicked loose after account creation. Akin to the other thread regarding a walkthrough on first edit, there could be a pop-up the first time a user goes to create a new article: "New to writing articles? Ask for help here!" Plus experienced editors linking to it regularly via declines and anywhere else they think someone needs a hand. They still need to decide to actually go there and look for things to help with if they want to do so, but if links are scattered around for newbie access that would help keep it on other people's minds. There could also be a "Ways to help out" link repository for that and all the other processes that require volunteers with experience. Flatly put, there's no real structure to the back end of the site, and I've found most places like this by stumbling from one random link to another. If I don't remember where something is I have to dig through vague searches. It's honestly kind of a mess, but long term editors don't think anything of it because that was par for the course when WP was created. ChompyTheGogoat (talk) 16:50, 11 July 2026 (UTC)

It's a weakness of English Wikipedia's consensus-based decision-making tradition: it doesn't scale up well beyond a handful of participants, which stalemates major changes from being agreed upon. Thus it's very hard to get consensus support for workflow changes that affect the user interface. That being said, I think many editors agree with improved support for new users, so I think there could be a path for introducing more guided walkthroughs. isaacl (talk) 17:39, 11 July 2026 (UTC)

Yeah, that's kind of what I was getting at. Most people recognize that new editors are needed, but object to any significant changes aimed at accomplishing it. Growing pains are a necessary aspect of progress. Making it optional and easy to opt out - like swapping between visual and source editor - is helpful, but it's important that enough experienced editors utilize the tools so they can answer questions about them. ChompyTheGogoat (talk) 02:40, 12 July 2026 (UTC)

I don't think there's a blanket objection; the problem is that different editors have different ideas about what changes to make. Walkthroughs can be made optional and so I think have a greater chance of getting implemented. isaacl (talk) 02:51, 12 July 2026 (UTC)

This is entirely optional too. No one is forced to either ask for or provide help. ChompyTheGogoat (talk) 04:11, 12 July 2026 (UTC)

I was following up on the subsequent thread regarding workflow changes. I don't think there's anything new for us to discuss regarding your idea for a different help venue. isaacl (talk) 07:09, 12 July 2026 (UTC)

I don't think I suggested any significant changes in that regard - just the pop-up on first article creation. A link repository and/or overall site directory shouldn't change anything that currently exists either. I'm mainly trying to think of additions that will make life easier for new users (and probably some experienced ones too), without putting up roadblocks for those who have been editing productively for years - the last thing we want to do is run those off! I don't think closing out a pop-up if they decided to edit from a new account or TA is too much of an imposition. If there's something specific I mentioned and am forgetting that you think would cause such issues, let me know. ChompyTheGogoat (talk) 07:34, 12 July 2026 (UTC)

I think we're talking at cross-purposes. My comments were on the theme of improving user workflows to support them in becoming more productive. I'm not trying to be your sounding board. isaacl (talk) 09:43, 12 July 2026 (UTC)

They're reluctant to ask mentors for all the reasons I've stated @ChompyTheGogoat would you mind summarising / relisting the reasons you think that new editors are reluctant to ask mentors for help? What I can see from the thread above is that you think that mentors might not know the answer (which may be true), and so some different avenue for seeking help is needed, but I don't think new editors are going to think "My mentor won't know the answer so I'm not going to ask". I ask the question as an active mentor who would be very keen to engage in more substantive assistance to my mentees, were they only to ask! Cheers, SunloungerFrog (talk) 17:26, 11 July 2026 (UTC)

They might not respond quickly (I don't expect them to be available at all hours, and if our schedules don't line up it could be prolonged back and forth to figure something out), plus I don't want to feel like I'm bothering them by leaving TP messages for every little "Why did I get an error" "What does this tag do" question. Places like the Teahouse allow anyone who feels like it to respond at any time, with no pressure, and since it's more public other people can learn from the answer too. I spend lots of time there skimming other questions - sometimes answering ones I know (which may involve additional reading to ensure I'm linking the appropriate shortcut), sometimes asking additional follow-ups. I think it's really helped a lot with the learning curve, and I feel something similar where I could peek in at the article creation process between another newbie and an experienced mentor assisting them would help similarly. Instead of just digging through edit history I could watch the talk page discussion where things are being explained, so it would help more people than just the newbie who's making the article.

Occasionally I'll also drop a follow up question on the TP of various experienced editors who were already involved in a discussion somewhere, when I don't want to derail the original conversation.

If I didn't have those options I probably would have hit up my mentor, but in most cases I already have an answer (sometimes more than one) before I'd expect an individual to respond anyway. If there was an easy way to crosspost that could be useful - then my mentor would know I have a question and can respond publicly if they're available, but so can anyone else. ChompyTheGogoat (talk) 02:31, 12 July 2026 (UTC)

Notified: Wikipedia:Mentorship noticeboard. —ClaudineChionh (she/her · talk · email) 03:26, 8 July 2026 (UTC)

Thank you for bringing this up! I do believe there's good potential to guide some editors using LLMs to contribute more constructively. WikiEdu's experience is really informative - they were struggling with lots of student editors using LLMs too heavily, and they found that training students on the right way to use LLMs with Wikipedia helped. Their training is clear and helpful: https://dashboard.wikiedu.org/training/students/generative-ai. I'm imagining: what if the standard warning templates for AI usage could offer a link to some kind of interactive online training to editors using LLMs, maybe even including short helpful videos, rather than just links to guidelines? (What if our policy/guideline pages offered videos where a friendly editor explains key points, as explanatory supplements, in general?!) Dreamyshade (talk) 04:29, 8 July 2026 (UTC)

we have WP:LLMRESP which I added to NOLLM with this in mind, I think expanding that essay to serve as that would be really good Kowal2701 (talk, contribs) 08:07, 8 July 2026 (UTC)

I understand what you're getting at, but I'm afraid that mention of a "right way" to use AI without direct oversight (as they have in a class) would just lead to more people asserting that their way IS the right way - and if they lack either the attention span or reading comprehension to grasp text guidelines, they're probably not going to do well here. ChompyTheGogoat (talk) 04:35, 10 July 2026 (UTC)

I’ve started to follow AINB. Wow. I’m impressed at the dedication of @Gnomingstuff and others in combating slop. One immediate idea/thought is that we should use more of a template for these discussions because I think that will help depersonalize the discussion (I’m thinking like Wikipedia:Bots/Requests for approval or Wikipedia:Dispute resolution). A bot also might be helpful ( /SlopBot please help me review user123 ) which would prepare the template and facilitate tagging edits. This is a good example of a discussion I think would be improved by more template:

Wikipedia:AI noticeboard#c-StartOkayStop-20260518204000-User:Kaspar-trout Dw31415 (talk) 12:34, 8 July 2026 (UTC)

I think even a template like Template:Sbb would help improve tone. Something like (on behalf of ai cleanup project) would establish the complaint as part of a larger team and reduce the “get off my lawn” vibes. I’ll make that template if there are editors who would use it. Dw31415 (talk) 14:26, 8 July 2026 (UTC)

idk I am wary of clique vibes Gnomingstuff (talk) 14:33, 8 July 2026 (UTC)

Agree we should avoid clique vibes an “on behalf of” goes to far. Dw31415 (talk) 14:47, 8 July 2026 (UTC)

I think you have the right idea; it should be possible to phrase it in such a way to make it clear that it's the overall opinion of the community, so they don't feel as targeted. ChompyTheGogoat (talk) 19:29, 9 July 2026 (UTC)

Dunno what to say about all this. I really have hoped that this user Jasonkeithmccoy, who have been using LLMs to create articles about Survivor contestants, to return as no longer LLM-reliant. He hasn't edited since his last comment in May, two months ago. Still, even my feeling bad for how newer LLM-reliant editors have been treated should be, IMHO, no excuse for how skilled such editors should have been in the first place. How long or how else must editor become less LLM-dependent, despite our best to not bite them? George Ho (talk) 06:57, 9 July 2026 (UTC)

I might be wrong about this since I wasn't an editor prior to the introduction of LLMs, but I suspect that having access to them has emboldened people who would never otherwise attempt to edit Wikipedia because they know they're incapable of writing on the necessary level on their own to sign up and inject slop instead. There's a big difference between that and people who COULD learn to do it correctly but just take the easy route. I'd imagine that data (if available) tracking the rate of new account creation and what percentage face disciplinary action in short order vs continue to make productive contributions would help support that theory. ChompyTheGogoat (talk) 07:19, 9 July 2026 (UTC)

This is very simple -

1) Should we allow LLM generated edits? The community has spoken. The answer is firmly No.

2) Should we bite new editors who use LLMs to generate content? No. We should politely and gently explain that such edits are not allowed, and give them a second chance to edit productively.

3) Should we bite editors (old and new) who continue to use LLMs after we have explained that such edits are not allowed? Yes. Not all bites are bad. Blueboar (talk) 14:56, 9 July 2026 (UTC)

Absolutely. I meant they seem to think that they're entitled to be allowed to edit now that they're capable of having tools do the work for them and get mad when they're told that they actually have to be competent, whereas before such tools existed they were less likely to attempt it if they aren't. ChompyTheGogoat (talk) 19:36, 9 July 2026 (UTC)

I have various thoughts on this. I'll try to keep them concise. Maybe I should just write an essay.

First, I've seen several types of users run afoul of our LLM rules. Each has a different behavior pattern, and merits a different response from us.

• The Tech Bro - An early adopter who got excited about the capabilities of LLMs and thought Wikipedia was a good place to test them out.

Identifying features: mass-creation of new articles on a fairly niche topic, repeatedly making similar changes to existing articles.

Typical response to complaints: condescension. "I understand and share your dislike of slop, but my workflow ensures quality output". Something about FUD. "AI is inevitable, Wikipedia must embrace it or perish."

Our desired outcome: that this person understands that yes, they do have to follow the guidelines. The Wikipedia community has already weighed all the arguments they are about to make, and has found them wanting. The authors of Wikipedia's AI guidance include many people with a deep understanding of these tools and many people who use these tools frequently in appropriate use cases, but we have collectively decided that generating or rewriting content on Wikipedia is not one of those appropriate use cases. If they accept this, there is no reason why this person can't be a productive editor (though they may decide that manual editing isn't interesting to them).

• The Civil POV Pusher - This person has a perspective they want to insert into Wikipedia and is using AI because it allows them to insert their desired content at scale.

Identifying features: edits exclusively in a topic that controversial in some way. Edit summaries include lots of AI-generated WP:WTF.

Typical response to complaints: evasion. "Let's keep this discussion focused on the content issues. AI accusations are a distraction, you should WP:AGF". Likely to open an LLM-generated noticeboard posts and get WP:BOOMERANGED.

Our desired outcome: that this person be directed into the normal dispute resolution process as soon as possible, and that they engage in that process with their own words. Many productive editors started out as single-purpose accounts who were motivated to come here because they felt their perspective wasn't being represented, and broad representation of diverse perspectives is beneficial to the project (recent unconstructive efforts in that direction notwithstanding).

• The PR Firm - This person puts AI marketing copy everywhere and Wikipedia happened to be on their list today.

Identifying features: all edits are to a single article or set of related articles with which the user likely has a conflict of interest. Edits consist mostly of copy/pasting raw LLM output that speaks in glowing terms about the subject.

Typical response to complaints: none. Continues editing until blocked or strongly warned. May pivot to LLM-generated edit requests if pointed to WP:COIEDIT.

Our desired outcome: To show them the door and revert their changes as efficiently as possible. It is unlikely that this type of editor will become one of the very few COI editors who actually contribute constructively.

• The Non-Native English speaker - This person is frustrated by what they perceive as Wikipedia's inadequate coverage of some aspect of their home culture, but doesn't have sufficient English fluency to write in an encyclopedic register.

Identifying features: dramatic differences between the register of English they use from one edit to the next. If a long-term editor, a dramatic shift in editing patterns around 2024.

Typical response to complaints: denial. "I'm not a robot! Why am I being treated like this?" Edits and talk page comments show signs of AI writing but ping less than 100% on AI-detection software. If incontrovertible proof of AI use is presented, may pivot to swearing never to use AI again or declaring that they are leaving the project forever, but often without directly admitting to the past AI use.

Our desired outcome: that this person understand that perfect English is not required to contribute to Wikipedia - if they have sufficient English to read and understand the article they are editing, they can just make the required edits and trust other editors to come along and clarify/clean up grammar. They can also use edit requests if they like. Also there are likely other editors here who can read their language and would be willing to engage with them on their talk page. Because users like this often have the ability to access non-English sources, they are potentially extremely valuable assets and we would like them to stay around. Unfortunately many of these editors come from cultures where the concept of Face (sociological concept) makes it very difficult to respond to direct accusations in a way that satisfies venues like ANI.

• The Brainrot Kid - this person just uses AI for all writing tasks and has never done otherwise.

Identifying features: mix of AI signs and clear evidence of human intent in their edits. Account created 2024 or later. WP:OAICITE and "utm_source=".

Typical response to complaints: "But I don't know how to edit without AI!"

Our desired outcome: that this person grow in communication and writing skills until they reach a point where they can right coherent, meaningful text without reliance on an AI chatbot, without doing damage to Wikipedia or wasting too much of our time as they do so. This person probably isn't ready to edit Wikipedia yet, but unless we figure out how to recruit and equip people from this demographic, our editor shortage will probably continue to increase.

The challenge is that the best way to engage to get our desired outcome is different for each of these types of editor. I think a starting point would be for those of us who are often "first contact" to start taking a second to ask ourselfs "what is our desired outcome here" before engaging. -- LWG ^{talk (VOPOV)} 16:34, 9 July 2026 (UTC)

Would "The Vibe Coder" be a good enough substitute for "brainrot kid"? Somepinkdude (talk | contribs), in solidarity 22:14, 19 July 2026 (UTC)

You should save this as an user essay or something, this is a pretty good breakdown to be quite honest. ‑‑gurkubondinn 17:01, 9 July 2026 (UTC)

agreed, I would rename "Brainrot Kid" though to something like, idk, The Average Customer -- when I see "brainrot kid" I think preteen vandal who puts "6-7" into everything -- and add one more category:

The Student Assignment: Posts their homework -- which like many students they used ChatGPT for -- to Wikipedia. Usually this is via an organized Wikipedia editing assignment, and they're often being graded on it (and may have gotten a good grade for it.)

• Identifying features: They usually say that they're a student. On the rare occasions that they don't, they generally edit articles that correspond to things you would write a college essay on, sometimes "draft" them in a sandbox with an outline or peer review, and finally add them to the article in one huge edit.
• Typical response to complaints: None, they usually don't stick around after the class, and if they're in a WikiEdu course they're often flagged by their coordinators and/or their professors. If they respond it seems to be off-wiki.
• Our desired outcome: Basically the same as the Average Customer; secondarily, that their professors get better at catching this stuff.

Gnomingstuff (talk) 17:44, 9 July 2026 (UTC)

oh and two more:

The Renewed Hobby

• Identifying features: They made their account a long time ago, then stopped editing for several years, possibly even over a decade. Then, sometime after 2022, they find out about these new AI writing tools, which inspire them to return to their old hobby. So they suddenly come back with a prolific burst of editing, which clearly resembles AI and clearly doesn't resemble their old stuff.
• Typical response to complaints: That they're a productive editor who has been here since whenever with however many edits and shouldn't be sanctioned like a newbie, and that they're just following Wikipedia guidelines (they're not) and writing like they used to (they demonstrably are not). They may also be used to older, more permissive norms about notability and reliable sources.
• Our desired outcome: That they retain their enthusiasm -- they obviously want to contribute, more than most people -- just without the AI part. They also need to familiarize themselves with the new guidelines, since the AI guidelines aren't the only ones that have changed.

The Trophy Collector

• Identifying features: Also more likely than not to be a longtime editor. Their main goal seems to be racking up a lot of DYKs, GAs, or even FAs, and they have often succeeded at that. To do this, they usually make dozens or hundreds of small piecemeal edits to one article at a time, and in aggregate it's clear that they are either AI edits or based on AI summarization of the sources. They probably feel a lot of pressure to "make it good," and they are under the impression that AI is a good way to do that, probably because they've been rewarded for it.
• Typical response to complaints: The usual "I used AI to polish but all ideas are my own and I verified everything against the source," and often "I worked really hard on this," or "the reviewer said it was OK." The reviewer will sometimes also jump in here saying it's OK.
• Our desired outcome: That they understand that AI is making their articles worse, not better, and that they actually do need to read the sources they cite. More importantly, that this stuff stops making it through the DYK/GA/FA process.

Gnomingstuff (talk) 17:58, 9 July 2026 (UTC)

FWIW another type is the sock, spammer, LTA Kowal2701 (talk, contribs) 17:59, 9 July 2026 (UTC)

+1 on making it a user essay Dw31415 (talk) 17:43, 9 July 2026 (UTC)

+2! I definitely think this can be useful in regards to previous comments about identifying which users have the most potential to become useful contributors and how best to approach them. ChompyTheGogoat (talk) 20:02, 9 July 2026 (UTC)

I've got another:

The Self-Described Disabled User

• Identifying features: Edits and discussion posts are both more-or-less purely AI, with minimal editing for customisation of messages, until caught.
• Typical response to complaints: User (with or without using an AI) claims they are using it because they suffer from a disability which makes editing more difficult, if not impossible.
• Our desired outcome: That the user find and use accessibility software more in line with their limitations and that isn't apt to misinterpret their instructions (generally some form of speech-to-text or similar alternative-input accessibility options). Emphasise that these options have been used by Wikipedia editors for decades at this point and are widely accepted by the community.

—Jéské Couriano v^_^v ^{Object Class: Drygioni} 02:41, 10 July 2026 (UTC)

Have to tread carefully on that one. A lot of people seem to think "I can't write at the level required due to neurodiversity" qualifies as a protected disability, when that A) is usually not the case (most could learn how if they wanted), and B) does not qualify as a "reasonable accomodation", which requires the person be capable of accomplishing the underlying task - which in this case means writing a decently composed article themselves. AFAIK volunteering here is not held to ADA standards anyway, but you couldn't use that justification to apply for a job as a writer, because you are not in fact writing. The difficulty becomes trying to challenge that claim without invalidating their supposed limitations. True accessibility products like you mentioned used by people inherently capable of doing the basic work required are of course not an issue, but that isn't usually what I see. ChompyTheGogoat (talk) 03:06, 10 July 2026 (UTC)

Neurodiversity is not an excuse. I say that as an autist who's been here for damn near 20 years, and I see "I need LLM because I'm autistic" as an attempt to try and hide behind the LLM for whatever reason. If you can argue your position without the LLM, then there's very little justification for using it for article content. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 03:17, 10 July 2026 (UTC)

for what it's worth I don't see this excuse used very often on wiki Gnomingstuff (talk) 04:05, 10 July 2026 (UTC)

It's less common than others, but I've definitely seen it tossed around both here and on social media. ChompyTheGogoat (talk) 04:08, 10 July 2026 (UTC)

Yes, that's my point (as a fellow autistic) - but like I said you need to be careful about how to approach such things, because generally speaking it's entirely valid for people to advocate for themselves and express their needs. They aren't required to tell you the exact nature of their limitations, which can be abused as a loophole of sorts. You have to focus on the fact that AI fundamentally changes the end result, as opposed to just accomplishing it a different way, as with screen readers or speech to text. I used to have a co-worker who was a near-total quadraplegic and did our online job (which made no concessions for disability) via Dragon assistant. We had monthly reviews and if her output hadn't been on par with the rest of us they would have terminated her. Same result, just different methods.

At any rate, I think it would be unwise to include it here (especially with the phrasing "Self-Described Disabled User") because it's a sensitive subject, and we should approach claims of disability on a case by case basis. It might be more useful to write an essay explaining in detail why AI is inherently different from other accessibility tools and listing common ones that ARE acceptable (being careful not to imply that they're the only ones allowed, just examples). ChompyTheGogoat (talk) 04:06, 10 July 2026 (UTC)

This sounds like what AI would generate, with the "The (X person)", but it's very funny reading this. And yes, I support that you create an essay on this, titled Types of newbies who use LLMs to write AI (...without realising we have rules for them). XD Hason-LEK-SIN ● Let’s chat! ● My contribs 12:35, 27 July 2026 (UTC)

@Hason-LEK-SIN the essay has been written as User:LWG/These are the LLM users in your neighborhood. -- LWG ^{talk (VOPOV)} 19:22, 27 July 2026 (UTC)

I've gone ahead and added an {essay} tag into the page. :) Hason-LEK-SIN ● Let’s chat! ● My contribs 22:47, 27 July 2026 (UTC)

Some thoughts on the new editor interaction:

LLM-using new editors want to know why we think their article is LLM. From the editor's point of view this makes perfect sense. But from the patroller's point of view, there's a big concern that going through in detail and pointing out AISIGNS is giving a masterclass on how to disguise LLM use, leading to articles where the text does not raise red flags but the sourcing and facts are still terrible. This is a worst case for us. So patrollers are vague, and editors naturally resent this.

What we want, when an article is LLM generated or heavily edited, is for them to trash it and start over. This is a really big ask. A new editor brought to AINB recently asked me to review their lengthy, detailed, technical article, which they had attempted to de-LLM. My honest answer has to be that they have not succeeded, and almost surely won't succeed by wordsmithing. But how can it be palatable to ditch all that lovely-sounding text and all those seemingly informative references? They had been thinking of GA and are now fighting to keep it from being deleted, which must have been a horrible shock. I am also working with another new editor who is trying to salvage a long draft. We have been three rounds of me giving detailed comments and while the article is improved, it's still flawed and probably should not pass AfC if submitted.

Four concrete recommendations:

• When a new editor first begins to edit they need a clear statement about NOLLM. Good-faith editors who simply don't know this are tragedies in the making. "I just wanted to help," as Michelle904 told me while I was in the process of reverting 90% of their edits.

• A new LLM patroller told me that the Newcomer Tasks of sourcing unsourced statements and updating out of date material (which are what Michelle904 was doing) are so difficult that they strongly incentivizes LLM use. As a newcomer they'd tried these and bounced completely off Wikipedia because sourcing a random statement in an area you're not familiar with is described as intermediate but is often brutally hard. I had the same experience. These tasks should be reconsidered.

• We need training for AfC, new page patrollers, and good article reviewers on LLM detection. I've been told by an AfC editor that 70% of what they see is LLM; editors who don't know the signs will pass these as they sound plausible and look sourced. We may or may not retain someone who gets caught on their first LLM article; I don't think we ever retain people who get caught on their 20th. (Or 400th, in one recent case; it's a damned shame to lose that editor but one can't blame them for giving up at that point. They were autopatrolled, too, which is a big failure of our process that I've seen at least twice recently.)

• AINB cases need more structure, to try to cut off long wrangles (anyone who reads the board will know what I mean). These use up the patrollers' good faith and time, and leave less energy for working with cooperative editors who have made a mistake. In particular, I'd love to see a working list of "if the editor brings this argument, we are done debating with them" and a community agreement to abide by that. M kuhner (talk) 15:39, 10 July 2026 (UTC)

(also worth saying, boilerplate messages are awful, they're so impersonal and antisocial, ngl if I'd gotten a user warning when starting out I'd've stopped editing. I cringe at how common they are. The best templates look hand-written) Kowal2701 (talk, contribs) 15:43, 10 July 2026 (UTC)

I think that's a matter of personal opinion, because some people get more offended if they feel like they're being called out by an individual, as opposed to receiving a standard warning on behalf of a community/organization/whathaveyou. But it's also hard to know when the best approach is "you made a mistake and we want to help" vs "knock that shit off or leave" - in the latter case it's more about getting them to leave before too much damage is done, when there was never a real chance of retaining them as a useful contributor. ChompyTheGogoat (talk) 16:36, 10 July 2026 (UTC)

If your goal is retention, then prior research says that "you made a mistake and we want to help" is more likely to work. The "uw-" templates were re-written with professional support from the WMF c. 2010, as part of the usability initiative. The goal is short and sweet. Of course, since then, we've had a decade and a half to add "just one more thing" and to make them sterner (←better for expressing our emotions, but not better at helping the project). WhatamIdoing (talk) 19:22, 19 July 2026 (UTC)

Editors who have zero interest in ever contributing without the use of AI continuing to run amok while sanctions are endlessly debated do not "help the project". Retention of USEFUL editors is the goal, but if we don't get better at cutting off the ever-increasing hoards of those who aren't, we're going to also face increasing burnout of editors who have already proven themselves to be helpful, which is the last thing we want. If it comes down to the retention of the 20 year editor who's been a major contributor at WP:WikiProject AI Cleanup or the new editor regurgitating slop everywhere who may or may not ever reform, I know which one I'd pick every single time. ChompyTheGogoat (talk) 01:54, 20 July 2026 (UTC)

How do we know that any editor has zero interest "ever" in anything? That sounds like an end-of-history illusion. We've had editors who started as vandals, grew up (*gasp*), and then came back to be productive. (Opposite is also true: A couple of months ago, I saw an experienced editor outright vandalize an article. Nothing in their previous couple thousand edits would have made that seem likely, and the hundreds since then have all been fine, too.) WhatamIdoing (talk) 05:09, 28 July 2026 (UTC)

But you do need to weigh the potential value of that editor against the potential value of the editors whose time they waste, or who they may drive away completely.

I ran a volunteer group for 14 years, and a bitter lesson I learned is that sometimes by putting a ton of effort into retaining a problem person, you quietly lose several well-behaved people. They will seldom tell you why they're leaving. They just go. M kuhner (talk) 05:14, 28 July 2026 (UTC)

Yeah, that. Given that mentors have limited time/brainpower it makes sense for them to focus on newbies who at least seem like they're WP:HERE, not those who come in creating problems immediately. If they want to reform they need to show a commitment to doing so before anyone is going to be interested in helping them. And I'm not talking about a single bad edit, but an ongoing pattern. ChompyTheGogoat (talk) 12:39, 28 July 2026 (UTC)

Agreed on the newcomer tasks. I'd get ones that said 2 minute copyedit and load an article that needed a complete top to bottom overhaul - I didn't even know where to begin. I don't think I completed a single one. They either need to be totally revamped or eliminated entirely, because in their current form I think they just create more problems that require later cleanup. I went through several today; some on articles that actually just needed to be trashed. Perfect example of "great in theory; kind of a mess in practice."

I really think a more formal walkthrough would help immensely - explain the basics, let them try a few test edits, then give them suggestions such as Teahouse and their sandbox where they can continue learning. Some FAQs would be great too. The desire to make editing accessible to anyone in the middle of reading an article really dumps people straight in the deep end. It should be easy enough to have a popup the first time you to go to edit from a new account or TA that lets you either pick "I'm new, please show me the walkthrough" or "I know what I'm doing - skip" (with some disclaimer about edits being undone if they do not in fact know what they're doing).

And yes, I think part of that walkthrough should be agreeing that they understand and agree to things like COI disclosures and not using LLM, so that good faith editors CAN avoid common mistakes and the rest don't have plausible deniability. Maybe little multiple choice quizzes. I'm sure WikiEdu could help put together something really basic, since they have experience with structured approaches like that. ChompyTheGogoat (talk) 17:01, 10 July 2026 (UTC)

My Wikipedia story looks like this: asked for a Newcomer Task, got an article for "copy-edit" with enormous problems, slowly worked out it was LLM, committed to actually fixing it; a month later I had read half a dozen papers, taken a merge proposal to AfD, deleted and rewritten 2/3 of two linked articles, carried out the merge.... I guess that could be considered a success but how many people are going to do that as opposed to bouncing off or resorting to LLM?

I am not pinging them at their request, but I know that Gnomingstuff, one of our best LLM patrollers, strongly believes that Newcomer Tasks are making things worse. M kuhner (talk) 17:35, 10 July 2026 (UTC)

I definitely bounced off newcomer tasks, but managed to learn a lot by poking around in back rooms and occasionally getting brave enough to make edits in mainspace when I stumbled across very minor things that needed to be fixed. My very first edit (and the entire reason I finally signed up) was literally a single word and I still managed to break the entire world due to a keyboard glitch 🤦‍♀️ I learned wikitext almost entirely through TPs because I was afraid of doing even worse by trying to inject markup. And most new users are not as tenacious (read: stubborn) as the two of us when it comes to sticking around. ChompyTheGogoat (talk) 17:47, 10 July 2026 (UTC)

If you incentivize and gamify editors to make number go up, then you are going to get people who use the most expedient way to make number go up, i.e. AI. It's to the point where if an article was tagged with copyedit, expand section, peacock, or whatever the system pulls from, the article has now been beset by 2+ pages of bad edits. Gnomingstuff (talk) 02:25, 11 July 2026 (UTC)

I have written an essay proposing conditions under which an AINB discussion should be cut off, and would welcome comments. User:M kuhner/sandbox/Discussion-ending LLM arguments. (I now realize it would have been better called something else, but that can be fixed later. Title suggestions also happily accepted.) By the way, for non-AINB regulars--you may wonder if some of these are for real. I assure you, I could put diffs to every single one. M kuhner (talk) 16:49, 10 July 2026 (UTC)

Thanks a lot, definitely a helpful place to point people to! Maybe it could be organized more clearly as an essay that we can link in relevant discussions, like Wikipedia:Help, I've been accused of using AI!? Great job nonetheless!

Maybe we could add something like: Invoking WP:IAR / claiming that WP:NOLLM is "just a guideline" and can be ignored, without further justification? It might intersect a bit with A statement that Wikipedia rules do not apply to this editor, but can be helpful to note. Also maybe, claims that Wikipedia does not have "an AI policy" after being clearly linked to WP:NOLLM. Chaotic Enby (in solidarity · talk · contribs) 17:08, 10 July 2026 (UTC)

I'm wondering if I'm mixing two things: a community commitment not to respond, and information directed at the LLM using editor. Maybe need to split those. M kuhner (talk) 17:52, 10 July 2026 (UTC)

Yeah; directing the editors to something that says "here's what we do to people like you" comes across pretty WP:BITEy. ChompyTheGogoat (talk) 17:57, 10 July 2026 (UTC)

My strong desire to bite people who give any of the arguments listed in that document is showing through! But I'll split it up.

(Cartoon seen a long time ago: Doctor tells woman she has a fatal case of rabies. She asks for pen and paper. After a while he notes that her will is rather long. "It's not a will. It's a list of the people I'm going to bite.") M kuhner (talk) 19:48, 10 July 2026 (UTC)

I've only been here a few months and I think my eyes are at risk of getting stuck in a permanent roll. Nonetheless, the initial stated goal for this discussion was how to RETAIN whatever small number of LLM editors actually show promise. If we can do so in a way that also makes it easier for us to show the rest the door - win/win. ChompyTheGogoat (talk) 19:59, 10 July 2026 (UTC)

As suggested, I have converted some of my thoughts from above (plus suggestions from others) into a user essay at User:LWG/These are the LLM users in your neighborhood. I welcome feedback/suggestions. -- LWG ^{talk (VOPOV)} 22:54, 10 July 2026 (UTC)

• This has been a good discussion, but I can't see that there's anything actionable here re putting a system in place? Is it best to just ask at WP:MNB if any help is needed at AINB for individual cases? Kowal2701 (talk, contribs) 12:27, 29 July 2026 (UTC)

Enabing the VE editing toolbar by default in source?

One of the advantages of VE is that you can use automated citation formatting, as well as automatic table insertion. That toolbar is also available for source editor as the 2017 wikitext editor, which you can enable in your preferences. Would it make sense to enable this as a default? Or enable this for new editors as a default? Do people who mostly use source typically have this enabled? In solidarity, —Femke (talk) 🐦 10:35, 14 July 2026 (UTC)

Personally, I don't find the 2017 editor at all useful. If I'm doing complex tasks for which toolbars are useful then the visual editor is superior, if I'm doing things that the visual editor is not capable of or which are very simple then the 2010 editor loads and saves significantly quicker. Thryduulf (talk) 11:24, 14 July 2026 (UTC)

Automatic citation formatting is available on the 2010 toolbar, or is this discussing something different? -- LCU ActivelyDisinterested «@» °∆t° 17:51, 14 July 2026 (UTC)

I wasn't aware. It took me a while to find out how to do this (assuming the 2010 editor is what new editors ge). You click the tiny cite, you select one of the four templates, and then you add the url (somewhere hidden in the middle right among many different parameters), and then you click the tiny search icon. It takes a while before something is added, without a signal to the editor that they system is 'thinking'. That does not seem like a good way to do things for new editors at least. I'll see if I can test loading times with the different versions, would be interesting to see how much of a difference it makes. In solidarity, —Femke (talk) 🐦 21:05, 14 July 2026 (UTC)

I like this idea and would support enabling it by default for new editors. I enabled the 2017 wikitext editor a long time ago to get the nice toolbar in source editing mode, and I forget how rudimentary the default toolbar is. Dreamyshade (talk) 05:43, 16 July 2026 (UTC)

I'd suggest encouraging people to enable it voluntarily in prefs before trying to change sitewide settings. WhatamIdoing (talk) 19:26, 19 July 2026 (UTC)

A fast-diff, extended-confirmed, anti-LLM edits browser to solve the problem of AI

I've had this idea for awhile and would like to get some people's thoughts on it and some help with making this proposal actionable/ironing out specifics for a proposal on VP. The rough gist of it is this: A fast-diff edit browser (inside of Wikipedia) for extended-confirmed users (the Rollbacker/Admin pool of users is not enough to effectively stop AI) that randomly selects 20 or so articles and scans each for 'ai signs' in their writing. (overuse of semicolons, em and en dashes, specific words and sentence structure that AI likes, if the user who added the content was new/was warned before for LLM use, if the content was added during the time AI could be used as a chatbot (post GPT-3 release timeperiod) and other AI artifacts in writing) Then, we score the specific sentences in each article for how 'likely' AI writing is. We would then use a small LLM, some basic local AI like Local LLAMA, to read the text and where the problematic sentence is and find a way to cut it out that does not break the structure of the article. The extended-confirmed user then simply checks 'Yes' or 'No' to decide if the specific removal (which will show up directly on the screen of the user) is just or unjust. It will then take them to the next and repeat the process with 20 more articles once out of content to decide on.

This is a very rough draft of my idea here and was written in like 10 minutes and probably has a variety of flaws in it's writing. I would like to hear people's thoughts, possible alterations to my idea and in general help to make this an actual proposal and not just an idea bouncing around in my head with all the others. Thank you. Ilov3gam3z (talk) 12:26, 14 July 2026 (UTC)

I've already been working on testwiki:User:Chaotic Enby/AIDiffBrowser.js, although it is for now more centered on browsing cases on the AI noticeboard. Once the first version is released, this sounds like a very good functionality that could be added down the line! Chaotic Enby (in solidarity · talk · contribs) 14:54, 14 July 2026 (UTC)

each for 'ai signs' in their writing. (overuse of semicolons

You should not make this until you have a better grasp of what AI writing looks like. Gnomingstuff (talk) 15:12, 14 July 2026 (UTC)

? This is why it's at the Idea Lab, not Proposals. I would need people to iron out things like that and most technical specifics (I don't know much on the technical side of Wikipedia). Ilov3gam3z (talk) 15:16, 14 July 2026 (UTC)

Also, I still see overuse of semicolons, overuse em and en dashes, overuse of bolding and over-organization of content as obvious signs of AI writing. Ilov3gam3z (talk) 15:17, 14 July 2026 (UTC)

These are not the most reliable signs and are very easy to misinterpret; the fact that so much outside reporting has fixated on things like this is a large part of why people think AI detection is not possible. Stuff like dashes is especially dubious for Wikipedia since they don't really appear very much in article text (possibly because we've had like 5 dash templates over the years to muddy the training data, but who knows) and are generally noisy due to bullet point dashes, dashes in headlines, etc.

For Wikipedia purposes, WP:AIVOCAB, WP:AIATTR, WP:AITREND, and WP:SUPERFICIAL are the four most reliable ones. Gnomingstuff (talk) 19:53, 14 July 2026 (UTC)

Again, what I have written here is the broad strokes of my proposal. AIVOCAB was already one of the things I was thinking of, though. The other signs would be good to include too. Ilov3gam3z (talk) 19:59, 14 July 2026 (UTC)

I think that automating the entire thing and letting editors make such sweepings decisions through a single checkbox is far too simplistic and ripe for abuse. Highlighting the problematic content with the attached reason it was flagged and allowing the editor to decide how to handle it seems like a safer proposition. I also don't think it should be accessible to all extended confirmed users, but perhaps a new user group for people who've demonstrated at least some degree of competency regarding LLM text. Possibly with upgraded permissions available for more experienced editors to make wider changes, similar to rollbackers.

I do agree that we're badly in need of tools to help combat the issue, and this certainly sounds like it has promise. ChompyTheGogoat (talk) 16:07, 14 July 2026 (UTC)

I did not mention this, but highlighting with a reason is also something that will probably be included. Maybe we could have a 1k or 5k edit user group above extended-confirmed? I still feel making this usable only by those that are approved by admins or what-have-you will bog the process down, but I am open to thoughts on this as the extended-confirmed restriction is something I came up with on the spot while writing this. Ilov3gam3z (talk) 16:11, 14 July 2026 (UTC)

Having 5k edits instead of 500 might correlate with familiarity with Wikipedia processes, but not at all with the much more specific task of AI text detection. I do plan to implement something like this to AIDiffBrowser one day, although it will likely be limited to a new user role (or pseudo-role like AfC reviewers) once I'm done with it. Chaotic Enby (in solidarity · talk · contribs) 16:15, 14 July 2026 (UTC)

My TAIV rights were granted in no time, so I think if the good folks at WP:AICLEAN kept an eye on requests they could go through quickly. There's nothing urgent about it, since they can still edit manually while it's pending. ChompyTheGogoat (talk) 16:16, 14 July 2026 (UTC)

If we go for something like this (and I'm undecided whether I think it's a good idea or not) then it should be handled similarly to AWB where there is a (pseudo?) usergroup that is granted only to those who ask for it and only to those who have demonstrated competence in the relevant area - in this case that would mean experience of detecting LLM-written material with a very low false positive rate. Thryduulf (talk) 21:24, 14 July 2026 (UTC)

I made a tool where step 1 is similar to "randomly selects 20 or so articles and scans each for 'ai signs' in their writing", and step 2 is similar to "score the specific sentences in each article for how 'likely' AI writing is", automatically skipping articles already tagged for AI cleanup: https://wikitomte.toolforge.org/

You're welcome to use the code as a starting point for additional experiments. For example, you could add a step 3: enable the user to select a suspicious passage to try to search the diffs and find out when the passage was added. I thought about linking to WikiBlame with a pre-filled query. Feel free to put in a PR if you come up with something interesting! Dreamyshade (talk) 04:40, 16 July 2026 (UTC)

It woudl be useful to have the edit feed be determined by a query for one particular AI tell (for example, "played a pivotal role". The tool would then search for pages with the phrase, figure out the blame, and possibly also highlight phrases left over from those AI edits in the article. This automates the process in User:Gnomingstuff/Guide to finding AI-generated text, which is quite similar to my own AI-detection process. Somepinkdude (talk | contribs), in solidarity 22:11, 19 July 2026 (UTC)

Great idea! Chaotic Enby (in solidarity · talk · contribs) 22:47, 19 July 2026 (UTC)

Yeah this is nice. Ilov3gam3z (talk) 00:13, 20 July 2026 (UTC)

"We would then use a small LLM, some basic local AI like Local LLAMA, to read the text and where the problematic sentence is and find a way to cut it out that does not break the structure of the article."

Let me get this right: we use an automated system (of uncertain reliability) to find text that was written by an automated (LLM) system, which text we assume to be unreliable because it came from an LLM, and we then use another (albeit smaller) LLM to rewrite the text removing the bit that our automated system thought might be from an LLM? And we assume that a human armed with a tick-box will take the time to check the new LLM-written text is more correct than the old LLM-written text? As a very naive person, aren't we going to end up with articles that were written by an LLM and then made LLM-filter-proof by another LLM? Why don't we cut out all the hassle by simply telling new editors that after they've got ChatGPT to write their article, they should ask Claude to remove all the AI signs? Elemimele (talk) 16:34, 24 July 2026 (UTC)

From what I understand, the proposal isn't to rewrite the AI content, but remove it in a way that leaves the rest of the article coherent – although, if the LLM starts to add padding text to connect the sentences on each side, we will indeed run afoul of WP:NOLLM and be at risk of WP:SYNTH. I don't necessarily agree with this particular way to do it, and in fact, the AI diff browser I'm working on will have a field for humans to manually rewrite the text once the sentences are removed, which is much better to leave it to LLMs. Chaotic Enby (in solidarity · talk · contribs) 16:56, 24 July 2026 (UTC)

We are not rewriting; we are using a (very basic, mind you) LLM to find out the best way to cut the content, i.e. should we clean up some punctuation? Should we remove some nearby sentences to make it flow better? etc. AI will not be adding any text, simply fixing issues that come with ripping out content from a sentence. Ilov3gam3z (talk) 17:16, 24 July 2026 (UTC)

(sentence or paragraph, mind you) Ilov3gam3z (talk) 17:16, 24 July 2026 (UTC)

There will also be no padding text as Chaotic Enby noted. If the situation is too complex for AI to fix, we will simply ask the user to do it manually in a web browser. Ilov3gam3z (talk) 17:18, 24 July 2026 (UTC)

I think that's still too iffy. We've got all these former spelling and grammar tools out here that are now making more advanced AI suggestions to "improve flow", which all too often amount to total rewrites that can change the meaning, which is why such tools aren't allowed on en-WP. Editors who are granted permission for this proposed tool should be sufficiently experienced to handle the necessary adjustments themselves - it's going through entire articles and trying to identify which specific parts from an extended edit history were inserted from LLM output that's the most tedious and time consuming, IMHO. The editors who are already doing such work manually could make a lot more progress if that part was automated, and it might help attract more people to the cleanup project as well. ChompyTheGogoat (talk) 00:28, 25 July 2026 (UTC)

There will be very strict rules on what the AI can and cannot do. AI will only be able to remove text or add punctuation and will have a very specific system prompt. If it adds text that is not punctuation, it will simply be asked to do it again until it gets it right. Ilov3gam3z (talk) 00:43, 25 July 2026 (UTC)

Even removing text can fundamentally change the meaning - "He did [not] do it" > "He did do it". That's why people get confused over the use of "minor edit", because length is irrelevant - only whether it changes the meaning of the content in any way.

Besides which, just auto-deleting text that's already been highlighted for inspection doesn't save the editor much effort and the content is still likely to require a rewrite if the AI insertion was woven in between good edits. I just don't think the tradeoff is beneficial enough to justify the potential risks, and I suspect any proposal to fight LLM content by allowing a different LLM to make edits will hit far too much pushback and end in a WP:SNOW close.

It might be more useful to build in functions that allow editors to fix various sections in various ways. For example, [Flagged section A] could be rewritten manually, [Flagged Section B] could be reverted back to how it looked at Last Good Edit, and [Flagged Section C] could just be deleted. Maybe a way to flick back through the previous edits to whichever section is selected so they can easily compare the changes to just that part without leaving the editor tool. I don't have the tech skills to have any clue how feasible it might be to implement that kind of thing. ChompyTheGogoat (talk) 01:35, 25 July 2026 (UTC)

See User:Chaotic Enby/AIDiffBrowser.js for the prototype I made of that! (not sure how buggy it is, mostly been developing it on testwiki for now)

Currently just giving you the option to revert (or keep given that some edits inbetween might have to be kept), but in-place editing will likely be the next thing I'll implement. Chaotic Enby (in solidarity · talk · contribs) 07:34, 25 July 2026 (UTC)

That's why I prefer to only allow this proposed system to identify the problematic text, not decide how it should be fixed - similar to how LLMs are not banned for RESEARCH purposes, but editors must do their own writing based on the findings. We clearly need some type of automation to try to keep up with all the slop insertion, but we have to tread very carefully to avoid said slippery slope. Limiting the user group would help ensure those with access have the necessary skills to confirm that the identified content is consistent with LLM output and not just assume that it was flagged correctly. ChompyTheGogoat (talk) 00:17, 25 July 2026 (UTC)

... and the skills required to identify LLM material are going to get tougher and tougher as AI gets better at imitating humans. The saving grace is probably that if a(nother) human checks the text and verifies the sourcing, and no one can even work out whether it was LLM or not, then it becomes rather unimportant whether it was LLM. Elemimele (talk) 14:40, 25 July 2026 (UTC)

And even the current automated tools for identifying it are unreliable, which is why human verification is vital. As you say, if it actually gets good enough that we can't tell the difference things may change, but currently we need to be able to remove invalid information that AI didn't realize is invalid, so we can't rely on AI to remove what's invalid. Flagging it for inspection and adding tools to facilitate removal just improve the workflow for human judgements. ChompyTheGogoat (talk) 05:27, 26 July 2026 (UTC)

Just to be clear, the idea I suggested doesn't involve any "AI removing AI". Instead, the diff browser would simply use WikiBlame, make a list of all the blamed user's added lines to that particular article, apply changes from later edits, and then end up with a list of AI-generated content from that user. Of course, this would go wrong if one user has both AI and non-AI content additions, but that's reasonably rare, and the EC user does have to use their own judgement in these cases. Somepinkdude (talk | contribs), in solidarity 20:29, 26 July 2026 (UTC)

The original proposal said We would then use a small LLM, some basic local AI like Local LLAMA, to read the text and where the problematic sentence is and find a way to cut it out that does not break the structure of the article. That's what I'm concerned with. If your suggestion is just for identifying the problematic text and can't make any changes without the editor manually reviewing it, then we're on the same page. I think there was some confusion in all the crosstalk. ChompyTheGogoat (talk) 04:21, 27 July 2026 (UTC)

Automatically grant new page reviewer rights in certain circumstances

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

---

According to Template:NPP dashboard, the New Page Patrol article backlog is "very large" and "growing very rapidly", with nearly 1000 new pages since last week. Given this, I propose that we automatically grant New Page Reviewer (NPR) rights to any editors who have more than 1000 unreverted, undeleted edits, have edited for at least a year, and have no current or prior blocks on the English Wikipedia. I suggest that we continue to offer WP:PERM/NPR for people who don't meet these requirements.

This way, we will be able to crowd-source a massive amount of reviewers while still only accepting people who are reasonably-experienced with the proper functioning of the Wikipedia. GrinningIodize (articles without a Wikidata item) (talk) 23:47, 14 July 2026 (UTC)

In general, I'm not super enthusiastic about giving out perms to review others' work automatically. Lots of people can gnome around but not really write whole articles themselves, which is fine and dandy work, but also not really the kind of work that would contribute towards warranting NPR. — Red-tailed hawk _(nest) 01:21, 15 July 2026 (UTC)

I think that users should have to want to do the reviewing. But then they can ask for that permission. Graeme Bartlett (talk) 01:25, 15 July 2026 (UTC)

The problem here is that currently, even WP:PERM/NPR has a reasonably-large backlog. GrinningIodize (articles without a Wikidata item) (talk) 16:26, 15 July 2026 (UTC)

I wouldn't say that three users waiting to be assessed is a reasonably large backlog. Cheers, SunloungerFrog (talk) 23:11, 15 July 2026 (UTC)

I fall under your classification for auto NPP, but know I am absolutely not trained up in it. Being given that without question of my ability would let me do all sorts of damage. Jerod Lycett (talk) 06:24, 15 July 2026 (UTC)

Why NPR and not autopatrolled? Autopatrolled doesn't require you to do anything, unlike NPR. sapphaline (talk) 08:11, 15 July 2026 (UTC)

Though if we're going to give away autopatrolled automatically, I would make it "1000 unreverted, undeleted mainspace edits", and also add something like "created at least 3 articles in the last 6 months and haven't had any of them deleted". sapphaline (talk) 08:13, 15 July 2026 (UTC)

1000 unreverted ... mainspace edits is a very high bar. Three out of my last 50 edits have been reverted by TAs or very-low count accounts that re-reverted my reverts of problematic edits. Anyone who patrols new edits is going to be regularly reverted by editors who think the proper response to being reverted is to re-revert back with no discussion. Donald Albury 15:34, 15 July 2026 (UTC)

"1000 unreverted, undeleted mainspace edits" in all time, not in a month/year/etc. sapphaline (talk) 10:02, 16 July 2026 (UTC)

I can confirm that this is my intended meaning. GrinningIodize (articles without a Wikidata item) (talk) 15:36, 16 July 2026 (UTC)

NPR requires a very particular set of skills which you don't acquire by turning up and gnoming, even for a long time. At the risk of hijacking the idea, giving autopatrolled automatically sounds like a better plan. You could even start with a high bar like 100,000 edits and 10 years then bring it down gradually if no problems arise. Certes (talk) 11:59, 15 July 2026 (UTC)

Are there any people with 100,000+ edits who don't have autopatrolled? sapphaline (talk) 12:13, 15 July 2026 (UTC)

Excluding bots, and limiting to accounts over 10 years old, there are 432 of us. But the threshold could be lowered later. Some of these people may have had autopatrolled granted but removed for good reason. It comes down to 374 after removing users with current blocks of any type. Certes (talk) 12:29, 15 July 2026 (UTC)

100,000 edits seem extremely high. I would say 5 years + 5000 mainspace edits. Some1 (talk) 22:45, 15 July 2026 (UTC)

Strongly disagree with this, I have seen several long-term editors in good standing who don't really grasp notability or even WP:RS, including some who currently have autopatrolled but probably should have it removed. Helpful Raccoon (talk) 23:52, 15 July 2026 (UTC)

(By 'long-term' I mean 20,000-200,000 edits over 15+ years.) Helpful Raccoon (talk) 01:10, 16 July 2026 (UTC)

AINB has two recent cases of long-term editors with autopatrolled who ended up injecting dozens to hundreds of LLM articles into mainspace without review. Really sad, but not as rare as we'd hope. M kuhner (talk) 02:35, 20 July 2026 (UTC)

That's a shame. In that case, we probably shouldn't extend even autopatrolled more widely than at present. Granting the permission only helps NPP of course, not the editor themselves (unless they plan surreptitious mischief). Certes (talk) 09:49, 20 July 2026 (UTC)

I never want autopatrolled. Would this let us opt out so we can guarantee a second pair of eyes? Jerod Lycett (talk) 02:28, 19 July 2026 (UTC)

Have you ever checked the page views on articles for the first day that they're in the mainspace? They usually get more than a dozen page views. What autopatrolled provides is nobody needing to click a button after looking at it. WhatamIdoing (talk) 02:48, 20 July 2026 (UTC)

Should have clarified: A second pair of eyes from an experienced, knowledgeable editor. Jerod Lycett (talk) 05:18, 21 July 2026 (UTC)

From my understanding, autopatrolled rights are really intended for frequent page creators, since they will otherwise let a lot of unwanted stuff get past the NPR folks. GrinningIodize (articles without a Wikidata item) (talk) 16:33, 15 July 2026 (UTC)

Alternative idea

It seems like a lot of people here are worried about competence. Perhaps we could automatically grant 1-month trials to eligible users on the condition that they take a training course and check a box saying that they have the necessary skills to become a new page reviewer?

After the 1-month trial period, users can request a permanent extension of NPR rights at WP:PERM/NPR if they can demonstrate their competence to an admin. GrinningIodize (articles without a Wikidata item) (talk) 16:30, 15 July 2026 (UTC)

I would also be open to 3-month trials if need be. GrinningIodize (articles without a Wikidata item) (talk) 16:34, 15 July 2026 (UTC)

I'm sure the good and experienced people at WP:NPR will have plenty of good advice on this topic. Certes (talk) 17:55, 15 July 2026 (UTC)

How likely is this to fix the problem? If people are not currently requesting permissions, what makes us think they would request a 1-month trial? Or if the trial is granted automatically, are we hoping editors will be notified of their new abilities and jump in to address the backlog? —Myceteae‍🍄‍🟫 (talk) 18:43, 15 July 2026 (UTC)

People are currently requesting permissions, but WP:PERM is so backed-up that many of them are stuck waiting for longer than they should have to. My idea is that a bot would send a talkpage notice to eligible editors with instructions on how to obtain NPR rights without waiting for another human. Editors who deem themselves worthy can take a short training course, affirm that they understand their duties, and work on the backlog until their trial ends. Afterwards, they can either return to their normal work or request permanent rights.

This system would help encourage more people to do new page reviewing while still keeping the process relatively meritocratic and filtering out most of the less-qualified editors early on. GrinningIodize (articles without a Wikidata item) (talk) 18:56, 15 July 2026 (UTC)

I think a bit of perspective may help here. The queue is currently at 20865. In my experience over the past 7 years or so, there's been one or two times that we've gotten the queue down close to zero, but most of the time it's hovered between 10,000 and 30,000. It typically takes 3 to 6 months for an article to get reviewed, although many are reviewed much quicker because many people patrol from the front of the queue.

As for requests, setting aside that the backlog is currently zero, when you wrote the above comment the backlog was a whopping four days and 3 requests. Calma mi hijo. _signed, Rosguill ^talk 00:16, 16 July 2026 (UTC)

A good chunk of editors who are scrutinized and approved by admins for a trial already fail to get the right renewed due to problems with their reviewing. Not to mention Wikipedia has had a lot of WP:UPEs targeting the NPR right to help their scam operations. Granting it automatically could greatly exacerbate the problem. Helpful Raccoon (talk) 00:45, 16 July 2026 (UTC)

There are only two people listed as available as trainers at all. One has stated zero slot availability. The other has not responded to multiple of us editors asking for training and appear to be missing. I don't think training courses are even a possibility without somehow incentivizing NPP to do so. Jerod Lycett (talk) 02:37, 19 July 2026 (UTC)

When I said "training course", I meant something more along the lines of an interactive tutorial; users would be presented a simulated curation interface with example articles, and they would have to perform the appropriate action for each example (approve, delete, skip, etc.) and the tutorial would tell them what the correct course of action was in each case. At the end, the user is presented with their statistics, and if they got a reasonable amount of actions correctly (perhaps an ~80% accuracy or higher), they check a box affirming that they believe themselves to be competent in NPR tasks, and that they understand that any bad-faith behavior or generally-bad decisions could get their rights revoked. GrinningIodize (articles without a Wikidata item) (talk) 17:37, 19 July 2026 (UTC)

The "training course" may be part of the problem. NPP has had so much stuff crammed into it over the years that "fully" reviewing one article takes too much time, and people feel like they aren't doing it right if they don't reject most of the articles.

For example: I went to Special:NewPagesFeed, set the filter to give me unreviewed articles from 30–37 days ago. The first five in the list were Quinn Whittock, Jeanne Bourgoint, Fulton Schools, Jane S. Jaquette, and Adam Kout. It took me less than five minutes total – I timed it – to determine that all five were real, non-hoax subjects, with real sources. None of them are deletion worthy; in fact, every single one of them is longer and better sourced than the median Wikipedia article. If an NPPer wants to do a quick check for copyvios (which I didn't bother checking because I didn't have the link handy) and LLM use (which I'm not skilled at spotting), then all five of these could be marked off the list.

The Wikipedia:New pages patrol/School approach doesn't work that way. It begins from a position of doubt: doubt the subject, doubt the editor, doubt yourself, doubt that Wikipedia can survive if you ever make a mistake. Most NPPers don't actually mark articles as being reviewed, even when they've reviewed them for what matters. The idea is that it's best to do nothing than to risk making a mistake. After all, if you make a mistake, your reviewer right can be yanked – but if you don't take an action, nobody will ever know you looked at it, so they'll never say that you did it wrong.

According to the NPP school, I've failed because I didn't:

• "Successfully use the NPP flowchart"
• "evaluate articles against specific SNG criteria" (they all meet GNG, which is sufficient for all except NCORP, which didn't appear in my sample set)
• "Find...common Wikipedia practices when evaluating notability" (I know the communities practices. I've even written substantial parts of some of the notability guidelines. I don't need to "find" them.)
• "Identify and appropriately remedy copyright issues in at least 90% of instances" (because I didn't check)
• "Engage in appropriate and useful conversations with other editors about NPP" (sounds like one of those creepy companies that monitors what its employees posts on social media about their working conditions)
• "Appropriately apply warning templates to users"
• "Apply appropriate tags to article with at least 90% accuracy"
• "Understand NPP procedures and norms"
• "Correctly and efficiently use scripts while doing new page patrol"

But I think if you know what you're doing and you look at those five articles, you'll agree that my quick review ended up with the correct answer. WhatamIdoing (talk) 20:23, 19 July 2026 (UTC)

File:Simplified NPP flowchart for articles.png is said flow chart. (You missed the first and last main steps.)

That said: What should NPP's job actually be, is it just finding articles that are CSD candidates and letting the rest through? Is it to do GNG and SNG checks on top of that? Should tagging things with {{uncategorized}} or whatever else be part of it as it seems to be? If the entire purpose of it is to simply find the junk articles and tag them for CSD then it's basically just a sub-project of CVU. If it's to ensure all articles meet GNG/SNG then it feels like AfC review is a subproject of NPP. If they are actually meant to understand and apply maintenance tags, then that's where we do need actual (basic) training or experience. Do you know if there's any good history of NPP that would explain what its intended mission is? I'd be happy to get an RFC on NPP going to ask which of those three it should be though. Jerod Lycett (talk) 05:45, 21 July 2026 (UTC)

Close this thread?

Apparently, auto-granting an NPP right has not gone well with the community here, despite trial alternatives. Shall this whole thread be closed then? George Ho (talk) 04:32, 20 July 2026 (UTC)

Yes. The "certain circumstances" item reminded me of John Templeton's famous saying: "This time is different" are the most expensive 4 words in investment. So no point in this. Yesterday, all my dreams... (talk) 02:50, 21 July 2026 (UTC)

@GrinningIodize: You okay with the whole thread being closed then? George Ho (talk) 03:07, 21 July 2026 (UTC)

I suppose that's alright with me. GrinningIodize (articles without a Wikidata item) (talk) 14:59, 21 July 2026 (UTC)

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

Preventing citogenesis when recreating deleted pages

I happened to stumble across the deleted page Albert P. Halfhill, the person who supposedly invented American-style canned tuna fish. Formerly a Good Article, it was deleted due to presumptive copyvio. I would like to recreate it by writing non-copyvio content based on reliable sources. Unfortunately, since I cannot view the previous state of the article or even when the article was created, it is difficult for me to be certain that potential sources did not draw their information from the article while it was still online. Which leads me to a thought: when deleting a page for copyvio (or other issues unrelated to notability, for example LLM use) would it be a good idea to set a precedent of copying at least the citation list to the talk page and leaving that up? Or is there another way to mitigate citogenesis resulting from bad content continuing to be reproduced elsewhere after we delete it here? -- LWG ^{talk (VOPOV)} 17:37, 16 July 2026 (UTC)

Please go to Wikibin and search halfhill [1], you will get the article. Yesterday, all my dreams... (talk) 18:13, 16 July 2026 (UTC)

Or use Wayback Machine[2]. sapphaline (talk) 10:33, 19 July 2026 (UTC)

WP:REFUND won't post copies of copyvio articles on wiki, but you could probably get an admin there to post or e-mail just the list of sources for you. WhatamIdoing (talk) 20:26, 19 July 2026 (UTC)

But why bother with that when Wikibin or Wayback will do it in 15 seconds. Yesterday, all my dreams... (talk) 02:46, 21 July 2026 (UTC)

It's often best not to inadvertently bias yourself to the now deleted article's text/structure by viewing it directly, and external internet archival services often may not be complete. GreenLipstickLesbian💌🧸 03:48, 21 July 2026 (UTC)

Wikibin triggered my antivirus software, which seems a bad omen. CMD (talk) 02:59, 24 July 2026 (UTC)

Do you use Norton or what? My Android tablet did not complain. But thanks for the info, I will not use Wikibin again. Wayback should be ok. Is there a Wikilist of problematic sites? Yesterday, all my dreams... (talk) 15:32, 24 July 2026 (UTC)

I'm only aware of WP:ATODAY, which is just the one site. WhatamIdoing (talk) 16:09, 24 July 2026 (UTC)

Oh, a Doug Coldwell article, aka the reason the GA system got a massive reform! Don't assume anything from it being a GA.

There's too many articles deleted for your idea to be practical, and we've got pretty solid consensus behind WP:G8, so I don't think this is desired by the community. In addition, I believe that in in cases involving POV pushing/UPE that often get swept up in something like G5 or even CPN, biasing future editors to a bunch of cherrypicked sources would be bad. However, this is something where you can just ask any admin in Category:Wikipedia administrators willing to provide copies of deleted articles for the citation list, and they'll (almost certainly) oblige. Given the article creator, though... don't bet on any of the sources being good, usable, or appropriate for the claims he made in the deleted article. I'm really not sure how a list of sources used in the old article would prevent citogenesis, either. When I was working on an old Doug Coldwell article where I suspect he added misinformation picked up by modern sources, knowing which sources he used did not help me with that. GreenLipstickLesbian💌🧸 23:55, 19 July 2026 (UTC)

I think the idea is that the sources predate the creation of the article, so they can't be citogenesis Katzrockso (talk) 01:25, 24 July 2026 (UTC)

Yes, this. Without knowing when the copyvio/inaccurate material was introduced, I don't know what my cutoff date is for knowing that an external source didn't get their info from here. -- LWG ^{talk (VOPOV)} 01:49, 24 July 2026 (UTC)

I mean, if the sources pre-date the article, then they're fine anyways, barring normal rules on reliable sources? And even if they were cited in the article, you'd have to know which got added first: the info or the sources (a la xkcd:978) to rule out citogenesis. GreenLipstickLesbian💌🧸 08:15, 24 July 2026 (UTC)

Maybe I'm just dumb, but is there a way for me to view when a deleted article was initially created? Also if, say, the article was a stub from 2011 to 2021, then a bunch of info was added in 2021, then if I find that info in sources from 2018 I can probably use them but if I find it in sources from 2022 I probably won't. -- LWG ^{talk (VOPOV)} 15:19, 24 July 2026 (UTC)

From what I have seen, you are not dumb. But within Wiki, unless you get admin help you can not see those. Wayback would give you help. Yesterday, all my dreams... (talk) 15:29, 24 July 2026 (UTC)

There's nothing inherently wrong with using the same sources as a deleted draft, and copyvio doesn't normally produce false information (which is what we'd be concerned about for WP:CITOGENESIS). WhatamIdoing (talk) 16:11, 24 July 2026 (UTC)

Isn't there a massive problem in this: if you're going to assume that all sources after a deleted Wikipedia article are potentially based on the deleted article and therefore inadmissable, then any deleted article automatically marks the end of all improvement of human knowledge on the subject! Deleting an article shouldn't force all future works on the subject to be deemed unreliable. Elemimele (talk) 16:15, 24 July 2026 (UTC)

As always, the best defense to citogenesis is rigorous verification of reliable sources. There's always bad information that's still live, and whether or not the article has been removed doesn't really have any effect on whether or not external sources did their homework correctly. In fact, if they were written AFTER the article was deleted then they can't be citogenesis (unless their lazy research involves digging through archives, which seems to defeat the purpose). Plus as stated above copyvio isn't really a cause for concern here - subsequent sources would essentially be pulling the information directly from the copyrighted source. Citogenesis from a G15 deletion would be a lot more concerning. ChompyTheGogoat (talk) 02:19, 25 July 2026 (UTC)

unless their lazy research involves digging through archives Or their research involved reading other sources that copied content from Wikipedia. Anomie⚔ 18:23, 25 July 2026 (UTC)

Right, there's nothing inherently wrong, but it's still something to think about. There's a lot of websites (for example local newspapers or small-town government webpages) that I would normally use as a "good enough" source in the absence of something better, but if I'm using them as a source for a claim that was already in a wiki article I normally compare the potential source with the wiki article history to make a judgement call on whether I trust it, since a lot of sources in that quality tier uncritically repeat information from Wikipedia. The copyvio is only relevant because its the reason I don't have access to the article history. -- LWG ^{talk (VOPOV)} 16:27, 24 July 2026 (UTC)

You can. The easiest way only works if the article was created after late June 2018: check the creation log. (It'll be listed at its original title there, so you may have to trace back through page moves.)

That doesn't apply for Albert P. Halfhill, which was created on 23 May 2017. For that, you'll need to look at the publicly-available metadata here, which will give you everything admins can see except the edit summaries, actual text, page length, and anything about revision-deleted/suppressed revisions, albeit in an uglier and much less convenient form. (I'll add that the article was of similar length in its very first revision as it was just before its copyvio blanking, ie it didn't stay at stub length for years as you speculate.) There are at least two user scripts (User:SD0001/deleted-metadata-link, User:DreamRimmer/DeletedMetaData) that clean it up some; I haven't used either, so have no firsthand experience with them. —Cryptic 16:31, 24 July 2026 (UTC)

That's what I needed, thanks! -- LWG ^{talk (VOPOV)} 16:35, 24 July 2026 (UTC)

You can get the page length, sha1, and tags from the API too, e.g. [3]. Anomie⚔ 22:57, 24 July 2026 (UTC)

What else to do with WP:WikiProject Biography?

I rose my concerns about the (in)activity of WP:WikiProject Biography at WT:WikiProject Council (discussion link). I thought about inviting individuals into revitalizing the WikiProject, despite some activity at WT:WikiProject Biography. If neither merger nor marking this as semi-active is the answer, then what else shall be done about this WikiProject? George Ho (talk) 19:55, 18 July 2026 (UTC)

Nothing needs to be done about it. WhatamIdoing (talk) 20:28, 19 July 2026 (UTC)

Why not? Otherwise, why posting notices other than FA Reviews and Nominations and GA Reassessments? I don't wanna go to that project talk notice just to expect a thread to become dormant (i.e. without replies) until bot archival, do I? George Ho (talk) 20:42, 19 July 2026 (UTC)

I suppose the question is: what other kinds of discussions would you like to see happening at that page? Blueboar (talk) 21:09, 19 July 2026 (UTC)

More editors replying there, obviously, not just the same editor replying on any other threads. Too bad, as Johnbod said, the "Biography" scope is very broad.... or too broad for the WikiProject to manage anymore. Right? If WP:WPBIO can't be further split into other subprojects (as it might have had), then... (I think I already asked the question in my OP, didn't I?) George Ho (talk) 23:20, 19 July 2026 (UTC)

Splitting it into smaller subject areas is unlikely to result in more editors per page. Also, WPBIO has a handful of task forces, and if they're equally non-responsive, then that would be evidence against that idea, too.

Perhaps more to the point, the notices you've been posting at Wikipedia talk:WikiProject Biography shouldn't be getting responses on that page, because you're asking them to join an existing discussion elsewhere.

I've left a note at WT:BLPN to see whether we can get a few more people watching that page. WhatamIdoing (talk) 20:33, 20 July 2026 (UTC)

• A highly unpopular view: From what I have seen, a good number of projects are either dying or planning their own funerals. Somehow belonging to a project is no longer in fashion. Please do not ask me why. I do not know. I belong to no projects because I do not know what I will get out of it. Look at Wikipedia talk:WikiProject Computing, what would I gain by looking at it. Nothing. WikiProjects are fading out. Sad, but true. Anybody need a Kleenex to dry their eyes? Yesterday, all my dreams... (talk) 02:42, 21 July 2026 (UTC)

  I don't think that's very unpopular, the issue with funerals is that it takes a lot of effort to fold a WikiProject into another. CMD (talk) 04:01, 21 July 2026 (UTC)

  I fully agree. If anyone wants to work on merging up under-active WikiProjects, please drop by Wikipedia talk:WikiProject Council. We were working on the instructions for doing this at Wikipedia:WikiProject Council/Guide/Merging WikiProjects a while ago. It's pretty complicated. WhatamIdoing (talk) 16:51, 24 July 2026 (UTC)

  Yeah, I'm not entirely sure of the point of WikiProjects. Jerod Lycett (talk) 05:50, 21 July 2026 (UTC)

  I would say it depends on the project. I looked yesterday and found I have pages from 25 projects on my watchlist, but it has been years since I've seen anything from some of them. Some projects have little or no activity on their talk pages, but notices about new pages, drafts, AfD, move requests, etc, appear on my watchlist, a process which likely increases the number of editors looking at them. Some projects I follow have active communities who regularly discuss problems with and improvements to articles covered by the project, something I do not think would easily happen without the wikiproject. Donald Albury 16:38, 21 July 2026 (UTC)

  The various country WikiProjects, and specifically their "assessment tables", are useful for gauging English Wikipedia's coverage of them at a glance. Looking at Wikipedia:Version 1.0 Editorial Team/Iceland articles by quality statistics vs/ Wikipedia:Version 1.0 Editorial Team/Togo articles by quality statistics vs/ Wikipedia:Version 1.0 Editorial Team/Bhutan articles by quality statistics, one can tell that Wikipedia has a better and more in-depth coverage of Iceland—more and higher quality articles about it—despite Togo being much more populated, and that Wikipedia has nearly as much coverage of Bhutan as Togo even as it is 10× less populated. We can similarly gauge how comprehensive our coverage of say, artificial intelligence is by looking at and exploring that project's table.

  For usefulness beyond statistical analysis, I can only really think of Women in Red. It captures the spirit of what a WikiProject is supposed to be—multiple editors coming together and cooperating towards a common goal, rather than just using the project talk page just as a noticeboard. WP:WPVITAL tried doing something similar but wasn't really successful. TryKid ^{[dubious – discuss]} 17:29, 21 July 2026 (UTC)

  Depends on the project. Two of the topic-based ones WikiProject China and WikiProject Plants that I signed up to are pretty active in terms of conversations on the talk page. And one of the maintenance ones WikiProject Unreferenced Articles is also pretty active; very active for the three month-long backlog drives we run every year. Shamelessly opportunistic plug: you can sign up for the imminent August backlog drive right here. Cheers, SunloungerFrog (talk) 17:40, 21 July 2026 (UTC)

  Wikipedia:A WikiProject is a group of people who want to work together to help Wikipedia. This sometimes takes the form of specific goals, such as the backlog drive that SunloungerFrog linked to, but often it just means helping each other out informally. "Joining" isn't nearly as important as "participating", and most participation takes the form of providing advice ("What should I do with this?") and assistance ("Thanks for the note. I've handled it").

  As WikiProjects' talk pages are one of the places that people post to when they have questions, I recommend that experienced editors put multiple WikiProject pages on their watchlist. The quickest way to find those groups for most editors is to go to the main article(s) central to your area of interest, and see which WikiProjects are listed in the talk page's top matter. WhatamIdoing (talk) 16:39, 24 July 2026 (UTC)

  As a new editor I can absolutely see the potential value in projects, but I've ran across plenty that are in fact more or less abandoned, despite plenty of active editors with interest in the subject. What I don't know is why, or what can be done about it. I suspect it's related to the overall structure not being very effective at promoting engagement. Maybe some kind of central project hub would help. This proposal seems like it has some promise, if anyone follows up on it, but I'm picturing some kind of personalized feed showing activity from ALL the projects someone has chosen to follow, without having to jump around to look at each one. I think there's a lot of potential for improvements to userspace that would make it easier for people to track various parts of WP space that they're interested in. The current watchlist format is basically just fancy bookmarks. ChompyTheGogoat (talk) 02:52, 25 July 2026 (UTC)

  Mostly the problem is that to have a visibly active group, it needs to be very large (50+ editors), but the people who want to start them want niche subjects. We're recommending that we have a big Wikipedia:WikiProject Television (only 33 editors have it on their watchlists and actually looked at its talk page at least once during the last month), or even a broader subject (Popular culture? Media?), and they want to start WikiProject My favorite TV show which only aired in a non-English-speaking country for two seasons several years ago and nobody except me remembers it.

  Especially when newcomers try to start the pages, they tend to have a build it and they will come mentality: if the pages exist, then suddenly all five of the people on the entire internet who obsess about this show will show up at Wikipedia and dedicate their lives to expanding all eight of the articles. When we tell them that they have to recruit the editors first, because a WikiProject is a group of people and not a collection of pages (and cleaning up a bunch of scattered templates and categories when the group fails is a pain), they can't do it. They don't know how to recruit editors.

  Wikipedia:Database reports/New WikiProjects is the easiest way to find inappropriate "WikiProject" page creations. Redirects (including to user space) are fine. Pages created by one or two people can be userified. If the group's not going to fail quickly, then we need to see 6–10 editors involved from the beginning, and at least one needs to be very experienced with WikiProjects.

  I've estimated that merging up the groups until there's something big enough to be functional could be a full-time job for more than a year. Once you've done a couple of them, it's not super difficult, but IMO it's not fun work. WhatamIdoing (talk) 05:42, 25 July 2026 (UTC)

  I'm not talking about niche projects. I mean things like WikiProject Fungi or WikiProject Cities, that seem large and certainly have plenty of activity on related articles, but very little collaboration on the project itself. It seems to be an inherent issue with the structure of projects, not whether or not a specific topic has interest. ChompyTheGogoat (talk) 01:35, 26 July 2026 (UTC)

  When I go to WT:FUNGI, I see that people who ask a question can realistically expect a knowledgeable reply in less than a day. It's also not always the same person, which is a sign of there being an actual group there. It's on the watchlist of at least 25 active editors, which is another sign of people working together. What makes you think that there's something wrong with this group? What were you expecting to find? WhatamIdoing (talk) 04:13, 26 July 2026 (UTC)

  There's only a handful of questions, several of which haven't gotten useful responses, and plenty of past threads have been archived with no replies. ChompyTheGogoat (talk) 05:19, 26 July 2026 (UTC)

  I'm looking at this revision. There are 8 discussions. Six have received a reply. Two did not. One of those two explicitly said not to reply at WT:FUNGI. I will not attempt to judge whether the replies were subjectively "useful", but I think that is a good number of responses. WhatamIdoing (talk) 23:02, 27 July 2026 (UTC)

  I feel like it's usually me or Jts1882 who are answering questions on WikiProject Fungi (or most of the other organismal WikiProjects; I have them all watchlisted, and Jts1882 seems to have them all watchlisted as well). There are a couple other editors who monitor several organismal WikiProjects, but if Jts1882 and I quit editing I think many more questions would go unanswered. And most of the projects where we answer questions aren't directly in our editing interests. The only organismal projects that regularly have talk page threads with more than three editors participating are Tree of Life, Palaeontology, Plants and Birds. Plantdrew (talk) 18:20, 28 July 2026 (UTC)

  As someone who asked a question on WT:FUNGI a few days ago, and got a detailed and well-explained answer barely half a day later, I think their current activity level is just fine. I've also used other related Wikiprojects multiple times in the past as a way to get assistance with editors knowledgeable in a topic, and they have always been helpful. Having a place to ask questions to people familiar with a topic is invaluable.

  That being said, some of the less active Wikiprojects should probably be merged. ARandomName123 (talk)^{Ping me!} 04:28, 27 July 2026 (UTC)

  Um... Which less active Wikiprojects then? George Ho (talk) 04:35, 27 July 2026 (UTC)

  Most of the ones in Category:Semi-active WikiProjects. Wikipedia:WikiProject Knots as an example. ARandomName123 (talk)^{Ping me!} 04:41, 27 July 2026 (UTC)

  Some questions getting answers only proves that it isn't entirely dead. It still doesn't help the fact that many others don't. In one case (re cities) there was an ongoing debate over various aspects of an article that I was attempting to help mediate, and we were trying to get outside input for how people who work on city articles felt that they should handle the issues that were in question, to maintain consistency. In my short time here I've seen many other people point out that projects seem largely abandoned and they've rarely gotten help from them, at least in recent times. ChompyTheGogoat (talk) 04:38, 27 July 2026 (UTC)

  I'm fine with closing the ones that don't get any activity (ie. no discussion). The ones that do get activity should stay open. Since WPCITIES had some discussion in the previous archive only a few months ago, I think it should stay open. ARandomName123 (talk)^{Ping me!} 04:44, 27 July 2026 (UTC)

  I'm not saying we should close them. I'm saying we should try to promote more engagement (at least for the ones that aren't overly specific) so we can answer the questions that DON'T get replies and get more overall collaboration on the subjects. ChompyTheGogoat (talk) 04:48, 27 July 2026 (UTC)

  Maybe some kind of central project hub would help Like Wikipedia:WikiProject Directory? Or Wikipedia:WikiProject Council/Directory? Cheers, SunloungerFrog (talk) 05:56, 26 July 2026 (UTC)

  As I said, it would be more than just a simple list - more of an interactive feed to make it easier for people to monitor and engage with the projects that they've already joined. I don't think FINDING them is really the problem - although it wouldn't hurt if there was also some kind of automated suggestion to add articles to relevant projects. ChompyTheGogoat (talk) 06:08, 26 July 2026 (UTC)

  Hmm. Maybe you might find one of the Watchlist-related user scripts on WP:USERSCRIPTS a useful addition for your workflow. For me, a combination of the standard Watchlist and selective subscription to individual threads suffices for monitoring what I'm interested in on Wikipedia. I appreciate that you find the Watchlist deficient, but I'm not quite sure in what way. There's also c:User:Jack who built the house/Convenient Discussions for talk pages. Cheers, SunloungerFrog (talk) 06:45, 26 July 2026 (UTC)

  I'm talking about broad changes to help improve project engagement wiki-wide, not just for my personal needs. That's what idea lab is for, right? ChompyTheGogoat (talk) 06:49, 26 July 2026 (UTC)

  Well, and to highlight existing solutions that might help. Maybe you could expand on the nature of the hub or interactive feed that you envisage. Cheers, SunloungerFrog (talk) 07:00, 26 July 2026 (UTC)

  Something more like notifications, that could have grouped previews for all the project pages someone follows - such as "Wikipedia:WikiProject Fungi#Article alerts has been updated", "Wikipedia talk:WikiProject Cities has had # discussions created or updated" <collapsible list of each new/modified section, similar to how multiple comments to a discussion are shown under a top level notification

  If someone is in a dozen projects, this could allow them to easily skim any recent changes to all aspects of their various projects (with the ability to modify which parts they're subscribed to) and see what they might be interested in, without having to click around and view everything one at a time. ChompyTheGogoat (talk) 07:20, 26 July 2026 (UTC)

  On a related note, it's a pity that Mediawiki Flow (and more at Wikipedia:Flow) from a while ago never reached fruition, because it looked to do a lot of what you are proposing. Cheers, SunloungerFrog (talk) 05:12, 27 July 2026 (UTC)

  You might be interested in the system shown at Wikipedia:WikiProject Medicine/Discussions. WhatamIdoing (talk) 06:58, 27 July 2026 (UTC)

  Yeah, that's exactly the kind of thing I had in mind; just more centralized to track various projects simultaneously. People can easily skim for anything that catches their interest on subjects they've already chosen to follow - potentially with different sort options (chronological, grouped by project, etc). ChompyTheGogoat (talk) 07:04, 27 July 2026 (UTC)

What should Mentorship be?

As it currently stands it's simply a version of Teahouse. A mentee can choose to ask a question and it will be asked on your talk page for you to answer. There is an argument that allowing that instead of just having the question be asked at the teahouse makes it more comfortable since it is one-on-one.

However, as asilvering stated: I've wondered about this myself. I'm concerned that the mentorship program is not actually beneficial, on the whole, to mentees or to mentors. Mentees can get help faster at the Teahouse, and if someone answers incorrectly it is relatively likely to be corrected. Not so on a mentor's talk page.

The questions are not exactly common. I have 82 mentees assigned and have been asked two questions.

• [4]
• [5]

From what's been said at Mentorship noticeboard, that's about a normal amount of questions. The topic of the questions is a bit abnormal though: most are about how to write autobiographies it seems.

I'm not sure how much time/money/etc. the WMF continues to put into maintaining Mentorship, it could be negligible.

Ultimately, I'm not sure whether it should be left to just sit as is, or be changed into something else. Given that the dashboard provides a link directly to the mentee's contributions I am wondering if mentors should also be considering reviewing those. I'm also wondering what ideas may come up from those who haven't looked at it and don't realize just how little is involved. Jerod Lycett (talk) 06:11, 21 July 2026 (UTC)

Speaking as a mentor, I think that the option for a newly registered editor to contact a named experienced editor who has offered to help 1-1 is useful to have, particularly for those who might feel less comfortable posting in a heavily trafficked forum like the Teahouse. My experience is that most interactions are question then answer then nothing, which is fine. Sometimes the questions are irrelevant, in which case I ignore them, or reply with something like "Let me know if you have any questions about editing Wikipedia". A few involve a longer back and forth, which is fine too. Personally I would not choose to review mentees' contributions as a matter of course - that feels a bit stalkerish to me, and given the sheer number of mentees one accumulates, not really feasible to do across the board. Ultimately, I think it's up to the mentee how much they choose to interact, not the mentor, and for the mentor to respond in accordance with that. Cheers, SunloungerFrog (talk) 10:01, 21 July 2026 (UTC)

People vary enormously in how much mentoring (menting?) they want/need. I don't think they should be squeezed into a one-size-fits-all model. But please listen to people who have experience of this, from both sides, more than to me. I do not have the patience to be a mentor and I'm too set in my ways to be a mentee. Phil Bridger (talk) 19:08, 22 July 2026 (UTC)

As a mentor and mentee, I find mentorship very important. My mentor has been extremely helpful and explained a large amount of information. Having the option to get mentored is very important. In solidarity Dafootballguy Want to talk? 23:33, 23 July 2026 (UTC)

I have not signed up to be a mentor in large part because those linked questions are the sort I see pop up on my watchlist on the talkpages of other users. It almost feels like if I see an account with a talkpage redlink post to a user talk, it's a coin flip between asking to create an autobiography and random nonsense or test editing. (Having mentors actively hunt through their mentees contributions seems like it's asking for a lot more effort than intended, and also would turn mentorship into more of an enforcement role.)

The Teahouse seems like it would be a better location for almost all of the questions (using a very broad definition of the word "questions") I see on my watchlist. However, the Teahouse currently has a "Meet your hosts" button. Why not a "Meet possible mentors" button? Introductory questions at the Teahouse, if someone wants to go more in depth in a less public space, the one-on-one option is available. CMD (talk) 00:42, 24 July 2026 (UTC)

As I mentioned in an above discussion (which I'm not going to attempt to dig through again, but it's there if anyone wants to look), I've found Teahouse far more helpful as a new user, and have never contacted my own mentor for that reason. It might be more useful to add some crosspost/auto-tag feature, so that people can ask the question on Teahouse and their mentor can be notified that the mentee has a question. There are times when it's helpful to have more of a one on one dialogue, and there could still be the option to ask directly on a TP, but for me it's usually been more a case of spinning off to talk to someone directly on either my TP or theirs after they responded to my original question. You're polling a wide pool of experience by asking at Teahouse so there's a much better chance that one of the many people who sees your question will know about it, even if it's highly specific - in addition to other new editors being able to see and learn from the answer(s) too. ChompyTheGogoat (talk) 03:03, 25 July 2026 (UTC)

How are mentors assigned? I never got one. (I also don't have very many questions, but I also do a unusal ammount of reading policies, to the point where I have spent more time reading stuff in the Wikipedia mainspace than editing in the article mainspace). Velocifyer (talk) 14:32, 29 July 2026 (UTC)

@Velocifyer You can see your mentor at your Special:Homepage, if you have that enabled. CMD (talk) 14:36, 29 July 2026 (UTC)

Add AI Content Moderation, Add a Head Person for every role.

“But Wikipedia isn’t a democracy!” I know, but who is the BEST at it gets to be a head. Look for Em-dashes ANYWHERE. Banana113 (talk) 00:30, 22 July 2026 (UTC)

Have you found anything that is a problem? The dashes are only a symptom. Our real issue is false and unencyclopedic text and fake references. Graeme Bartlett (talk) 06:36, 22 July 2026 (UTC)

Just a passing comment that the real issue may be that the curve representing the number of Wiki articles has moved upwards much faster than the curve representing the number of active users interested in cleanup. Hence we have too few eyes on too many articles. The problem has been exacerbated by two other factors. Everyone wants a Wikipage for their cousin and the use of LLMs. Alas I do not have a solution to suggest. Yesterday, all my dreams... (talk) 10:49, 22 July 2026 (UTC)

Mostly LLMs, because non-notable articles written by inept users are much easier to spot and more likely to get flagged as vandalism than polished LLM versions. I'd bet every penny to my name there's a direct correlation between rate of article creation (especially those that are denied/deleted) and public access to LLMs. ChompyTheGogoat (talk) 04:20, 25 July 2026 (UTC)

Wikipedia is a democracy in denial that's what it is. And one thing we don't want is leaders and vertical processes making decisions for the community. Another thing we don't want is, okay you probably guessed it already. Chaotic Enby (in solidarity · talk · contribs) 10:43, 22 July 2026 (UTC)

please say whatever it is you are trying to say directly Gnomingstuff (talk) 01:19, 24 July 2026 (UTC)

User appears to be a troll, and possibly a sock. ChompyTheGogoat (talk) 04:39, 25 July 2026 (UTC)

Wikipedia is actually one of the few places where I would regularly come across em-dashes before AI/LLMs took off. I would even theorize that the reason AIs tend to use em-dashes so often is because of Wikipedia. Em dashes were always available on the edit toolbar in the source editor, and our manual of style has a whole section on where to use them. --Ahecht (TALK
PAGE) 14:32, 28 July 2026 (UTC)

Restrict use of minor edit button

Why don’t we restrict it to rollbacks and edits that are between -200 and +200 bytes? _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 21:06, 25 July 2026 (UTC)

Why should we? For example this would prohibit marking Special:Diff/1363524700 as minor because it's +212 bytes, when no one needs to review it. Tenshi! (Talk page) 21:15, 25 July 2026 (UTC)

minor edit have nothing to do with the size of the edit, but the meaning of the actice. see help:minor edit Lavender-wikigirl (talk) 21:25, 25 July 2026 (UTC)

I know. That said, misuse is more common than correct use (I think) when adding or removing 200+ bytes. _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 01:50, 26 July 2026 (UTC)

The minor edit button would be useful if it were restricted to experienced users who routinely used it when performing mundane tasks. Then the filter "Hide minor edits from the watchlist" would make sense. Doug butler (talk) 22:05, 25 July 2026 (UTC)

Agreed - the biggest issue with it seems to be misunderstandings about "minor" referring to size rather than meaning (as with this question), followed by a smaller number of trolls trying to hide vandalism. Limiting it to EC users would probably eliminate the majority of that, so that all edits by newer editors are more likely to be reviewed. Maybe a pop-up asking them to read and confirm they understand Help:Minor edit the first time they gain access to it - I don't think most people notice or care that it's linked next to the checkbox, given the number of questions like this that we see. ChompyTheGogoat (talk) 01:44, 26 July 2026 (UTC)

No, I know that it is about the meaning, but when I see something somewhat like “(-387) . . (fixed typo)”, it feels like something fishy is going on. If it legitimately is a minor edit, it should be explainable in the edit summary. When reviewing, false positives are much better than false negatives. _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 01:48, 26 July 2026 (UTC)

That is one of the Wikipedia:Canned edit summaries, so it's not unreasonable to always consider that edit summary to be guilty until proven innocent.

Would you like it if the minor-edit thing simply wasn't visible to you at all? I (like many experienced editors) turned off the "Hide minor edits" thing in Special:Preferences#mw-prefsection-rc-changesrc years ago, which is enough for me, but I believe it's actually possible to make it invisible in CSS, so you'll never know again whether someone misused the unimportant box. WhatamIdoing (talk) 04:18, 26 July 2026 (UTC)

Fishy is fishy, regardless of length - you can completely flip the meaning of something just by adding or removing "not". Limiting use to EC would minimize such misuse, though nothing can eliminate it entirely. I see more of the GF mistaken uses than intentional abuse. ChompyTheGogoat (talk) 04:30, 26 July 2026 (UTC)

If the concern is abuse, why not limit it to semiconfirmed users? Amyipdev (talk) 00:44, 28 July 2026 (UTC)

I would much rather limit it to WP:Autopatrolled editors, since they are editors where we have explicitly said that we trust their edits enough that they don't need further review. --Ahecht (TALK
PAGE) 14:28, 28 July 2026 (UTC)

I think that would be a bit much - as I've said above my personal observation is that it's mostly accidental misunderstanding of "minor" rather than intentional abuse, and limiting it to EC would ensure they've been around for a minute to get a feel for things, as well as stopping the more obvious trolls that don't take time to build up an account. A lot of newish users that are EC but not autopatrolled gain experience gnoming, and those are exactly the type of small good edits that we don't need to be clogging watchlists with. It's not as if minor edits never get eyes on them; it effectively just lowers the priority of checking them. Autopatrolled is a much higher bar that green flags entire articles. Conversely, I don't think that only limiting it to autoconfirmed (which I believe is what the above user meant) would have any significant impact. ChompyTheGogoat (talk) 14:55, 28 July 2026 (UTC)

Some anti-vandalism tools mark reverts of vandalism as 'minor'. WhatamIdoing (talk) 15:32, 28 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)

Making Multiple issues's tag color change depending on the highest tag ranking of any of the issues under it

I have opened a discussion on Template talk:Multiple issues to change the tag color of the template to whatever is the most severely colored tag in the issue templates under it. Right now, it defaults to orange. Under my proposal, it would be yellow if all the issues are yellow, orange if at least one was orange, and red if at least one was red. This is an issue since tag colors are often used as a quick shorthand to deal with article quality, and the standard orange template can frequently underestimate or overestimate the problems of an article (especially if it has a lot of issues). I am posting here to get broader community input (and specifically in the idea lab section since I'm not sure how technically feasible this is). — Knightoftheswords 05:16, 27 July 2026 (UTC)

This comment indicates that it's not feasible, so it may not be worth discussing.

I don't think this is important. I wouldn't object if it happened; I just don't care. WhatamIdoing (talk) 15:34, 28 July 2026 (UTC)

Quick note per my response in the discussion, I have tested an implementation and it is possible. FlammablePizza (talk) 18:45, 28 July 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 [6] 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)

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

We need to do something about the scourge of fake footnotes

I don't mean footnotes leading to dead links or fake sources. I mean literally the kind of thing found in, for example, Damas Gratis, bolded for emphasis here:

The music and rhythm of the Damas Gratis group continued to advance until it transcended the limits of tropical music, as reflected in various articles published in the main newspapers of Argentina such as: Clarin, La Nación,[4] El País,[5] Buenos Aires Herald and magazines of the magnitude like Rolling Stone[6] that also dealt with this phenomenon that revolutionized the tropical scene.

That [4], [5], and [6] lead nowhere and refer to nothing discernible. There is no [1], [2], or [3] there, by the way, but there are some later numbers further down. I have seen at least hundreds of articles with notations such as these, almost certainly copied from someone's school paper or external draft. The need to be rooted out and exterminated, and any editor in the habit of adding them needs to be soundly trouted. BD2412 T 03:33, 29 July 2026 (UTC)

For your given example, it seems like the user translated the Spanish Wikipedia article of w:es:Damas Gratis to English (probably by copying/pasting the text into Google Translate or something). Compare the English Wikipedia version[7] with the Spanish Wikipedia version [8], for instance. Seems like the user didn't carry the sources/references over. Some1 (talk) 03:54, 29 July 2026 (UTC)

It is curious how the user in their edit used wikiformatting for the lv2 header but <big></big> tags for the lv3 headers. Nonetheless, it seems the user was a very short-lived SPA, a trouting may not be useful. It does seem like detecting this could be a useful maintenance cat, most instances are going to be copying, either from someone's school paper or from another wiki. CMD (talk) 05:14, 29 July 2026 (UTC)

I am sorry but the subliminal mentality in that message is that we human beings need to monitor these footnotes. Alas we do not have enough troops to do so. But a bot could do so for sure, without significant effort. However some of those who can write such bots are busy dealing with useless discussions. So please invoke WP:HEAR to end that discussion then talk Anome into writing the bot. Twenty years ago I would have written the bot myself, but not now. I need to go back to my rocking chair. So please rely on bots. Cheers. Yesterday, all my dreams... (talk) 05:07, 29 July 2026 (UTC)

In WikiProject Unreferenced Articles, ARandomName123 runs a bot to detect "probably unreferenced articles" (see the full list in PetScan here) and we include those in our backlog, to be dealt with in due course. In the past, I have come across a few articles like this in the "probably unreferenced articles" list. It is interesting though that this particular one is not in the list. @ARandomName123, if you had the opportunity, would you mind looking at why this one hasn't been caught in our net? Maybe there is some logic that could be tweaked. Cheers, SunloungerFrog (talk) 05:27, 29 July 2026 (UTC)

We could have a bot search for and flag articles with fake footnotes. There could be rare false positives (e.g. Hyperoperation), however. –LaundryPizza03 (dc̄) 06:10, 29 July 2026 (UTC)

Would the bot just tag them or would it revert the edits? Velocifyer (talk) 14:15, 29 July 2026 (UTC)

In addition, we'd have to cap the number inside the brackets at 3 digits, since years in square brackets are a standard citation format in British law. Fortunately, articles with 1000 or more distinct numbered references are exceedingly rare; I'm not sure if any exist on enwiki. For comparison, the current revision of United States has 686. –LaundryPizza03 (dc̄) 06:18, 29 July 2026 (UTC)

Enwiki has 5 articles and ~25 lists with over 1000 references, per WP:MOSTREFS. There is even one list with over 2000 references, so while exceptionally rare (about 0.00004% of articles), they do exist. I don't think that British legal citations would be particularly prevalent, and would arguably be to similar to parenthetical referencing, which is a deprecated format per WP:PAREN, and thus should be removed anyway. Perhaps in the case of false positives, a template could be created to exclude the triggering content from the bot in the form of {{!fakeref|content}} or similar. Mitchsavl (talk) 07:48, 29 July 2026 (UTC)

Even so, I would seriously doubt that articles exist with more than a few hundred fake footnote indicators. BD2412 T 12:20, 29 July 2026 (UTC)

While I agree it is highly unlikely for an article to have a few hundred fake footnotes, I would not be surprised by an article with a few hundred references, but only one or two fake ones from a recent addition. Mitchsavl (talk) 12:49, 29 July 2026 (UTC)

Damas Gratis has multiple URLs in the external links section, all of which trip the bot as a potential reference. ARandomName123 (talk)^{Ping me!} 06:19, 29 July 2026 (UTC)

For that one, I reverted to a 2023 revision before a massive overwrite with zero references. It was likely machine-translated from eswiki using an LLM. –LaundryPizza03 (dc̄) 06:33, 29 July 2026 (UTC)

Thanks for adding the expand language tag as well. Haven't seen an llm leave references like that, although it is possible, but I've seen that before for simple google translate. CMD (talk) 09:53, 29 July 2026 (UTC)

It happens from time to time, although it's certainly not the most common way they mess up footnotes. (Vaguely seems to be more common with some LLMs than others, but haven't nailed down specifics yet.) Also something that humans can do on their own.

(The edit here doesn't seem like it involved AI, for what it's worth.) Gnomingstuff (talk) 13:10, 29 July 2026 (UTC)

These are almost always an indicator that the article was AI-generated. sapphaline (talk) 12:25, 29 July 2026 (UTC)

Or as Some1 notes above, translated/copy-pasted between windows or programs without paying attention. -- Reconrabbit (talk) 13:39, 29 July 2026 (UTC)

Using an insource: search [9] I find a lot of strange style choices using [], they include Bible verses, coordination numbers, symmetry group names, tennis seed positions. However World Surf League seems to have fake foot notes in tables. 2C-B and War crimes in the Syrian civil war have useless footnotes in quotes included in references. 1346 in Ireland has semifake footnotes, needs to convert to use ref tags. Graeme Bartlett (talk) 13:13, 29 July 2026 (UTC)

[10] would be a better search, though there's a ton of false positives. sapphaline (talk) 13:19, 29 July 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)