Edge Rewrite
everything Source code View original
// HTMLRewriter · presentation

This page was redesigned at the edge.

Cloudflare fetched the original article and streamed it through HTMLRewriter to apply an entirely new visual system without rebuilding the source page.

// request.cf · coarse context

A page that knows where it met you.

Only coarse request metadata is shown. This demo does not display or persist visitor IP addresses.

Country
US
Cloudflare location
CMH
Connection
HTTP/2
Language
Not provided

Ray ID: a248b2aa689c689d

Jump to content

Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPA)

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pumps
icon
Discuss existing and proposed policies
icon
Discuss technical issues about Wikipedia
icon
Discuss new proposals that are not policy-related
icon
Incubate new ideas before formally proposing them
icon
Discuss matters involving the Wikimedia Foundation
icon
Post messages that do not fit into any other category
Other help and discussion locations
I want... Then go to...
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute Requests for comment
...help using or editing Wikipedia Teahouse (for newer users) or Help desk (for experienced users)
...specific facts (e.g. Who was the first pope?) Reference desk
...to ask questions or make comments Questions
...to comment on a specific article Article's talk page
...to find my way around Wikipedia Department directory
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to view and discuss other Wikimedia projects Wikimedia Meta-Wiki


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Current status of translation tools considered harmful.

Moved from Wikipedia:Administrators' noticeboard § Current status of translation tools considered harmful.
 – voorts (talk/contributions) 21:46, 2 July 2026 (UTC)

First: I DO understand there are reasons Why_machine_translation_is_disabled_in_content_translation. That making it too easy to make crappy LLM-assisted translations is bad. But the current situation is making proper LLM-assisted translation unnecessarily way more difficult than it should be. With the LLM features disabled, the Wikipedia:Content translation tool is worse than useless. It's user-hostile. Felt this strongly at step 7-8 below, and also when citations wouldn't copy over (at step 4-6, below).

Proposal: Wikipedia:Content_translation_tool (uncrippled) should be available. On a limited basis, i.e. one-translation-to-draft-space-at-at-a-time-per-editor-with-1000+-edits.

If rehabilitating the tools is mostly opposed, the tool should be disabled/deprecated.

Post mortem:

  1. I noticed a redlink to Stalinon in List of withdrawn drugs. I noticed there was a french version of the page. I decided to translate it.
  2. I'm skilled in both the origin and target languages.
  3. So, I started with a machine translation from page on French 'pedia, performed by my browser's built-in translation feature. Because I intended to immediately refine it to proper English, so I added a {{under construction}} with an explanation.
  4. I thought the citations copied over, and it looked like they would, but after saving, noticed they didn't, at all. Ugh. See image Mirage:
    Screen Shot of Wikipedia GUI editor apparently ready to save the content of translated fr Stalinon page
    'Screen Shot of Wikipedia GUI editor apparently ready to save the content of translated fr Stalinon page, complete with all its citations'
  5. I scratch my head, wondering: "Glitch or are would-be translators being actively prevented from starting with a machine translation?" If intentional, it makes me want to abandon the effort. Is it?
  6. I decide that if the references (which I see will need fixing/refinement) can be moved over, I want to proceed. But I don't see how. I don't understand why they didn't make it.
  7. I tried to restart, using what Wikipedia:Translation led me to - Wikipedia:Content_translation_tool, assuming it would be helpful, but it's been crippled. With the LLM translation features disabled, the Wikipedia:Content translation tool is worse than useless. It's user-hostile. I see there's a CS1 translator module but I guess it's broken? Crippled? It's stated "all you need to do is copy the citation from the source and paste it into the en-wiki article, preview, fix any errors, and publish " - by this it's meant it has to be done citation by citation? Why? Seems like intentional discouragement - a violation of WP:bite.
  8. Very unpleasant feeling. Feeling bitten by editor-hostile documentation/process. I notice I better draftify the page, which I do.

Seems clear to me that blocking the LLM tool for ALL users violates our core principles. e.g. "As always, assume good faith." (WP:DNB guideline and WP:AGF).

I don't think the Wikipedia:Content_translation_tool should remain crippled (I guess I'm proposing revisiting that question I see was decided in 2016). How 'bout we make it available, say on a one-translation-to-draft-space-at-at-a-time-per-editor basis, ? If it is to be kept intentionally crippled (the LLM translation features are to remain disabled) then at least it should be disabled/deprecated so would-be translators don't have to find out the hard way they are being actively prevented from starting with a machine translation?

Support - as proposer. If I hadn't run into all these hurdles, I wouldn't be pissed off and would have finished the translation by now. -- RememberOrwell (talk) 01:39, 2 July 2026 (UTC)reply

Estimates are that, before machine translation was turned off, 95% of articles created with this tool were unacceptable without significant additional work. That's a very worrying figure, is there any evidence that this has changed over time? If we've only got a 5% usability rate then I really don't think it should be turned back on.
BTW AGF and DNB wouldn't apply to this situation, they're both behavioural guidelines describing the way that one editor should treat another editor. It doesn't mean that we presume editors can use certain tools competently (I think that's what you mean here?) In solidarity, Blue-Sonnet (I'm listening) 03:11, 2 July 2026 (UTC)reply
The source for this seems to be one user's informal experiment from 2016. Given the very rapid improvement of machine translation over this period, I don't think it's fair to assume we'll necessarily see the same issues. (We may see new ones, if the machine translation now incorporates LLMs that hallucinate instead of just making stupid decisions about idioms and so on). Rusalkii (talk) 15:54, 3 July 2026 (UTC)reply
Yes, we are seeing new ones. Gnomingstuff (talk) 17:04, 3 July 2026 (UTC)reply
No articles have been created with an (uncrippled) Wikipedia:Content_translation_tool in years. No?
Re. new ones: OKA "was mostly relying on cheap labor from contractors in the Global South". Relevance?
Also, what was the justification for moving this from where I posted it, and
What was the justification for not notifying me of the move? And Voorts , why exactly didn't it belong at AN? That's where previous discussions on this topic took place. RememberOrwell (talk) 17:47, 3 July 2026 (UTC)reply
AN is for discussing issues needing administrative attention. I don't know why these past conversations occurred at AN. As for notification, there's literally a link at AN to this thread and moving a discussion doesn't unsubscribe you from it. voorts (talk/contributions) 17:56, 3 July 2026 (UTC)reply
I was following precedent. Don't see why this isn't an issue needing administrative attention, now, even though discussion of the same issue was appropriate for there in 2016. OK. It seems my alerts/notifications glitched or I missed 'em-I'm getting them now but didn't see any initially. RememberOrwell (talk) 18:09, 3 July 2026 (UTC)reply
Linking for historical interest WP:AN/CXT. There are still very substantial numbers of unreviewed translations from that era, about which nothing is being done or will ever be done, because the community has made conflicting decisions on this. The speedy deletion criterion has been retired and the speedy draftification process withdrawn. The number of editors willing to follow the current process for dealing with them is exactly zero.
Is it feasible to make access to the AI-assisted content translation tool a granted user-right? I have no idea whether that could work.—S Marshall T/C 08:36, 2 July 2026 (UTC)reply
Shouldn't this be at WP:Village pump (proposals) rather than AN? -- LCU ActivelyDisinterested «@» °∆t° 10:17, 2 July 2026 (UTC)reply
I wondered that myself, I think it's because the original 2016 discussions took place at AN? In solidarity, Blue-Sonnet (I'm listening) 10:59, 2 July 2026 (UTC)reply
Editors can (and do) make bad machine translations in good faith. Taking steps to prevent this is not assuming bad faith since the behavior is not innately bad faith.
It's unclear how equally preventing ALL users from accessing a feature to prevent potential misuse is covered by Wikipedia:Please do not bite the newcomers. fifteen thousand two hundred twenty four (talk) 07:24, 3 July 2026 (UTC)reply
Intentional hurdles that prevent good machine translations done in good faith is assuming bad faith. Unless 'assuming bad faith' is understood poorly. RememberOrwell (talk) 07:23, 13 July 2026 (UTC)reply
The content translation tool was somewhat deprecated long before llms became involved, so the reasons were not "making it too easy to make crappy LLM-assisted translations is bad". Given that, I'm not following the framing that disabling llm tools is crippling the tool, or even the particular relevance of llms to this. The use of the machine translation tool is, as you felt, intentionally discouraged, and again this was long before llms became available. That aside, problems with the features of the tool are not under the control of the en.wiki community, as it is maintained by the WMF (mw:Content translation). CMD (talk) 08:41, 3 July 2026 (UTC)reply
The content translation tool was never deprecated at all. It's only the machine translation module inside it that was disliked, and it was largely disliked because it was accidentally enabled with no warning, and one person made a huge number of bad translations before we figured out what the problem was and stopped it.
The content translation tool itself solves two problems for us, namely getting the source of the translated article properly linked in the edit summary, and getting the article automatically linked in Wikidata. WhatamIdoing (talk) 01:14, 12 July 2026 (UTC)reply
Do you not understand a particular part of "I see there's a CS1 translator module but I guess it's broken? Crippled? It's stated "all you need to do is copy the citation from the source and paste it into the en-wiki article, preview, fix any errors, and publish " - by this it's meant it has to be done citation by citation? Why*? Seems like intentional discouragement - a violation of WP:bite." ? Your claim about framing isn't reflective of someone who understood that. The Wikipedia:Content_translation_tool - apparently better known as the "CXT tool" or "CT tool" (?) has been crippled. Disabling machine translation tools (including llm tools) the CXT tool generally relies on is crippling the CXT tool. Whether folks acknowledge seeing it or not.
  • Are you blaming that on the WMF?
Like the questionable, aggressive removals of my requests at https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#Current_status_of_translation_tools_considered_harmful. which leave me once-again feeling bitten by editor-hostile documentation/process.
Feels like the refusal to see that "As always, assume good faith." (which is policy) is not compatible with what is happening - - the blocking of access to the tool to anyone translating to English!
In other words, insisting my perceptions aren't valid feels like gaslighting. With tortured linguistic semantic claims. RememberOrwell (talk) 07:00, 13 July 2026 (UTC)reply
Not sure how you're reading gaslighting. Your perception, that there was discouragement, was correct. CMD (talk) 07:07, 13 July 2026 (UTC)reply
LOL. You're telling me what my perception is, and implying that when I tell you what my perception is, I'm wrong.
OMG. RememberOrwell (talk) 08:03, 13 July 2026 (UTC)reply
As someone who occasionally uses our Content Translation tool (translating from English) and patrols edits by others who do the same, I have to say that the Google translation service it uses has improved immensely over the last couple of years. Rather than pushing people toward general-purpose LLMs (which we cannot prevent), we should encourage them to use our in-house tool, with its two-column translation interface, instant preview, category editing, reference transfer, and other wiki-specific features. It also flags edits with too much unmodified machine-translated text and requires the user to confirm before publishing them. And yes, restrict machine translation to, say, extendedconfirmed users. The tool feels a bit abandoned, probably because WMF tends to respond best to pressure from this wiki—and there hasn't been much. Ponor (talk) 17:38, 3 July 2026 (UTC)reply
@Ponor When I try to use the in-house tool, I find no translation tool. What is this Google translation service it uses that you speak of? When I tried to use it, no translation occurred.
https://en.wikipedia.org/wiki/Special:ContentTranslation?from=fr&to=en&targettitle=Stalinon&page=Stalinon is where I tried to use it. Each time I clicked translate, it just copied the French over.
@Fifteen thousand two hundred twenty four: Umm... equally preventing ALL users from accessing a feature to prevent potential misuse is assuming bad faith of ALL users . RememberOrwell (talk) 17:58, 3 July 2026 (UTC)reply
That's what this req. for comments is about. There's this note on top of the tool on this wiki: »On the English Wikipedia this tool is limited to extended confirmed editors, and the machine translation component is disabled for all users«. See if this one works, @RememberOrwell: CT Croatian to French Ponor (talk) 18:05, 3 July 2026 (UTC)reply
Ah, so it ( machine translation component ) is only disabled for translation to English? Yes, I see https://it.wikipedia.org/w/index.php?title=Speciale:TraduzioneContenuti&from=fr&page=Stalinon&to=it works. (the link you provided did not work for me - for other reasons - "Il y a une traduction en cours par Ponor. ..."). RememberOrwell (talk) 18:29, 3 July 2026 (UTC)reply
Yes. On other wikis, the machine translation works as intended. I have used CXT for all of my translations, as I find it saves me more time than it spends, but it's very broken. Even if the initial machine translation bit worked, all the rest of your issues still would happen. In solidarity, asilvering (talk) 01:14, 4 July 2026 (UTC)reply
Please read my entire comment before pinging me, thank you. fifteen thousand two hundred twenty four (talk) 04:03, 4 July 2026 (UTC)reply
@RememberOrwell So we should make all editors administrators since denying non-admins access to the admin tools is assuming bad faith? --Ahecht (TALK
PAGE) 21:13, 14 July 2026 (UTC)reply
It seems the LLM tools have come a long way and https://meta.wikimedia.org/wiki/Community_Wishlist/W55 our policies haven't.
Is it a mod or admin who has intentionally made it difficult for someone, e.g. me, to, e.g. translate Stalinon from French to English. In any case, it's based on an assumption of bad faith that the system was changed to prevent ALL users from accessing a feature to prevent potential misuse.
Wondering if trying dphilipov/wiki-translate (https://github.com/dphilipov/wiki-translate) will help.
Hereby requesting access to the tool that's been disabled. RememberOrwell (talk) 19:51, 4 July 2026 (UTC)reply
Hello? RememberOrwell (talk) 06:37, 7 July 2026 (UTC)reply
What is happening technically that breaks (disappears) all the citations? Workarounds other than a manual process that seems more laborious than the creation of the original citations in the first place? RememberOrwell (talk) 06:41, 7 July 2026 (UTC)reply
Can you explain what you're seeing? WP:CX is intended to preserve citations. WhatamIdoing (talk) 01:16, 12 July 2026 (UTC)reply
Do you not understand a particular part of "I see there's a CS1 translator module but I guess it's broken? Crippled? It's stated "all you need to do is copy the citation from the source and paste it into the en-wiki article, preview, fix any errors, and publish " - by this it's meant it has to be done citation by citation? Why*? Seems like intentional discouragement - a violation of WP:bite." ? Do I need to be more specific?
I also wrote,"I thought the citations copied over, and it looked like they would, but after saving, noticed they didn't, at all. Ugh." Do I need to be more specific?
I identified the issue was when I tried to translate Stalinon from French to English. You can see the French version and you can see my work at Draft:Stalinon and Stalinon. Do I need to be more specific? Than the contributor note there? RememberOrwell (talk) 07:08, 13 July 2026 (UTC)reply
In other words, I'm asking: What is happening technically that breaks (disappears) all the citations, when I follow the 8 steps detailed in the OP? RememberOrwell (talk) 08:10, 13 July 2026 (UTC)reply
Yes, @RememberOrwell, I need you to be more specific. For example: you say "I started with a machine translation", but what exactly did you do? Which website or tool did you use? Did you copy/paste wikitext code into it, or did you copy/paste the whole URL in, or what? WhatamIdoing (talk) 19:29, 13 July 2026 (UTC)reply
You claim there's a workaround other than a manual process that seems more laborious than the creation of the original citations in the first place. I need you to document it if it exists. RememberOrwell (talk) 01:15, 14 July 2026 (UTC)reply
@RememberOrwell, please provide a link to that alleged claim. I'm not sure what workarounds are functional these days, and I don't remember saying anything about one.
What I'm offering here is my help to figure out what went wrong when you used machine translation on that article. I can't do that when you won't tell me what you actually did. "I started with a machine translation" isn't enough information to figure out how you ended up with empty ref tags. Something like "I opened the article in the visual editor, selected a paragraph, and used the ExampleTranslation Plug-In to translate it" might be. WhatamIdoing (talk) 01:37, 14 July 2026 (UTC)reply
"all you need to do is copy the citation from the source and paste it into the en-wiki article, preview, fix any errors, and publish " - I say this doesn't work. I read "WP:CX is intended to preserve citations." as implying it does. edit of revision where I tried. I say this shows it doesn't work. That was all the citations from the source. Fixing the errors seems un- do-able. Past 1st cite, errors are gibberish. Hidden comment (to save space) showing what I see: (see source) RememberOrwell (talk) 03:29, 14 July 2026 (UTC)reply
You weren't using WP:CX in that edit. Software that you're not using isn't going to do anything for you. WhatamIdoing (talk) 03:51, 14 July 2026 (UTC)reply
So you bringing it up just derailed the conversation. RememberOrwell (talk) 03:55, 14 July 2026 (UTC)reply
I have finally tracked down this "all you need to do" line to its origin in Wikipedia:Translation#Citation templates, and clarified that if you want the citation template to be auto-translated on this wiki, then you have to actually copy the wikitext for the citation (the bits beginning <ref>{{Ouvrage|prénom1=Corinne..., not the little blue clicky number in the reader view or the visual editor). WhatamIdoing (talk) 04:15, 14 July 2026 (UTC)reply
"all you need to do is copy the citation (i.e., the full wikitext code for the template, not the little blue clicky number itself) from the source article and paste it into the en-wiki article, preview, fix any errors, and publish." would be good advice if it worked when a bunch of citations are copied. But as my earlier comment below noted - https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)#c-RememberOrwell-20260714034900-WhatamIdoing-20260714013700 - it doesn't. You seem to have incorrectly assumed that https://en.wikipedia.org/w/index.php?title=Draft:Stalinon&oldid=1362101946 was made using an external website, without looking at it. It wasn't. I did take the full wikitext code for the templates and paste 'em into the en-wiki article. Got hot garbage.
I urge you to accept that I'm not wanting help using a severely crippled tool. I'm wanting a tool that isn't severely crippled. RememberOrwell (talk) 04:51, 14 July 2026 (UTC)reply
Okay, let me ask this a different way:
  • The French original contains this wikitext code:
    • Le Stalinon est conçu au début des années 1950 comme traitement contre la [[furonculose]]. La Stannomaltine, une spécialité pharmaceutique à base d'étain et d'oxyde d'étain<ref name=":2">{{Article|langue=|auteur1=Bonah Christian|auteur2=Gaudillière Jean-Paul|titre=Faute, accident ou risque iatrogène ? La régulation des événements indésirables du médicament à l'aune des affaires Stalinon et Distilbène|périodique=Revue française des affaires sociales|date=2007|issn=|lire en ligne=https://www.cairn.info/revue-francaise-des-affaires-sociales-2007-3.htm-page-123.htm|pages=123-151}}</ref>
  • The English draft contains this wikitext code:
    • Stalinon was designed in the early 1950s as a treatment for furunculosis. Stannomaltine, a pharmaceutical specialty based on tin and tin oxide<ref name=":2" />
If you actually copied the full wikitext code for the ref and the citation template from the French source article and pasted it into the English draft, then why does the English draft not contain the wikitext code? It only says <ref name=":2" /> without any of the {{Article|langue=|auteur1=Bonah Christian... bits. This is what I would expect to see if you copy/pasted the little blue clicky number instead of the wikitext code. WhatamIdoing (talk) 21:33, 14 July 2026 (UTC)reply
Umm...
The English draft I linked to contains this wikitext code:
<ref name=":2">{{Article|langue=|auteur1=Bonah Christian|auteur2=Gaudillière Jean-Paul|titre=Faute, accident ou risque iatrogène ? ....|pages=123-151}}</ref>
I don't know why you didn't use the link I provided and specifically directed you to, just above, but if you had, you'd see that code there. But doesn't matter.
What matters is whether you can show us a way to use a tool that isn't severely crippled, or just show us that you can. With steps or a screen recording. If so, great, but I don't think you can -- because such a tool isn't available. RememberOrwell (talk) 04:46, 22 July 2026 (UTC)reply
In this comment, you directed me to this version of the English draft. That version, which was created in the visual editor, does not contain the wikitext code for the Bonah source. Have a look at the wikitext code for that version yourself.
If the visual editor is randomly deleting sources that you actually put into an article, that really does matter, and for more purposes than translation. WhatamIdoing (talk) 16:33, 22 July 2026 (UTC)reply
Nope. You keep on with this derailing question: "why does the English draft not contain the wikitext code?" I don't care if it does (or not). This is all more derailing. And it snubs : What matters is whether you can show us a way to use a tool that isn't severely crippled, or just show us that you can. With steps or a screen recording. If so, great, but I don't think you can -- because such a tool isn't available. What I'm wanting isn't what you're offering. What I'm wanting is help to (figure out how to) use machine translation on articles (e.g. Stalinon) in a way that is not less efficient than using the tool if it wasn't crippled would be. I see no need for what you're offering. RememberOrwell (talk) 06:59, 27 July 2026 (UTC)reply
Okay, it sounds like you really, really, really don't care if refs are randomly being deleted from your articles.
Just so you know, if someone complains that your articles are unsourced, or if someone else gets bitten by this bug, I'm going to tell them that the reason the possible bug wasn't identified and fixed already is because you insisted that randomly removing refs from articles is unimportant. WhatamIdoing (talk) 20:27, 27 July 2026 (UTC)reply
Complete nonsense. I did no such thing. Please stop. RememberOrwell (talk) 19:40, 29 July 2026 (UTC)reply
You've repeatedly refused to answer the questions that are necessary to determine how your first draft came to have no valid refs in it. When I ask for the information needed to file a bug report, you refuse to answer the questions and say that it's "just more derailing". WhatamIdoing (talk) 20:51, 29 July 2026 (UTC)reply
I started with a machine translation from the page on French 'pedia, in other words, one performed by my browser's built-in translation feature. As I said earlier I "used an AI I don't recall to translate it". And, I just tried to retrace my steps and discovered this add'l info I am sharing with you about the AI I used. Don't recall what browser I was using at the time. But if there's any browser that results in a page that can be copied and saved with valid refs, I'd love to know; I'll use that. So, "you insisted that randomly removing refs from articles is unimportant" - is utterly backwards. RememberOrwell (talk) 00:58, 31 July 2026 (UTC)reply
See Draft:StalinonTest, in particular the screenshot within it. RememberOrwell (talk) 01:37, 31 July 2026 (UTC)reply
Big picture: This is just more derailing. What I'm wanting isn't what you're offering. What I'm wanting is help to (figure out how to) use machine translation on articles (e.g. Stalinon) in a way that is not less efficient than using the tool if it wasn't crippled would be. I see no need for what you're offering. RememberOrwell (talk) 05:06, 22 July 2026 (UTC)reply
It looks like what you ran into is that we can't automatically translate fr:Modèle:Article like we can fr:Modèle:Ouvrage because "Article" is also an English word and Template:Article is used for a different purpose so it's not available for citation auto-translation. For that particular template, you'd need to change the citations to use Template:Cite journal/French or Template:Cite news/French (it's not clear to me which is correct; both claim to correspond). Anomie⚔ 11:24, 14 July 2026 (UTC)reply
In an early edit comment, I wrote, "If the references (which I see will need fixing) can be moved over, I want to proceed." I don't see how figuring out what went wrong when I used machine translation on that article is going to help when the admins comments and actions indicate they're dead set on intentionally not fixing the problem and shutting down discussion of doing so. No point proceeding. You say I won't tell you what I actually did. Let's say https://en.wikipedia.org/w/index.php?title=Draft:Stalinon&oldid=1362101946 was, to the best of my recollection, the result of "I opened the article in the visual editor, selected the whole article, and used an AI I don't recall to translate it" and pasted the translation, commented " Machine translation from page on french 'pedia I'm about to refine to proper English" and saved. Seems I'm telling you what you already knew. So what's the point? RememberOrwell (talk) 03:49, 14 July 2026 (UTC)reply
Wikipedia's templates (all of them) are local to each wiki. External websites (e.g., DeepL Translator, chatbots, Google Translate) have no idea what to do with them. You're lucky that it even maintained the HTML description, which is why you got back a little blue clicky number instead of plain old text in the form of [1].
If you'd been using WP:CX, you'd get these benefits:
  • Most links would be linked to the correct article at the new language's Wikipedia. For example, in the first sentence of the French article has a link to w:fr:Staphylococcus, and it would have correctly linked to the English Wikipedia's Staphylococcus article.
  • Most templates, including all the main CS1-style templates, would not just exist, but 'translate' the parameters. The French Wikipedia's {{Ouvrage|prénom1=Corinne... would become the English Wikipedia's {{Cite book|first=Corinne... with a simple click.
  • Formatting is preserved. Some machine translation websites can do most of it, especially if you copy/paste from the visual editor instead of from the ordinary reader's view; however, CX can do almost 100% of it.
What you can't get in CX at this particular wiki is built-in machine translation. I think the community should change that, but in the meantime, have you considered to combining CX's features with copy/pasting each section at a time to your favorite machine translation tool? Given a paragraph of "blah blah blah blah[1]", you could click on the original (full text of the paragraph, plus links and templates), then copy just the "blah blah blah blah" part (leaving the 'translated' citation in place), run it through machine translation, and paste the results in just before the little blue clicky number. It's a bit slower, but you would get your refs.
You could even start the page with just the formatted refs and no other content, and then fill the paragraphs back in. WhatamIdoing (talk) 04:09, 14 July 2026 (UTC)reply
"What you can't get in CX at this particular wiki is built-in machine translation. I think the community should change that". Glad to hear that.
I urge you to accept that I'm not wanting help using a severely crippled tool. I'm wanting a tool that isn't severely crippled. And disgusted at the prospect of further - and by my actual attempts at - use of one that is. " It's a bit slower" - not seeing that. As I said, with the LLM translation features disabled, the Wikipedia:Content translation tool is worse than useless. It's user-hostile. I'm already many wasted hours behind and many other editors are countless more hours behind because of this ongoing crippling of the tool, IMO. "You could even start the page with just the formatted refs and no other content, and then fill the paragraphs back in" - not seeing that either - and if it did sort of "work", not seeing it as anything but user-hostile.
It feels important to reiterate: I offered two options, one of this was If rehabilitating the tools is mostly opposed, the tool should be disabled/deprecated. It's disturbing to see it ignored.
Admins, by ignoring even that option, are showing they don't value and are happy to squander editor time and intentionally frustrate editors en masse. I don't agree with, but can respect those arguing against going with the other option, which at least can be defended by arguing that it's better to block machine translation edits than improve upon them. Those (not you) arguing that it's OK to squander editor time and intentionally frustrate editors en masse with an 'it's not a WP:AGF violation' argument ... I don't have the words... RememberOrwell (talk) 05:17, 14 July 2026 (UTC)reply
To add to WhatamIdoing‘s comment, if the “Copy original content” option is used and the text is manually translated without removing the citation, the citation should copy over, provided the reference template exists in both languages. We’d be happy to enable machine translations, but it’s a community decision. The Wishlist mentioned in the conversion is being reviewed, and this ticket has been created. UOzurumba (WMF) (talk) 14:41, 14 July 2026 (UTC)reply
@UOzurumba (WMF), I think the question is "could machine translation be enabled for specific editors" (a technical question), not "could machine translation be enabled at all" (as you note, a community one). In solidarity, asilvering (talk) 15:26, 14 July 2026 (UTC)reply
Machine translation can theoretically be enabled for specific editors. It might require a bit of technical work, but I believe it would be small. However, whether to allow such a thing to happen is a community decision. WhatamIdoing (talk) 21:37, 14 July 2026 (UTC)reply
@Asilvering, enabling machine translation for specific editors would require further development or technical work. We currently have a per-wiki configuration option. As WhatamIdoing said, if there is consensus to allow it, the Language and Product Localization team can consider doing the technical work. UOzurumba (WMF) (talk) 18:47, 15 July 2026 (UTC)reply
Umm, how can that be true? I said earlier, "Access to the whole tool is already restricted to certain groups." In particular, per https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/CXT#c-Xaosflux-2016-07-31T04:27:00.000Z-Lower/Change_the_5000-Edit_Bar? (already linked to earlier in this discussion) was closed by xaosflux it was restricted to the extendedconfirmed group. I presume it still is, so if machine translation was enabled today, which would require no "further development or technical work", it would re-enable machine translation, but only for everyone with extendedconfirmed. If it was then restricted to admins, it would be available to just that group of editors. If I'm wrong, where is the error in this? RememberOrwell (talk) 03:58, 22 July 2026 (UTC)reply
Hello? RememberOrwell (talk) 04:58, 27 July 2026 (UTC)reply
Last I heard, restricting access to the whole tool was done via Special:AbuseFilter, by preventing people from saving finished translated pages into the mainspace. That method cannot be used to restrict access to buttons inside the CX tool.
If we wanted to have a system in which:
  • Wikipedia:Extended confirmed editors can use the CX tool without machine translation, and
  • a new user right – maybe we call it "authorized machine translation user" – meant that some editors could use the CX tool with machine translation
then that new user right has to be created, and the CX tool has to be adjusted to pay attention to it internally. WhatamIdoing (talk) 20:18, 27 July 2026 (UTC)reply
To my eye, the above (if anything) confirms that machine translation could be enabled today, in a way which would require no "further development or technical work". Reiterating that there's a way that would require more work doesn't change that. RememberOrwell (talk) 19:34, 29 July 2026 (UTC)reply
I'm quite sure there's a way. Access to the whole tool is already restricted to certain groups. Copyable code, surely would get the job done, if nothing simpler. How was it taken away, exactly? RememberOrwell (talk) 07:16, 13 July 2026 (UTC)reply
I believe the initial approach was an WP:ABUSEFILTER that refused to save translated pages in the mainspace. I believe that the configuration has changed since then. WhatamIdoing (talk) 04:19, 14 July 2026 (UTC)reply
The current status of the translation tools is harmful. The process is terrible, as my experience and the discussion thereof shows. Who is interested in improving it? Bold enough not to bury their head in the sand? to make or find and document or de-cripple the tool(s) available? RememberOrwell (talk) 01:24, 14 July 2026 (UTC)reply

Okay, so let's do that, for love of the encyclopedia and its many willing, experienced bilingual editors.--Carwil (talk) 12:39, 29 July 2026 (UTC)reply

I don't think there is any way to grant individual contributors access to the machine-translation aspect of the tool. In solidarity, asilvering (talk) 14:28, 7 July 2026 (UTC)reply

Continuation of ANI Discussion About MFD Relisting

There have been some issues raised at a discussion at WP:ANI about relisting of MFD discussions, and the discussion there seems to be winding down because maybe WP:ANI action is not required. I posted my questions a few hours ago to the MFD talk page, but I now see that it is not an active talk page, so I will mark these questions, which were not answered yet, as moved to VPP.

The original issue was that an MFD had been open for a week, and an editor relisted it, and another editor reverted the relisting, and the original editor objected, at WP:ANI. The conclusion appeared to be that the last time there was a discussion of whether MFD discussions may sometimes be relisted as in 2016, and an RFC concluded that relisting is still an option for MFD. There aren't very many MFDs at any given time, so that all of the MFD discussions are available on a single board, MFD. At least one editor objects to the relisting of MFD discussions because it rearranges the paperwork. At least one editor thinks that relisting of MFD discussions is sometimes useful because it rearranges the paperwork.

So I will ask here:

  • Should deletion discussions at MFD sometimes be relisted? There has been an RFC which said that MFD discussions may sometimes be relisted, so if there is a view that consensus has changed, is a new RFC warranted?
  • Should non-administrators be permitted to relist MFD discussions as a non-administrative closure?
  • Should the editor who relists an MFD discussion be expected to provide a comment explaining why they have relisted the discussion?
  • Should non-administrators be permitted to revert the relisting of MFD discussions? If so, when and why?

Robert McClenon (talk) 01:43, 3 July 2026 (UTC)reply

The answer to all of your questions is that MfD should not be treated any differently than any other XfD. Creating bespoke rules makes everything more confusing and there is no good reason for it. voorts (talk/contributions) 18:00, 3 July 2026 (UTC)reply
+1. Allow relisting. MFD closers shouldn't need to learn different rules about relisting than the other XFD venues. If a discussion has low participation or could benefit from more discussion, and hasn't already been relisted, then relisting is a standard and helpful tool in the toolbox. –Novem Linguae (talk) 03:42, 4 July 2026 (UTC)reply
When all the discussions fit comfortably on a single page, relists are just needless paper-pushing, which is why they're not the norm at MfD, DRV, or MRV. MfD is different from the other XfDs because it doesn't use daily log pages. I disagree with the 2016 RfC (which I wasn't aware of until a few days ago) and would say as much if someone decides to start a new RfC. Extraordinary Writ (talk) 19:21, 3 July 2026 (UTC)reply
While I take Voorts' point about consistency across processes, we do already use different layouts/structures for them, and subject nominations to a different set of deletion reasons. I guess I'm just not sure what the function of relisting is when there are only three nominations across the entire process. For reference, here's what MfD looked like on today's date in 2016, when that RfC took place, and here it is today. 62 nominations vs. 3 nominations. Now, 3 is low even by today's standard, but we haven't been anywhere near 62 in a long time, because drafts now have an automatic expiration date that they did not back then. To be clear, I don't think relisting hurts anything, either, but I just don't understand. — Rhododendrites talk \\ 19:31, 3 July 2026 (UTC)reply
I agree that maybe this relist wasn't particularly necessary, but I don't think that it hurt anything. I think reverting it was even less necessary. People shouldn't be getting verklempt over a single relist. voorts (talk/contributions) 19:45, 3 July 2026 (UTC)reply
I asked four questions. I will summarize what I think is being said:
1. Should MFD discussions sometimes be relisted? This is the main question. The 2016 RFC said that MFD discussions are no different from other deletion discussions and may be relisted. There are reasonable arguments that consensus has changed and a new RFC may be in order.
2. Can non-administrators relist MFD discussions? I think that the answer is that this depends on whether MFDs may sometimes be relisted. Otherwise, we do occasionally see non-administrative closes at MFD, and a relist is a closing action.
3. Should a comment be provided when relisting an MFD discussion? First, this depends on whether MFDs may sometimes be relisted. Second, in my opinion, if MFD discussions should sometimes be relisted, a comment should be provided. I agree that comment-free relistings at MFD are not helpful.
4. Should non-administrators be permitted to revert the relisting of MFD discussions? This was the original topic of the ANI report, but has not been addressed. I think that the answer is an unambiguous no, but I haven't researched whether there are non-admin reverts of relistings at AFD, TFD, or CFD.
It probably doesn't matter that MFD is like AFD in one respect in which they differ from TFD and CFD. Each AFD and MFD discussion is its own page in project space, while the daily logs are the unit pages in TFD and CFD.
Should we have a new RFC on question 1? If not, do we need to address questions 2, 3, and 4?

Robert McClenon (talk) 20:32, 3 July 2026 (UTC)reply

As a non-contributor to MfD who has read this thread, my answers to your questions are:
  1. MfD discussions may be relisted but most often probably shouldn't be, because it achieves little. There may be exceptions to the general rule where a relisting is beneficial so it would be counterproductive to prohibit these.
  2. Yes. Everybody may relist a discussion, but in most cases nobody should, per the answer to question 1. For the exceptions to the general rule it makes no difference whether the person relisting is or is not an admin.
  3. It depends. If it's unclear why a discussion is being relisted it should be accompanied by a comment, if it is clear then a comment is neither required nor prohibited.
  4. No. If someone is relisting inappropriately this is a user conduct issue that should be dealt with as a user conduct issue. I can think of only three reasons why a discussion might be inappropriately relisted and in neither situation does reverting the relisting help:
    • If discussion didn't need relisting because consensus was already clear, then just close the discussion according to that consensus. There is no minimum time between relisting and closing a discussion.
    • If consensus was not clear but discussion was ongoing, then the relisting might have been disruptive to that discussion but unrelisting will be at least equally disruptive. One disruptive event is better than two so just leave it be.
    • If consensus was not clear but discussion was not ongoing, just leave it be. Either the relisting will attract more input (in which case everybody wins) or it won't (in which case nobody loses).
In all cases though, if a relisting breaks any incoming links, create some sort of pointer or redirect so that people following them can find where the discussion now is. Thryduulf (talk) 21:47, 3 July 2026 (UTC)reply
Thumbs up icon — Rhododendrites talk \\ 22:49, 3 July 2026 (UTC)reply
@Thryduulf: MfD notices target a discussion subpage (as opposed to dates and anchors at RfD) similar to AfD. Thus—when a transclusion of an MfD subpage moves within the list on the main MfD page, no incoming links are broken and nothing needs to be altered in that regard. — Godsy (TALKCONT) 09:21, 4 July 2026 (UTC)reply
I agree with this, also as someone who rarely participates in MFD but is a regular at other XFD venues. My one amendment is that relisting comments should perhaps be more strongly encouraged at MFD than at similar venues. They should not be required but if the norm is to generally not relist, a brief explanation will be especially helpful. In one sense, this is the same approach that should be taken with all relistings—when the reason to relist is non-obvious, an explanation should be provided. —Myceteae‍🍄‍🟫 (talk) 16:27, 4 July 2026 (UTC)reply
Broadly agree with Extraordinary Writ, Rhododendrites, and Thryduulf. At such a small venue the main effect of relisting isn't to encourage further participation. MfD discussions are rarely poorly attended, and rearranging the order of discussions is not a fruitful way of pursuing that end anyway since old discussions aren't forgotten about. Relisting mainly functions to discourage closure for another week. That is generally most helpful where new information has arisen later in the discussion period that is likely to change participants' minds. I think in that instance a comment will always be useful. J947 ‡ edits 00:44, 4 July 2026 (UTC)reply
Granted, it is often not the case in practice, but a relisted discussion may be closed once consensus is determined, without necessarily waiting for another seven days (WP:RELIST). — Godsy (TALKCONT) 09:11, 4 July 2026 (UTC)reply
MFD is qualitatively different from every other deletion venue (unless you count DRV) in that it doesn't have daily subpages, so moving discussions around doesn't place them on a better-attended page. That's the sole benefit of relisting. With that gone, it's all downside. —Cryptic 00:54, 4 July 2026 (UTC)reply
I am going to defend relisting at MfD for several reasons:
  • Generality - After 7 days, relisting serves the purpose of bringing less-attended discussions, where consensus has yet to be achieved, back to prominence at the top of the page. Many times well-attended or complicated discussions tend to languish at the bottom of the list, despite having achieved a full or rough consensus. Separating these two major archetypes of discussions makes the ones that need attention more likely to get it, especially from contributors more familiar with other deletion venues. Relisting discussions also gives them a non-mandatory (relisted discussions may be closed at any time if a clear consensus develops as I quote from guidance to another comment above) additional 7-day time-buffer of sorts to allow a consensus to naturally develop without the discussion appearing in need of expedited closure in the old business section. Set time periods allow for a deeper, fuller consensus to develop (as opposed to a constant under-the-wire environment where, for example, a sudden change in direction prevails in a tight case where it otherwise would not have).
  • Parity with other venues - Driving more participation and expanding ease-of-access for the maximum possible userbase is a boon in general. Relisting is an expected feature of deletion venues; the average user may assume that the old business section consists of discussions ready for closure and wanting of one. This misconception is avoided if a discussion is at the top of the list. Of special note, users also should not be treated poorly or chided if they attempt to relist something in good faith because of such reasonable expectations.
  • Timelessness of venue - Whether or not MfD is experiencing a slump or boom, having a functioning relisting system makes the venue future-proof. The architecture of relisting (being slightly different from other venues and less automated) may otherwise decay and be unready when warranted. Take {{mfd relist}} and User talk:Legobot/2025#Miscellany for Deletion relisting which show an example of such deterioration. Right now, relists must be done manually.
  • Non-adminstrator relists and comment-free relists - Non-administrators who are (WP:NACD) experienced[,] ... uninvolved[,] ... [and] registered (WP:NADC) may close (or relist) ... discussions (WP:NACD). Relisting is a determination of non-consensus (i.e. that consensus has yet to be achieved). Non-administrators regularly relist discussions at other venues; it should be no different at MfD. It is less explicitly officially documented, but comment-free relists are standard (and perhaps preferred) practice when it comes to relisting. This should also not be any different at MfD than any other venue. The relisting comment field exists for the following reason:
    In general, a discussion should not be relisted more than twice. When relisting for a third (or further) time, or when relisting a discussion with a substantial number of commenters, the relisting editor should explain why they did not consider the current state of the discussion sufficient to determine a closure result (WP:RELIST).
More often than not, on the first (especially the first) or second relist, it is clear that the discussion is being relisted because consensus is (likely) split in different directions (i.e. yet to be achieved due to lack of agreement) and 'no consensus' closure is not yet appropriate. If there is a special circumstance, or something to note, then a relisting comment would certainly be appropriate.
That just about encapsulates my thoughts on the matter (though I may have forgotten some sentiments and will post again later if that proves to be the case).— Godsy (TALKCONT) 08:51, 4 July 2026 (UTC)reply
Mackensen made an argument regarding relisting comments being generally non-optimal in the discussion that this one stemmed from, which I elude to but do not explain in depth. — Godsy (TALKCONT) 09:46, 4 July 2026 (UTC)reply
@Robert McClenon: I would draw your attention to my fourth bullet point just above, with the hope of perhaps changing your opinion in regard to relisting comments. — Godsy (TALKCONT) 10:36, 4 July 2026 (UTC)reply
Generality - After 7 days, relisting serves the purpose of bringing less-attended discussions, where consensus has yet to be achieved, back to prominence at the top of the page
Undesirable, if there is no point in the relisting except to move it back to the top. The pointlessness of the relisting is evident in the lack of relisting comment on why it is being relisted. Moving an MfD discussion back to the top does not get it fresh eyes, but tricks the few regulars, who already saw it, already commented or already ignored it, in to thinking that there is a new nomination.
Godsy has many many good contributions at MfD, but sometimes exercises poor judgement. When challenged, he goes on an on, as previously, and refuses to concede a single point. SmokeyJoe (talk) 14:27, 11 July 2026 (UTC)reply
User:SmokeyJoe - If you don't know the gender of a user, you can use the singular they, which has been used since early modern English. Robert McClenon (talk) 03:17, 16 July 2026 (UTC)reply
Given that relisting is presently allowed at MfD per the RfC that has been cited, only a new RfC can overturn the old consensus, not discussion at VPP. I see no reason to discuss further rather than just open an RfC, assuming that nobody is going to change their mind at this point. voorts (talk/contributions) 22:22, 10 July 2026 (UTC)reply
“Allowed” is a weak defence. Relisting is normal at MfD, but pointless comment-free relisting is not. Only Godsy does it. I object to him doing pointless comment-free relisting. It does no good, and it does some harm. SmokeyJoe (talk) 14:30, 11 July 2026 (UTC)reply
We all understand your position at this point. Your position is presently against cosnensus established by an RfC. voorts (talk/contributions) 15:52, 11 July 2026 (UTC)reply
If it's true that only one (1) person does this (e.g., over the course of several months or a whole year), is what that person does really the community's practice? WhatamIdoing (talk) 19:32, 13 July 2026 (UTC)reply
It's not just one person. I'm fairly certain I've relisted discussions at MfD. voorts (talk/contributions) 20:39, 13 July 2026 (UTC)reply
Relisting at MfD is normal and fine. But is it normal and fine to sporadically do comment-free pointless relisting, be told that your pointless comment-free relistings are a negative, to insist that it’s “allowed” by some guideline, and to insist on continuing? SmokeyJoe (talk) 21:34, 13 July 2026 (UTC)reply
Your view that comment-free relistings are inappropriate (especially in general) is a minority viewpoint (if not a vast minority viewpoint). It is overwhelmingly accepted that relists, on the first (or even second), have an inherent purpose that need not be spoken (or rather written) through a comment. I have expounded upon this at-length above. You are seemingly the only contributor that has a (at least major) problem with them, as evidenced here (aimed at others besides me). You have been a contributor at MfD for a long time and have done a lot of good work there. However, your viewpoint in this case does not overrule several well-documented discussion closes and guidelines etc. (again above) established through community consensus. Your view should not be conflated as more than that or be implied to be the view of the community. As far as sporadicity, I have periods of more or less activity, as do many contributors (appropriateness of relisting, however,—bar new community consensus—remains the same). — Godsy (TALKCONT) 01:39, 16 July 2026 (UTC)reply
My particular view relevant is that most of your (singular you) comment-free relists at MfD are completely worthless, and of negative impact to people who pay attention to the size of the backlog.
I’ve asked you to stop.
You don’t reply to the substance, but respond verbosely off topic, ad nauseam, to use your word choice.
- SmokeyJoe (talk) 01:53, 16 July 2026 (UTC)reply
Maybe nobody else thought that she needed to stop. Any editor can ask another editor to do anything. Sometimes the asking can be ignored. Robert McClenon (talk) 22:28, 17 July 2026 (UTC)reply
I acknowledge this point. It is a relatively low level issue. My previous challenge was rebuffed, which is why I felt the revert was justified. And here we are, still with the question unanswered, “why do this relist?”. And I believe that “Because rules allow it” is not a reasonable answer. SmokeyJoe (talk) 23:57, 17 July 2026 (UTC)reply
I have started an RfC below. If you have already set forth your views in full in this discussion, I suggest distilling them into a concise !vote and referring editors to your comments above. voorts (talk/contributions) 02:06, 16 July 2026 (UTC)reply

RfC: MfD relists

Should comment-free relists be allowed at MfD? 02:01, 16 July 2026 (UTC)

Notified: Wikipedia talk:Deletion process, Wikipedia talk:Miscellany for deletion and Wikipedia talk:Deletion policy. voorts (talk/contributions) 02:05, 16 July 2026 (UTC)reply

Background

Survey re RfC: MfD relists

  • WP:RELIST, which applies to all XfDs, states: "When relisting for a third (or further) time, or when relisting a discussion with a substantial number of commenters, the relisting editor should explain why they did not consider the current state of the discussion sufficient to determine a closure result." Otherwise, a relisting comment is not required. I do not believe there is sufficient reason to treat MfD differently from other XfDs. We shouldn't create arbitrary exceptions to guidelines, particularly procedural ones. voorts (talk/contributions) 02:01, 16 July 2026 (UTC)reply
  • Someone is repeatedly removing my !vote from here. Please stop it.
    Of course. The question is the wrong question. A better question is: What should be done when an editor repeatedly exercises bad judgement in relisting? SmokeyJoe (talk) 02:07, 16 July 2026 (UTC)
    This is a wiki. Many things are “allowed”, technically, even if not a good idea. Good judgement is required. People without good judgement should be less bold. —SmokeyJoe (talk) 06:36, 16 July 2026 (UTC)reply
    I moved your "!vote" below and responded to it there, where you also responded. This is the "yes" section in response to the survey, not a place for you to continue to make inappropriate comments about other editors. voorts (talk/contributions) 20:13, 16 July 2026 (UTC)reply
  • Yes. Comment-free relists are standard (and perhaps preferred) practice when it comes to relisting. This should not be any different at MfD than any other venue; bringing a discussion to the top of the list is a valuable action which has a net-positive affect on the deletion backlog by being an attention-drawing boon for the vast majority of contributors. The relisting comment field exists for the following reason:
    In general, a discussion should not be relisted more than twice. When relisting for a third (or further) time, or when relisting a discussion with a substantial number of commenters, the relisting editor should explain why they did not consider the current state of the discussion sufficient to determine a closure result (WP:RELIST).
More often than not, on the first (especially the first) or second relist, it is clear that the discussion is being relisted because consensus is (likely) split in different directions or the discussion is under-attended (i.e. consensus has yet to be achieved due to lack of agreement or participation) and 'no consensus' closure is not yet appropriate. Otherwise, a constant under-the-wire environment with no semi-firm time limits is fostered (which serves as an adversary to achieving natural, full consensus). If there is a special circumstance, or something to note, then a relisting comment is certainly appropriate. — Godsy (TALKCONT) 02:52, 16 July 2026 (UTC)reply
  • Yes. The question is whether they are permitted, and they should be permitted. Questions about when various types of relistings should encouraged or discouraged can be addressed later, after the current question is answered. Robert McClenon (talk) 04:18, 16 July 2026 (UTC)reply
  • Yes. Whether they should be encouraged, discouraged or neither are separate questions but there is absolutely no reason to prohibit them. Thryduulf (talk) 08:37, 16 July 2026 (UTC)reply
  • Yes. MfD shouldn't be different from other venues in this regard. FaviFake (talk) 09:26, 16 July 2026 (UTC)reply
  • Yes. As I said during the ANI discussion, comment-free relists are normal and speak for themselves. Mackensen (talk) 10:46, 16 July 2026 (UTC)reply
  • Yes. Allow relisting. MFD closers shouldn't need to learn different rules about relisting than the other XFD venues. If a discussion has low participation or could benefit from more discussion, and hasn't already been relisted, then relisting is a standard and helpful tool in the toolbox. –Novem Linguae (talk) 12:56, 16 July 2026 (UTC)reply
  • Yes, there certainly are cases where a relisting does not need much of an explanation for itself. jolielover♥talk 13:40, 16 July 2026 (UTC)reply
  • Relisting is an unusual action at MfD. Like at DRV, discussions rarely suffer for attention. As such a comment explaining why a particular discussion does in fact warrant further participation is normally helpful. Prescribing a comment serves to discourage thoughtless and otherwise unhelpful relists. I know I have done such relists at MfD, erroneously thinking its situation the same as at any other venue. It is ineffective to inform every editor to fall under this common misapprehension individually. I do not find the argument that the same relisting considerations should apply to all deletion venues convincing. Encouraging unfruitful relists is counterproductive. J947 ‡ edits 03:35, 16 July 2026 (UTC)reply
    What makes a relist helpful or unhelpful? Where do we draw that line? voorts (talk/contributions) 03:39, 16 July 2026 (UTC)reply
    I am currently drafting User:J947/Essays/When to relist? on that question. J947 ‡ edits 03:44, 16 July 2026 (UTC)reply
    I don't think it's reasonable to ask editors participating in this RfC to read a 700+ word (the page size tool doesn't count items in lists) essay. voorts (talk/contributions) 03:53, 16 July 2026 (UTC)reply
    (edit conflict) Well I wasn't quite sure what you were getting at. I mean you do plenty of relists yourself; you don't need me to explain which relists are good or bad. (Although, for the sake of others, I'll summarise my position. It's a judgment call of how productive the relister expects the relist to be. Relists shift attention from new discussions to old discussions. Extensions of a discussion by a week or two are usually significantly less productive than the first week, but some discussions are complicated or important enough to warrant a RfC-like amount of time (that is, where there is no consensus or no clear consensus).) J947 ‡ edits 04:50, 16 July 2026 (UTC)reply
    To clarify, an explanation should be required, not merely a comment. Comments like "final relist" and "keep or delete?" -- which pretend to be binding but are not -- are rarely useful. J947 ‡ edits 03:44, 16 July 2026 (UTC)reply
  • No. Per my comments above I don't think relisting an MfD is useful at all in the mine run of cases, so I suppose I'd support requiring the relister to explain their reasoning. But whether or not there's a comment is orthogonal to the more important question of when to relist in the first place, and I don't really understand why this RfC is framed around the former rather than the latter. Extraordinary Writ (talk) 06:03, 16 July 2026 (UTC)reply
    When to relist is already covered by WP:RELIST. voorts (talk/contributions) 19:33, 16 July 2026 (UTC)reply
  • There is no point resisting the incredibly strong human urges for superficial order, symmetry, and conformity, as any such act of resistance is instinctively treated as an act of aggression. In any system that has awoken to a semblance of non-conformity or non-sameness, or to a however vacuously construed internal gap, any person who advocates for that gap not to be bridged is viewed as an enemy. Any individual insisting that the gap has always been there and exists for a reason is labeled a perpetrator of mental violence. Arguing that the structure is not inconsistent, but rather applying legitimate different treatment to different things, is considered even worse, because it implies the existence of multiple gaps and thereby doubles the perceived mental violence. Because a mass society cannot tolerate the cognitive friction of specialized, highly tuned mechanisms, these elite-orientated structures inevitably face a destructive regression to the mean once exposed to the uninitiated public. Since it is impossible to protect fragile internal functions from this homogenizing force, the system must survive by fabricating a flawless public veneer of absolute consistency and "fairness".—Alalch E. 19:30, 16 July 2026 (UTC)reply
    User:Alalch E. : That paragraph is a philosophically interesting example of the use of language, because the individual phrases make semantic sense, but the overall paragraph has no semantic meaning. Robert McClenon (talk) 05:32, 18 July 2026 (UTC)reply
    Read Cognitive inertia. SmokeyJoe (talk) 23:26, 18 July 2026 (UTC)reply
    When the system stops being rational after all its finely-tuned "inconsistent” internal mechanisms are dismantled in succcessive confirmity campaigns, the iron law of oligarchy comes into full effect. —Alalch E. 19:42, 16 July 2026 (UTC)reply
  • I am generally opposed to relisting (at all venues), but I do not believe we should have special rules here. Relisting should be avoided if possible, and "relisting without comment" reflects poorly on the relister, but let us fix that elsewhere, not by making additional rules for one specific venue. —Kusma (talk) 12:54, 19 July 2026 (UTC)reply

Discussion re RfC: MfD relists

  • This is, as previously, not the relevant question. It is a disruptive survey. -SmokeyJoe (talk) 02:05, 16 July 2026 (UTC)reply
    Your complaint above was that the relists were "pointless" and "comment-free". I apologize if that wasn't the issue you have with the relists. voorts (talk/contributions) 02:08, 16 July 2026 (UTC)reply
    Actually, this is precisely the relevant question, as you yourself stated:

    The problem is comment-free relisting. All downside, no upside.

    Every question you pose is a red herring. SmokeyJoe (talk) 01:53, 11 July 2026 (UTC)

    voorts (talk/contributions) 02:11, 16 July 2026 (UTC)reply
    I hold that “comment-free” relisting is a problem. It has a number of problems. I acknowledge that it is widespread at other XfDs. It is not common at MfD. The only repeatedly comment-free relister at MfD is Godsy. I have explained the entirely of the problem to him, but he completely doesn’t get it. So, what to do? SmokeyJoe (talk) 02:17, 16 July 2026 (UTC)reply
    Can you please stop commenting on editor conduct. This is not the place to do so. I suggest leaving a brief, civil !vote above. voorts (talk/contributions) 02:19, 16 July 2026 (UTC)reply
    No. This is precisely about one specific behaviour of one specific editor, since about ten years ago. They and you are responding with widespread generalities, and widespread generalising is evasion of the issue. SmokeyJoe (talk) 02:21, 16 July 2026 (UTC)reply
    No. This is a policy dispute, that has been going on for about ten years, that is largely between two users, and is compounded by the interaction between two users. I mediate article content disputes, and I instruct the editors to Comment on content, not contributors and Discuss edits, not editors. Those two instructions are the same, and are repeated because they need repeating. Often an article content dispute is compounded either by conduct or by conduct allegations. Often resolving the content dispute by focusing on content will alleviate the conduct. One of the two editors, User:SmokeyJoe, objects to content-free relistings, and has been reverting them for about ten years. The other editor, User:Godsy, reported the reverting at WP:ANI. User:voorts is trying to resolve the policy dispute by clarifying the policy by an RFC, and is asking about exactly what SmokeyJoe was objecting to. At this point, objecting to the resolution of the policy dispute is bizarre. Robert McClenon (talk) 04:10, 16 July 2026 (UTC)reply
    The main dispute is over an editor's judgement, in a relatively small matter. Incidentally, I find I agree with that user's opinions on all other matters.
    I do not want your mediation.
    User:Voorts, who has recently been aggressively involved in these discussions, has unilaterally launched an RfC framed around the wrong question.
    I am very interested in J947's page User:J947/Essays/When to relist?, and I hope to contribute to it. SmokeyJoe (talk) 11:03, 16 July 2026 (UTC)reply
    I did not offer to mediate. I am not neutral.
    You say that the question is the wrong question. You were complaining about content-free relistings at MFD, so the RFC is about content-free relistings at MFD. What is the right question?
    If you think that the question should be about Godsy's judgment in relisting MFDs, why don't you start a discussion about what you see as the real issue? (Perhaps because you know that you are in the minority?) Robert McClenon (talk) 16:28, 16 July 2026 (UTC)reply
    User:Robert McClenon, there are threads in multi places, and many questions that are not important, so some good questions like this one can be hard to find.
    The first question, is whether this edit to Wikipedia:Miscellany for deletion/Wikipedia:Userboxes/Apps was a good edit. In my opinion, it was not. The discussion was ready to close, and it belonged in the backlog. I thought my edit summary was not impolite. This is a question of judgment when relisting.
    The more general question that follows that I ask is: What is the point of relisting without comment (or reason), as in when it leaves others mystified as to why it was relisted.
    I hesitate, because I am not sure whether this is a general issue for relisting everywhere, or is particularly relevant for mfd.
    I have posted by thoughts at User talk:J947/Essays/When to relist?, and encourage interested others to read User:J947/Essays/When to relist?. SmokeyJoe (talk) 23:51, 17 July 2026 (UTC)reply
When someone is working on a backlog and they encounter something that's difficult to close, the following options are safe and easy and won't result in a long whiny complaint: (a) Ignoring that discussion and (b) Relisting that discussion.
Closing that discussion is more difficult and requires an investment of thought and work, and randomly, it gets quite needless amounts of stress from aggrieved editors. So over the years we've got into the habit of ignoring or relisting the difficult ones more and more frequently. I can absolutely see why.
But we're stretched too thin. We don't have the volunteer numbers now to process all these discussions. A relist used to be unusual, a second relist used to be remarkable. Now we're unsurprised to see three relists.
We've also got another problem which is the discussions that get no participation. Again, the people working on the backlog tend to relist. But that isn't always the right thing. Some discussions get no participation because we have too few volunteers and too many XFDs, in which case relisting might help. Others get no participation because nobody cares.
I think that where a discussion has had a reasonable amount of participation it should be closed rather than relisted. (If it looks difficult and you're one of those conflict-averse people, just write "No consensus".)
I think that where a discussion hasn't had much participation it should get relisted once. If it gets near-zero participation a second time, then we ought to close it without result.
And I think that by following those principles we would use our volunteer time more productively.—S Marshall T/C 09:57, 23 July 2026 (UTC)reply

Lack of climate change denialist categories

I noticed that all of these exist and are seemingly widely endorsed and can be seen under , including examples like:

However, anything like has been repeatedly and seemingly aggressively eliminated, see here:

Why are we alright with putting people into one set of pseudoscience enthusiast categories, but not the climate change folks? — Very Polite Person (talk/contribs) 22:41, 9 July 2026 (UTC)reply

It could very well be that some of the other categories are inappropriate, per WP:CATEGORIZATION, WP:BLPCAT and WP:OVERCAT. Some editors really like avidly sorting, labelling, categorizing, and sub-categorizing. This can become problematic when it involves living people. --Animalparty! (talk) 23:05, 9 July 2026 (UTC)reply
Particularly per WP:OPINIONCAT. Nat Gertler (talk) 01:17, 10 July 2026 (UTC)reply
A missing canonical case here is . Recently, Naomi Oreskes compares climate denial with pro-child labour movement in USA: "It’s a question of freedom. It’s not for the government to decide. A businessman—and it was almost always men—should have the freedom to run his business the way he sees fit without the government intervening. And a father should have the right to run his family the way he sees fit.”.[1] Many people, organizations and corporations are described as deniers in plain text by many RSs. I see a lot of WP:CRYBLP against this necessary category. Ixocactus (talk) 01:05, 10 July 2026 (UTC)reply
It is not a necessary category. It is not WP's place to WP:RIGHTGREATWRONGS. As editors, I'm sure we all agree that people that deny the Holocaust happened are not very great people, but we can't put that in Wikivoice, unless they clearly self-identify as that. And even then, a category like that is a honeypot for editors to add anyone they want.
Categories that involve these types of labels with BLP are pretty much not workable on WP, because there's no direct way to source their inclusion. They can be included in a list, where we can include sourcing, and where we can arrange the list to make clear its not Wikivoice but attribution (Like a "List of people considered to be Holocaust deniers") with strong appropriate RSes to show that. Masem (t) 01:19, 10 July 2026 (UTC)reply
RGW is about a lack of sources, not the act of being subjective. Read the policies you link and thus can click, people. LightNightLights (talk • contribs) 18:52, 12 July 2026 (UTC)reply
As someone who frequently edits about Holocaust deniers I do not think the situations with these categories are anywhere comparable. For most people in the Holocaust denial categories it is their main or a major source for notability, and therefore defining, and also self-describe as a "revisionist" or something. There was a specific movement of activists in question. PARAKANYAA (talk) 19:23, 10 July 2026 (UTC)reply
If I had to choose, I'd lean toward throwing out much of Category:Advocates of pseudoscience, for the same reason we got rid of Category:Climate change denialists as well as things like Category:Terrorists. Thebiguglyalien (talk) 05:14, 10 July 2026 (UTC)reply
I think a category for climate change denialists would be useful, but it would not be practical. The category would be for activists. As Nat Gertler noted with OPINIONCAT, it can't be people who simply voiced denialist ideas. To my mind a main hassle will be hardly any activist peddler of denial wants to claim the name. Their Wikipedia articles become the subject of talk page discussion over what euphemism or watered-down locution to use instead. People whose activist careers center on climate change denial have successfully kept their news media coverage largely scrubbed of that term. So maintaining a category simply won't work. -- M.boli (talk) 12:54, 10 July 2026 (UTC)reply
I think climate change categories would run afoul of WP:CATDEF far more often than those listed. Also, WP:OPINIONCAT. Then again, all of these categories have this problem... PARAKANYAA (talk) 19:22, 10 July 2026 (UTC)reply
Are you certain about that? We sometimes get this idea that CATDEF bans all cats that aren't "defining characteristics", but it actually says the opposite. According to CATDEF, we should normally add cats for defining characteristics (to the extent feasible), we should normally not add cats for trivial characteristics – it gives "Category:Italian people with dark eyebrows" as an example of a trivial characteristic – and we are allowed to add cats for things in between 'defining' and 'trivial'.
It seems to me that climate denial would be a defining characteristic for some outspoken deniers (e.g., certain politicians, petroleum producers, pseudoscientists) and a non-trivial characteristic for some other living people (e.g., certain celebrities). WhatamIdoing (talk) 01:27, 12 July 2026 (UTC)reply
CATDEF says this: "Defining characteristics of an article's topic are central to categorizing the article. A defining characteristic is one that reliable sources commonly and consistently refer to in describing the topic, such as the nationality of a person or the geographic location of a place."
Why would it be a defining category for a petroleum producer? Looking at these categories, it doesn't seem defining for most of them. Of more relevance is OPINIONCAT, which says: "Avoid categorizing people by their personal opinions, even if a reliable source can be found for the opinions." PARAKANYAA (talk) 00:47, 13 July 2026 (UTC)reply
Why would climate change be a defining category for certain (i.e., not all) petroleum producers? Approximately for the same reason that claiming cigarettes don't cause lung cancer is a defining characteristic of certain tobacco manufacturers (see, e.g., Tobacco politics#Significant cases).
Corporations aren't "people", and self-serving claims to promote your business against established science aren't "personal opinions". WhatamIdoing (talk) 04:34, 13 July 2026 (UTC)reply
Yes, and these are people categories, so they wouldn't go in there anyway? PARAKANYAA (talk) 20:34, 13 July 2026 (UTC)reply
The cat doesn't need to be restricted to natural persons. WhatamIdoing (talk) 00:12, 14 July 2026 (UTC)reply
Why would we put companies and people in the same category? And as a subcategory of activists, it would. PARAKANYAA (talk) 01:15, 14 July 2026 (UTC)reply
Why would it have to be a subcategory of activists? Why not put it under Category:Activism, which includes both people and organizations? WhatamIdoing (talk) 01:29, 14 July 2026 (UTC)reply
Because this is a discussion about the "advocates of pseudoscience" category and its subcategories. Which are already all in the activists subcategories. PARAKANYAA (talk) 00:46, 16 July 2026 (UTC)reply
Inside Category:Advocates of pseudoscience, I find categories for organizations, such as Category:Anti-vaccination organizations and Category:Astrological organizations, and in various categories immediately under it, I find individual organizations, such as New York Rescue Workers Detoxification Project, Narconon, and Human Diversity Foundation. If these organizations can be listed in the cats under Category:Advocates of pseudoscience, then so can others. WhatamIdoing (talk) 00:59, 16 July 2026 (UTC)reply
Climate change denial isn't an opinion. Jerod Lycett (talk) 10:03, 13 July 2026 (UTC)reply
Opinion: "a view, judgment, or appraisal formed in the mind about a particular matter". Yes, it is. PARAKANYAA (talk) 20:35, 13 July 2026 (UTC)reply
There are certainly some people for which climate change denial becomes effectively a form of activism. I think a category could be compliant with OPINIONCAT if it was limited to those people. Katzrockso (talk) 00:22, 14 July 2026 (UTC)reply
Such as folks who WP:RS or WP:SELF folks are sourceable as either activists, lobbyists, "took a stand, paid a price" sorts of people? — Very Polite Person (talk/contribs) 00:49, 14 July 2026 (UTC)reply
Yeah. I could see American Enterprise Institute being in a hypothetical category too. ExxonMobil climate change denial (an entire article!) would warrant inclusion. Someone like James Inhofe, whose name was immediately followed by "climate change denier" in headlines when he died seems like the kind of article that be worth including, too. Katzrockso (talk) 01:03, 14 July 2026 (UTC)reply
Then the problem is maybe more with the category name rather than the categorization itself. Maybe it shouldn't be Category:Climate change denialists (which would include people by opinion) but instead it should be more specific: Category:Climate change denial activists. Nakonana (talk) 11:13, 19 July 2026 (UTC)reply
It should either follow the existing Category:Holocaust deniers or the existing Category:HIV/AIDS denialists, possibly with a unification among all of them re denier vs denialist. Jerod Lycett (talk) 23:56, 25 July 2026 (UTC)reply
American Enterprise Institute and ExxonMobil are among the 95+ articles in Category:Climate change denial in the United States. Peter Gulutzan (talk) 13:43, 20 July 2026 (UTC)reply

What's the deal with paid editing?

I've previously started discussion here about my perspective that paid editing would seem to me to be inherently WP:NOTHERE, which people didn't agree with. Increasingly, though, I come across examples of paid editing that absolutely baffle me as to why they're allowed.

My main question is; why do we allow paid editing at all? Why, especially, do we allow freelance paid editors/digital marketing types who engage in paid editing, en masse, for multiple clients? Is it simply a matter of "if we don't allow and police it then they'll just do it surreptitiously and it'll be harder for us to manage?"

I'm not particularly compelled by the idea that this type of editing is tangentially beneficial to the encyclopedia. The sorts of information these editors are focused on adding and maintaining is typically trivial at best and outright promotional at worst.

Additionally, paid editing being openly allowed permits the companies and individuals doing the paying to essentially keep throwing shit at the wall until something sticks. Draft:Kodiak AI is an attempt at recreating an article deleted at AfD. The original article was created by an (ostensibly) unrelated paid editing contractor. After it was deleted and that contractor blocked for sockpuppetry, the company evidently just went ahead and hired a different contractor to attempt to recreate the article. Should this sort of thing be allowed? We speedily delete articles under G5 if they're recreated by a blocked user; but if they're created by a new meatpuppet acting on behalf of the same company, is that fine?

Fundamentally, anybody who spends any length of time at AfC can tell you that the drafts we receive from declared paid editors are, essentially without exception (certainly I have yet to see one), promotional in nature and wholly unencyclopedic; because of course they are. Nobody's going to pay someone to write an article that isn't in some way flattering to them or beneficial to their publicity. Why do we tolerate a category of editing that seems to be fundamentally at odds with our core principles, not to mention universally a drain on the resources of editors who are actually here to build an encyclopedia?

It especially seems absurd to me that we constantly tell these editors in some form or another that what they're doing is at odds with Wikipedia and almost certainly guaranteed to fail, but we won't go as far as to just stop them from doing it?

It seems obvious to me that if an editor came here and outright said "My purpose for being here is to promote [article subject]. I'm not going to break any rules outright, but I will not engage in any editing except for trying to publish an article about the subject I'd like to promote" we'd surely call them NOTHERE and show them the door unless they engaged in productive and non-promotional editing. But when they instead say "[Article subject] has paid me to publish the article" it becomes acceptable, despite the behaviour being the same, and we're then expected to spend our time reviewing their obviously promotional article and trying to help them hammer their square peg into a round hole.

I'm aware this has been a bit scatterbrained and polemic, so here's my attempt at collecting this into some kind of organised thought that people can engage with:

  • It seems to me that "being here to build an encyclopedia" and "being here to engage in paid promotion" are inherently at odds.
  • It seems to me that one fundamentally cannot be paid to publish an article about a subject without that article being inherently promotional in nature. Nobody's actually paying to get a neutral encyclopedic article about themselves, even if that's what they say they're doing and think they're doing; they have no idea what an encyclopedia article actually is, because if they did they wouldn't be paying for one. The intent is promotion and publicity.
  • QED, people here to engage in paid editing are inherently here to engage in publicity, and so are not here to engage in encyclopedia-building.
  • That issue aside, the fact that companies can just keep dangling the promise of a paycheck over the heads of successive paid editors despite failed attempts and AfDed articles would seem to me to be meatpuppetry. What else would you call a succession of different people engaging in editing on behalf of the same outside party?
  • Maybe being paid to submit edit requests to an existing article to update uncontroversial biographical/corporate facts is fine, but being paid to write new articles from scratch I would certainly argue shouldn't be allowed, because the result is universally promotional cruft which wastes the time of volunteer editors. I don't think we should accommodate some hypothetical editor who's capable of writing an entirely unpromotional, encyclopedic article in exchange for payment; because that hypothetical editor has seemingly yet to show their face.
  • If nothing else, we should at least blacklist companies whose articles have been deleted at AfD, rejected at AfC, etc.

Athanelar (talk) 06:03, 11 July 2026 (UTC)reply

If we ban paid article creation, companies will still submit the articles, they just won’t self-declare. Better to have a label to recognise the reality that paid editors will exist regardless and to help filter out the promotional cruft, even if that makes up the overwhelming majority. Mir Novov (contribs | talk) 06:51, 11 July 2026 (UTC)reply
I don't find this argument compelling because it's like arguing we should let vandals do a little bit of controlled vandalism because they'll do it anyway otherwise.
Sure, if we have a rule against something people will break that rule, and then they'll be sanctioned for it. Plus, the majority of paid editing is so evidently promotional that it's not exactly hard to detect without a declaration. A great number of paid editors don't know about the disclosure requirements when they first come to AfC, and we end up advising them about it because we can tell it's quite obviously paid (or at least COI). Of course there's survivorship bias there; but if someone wants to do UPE now they can, and if they're good enough to not get caught then they won't be, regardless of whether we permit paid editing or not. Athanelar (talk) 07:55, 11 July 2026 (UTC)reply
Pretty much a basic element of life. Kids should make mistakes so that they learn. This is an open wiki so that people can make mistakes and we can still collectively move forward. If you want to keep everyone in check, a wiki is the wrong model to use in my opinion. —TheDJ (talk • contribs) 11:23, 11 July 2026 (UTC)reply
To be fair, we also disallow block evasion, even if the person is transparent about circumventing their block and everything. Chaotic Enby (in solidarity · talk · contribs) 17:07, 11 July 2026 (UTC)reply
I feel that is somewhat different; block evaders probably know they are breaking a rule from the jump, but from anecdotal experience I've had to tell multiple people IRL that Wikipedia isn't like e.g. Facebook in regards to self-promotion. Mir Novov (contribs | talk) 10:06, 13 July 2026 (UTC)reply
I am also not certain that everyone agrees with either prong of QED, people here to engage in paid editing are inherently here to engage in publicity, and so are not here to engage in encyclopedia-building. - for one thing, bringing stuff one likes to wider attention is "engaging in publicity" and a major motivation for non-paid edits, for the other thing, they are compatible with encyclopedia-building. Although on the flipside it's true that a lot of paid editing and most of spamming contributes little to encyclopedicity. Jo-Jo Eumerus (talk) 07:04, 11 July 2026 (UTC)reply
for one thing, bringing stuff one likes to wider attention is "engaging in publicity" Correct, and explicitlyincluded in our policy against promotion; see WP:YESPROMO. A desire for attention should ideally never be part of an editor's motivation. Obviously that may not alwaysb e the case, but a non-paid editor has much less incentive to publicise and promote.
for the other thing, they are compatible with encyclopedia-building. Only theoretically. I'd be very interested to see an example of paid editing, especially paid creation of a new article, which benefitted the encyclopedia rather than just wasting a bunch of editor time reviewing it, deleting it etc. And even if such an example exists, on balance it's just far less common than the alternative. As I said, one only needs to spend a week or two at AfC to see how much of a timesink paid editing is. Athanelar (talk) 07:59, 11 July 2026 (UTC)reply
I like jawless fish. I'm happy to write about them to bring them to wider attention. This, by itself, is not necessarily bad. Where you're right is that it becomes more questionable when there is a financial incentive (or other conflict of interest) involved, which is the more important aspect rather than wanting to bring something to wider attention in a vacuum.
This can directly affect the content of the edits. If, say, I was selling fish fossils, I would have a bigger incentive to promote the species I have in stock as especially rare or noteworthy. Meanwhile, if I just want to bring a species I heard of to wider attention because I find it neat, I'll be more likely to write about its interesting features without artificially overhyping it.
All in all, I broadly agree with your point, just wanted to recenter the emphasis a little bit. Chaotic Enby (in solidarity · talk · contribs) 17:15, 11 July 2026 (UTC)reply
Banning stuff just simply doesn't work that well; if there's a demand for it, people will still partake. Just look at drug prohibition as an obvious example.
If we banned paid editing, all we'll be doing is turning every declared paid editor into an undeclared one, which is an even bigger time sink and harder to spot. It's not so much that we accept paid editing, it's more that the current rules are better than the alternatives. As someone with pretty extensive AfC experience, paid editors are the least of my concerns when compared to copyvios and AI-slop. In solidarity, nil nz 12:39, 11 July 2026 (UTC)reply
You could apply this argument to a lot of things, though. Should we let people generate as much AI slop as they want so long as they declare it, because it's harder to catch undeclared AI slop than it is to clean up declared AI slop? "Prohibition doesn't work" seems to be a non-argument on a website where lots of things are already prohibited. Why would restricting paid editing, or at least paid article creation, be less tenable than restricting AI editing, or than restricting vandalism, POV pushing, or any other number of editing behaviours we forbid? Athanelar (talk) 14:18, 11 July 2026 (UTC)reply
Paid article creation has been an issue on en.wiki for close to 20 years (I participated in the Arch Coal / MyWikiBiz DRV that was one of the first instances: [[2]]). My hot take: declared paid editing, including article creation, is one of the most transparent forms of biased editing. And biased editing in general is absolutely routine on en.wiki. We need ways to combat bias, rather than to try to bar it, which is futile.
I say this because I think most substantive article editing, including article creation is motivated by the editor having some sort of special interest in the subject. That very often leads to a bias, pro- or anti-, and this shows up in many articles. It is an ongoing challenge for the en.wiki community to tone that down through collective review and editing. The paid editor biased by publicity/marketing factors is not that different from the passionate fan of a borderline-notable band, or the keyboard warrior determined to cast light on deep wrongs in society. Or a state-allied, or state-opposed political actor. Any and all of them need policing for the inevitable bias they knowingly or unknowingly bring, but also help grow the encyclopedia.
We shouldn't bar declared paid editing outright, just manage it (as we are doing pretty reasonably now, I think). Because alongside transparent attempts to place nonencyclopedic content, paid editors also bring content we should have but haven't gotten around to adding without them. If we can't put in place reasonable processes to separate their wheat from chaff, we might as well shut up shop and go home, since in that case we definitely won't be doing a decent job addressing other forms of biased editing either. Martinp (talk) 12:41, 11 July 2026 (UTC)reply
but we won't go as far as to just stop them from doing it - What's your idea for how to do this? Levivich (talk) 16:06, 11 July 2026 (UTC)reply
For a minimum, we should blacklist paid editing on behalf of companies or individuals which have already had their articles rejected at AfC or deleted at AfD. We don't necessarily need to sanction the editors involved, but we should have a G5-like process to summarily reject/delete repeated creations of these articles by new paid editors, so as to prevent companies from continuously hiring new editors in an attempt to get their article published.
Ideally, I would say we go one step further and ban paid editors from creating new articles. Let them declare and propose edits to existing articles, but just outright forbid the creation of new articles in response for payment, even as drafts for AfC. There's no rush to make any particular article; truly notable companies and individuals can just wait for a volunteer to take notice of them and interest in them enough to write an article about them. If we catch UPEs trying to create articles anyway (which really isn't hard - most peopls looking to make a quick paycheck through UPE vastly underestimate Wikipedia's standards, and their brazenly promotional article isn't likely to last long) then we do what we already do for UPE: block and move on. No more wasting time at AfC and at help forums trying again and again to explain WP:NCORP to people who are just looking to do the absolute minimum to get their article published and collect their paycheck. Athanelar (talk) 16:51, 11 July 2026 (UTC)reply
To take the first idea: blacklist paid editing on behalf of companies or individuals which have already had their articles rejected at AfC or deleted at AfD ... have a G5-like process to summarily reject/delete repeated creations of these articles by new paid editors
How can that work in practice? Suppose Elon Musk pays an editor to write an article about SpaceX, and it's rejected at afc or deleted at AfD multiple times. We blacklist SpaceX? Like the encyclopedia should just never have an article about that company? Levivich (talk) 17:02, 11 July 2026 (UTC)reply
We do have WP:G4 for repeatedly recreating the same article that was already deleted at AfD. However, we don't do it when the article is substantially different from the deleted version. Where to draw the line can be a tough question, but I don't think something as drastic as blacklisting the article indefinitely would be helpful. Chaotic Enby (in solidarity · talk · contribs) 17:17, 11 July 2026 (UTC)reply
Yeah, that's why I'm asking for clarification. I assume "blacklist" and "G5-like process" means something more than G4/G5 but something less than WP:SALTing (which, I assume, nobody would be in favor of). I'm not sure what that in-between would be, but maybe Athanelar or someone else has a new idea for how it could be done. Levivich (talk) 17:36, 11 July 2026 (UTC)reply
@Levivich I mean that if another paid editor came along and said they're being paid by the same company to create the same article, we'd say no, and if they tried anyway then we'd summarily reject/delete it. An uninvolved editor would still be able to create the article if they so wished, it'd only be blacklisted from paid editing specifically. The purpose would just to be to make sure the company can't keep trying to throw new editors at us in the hopes one of them succeeds. Athanelar (talk) 18:27, 11 July 2026 (UTC)reply
if another paid editor came along and said they're being paid by the same company to create the same article, we'd say no, which is why when another paid editor comes along, they won't say they're being paid by the same company. So how does that improve anything? The company will continue to throw new editors at us in the hopes one of them succeeds, they just won't disclose paid editing. And so the purpose will not be achieved. Levivich (talk) 18:51, 11 July 2026 (UTC)reply
So then they'd either end up creating a draft which so obviously reeks of UPE that we easily sanction them for it, or else they go totally unnoticed, which they could very well do now as well.
Like I said: by this logic, why forbid anything? Why forbid AI generated content when people can just lie and maybe you won't be able to detect them? Why forbid POV pushing when people might be subtle enough that you can't detect them? Athanelar (talk) 21:10, 11 July 2026 (UTC)reply
Because that's not logic, that's fallacy :-) Specifically: not all things are the same. Just because X applies in one situation doesn't mean X applies in all situations. In the examples you give, you're conflating two very different categories of things: content and authorship. (Alan makes the same point below.) We can regulate content very well: noncompliant content is easy to detect and easy to fix or remove. Regulating authorship is an entirely different story: we allow anonymous and pseudonymous editing, and that means we have no way of really identifying the author, and thus it's almost impossible to regulate the author. That's why we ban, for example, creationist POV-pushing, but we do not ban creationists. It would be impossible to do. Similarly, we ban WP:PROMO, which is a type of content, but we do not ban super-fans or paid editors. (And, as you know, many editors apply that same logic to AI. That's why nobody cares that shit flow diagram was written by LLM.) Levivich (talk) 20:15, 12 July 2026 (UTC)reply
OK, if it's about content v authorship; then we ban sockpuppets and meatpuppets. Why doesn't the same logic apply there? Athanelar (talk) 05:02, 13 July 2026 (UTC)reply
Same fallacy! :-) That's a third category of thing: neither (1) content nor (2) authorship (as a broad group, e.g. creationists, or paid editors), but (3) individual editors who are banned for their individual actions on-wiki. We don't categorically ban Nazis (hence WP:NONAZIS is an essay, not a guideline or policy), but we do ban individuals for, e.g., publishing racist slurs on-wiki. Sockpuppetry falls in the same category: banning individuals for what they did, for breaking our PAGs. And we similarly ban individual paid editors, and also individual unpaid editors, for, e.g., repeatedly breaking WP:PAID or WP:PROMO.
BTW, why do we block and ban individuals for breaking policies? Because it's the most effective tool we've been able to think of. Some portion of the individuals will reform in order to get unbanned/unblocked, and that's so far the best we can do. Nobody's come up with a better idea AFAIK in 25+ years. But honest, as I asked at the start of our conversation, if you have any new ideas, I'm sure I'm not the only one that's all ears. I've been talking about how things are, but it's not how they have to be, it's just that this being a perennial discussion, this is well-tread ground. I'm sure all editors would welcome improvements for how to deal with all kinds of undesirable edits: paid editing, sockpuppeting, POV-pushing, AI slop, copyvio, and so on. But new ideas are rare, and promising ones are scarce. Levivich (talk) 08:35, 13 July 2026 (UTC)reply
Yes, but the argument you're making is that it's untenable to block paid editing in certain contexts because it'll just drive them underground. I'm not sure how it's a fallacy to apply the same logic to, for example, people engaging in meatpuppetry to do POV pushing. That's not allowed. Surely the same argument applies? We should just let them do it, provided they declare exactly what they're doing?
You can't just say "blocking and banning people works in all these other cases, but it won't work in this specific case" without specifically explaining why. Sure, I understand that the nature of the offense is different; but why, specifically, should we rule out blocking as a response to this offense? Athanelar (talk) 12:27, 13 July 2026 (UTC)reply
Nah dude you are bending over backwards to try to make a point. The guidelines are not consistent. Nor do they need to be. We ban authors when there's a consensus to do so. Czarking0 (talk) 06:16, 16 July 2026 (UTC)reply
I mean, yeah, why not? There's some point at which not having an article about a company becomes silly, but I'd argue that point is pretty far down the line, and there could be something providing an exemption for articles written by genuinely uninterested parties. For example, an article that is instantly submitted to AfD as a condition of its creation. This is not a brilliant idea, but it's something I think would probably work.
A company with worldwide fame, like SpaceX or General Motors or Theranos, would easily survive AfD, and we would have no problem. But a company whose whole history on here is a bunch of paid-for spam articles is only going to be SpaceX 0.02% of the time. The overwhelming majority will be stuff like this, which I just don't think would survive AfD, and I don't think we lose anything by saying "listen buddy, make it through Series C and do something with a substantial impact outside buying billboards in San Francisco and then we'll see". jp×g🗯️ 17:46, 21 July 2026 (UTC)reply
It is true that Wikipedia loses out by failing to have an article about some company that barely scrapes past GNG, but the company loses out way more than we do. "You will never be able to have an article" is an actual consequence that will affect people's decisionmaking, whereas "you get unlimited retries" is not. jp×g🗯️ 17:52, 21 July 2026 (UTC)reply
(edit conflict) You seem to be assuming that paid editors exclusively want to create articles about the organisation that is paying them. We know that is not true - see Wikipedia:Administrators' noticeboard#Anna's Archive Wikipedia bounty program, pattern across multiple articles for just one recent example showing that it's not as simple as that. Thryduulf (talk) 17:08, 11 July 2026 (UTC)reply
Around the time that the UPE rules were created, I had been thinking about hiring someone to make a series of a few hundred tedious edits from an excellent source I'd found ("___ is a rare disease[MEDRS source]"). I gave up on the idea, and it never happened. I don't think anyone would say that's WP:NOTHERE.
We've had several government agencies (e.g., National Institute for Occupational Safety and Health) and charitable organizations (e.g., Cancer Research UK) hire editors to improve articles. I don't think anyone would say that's NOTHERE, either. WhatamIdoing (talk) 01:44, 12 July 2026 (UTC)reply
I was actually thinking about the NIOSH guy myself, reading through this thread. I reviewed a couple of his DYK submissions, they were great. jp×g🗯️ 17:47, 21 July 2026 (UTC)reply
To address the second idea, banning new page creations by declared paid editors: If we catch UPEs trying to create articles anyway (which really isn't hard..., how do you know it really isn't hard? What is the total number of UPEs, and what percentage have we caught, and how could we possibly know the answer to those two questions? Levivich (talk) 19:20, 11 July 2026 (UTC)reply
Indeed, any undisclosed paid editors who write and/or maintained quality content about notable subjects will (and almost certainly do) go completely undetected. Nobody investigates people who add or maintain good content, and it would benefit nobody to change that because, well we want good content. Thryduulf (talk) 20:32, 11 July 2026 (UTC)reply
The UPEs who we already don't detect will continue to go undetected; but we're already not detecting them, so nothing changes.
The declared paid editors whose work is generally obviously paid may become UPEs if we forbid declared paid editing, but we'll be able to detect those editors because their work is already detectable as paid editing even without declaration; as evidenced by the fact that we constantly have to inform people about the declaration requirements because they don't know about them but their work is still evidently paid. Athanelar (talk) 21:12, 11 July 2026 (UTC)reply
And we'll continue to have false accusations, especially from editors who struggle to differentiate between "paid promotional content" and "information that doesn't particularly interest me". I remember a particularly unpleasant round a while ago, in which the terrible, horrible, no-good, very bad allegedly "UPE" editor just turned out to be an ordinary person who had attended a notable festival and decided to improve the Wikipedia article to the best of her ability. WhatamIdoing (talk) 01:52, 12 July 2026 (UTC)reply
The very first article I created was about a commercial tourist attraction. I could very well have been accused of being a paid editor based on that (people have been accused of such with far less justification) despite having no more connection than having recently visited. Fortunately this was way back in the days when adding content about notable subjects was viewed as a Good Thing so I wasn't and I'm still here 21 years later. Thryduulf (talk) 10:50, 12 July 2026 (UTC)reply
I think you're on the right track with this observation, but the relevant categories aren't just "detected" and "undetected," that's an oversimplification. If you're thinking detected paid editing is bad (because we can detect it) and undetected paid editing is OK (because we can't detect it), and if you're using the word "detect" to actually mean "PAG-compliant" (because if we detected paid editing that is fully PAG-compliant, it would be OK, not bad), there are four relevant categories:
  1. PAG-compliant disclosed paid editing
  2. Non-PAG-compliant disclosed paid editing
  3. PAG-compliant undisclosed paid editing
  4. Non-PAG-compliant undisclosed paid editing
Yet even those four categories are oversimplifying what's actually going on, because it's a continuum, not an either/or. An article can be more, or less, compliant than another. An article that violates the MOS by not having the article title in bold in the first sentence may not be PAG-compliant, but a hoax article is far less PAG-compliant. One of those two things is a real problem, and the other one isn't.
So the answer to the question why do we allow paid editing at all? is "because we have no way to prohibit it." And that leads to the next question that you implicitly ask, which is why "then why do we require paid editors to disclose at all?" And the answer is: so we can talk to them (and, through them, to their clients). So we can teach them how to move from category #2 to category #1. If they're in category #4, that becomes harder for both us and them. We encourage them to declare so we can teach them how to do it right (when they do it wrong), and that means (hopefully) they'll do it right from then on, and so it actually reduces category #4 by moving them to category #2, which helps us reduce category #2 by moving them to category #1. 25 years of testing tells us this works better than just leaving all the problematic paid editing into category #4. Levivich (talk) 20:39, 12 July 2026 (UTC)reply
Here's another POV: Some editors think that the rules are supposed to be idealistic. The practicality of the situation (e.g., whether we can actually prevent rule violations) is irrelevant. In this black-and-white way of thinking, it'd be far better to say "____ is bad, and we can't stop bad people from doing bad things, but we draw a line in the dirt here and say NO! to bad people doing bad things, because taking a public stand for good values is what good people do." And then when people do break them, you get to be outraged about how bad the bad people are (cue the dopamine hits from the internet outrage machine).
Here's a third POV: Some editors are looking for a sense of belonging. One of the not-so-obvious things about a community is that you cannot have a community without defining some people as being outside the community. It's "us against them", which isn't possible unless "they" exist. "We" say that "they" aren't part of the community, so why should we let "them" be present here, in our community's virtual home? They're polluting our community and our space.
I have more sympathy for some of these POVs than for others, but I think the main point is that different people will always have different values and therefore different views. WhatamIdoing (talk) 19:57, 13 July 2026 (UTC)reply
We basically have to allow some degree of paid editing, in that companies have a reasonable right to request correction of erroneous information about themselves, and correction of misinformation does indeed serve encyclopedic purpose. If I see an error regarding myself, I can edit the Talk page of the relevant article to request an article edit; indeed, I have done this very thing. That is not viewed as a paid edit. However, if there are errors about a corporation, which can reasonably want to have errors ("the date of founding is wrong") or omissions ("that lawsuit was withdrawn") addressed in serving the accuracy of the article... but any employee in position to make that request on the behalf of the company would be viewed as paid.
That is, of course, a different situation from starting a page on how Yumyum cookies are the best-tasting cookies because they are made from the finest ingredients. -- Nat Gertler (talk) 19:08, 11 July 2026 (UTC)reply
I think the fundamental dilemma is 'focus on the content not the editor'. I think, we determined a long time ago we can't control people's motivations, we can try to channel them, at best -- but we do want people to be motivated to edit. At any rate, this has been hashed out for decades, and although perhaps, a new consensus could form, I doubt it. I might even like a policy of a total ban (on article creation?), just for the feels. The present policy has costs, but any new policy will too, and likely unintended consequences. Alanscottwalker (talk) 11:26, 12 July 2026 (UTC)reply
I agree with you that paid editors are fundamentally NOTHERE to build an encyclopedia (with some exceptions, as WAID notes); they're here because their boss told them to be here. However, I still think that allowing paid editing with guardrails is a net benefit. Requiring PE disclosure allows us to review content before it makes its way into mainspace and ensures that comapnies can request that content of interest to our readers, such as revenues figures, leadership changes, or important mergers, be updated. The only harm from paid editing (other than the ideological harm of having editors who are NOTHERE) is some level of slop, but that problem wouldn't go away if we banned paid editing; I'd still be patrolling Category:Candidates for speedy deletion as spam from time-to-time. In fact, I think the problem would arguably be worse because we wouldn't be able to track paid editors as easily without the formalized COI edit request structure. Finally, as @NatGertler said, I think we'd run into serious issues if we didn't allow companies to request corrections to outdated (or even mis-) information. voorts (talk/contributions) 21:10, 13 July 2026 (UTC)reply
The greatest contribution of paid editors on Wikipedia is disclosure. Accesscrawl (talk) 07:42, 14 July 2026 (UTC)reply
The problem is that "misinformation," to a PR flak, often means "anything that does not glaze our company." Gnomingstuff (talk) 19:49, 14 July 2026 (UTC)reply
I meant literally incorrect information. voorts (talk/contributions) 20:38, 14 July 2026 (UTC)reply
You do not hear about the paid editors that do not cause problems. I do a lot at the COI backlog so I see probably more than others would. I have also been working on Flock Safety recently I find their paid edits to be worth discussion. Czarking0 (talk) 06:11, 16 July 2026 (UTC)reply
I feel like one of the major incentives for paid editing is that we have an extremely half-assed approach to consequences, and we also have a very dumb lopsided set of procedures that make it impossible to follow the rules. For example, if you want to "follow the rules", you have a single contractor submit something to AfC with their whole deal disclosed, in which case you wait several months for a review, it probably gets instantly rejected, and you have no recourse. Most people would consider this a punitive response. Meanwhile, if you just hire people to sockpuppet and break the rules, you get a review nearly instantly (either the article gets speedied or it doesn't). You also get unlimited retries, because every time you hire a spammer to write an article, we will treat it as a new isolated incident, and there's always a possibility it just survives NPR and AfD, and then you win.
One time, a friend of mine messaged me to ask how he would go about having an article made for some famous guy he knows, knowing and agreeing that we hate paid articles and you're supposed to follow a process to do it legitimately. This is someone who is actively trying to follow the rules. The subject seemed like he might have actually passed GNG. so I asked around with some other admins and other highly knowledgeable people to see if anybody knew what he was supposed to do. Everyone's best suggestion (including mine) was "they need to have the person writing it make an account and do the CoI declarations and throw it in the jungle of AfC and then after 3 months some random person will decline it on a lark". Contrariwise, I have had a great deal of experience with people who paid for drafts, and then they got rejected, and they just kept trying to do it with different accounts, and it actually worked (until I screwed them over by going back to find all the previously-declined submissions and draftified everything).
My proposal to even things out would be that we just, like, institute a policy that any time there's out-of-process submissions for a company/organization/businessperson, they are put in a "go to hell forever" category where it doesn't matter if you pass AfC later. That is the only thing I can think of that would actually make a rational person try to submit anything to our process rather than just hire paid editors over and over until one got through. jp×g🗯️ 17:38, 21 July 2026 (UTC)reply
I think that would harm Wikipedia at least as much as it would harm the company tbh - we want content about notable topics and this would prevent us from having that in some cases. The one that thing would actually encourage doing things by the book is to fix AFC so that reviews happen in a reasonable timeframe (days at most) and reliably reflected the actual state of the article and topic (i.e. stub-class or better articles about notable topics would get accepted, stub-class or better articles about borderline notable topics would be accepted subject to an AfD or equivalent community discussion). Unfortunately both of those are hard problems to solve. Thryduulf (talk) 12:24, 26 July 2026 (UTC)reply
Additionally, blocks/page deletions are not designed to be used for punishment/deterrence. Even if they were, I think this line of reasoning overestimates how much people actually give a shit about being blocked or having a page deleted on Wikipedia. voorts (talk/contributions) 12:32, 26 July 2026 (UTC)reply
another reason not to blacklist topics like this is that it would be very easy to do a joe job on a competitor. There's not very much more stick we have to use - we've got to make the carrot more acceptable. one possible idea i have had is reducing the workload for COI edits by having something like "pending changes", so a COI reviewer can say yay or nay to specific changes rather than having to pore through prose edit requests which can often be quite fiddly to implement. this won't help for AFC though of course. Morwen (talk) 13:10, 26 July 2026 (UTC)reply

Display of legend notes

Hi, Myself and user 4TheWynne (talk · contribs) have a difference of opinion (as seen here). As far as I know, when we have a legend, such as the one in this template, we show only the relevant notes (such as c and vc in this case currently), while 4TW thinks we should display all the legend regardless (including for example injuries and pregnancies even though Collingwood don't have any currently). Can anyone here please chip in and point me to the relevant policy about such a question? In all cases I've seen (for example on national football team pages on recent call-ups section) we only show the relevant notes. --SuperJew (talk) 06:23, 15 July 2026 (UTC)reply

For context, late last year I fixed the formatting across the 72 AFL/AFLW squad and personnel templates, as many were formatted incorrectly/inconsistently and/or out-of-date, and this included tweaking the legend in the personnel templates; I don't see how displaying the full legend is an issue, particularly given they are only visible on two pages each and nowhere in MOS:LEGEND (or even in MOS:TABLES as a whole) does it state or advise against doing this. SuperJew, for the record, 1. the legend has been fully displayed for over six months, which would make this the stable version, and you only hid the legend for the first time two days ago, which I then reverted, so I'd rethink your position on who is the B and who is the R in BRD, and 2. it wasn't blind reverting, as I had deliberately formatted the columns so that the first and far right (coaches/legend) columns were the same length, as I've always done. 4TheWynne (talk • contribs) 07:40, 15 July 2026 (UTC)reply
You're bringing up points that are not related at all to this discussion - consistency and editing history of BRD. This discussion is net about the policy of displaying legends. Having notes for things which aren't relevant just begs questions of the reader and is confusing. There is no need to include unnecessary content. --SuperJew (talk) 18:43, 15 July 2026 (UTC)reply
Those points are the reason we are having this discussion at all. I did give my stance as well, including that the visibility is extremely low anyway, but on your other point, displaying the full legend and each of its elements, which have very clear uses, isn't likely to confuse readers in and of itself (and if anything can be useful/interesting to show the different categories/management of players), at least nowhere near as much as elements appearing on the templates which weren't in the legend (which used to happen every now and then). 4TheWynne (talk • contribs) 20:30, 15 July 2026 (UTC)reply
I have to agree. As a reader, I often "work backwards" from the legend, and having legend entries that aren't in the chart is simply confusing. If there is a technical hurdle to trimming the legend, then fine, but it sounds like that's not the case here. --Ahecht (TALK
PAGE) 16:35, 16 July 2026 (UTC)reply
I agree with 4TheWynne's position. Given the formatting is consistent across all similar templates in the project, displaying a consistent legend is desirable – because it unambiguously communicates that there are no long term injured or pregnant players in this specific team. The alternative of omitting legend leaves the reader unsure whether the team is injury/pregnancy-free, or the editor of the page in question has simply given no consideration to including that designation. I think Ahecht's comment above makes sense for a standalone table, but 4TheWynne's position makes more sense for a related group of tables, even across multiple pages if in the same context or category. Aspirex (talk) 11:52, 20 July 2026 (UTC)reply
As far as I'm aware there isn't any policy for this, besides the general MOS pointer of "have a legend". Subjectively though, I'd tend to agree with 4TheWynne too - especially given the case that these template receive frequent updates (or at least should, in theory), having a consistent legend I think is important for stability. The relevant legend entries might not always appear, but the conclusion from there would be none of them currently apply. With respect to Ahecht's comment though, it might be pertinent to reconsider what information is important for inclusion in the legend for the purpose of minimising confusion. Is highlighting pregnancy/retirement/LTI worth it, when all three ultimately fall under the already-listed Inactive list, for example? Empole1 (talk) 23:04, 22 July 2026 (UTC)reply
Empole1, I do understand where you're coming from, but none of those are likely to cause confusion; I feel it could be useful to distinguish between different playing absences in a way that the squad (navbox) templates don't to fill in the gaps better and further set the two template types apart. 4TheWynne (talk • contribs) 15:34, 24 July 2026 (UTC)reply
I wasn't aware of this discussion, but 4TW has repeatedly reverted me for removing unused legend items, and previously reverted my balancing of the length of the columns in the table because he wanted the first column to match the length of the last column, which is extra long due to the extraneous legend entries! i made my recent edits after doing some edits for golfers, and in their articles, they only list the relevant legend entries, not all possible win types. Simplicity is best. There's no need to show legend entries for items that aren't in the attached table. The-Pope (talk) 16:36, 24 July 2026 (UTC)reply

Revision of WP:BIDI

Proposed revision of WP:BIDI:

−
Whether to include navboxes, and which to include, is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]] at each individual article. Per the bidirectionality principle above, this may also affect inclusion of a particular article in a navigation template. If a disagreement should arise, please centralize discussion at the article talk page, not that of the template (which may be [[Help:Watchlist|watchlisted]] mostly only by template coders).
+
Whether to include navboxes, and which to include is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]]. Community consensus can be arrived at by starting a discussion at the talk pages of each contested article in the navigation template, or through discussions in the template's talk page to make an exception to BIDI as it applies to all articles on the template if starting a discussion on each contested article's talk page would create an unreasonable burden on editor time that can better be resolved in a single discussion. If the discussion is started on the navigation template's talk page, additional measures should be taken to ensure the discussion receives attention (such as by posting to a noticeboard), as navigation templates are often [[Help:Watchlist|watchlisted]] only by template coders.

I will describe the problem I am trying to solve with this revision.

I maintain multiple large-scale sidebars that have encountered the same type of conflict. I will talk about Template:Gaza genocide sidebar, the most illustrative example, where a good-faith editor cited WP:BIDI and deleted 33 articles from the sidebar [3] that I believe are conducive to the sidebar but do not technically have the sidebar on their article pages. Edit: Mentioning this is not a means to win any specific dispute, but instead to provide a case study where BIDI has caused friction and would benefit from being updated. After contesting this at the template's talk page, consensus found that per BIDI and WP:ONUS, the inclusionist editors are expected to start individual discussions for all 33 removed articles and create consensus for each individual sidebar re-addition on each individual page, because the sidebar had been (in most cases) removed from each of those individual 33 pages after being initially added (this specific point may be contested, but I believe this is an accurate characterization). ZLEA summarized this conflict well, saying Centralizing 33 discussions into one may sound like a good idea in theory, but I believe it does go against the principle of WP:BIDI.

Using BIDI as a rule-of-thumb rather than an absolute is the norm for large sidebars, as according to this comment, Template:LGBTQ sidebar has 245 articles linked but 38 of those articles do not have the sidebar linking them back. I could theoretically go to Template:LGBTQ sidebar, delete all 38 links, and cite WP:BIDI, forcing editors to start an individual discussion on the talk pages of each of the 38 removed articles (as opposed to having one centralized discussion where we can agree it's probably okay not to have to follow BIDI absolutely on this sidebar). This would tire out editors maintaining Template:LGBTQ sidebar to the point where they would likely give up on adding the content back because the centralize discussion at the article talk page, not that of the template provision in BIDI makes inclusionists do an unreasonable amount of work in many instances.

There are many reasons why a page might not use a sidebar, including the page just not having much space or a person removing it by accident (which I've seen happen, although I forget the exact location) which is only noticed later down the line. These reasons that have little to do with the relatedness between a sidebar and its articles should not be a reason to prohibit the sidebar from linking non-BIDI articles on the sidebar if doing so makes sense for the sidebar. That is why I am expanding the centralize discussion at the article talk page, not that of the template provision to include an option for one centralized discussion on the nav template's talk page. Alexandraaaacs1989 (talk) 22:41, 2 July 2026 (UTC)reply

Pinging additional editors who were involved with related discussions:
PARAKANYAA, Sirfurboy, ScrubbedFalcon, WhatamIdoing, The Gnome, SnowRise, CNC, Katzrockso, Cdjp1, David A Alexandraaaacs1989 (talk) 22:45, 2 July 2026 (UTC)reply
x2 SecretName101, Tryptofish Alexandraaaacs1989 (talk) 22:45, 2 July 2026 (UTC)reply
It is seldom wise to make a proposal to change general policy as a means to win a specific dispute. AndyTheGrump (talk) 22:51, 2 July 2026 (UTC)reply
Please do not assume bad faith. Even if this proposal is passed, it would not "win" me any dispute. I am here making a good faith suggestion I believe would improve Wikipedia. Alexandraaaacs1989 (talk) 23:01, 2 July 2026 (UTC)reply
There is an open RfC on Template talk:Gaza genocide sidebar regarding this issue, which you started. AndyTheGrump (talk) 23:12, 2 July 2026 (UTC)reply
That RfC has expired with presumed consensus against my proposal. Alexandraaaacs1989 (talk) 23:13, 2 July 2026 (UTC)reply
Then why would you start a new discussion at a different forum if your proposal doesn't have consensus? SuperPianoMan9167 (talk) 20:39, 3 July 2026 (UTC)reply
I'm responding to the ping. I think it might be reasonable to interpret the existing language as permitting discussion at a particular article talk page, chosen so as to be a potential best "fit" for the discussion, but also to post notifications elsewhere. One way to accomplish that would be to post a link to the discussion at the article talk pages of the other affected pages, although of course this might require a very large number of such notifications. Alternatively, one could post only at those pages seen as most likely to be significantly affected, or at a WikiProject that would be interested in the particular topic. Or one could ping interested editors, as was done here.
An alternative option might be a discussion at templates for discussion. When a template is discussed there, I believe a bot or some sort of automated process puts an (annoying) message alongside the template on every page where it is used.
I also think that it's a potential misreading of ONUS to say that only the "inclusionist" editors are obligated to issue the notifications. If, hypothetically, a template has been used for "a long time" (I'm not going to attempt to define that precisely) at a page, then the "deletionist" editor who wants that template removed from that page has an obligation to justify changing that page from the status quo. --Tryptofish (talk) 23:13, 2 July 2026 (UTC)reply
Whether a particular article should be listed in a navbox is not within the scope of TfD and I don't see the benefit to centralizing these types of discussions there. voorts (talk/contributions) 23:23, 2 July 2026 (UTC)reply
That's a valid point, I guess, although I was thinking about discussions at CfD, where there is sometimes a decision to partially purge the members of a category, so I think one could propose limiting the scope of a template without proposing its deletion. --Tryptofish (talk) 23:28, 2 July 2026 (UTC)reply
I like all the suggestions you made, and I think writing them into the policy as possible ways to go about starting one centralized discussion would be an improvement over the current wording. But I disagree that it's clear these options are available (as opposed to it seeming like we're expected to start a unique discussion on each individual article talk page), since BIDI specifically says discussions must be started at each individual article, don't you think?
The ongoing ONUS vs NOCON debate seems to currently be trending against introducing a "long time" constraint (or expectation for deletionists to ever have to be the ones to issue a notification) affecting whether WP:ONUS triumphs over WP:NOCON when there's a contradiction between the two, so I wrote this proposal under the assumption that WP:ONUS takes precedent when the inclusion of any content is contested. Your interpretation of ONUS may win the dispute though, in which case this proposal would not be as useful as it would be otherwise, but regardless I think BIDI is overdue for some clarifications in wording even if we take your assumptions about one centralized discussion being an option to be true. Alexandraaaacs1989 (talk) 23:28, 2 July 2026 (UTC)reply
−
Whether to include navboxes, and which to include is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]] at each individual article. Per the bidirectionality principle above, this may also affect inclusion of a particular article in a navigation template. If a disagreement should arise, please centralize discussion at the article talk page, not that of the template (which may be [[Help:Watchlist|watchlisted]] mostly only by template coders).
+
Whether to include navboxes, and which to include is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]]. That discussion should generally occur on the talk page of the affected article with notification to the template talk page and other affected articles, if any. It may also occur on the template talk page with notification to the affected article.
voorts (talk/contributions) 23:20, 2 July 2026 (UTC)reply
Don't make things more complicated than they need to be. PAGs rarely require, rather than encourage, notification of affected editors or pages. For example, editors are required to place a template on the target page of a merge discussion. We should not extend those requirements to whether a particular page is included in a navbox. voorts (talk/contributions) 23:22, 2 July 2026 (UTC)reply
I like that proposed revision, and I agree that it's good to keep things simple. --Tryptofish (talk) 23:29, 2 July 2026 (UTC)reply
Me too, I'm happy with this simpler proposal. Alexandraaaacs1989 (talk) 23:33, 2 July 2026 (UTC)reply
Minor nitpicks:
−
Whether to include navboxes, and which to include is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]]. That discussion should generally occur on the talk page of the affected article with notification to the template talk page and other affected articles, if any. It may also occur on the template talk page with notification to the affected article.
+
Whether to include navboxes, and which to include, is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]]. That discussion should generally occur on the talk page of the affected article with notification to the template talk page and other affected articles, if any. If multiple articles are affected, the discussion should generally occur on the template talk page with notification to any affected articles. Notifying related discussion pages, like [[Wikipedia:WikiProject|WikiProject]] pages, may also be appropriate.
Alexandraaaacs1989 (talk) 01:07, 3 July 2026 (UTC)reply
Also, see WP:NOTIFIER. voorts (talk/contributions) 23:26, 2 July 2026 (UTC)reply
I think this proposed change undermines the very principal of WP:BIDI. I won't pretend to know what specific circumstances led to determined through discussion and consensus among the editors at each individual article being included in the guideline, but its not hard for me to imagine the purpose of that exact wording. First of all, I do think discussions should be as centralized as reasonably possible to prevent misunderstandings and to simplify decision-making processes. However, there comes a point where too much centralization can hinder such processes and prevent a consensus from forming. To use the Template:Gaza genocide sidebar example you mentioned, a centralized discussion on whether to include 33 links creates a serious problem. Each editor who wants to weigh in on the issue now has to go through each of the 33 articles and individually justify their decisions about all of them. This can become extremely complicated and potentially heated very quickly, and would be nothing less than a nightmare for the closing user to sort through. And let's be real, I doubt very many editors have that kind patience, and most will probably do a blanket "support" or "oppose" vote on all articles in question without taking a close enough look at them (which opens the door for another serious problem I'll cover below). Meanwhile, 33 individual discussions would be far more manageable. Users who watch the articles or are more knowledgeable in the topics can easily weigh in without having to worry about other articles they either don't care or know enough about. Likewise, closers don't have to spend unreasonable amounts of time sifting through each users' arguments for dozens of articles.
As I stated above, the most likely outcome of a centralized BIDI discussion is that editors choose blanket support/oppose votes rather than taking the time to comment on each article individually. This potentially opens the door for bad faith editors to sneak articles that probably should not be linked in the template (similar to the concept of rider legislation in politics). This would be especially troublesome for templates that could reasonably be perceived as allegations of crime, including and especially genocide, where just one wrong link could trigger WP:LIBEL. - ZLEA TǀC 02:08, 3 July 2026 (UTC)reply
Hi Zlea, thank you for your in-depth response and explanation. I think there's some miscommunications between us at play here:
  • I think this proposed change undermines the very principal of WP:BIDI. I agree. I'm seeking to change its principle.
  • Regarding when there's one centralized discussion when many articles are removed from a template: some individual article removals may be debated in the centralized discussion, but overall the purpose of centralizing the discussion is that you can talk about the disputed content in groups, rather than as individuals, whereas in your example, you talk about it as if the centralized discussion would be going into depth about all 33 individual links even though this would not usually be the case (unless deletionists took the time to start discussions about each of the individual 33 disputed articles). I.E. this policy change seeks to expedite things by not necessitating that all 33 links disputed are spoken about individually which is what the policy mandates right now. Respectfully, 33 individual discussions would be far more manageable sounds oxymoronic to me as a statement in general, which is what this change is seeking to address.
  • the most likely outcome of a centralized BIDI discussion is that editors choose blanket support/oppose votes rather than taking the time to comment on each article individually. This potentially opens the door for bad faith editors to sneak articles that probably should not be linked in the template The problem is that right now, the opposite is true: that currently if you decide to remove dozens of articles from a sidebar, it is nearly impossible to challenge said removal without devoting weeks of time to each individual discussion. There needs to be a balance struck between the two, and I think this subtle change to the wording of this policy will accomplish this.
Alexandraaaacs1989 (talk) 03:59, 3 July 2026 (UTC)reply
I agree. I'm seeking to change its principle. Most good (and successful) proposals to change policies and guidelines are made with the intention to clarify and/or strengthen their principals. Their principles are things that should very rarely, if ever, be messed with, as changing them without considering all the possible ramifications can lead to very unpredictable outcomes.
...but overall the purpose of centralizing the discussion is that you can talk about the disputed content in groups, rather than as individuals... That's exactly my point. Such discussions should be the exception, not the rule, and as such should only be done with exceptionally good reasoning.
Respectfully, "33 individual discussions would be far more manageable" sounds oxymoronic to me as a statement in general, which is what this change is seeking to address. That only tells me that you have never been involved in any actual over-centralized discussions. There's a reason that the immediate response of many editors to your discussion was to oppose it as a bad RfC. Most of them have probably seen the results of similar over-centralized discussions, understand why guidelines such as BIDI explicitly discourage them, and want to avoid them at all costs.
The problem is that right now, the opposite is true: that currently if you decide to remove dozens of articles from a sidebar, it is nearly impossible to challenge said removal without devoting weeks of time to each individual discussion. The problem is that users are adding links to sidebars without regard for the relevant guidelines. Had they followed the guidelines to begin with, this issue would have never happened in the first place. There needs to be a balance struck between the two, and I think this subtle change to the wording of this policy will accomplish this. First of all, there's nothing subtle about rewriting half a paragraph to undermine or change the principals of a guideline. Second, we shouldn't change guidelines to conform to nonconformity of said guidelines. That's like declaring an unreliable source to be reliable simply because it's already used on thousands of articles and would take too long to fix. Yes, fixing rampant policy/guideline nonconformity sucks, but that's no reason to move the goalposts to make noncompliance acceptable. - ZLEA TǀC 05:07, 3 July 2026 (UTC)reply
I shouldn't have so hastily stated I'm seeking to change its principle - that was a poor choice of words so I take back what I said about seeking to change the policy's principle. I only meant I am seeking to change the policy to make it easier to start centralized discussions that allow many unidirectional links to be added to a navbox. This would affect the policy's implications, but not its underlying principle.
WP:BIDI, as of right now, de facto precludes the sidebar from including unidirectional article links even though we are de jure allowed to include as many unidirectional articles as you'd like to be added to a navbox. The de jure aspect, in my view, represents the principle of the policy, whereas the de facto aspect represents a disconnect between the policy's principle and practice.
What's more, technicalities in the policy's wording should not override the capacity for editor discretion in deciding how they would like to run discussions about disputed content. There are reasons an article might not include a sidebar that do not imply the sidebar wouldn't benefit from a unidirectional link from that article, and discussing these cases shouldn't be technically allowed, but practically impossible when there's more than 3 articles in question.
If editors are adding links to sidebars without regard for the relevant guidelines, that's something that can be addressed by deleting the contested content from the navbox for reasons other than BIDI and expecting the editors seeking to include the disputed content to start a discussion if they'd like to contest the content's deletion (assuming WP:ONUS overrides WP:NOCON). The proposed revision in no way prohibits us from debating the inclusion of any individual articles on the navbox. It only prevents the necessitation that we debate the inclusion of each unidirectional article even when editor discretion finds that doing so is an exorbitant and unnecessary time sink. If editors can agree that being forced to start 33 individual discussions is less efficient than what could instead be the same quality of conversation across one or multiple centralized discussions, then BIDI should not override editor preferences and force them to go about a potentially highly-inefficient way of running discussions about a set of related articles. Alexandraaaacs1989 (talk) 11:32, 3 July 2026 (UTC)reply
I only meant I am seeking to change the policy to make it easier to start centralized discussions that allow many unidirectional links to be added to a navbox. This would affect the policy's implications, but not its underlying principle. That sure sounds like you're trying to change its principle, or at the very least attempting to make it easier to undermine it. That's not even considering the fact that over-centralization of discussions is detrimental to consensus building. (Some context for my next point, the removal of links that violate the guideline is nothing more than housecleaning. It's not "deletionism" or whatever you want to call it. There's a sharp contrast between the removal of guideline-violating links and the mass removal of links that do not violate the guideline.) The mass addition of non-bidirectional links or the mass removal ofbidirectional links is not supposed to be easy because such proposals could be easily abused.
There are reasons an article might not include a sidebar that do not imply the sidebar wouldn't benefit from a unidirectional link from that article, and discussing these cases shouldn't be technically allowed, but practically impossible when there's more than 3 articles in question. Again, those should be the exception, not the rule. If an unreasonably large number of articles cannot include a sidebar for whatever reason, then that's an entirely separate problem that would be swept under the rug by your proposal.
If editors are "adding links to sidebars without regard for the relevant guidelines", that's something that can be addressed by deleting the contested content from the navbox for reasons other than BIDI and expecting the editors seeking to include the disputed content to start a discussion if they'd like to contest the content's deletion (assuming WP:ONUS overrides WP:NOCON). That's not how policies and guidelines work. Blatant violations of the both the letter and spirit of the rules should not be kept just because they don't appear to violate any other rules. Exceptions to the rules can and should exist if it benefits the overall goal of Wikipedia, but they must be individually justified.
It only prevents the necessitation that we debate the inclusion of each unidirectional article even when editor discretion finds that doing so is an exorbitant and unnecessary time sink. That "time sink" isn't exorbitant or unnecessary, but rather by design. As I explained above, processes that are too easily abused are not supposed to be easy and will take time. - ZLEA TǀC 15:31, 3 July 2026 (UTC)reply
You said: If an unreasonably large number of articles cannot include a sidebar for whatever reason, then that's an entirely separate problem that would be swept under the rug by your proposal. But why is is that necessarily an entirely separate problem, when I explained There are reasons an article might not include a sidebar that do not imply the sidebar wouldn't benefit from a unidirectional link from that article?
You point to the risk of abusability meaning editor discretion (regarding whether to centralize discussions) should be prohibited and editors should be forced into decentralized discussions. But how precisely might this policy be abused? Because what this process would look like is that before someone would like to add non-BIDI links to a navbox, they would be expected to make a list of non-BIDI links they'd like to include and start a consensus-building discussion on the navbox talk page. Then the community would decide whether the navbox merits a template-wide exception for BIDI depending on the scope of the navbox and the articles seeking to be added. No exceptions to BIDI will be made without explicit discussion, and the exception still needs to be individually justified - just on a template-wide basis rather than a per-article basis. Setting the standard as needing to be set on a per-article basis rather than a per-template basis feels arbitrary. Can you really say that two non-BIDI articles of the same category need to have completely separate discussions for inclusion 100% of the time, mandated by Wiki policy, banning the capacity for editors to merge the two discussions into one? Alexandraaaacs1989 (talk) 23:27, 4 July 2026 (UTC)reply
But why is is that necessarily an entirely separate problem, when I explained "There are reasons an article might not include a sidebar that do not imply the sidebar wouldn't benefit from a unidirectional link from that article"? Because those reasons are few and far between and should be relatively easy to work around in a vast majority of circumstances. I've lost count of how many times I've repeated "the exception, not the rule", it's practically become my catchphrase.
You point to the risk of abusability meaning editor discretion (regarding whether to centralize discussions) should be prohibited and editors should be forced into decentralized discussions. But how precisely might this policy be abused? Alright, here's an example. Let's consider a hypothetical scenario involving a sidebar template about communism. A bad-faith user with an extreme dislike of one of their local left-wing politicians wants to insinuate some sort of similarity between said politician and figures like Joseph Stalin or Fidel Castro. To accomplish this task, the user proposes adding 35+ links to articles on what they claim to be "prominant communists", but sneakily includes the name of their local politician somewhere in the middle. They know that most users will probably give the list of links a glance, see a few well-known names, and focus on the merits of such a list being included in the sidebar rather than scrutinize the proposed links themselves. This scenario is similar to the concept of rider legislation in politics. Right now, such a scenario is thankfully next to impossible because the very principle of BIDI stands in the way. Even if all the benefits you envision from changing the principle are guarenteed to come to pass, you still have to weigh them against the potential consequences. The example I have is just one hypothetical scenario or how your proposed change could be abused, but the actual outcome of your proposal will almost certainly be something neither you not I could predict. As I said before, there is a reason the principles of policies and guidelines are rarely, if ever, messed with.
Now that I have given just one example, I'd like to hear from you, as the proposer, what other potential consequences of the proposed changes you have considered, and why you believe the benefits outweigh them. How confident are you that any unforseen consequences would also be outweighed by the benefits?
No exceptions to BIDI will be made without explicit discussion, and the exception still needs to be individually justified - just on a template-wide basis rather than a per-article basis. I already explained why this is a bad idea, so all I have to say at this point is good luck convincing anyone who has been involved in overcentralized discussions otherwise.
Can you really say that two non-BIDI articles of the same category need to have completely separate discussions for inclusion 100% of the time,... Yes, that would be ideal. I'd say maybe 99% of the time, though. There may indeed be circumstances where a more centralized discussion would be beneficial, but I'm sure you know my catchphrase by heart by now. ...mandated by Wiki policy,... BIDI is a guideline, not a policy. There arguably should be a policy on the overcentralization of discussion if avoiding such is so controversial, but from what I'm seeing from everyone else's responses here, we're not at that point. ...banning the capacity for editors to merge the two discussions into one? "Banning"? No. At least not unless it's absolutely necessary because users keep overcentralizing discussions to the point that it's a major burden to the community. - ZLEA TǀC 05:19, 5 July 2026 (UTC)reply
I'll also give my thoughts on your use of "inclusionist" and "deletionist" labels in this discussion. Our policies and guidelines are written with the sole purpose of guiding users on how to build and maintain an encyclopedia. A user's "-isms" are an informal reflection of their interpretations of said policies and guidelines, but these labels are not supposed to define a user's identity or behavior on Wikipedia. Attempting to change the rules to benefit a specific "-ism" runs counter to the purpose of P&Gs; "-isms" aren't supposed to act like or be treated like political parties. Therefore, it is my opinion that such labels are best left out of discussions on policies and guidelines as they can lead to false assumptions about the motivations of entire groups of editors. - ZLEA TǀC 05:37, 3 July 2026 (UTC)reply
I'm simply using the terms as shorthand for "editor who wants the content removed" and "editor who wants the content included", nothing deeper. But I understand how it might sound a little WP:BATTLEGROUND. If you have alternative shorthand phrasing ideas, I'm all ears and am open to improving my choice of words. Alexandraaaacs1989 (talk) 10:51, 3 July 2026 (UTC)reply
That's my point. You're thinking in terms of "editor who wants the content removed" and "editor who wants the content included" without considering the underlying reasons. I'll reiterate that policies and guidelines are written with the sole purpose of building and maintaining an encyclopedia. If they are written or changed to cater to any specific "-isms", then they stray from that purpose. - ZLEA TǀC 15:31, 3 July 2026 (UTC)reply
In all honesty, in many cases where Alexandraaaacs1989 refers to a hypothetical "inclusionist editor" and "deletionist editor", you can replace "inclusionist editor" with "Alexandraaaacs1989" and "deletionist editor" with "Sirfurboy" and the meaning of the comment will remain largely unchanged. See my comment below. SuperPianoMan9167 (talk) 20:45, 3 July 2026 (UTC)reply
I am not saying we should understand the disagreement as a conflict between two opposing "isms". I'm simply using the "isms" as shorthand words that are more effective at conveying which side (no, not side in the battleground way) each editor is on in the disagreement than saying "editor A" and "editor B". Whenever I read "editor A" and "editor B", I lose track of which one is which. But the "inclusionist" is the editor trying to include the content, and "deletionist" is the editor trying to delete the content, and those labels are much easier for my brain to understand. If you'd like to continue this line of discussion, let's bring it to my talk page. Like I said I am all ears to suggestions, but this feels a bit like a semantic nitpick with my choice of phrasing that I'm not sure is conducive to this policy discussion. Alexandraaaacs1989 (talk) 23:12, 4 July 2026 (UTC)reply
I do not wish to continue arguing about this. I think you've explained what you meant quite well here. - ZLEA TǀC 05:19, 5 July 2026 (UTC)reply
I think that "undermining the very principle of WP:BIDI" is exactly what's needed for sidebar navboxes only. The sidebars are supposed to be short lists of links to a handful of key articles. Some of them instead link to more than 150 articles, because someone enforced BIDI by adding all the articles that were transcluding the main template. I think that Template:Psychology sidebar, as shown here, or even a more concise version of it, could legitimately have 25 links in it, and correctly/usefully/relevantly appear on more than 1,000 articles.
I'd suggest a rule that says something like:
  • Sidebars should link to a small number of key articles, with a limit of n links.
  • The sidebar should be placed in any article where editors agree that it's relevant and desirable. Display considerations (e.g., preferring it in an article without an infobox) are acceptable reasons for including/excluding.
  • The goal should be for a sidebar to be placed/potentially place-able in at least 10 times as many articles as are linked in the sidebar. It should be "psychology" with 25–50 links in a thousand or more articles about psychology, not "quantum psychology subtype 2" with 10 links in just those 10 articles. If you want BIDI or if it can realistically only be placed in a few articles, then it should be formatted as a footer navbox instead of a sidebar navbox.
WhatamIdoing (talk) 21:16, 4 July 2026 (UTC)reply
I don't disagree with you, but I'm not sure that would be "undermining the very principle of WP:BIDI". If we were to consider such sidebars to be an accessory to navboxes (all links in the sidebar must appear in the navbox at the bottom of the page), then the principle is already satisfied by the latter. - ZLEA TǀC 05:19, 5 July 2026 (UTC)reply
That would result in stacks and stacks of navboxes. The article Psychology would have to have navboxes to basically every article that's about psychology. Having links to thousands (or tens of thousands) of articles is IMO an anti-goal.
Instead, I think that editors ought to be able to decide between specific/BIDI (footer) and short, general, non-BIDI (sidebar) navboxes, based on their editorial judgment about the needs of the article. If editors decide that some minor sub-article should have a sidebar that offers our desktop (minority) readers a quick path back to the key articles in the subject, then let them. Don't try to force a link in the Psychology article's navboxes to that minor sub-article. WhatamIdoing (talk) 16:46, 5 July 2026 (UTC)reply
Oppose. Why? What does this add? Why is this an improvement? Sidebars are not supposed to be all inclusive by their very nature, this would go against that. PARAKANYAA (talk) 03:20, 3 July 2026 (UTC)reply
It's an improvement because it would allow navbox-wide exceptions to BIDI to be made without needing approval for every single article in the navbox. Forcing editors to seek approval dozens of times in order for non-BIDI articles that otherwise belong in a navbox to be included in that navbox places a nearly-impossible burden on inclusionists seeking to dispute the deletion of non-BIDI articles from the navbox. It isn't in favor of being "all-inclusive". It's simply in favor of preventing BIDI from functionally prohibiting exceptions that would enable non-BIDI articles to be added en masse to navboxes. Alexandraaaacs1989 (talk) 04:11, 3 July 2026 (UTC)reply
And why would we want that? PARAKANYAA (talk) 10:07, 3 July 2026 (UTC)reply
I explain here. Alexandraaaacs1989 (talk) 11:05, 3 July 2026 (UTC)reply
Oppose - Per ZLEA above, this is an attempt to undermine the very principle of WP:BIDIRECTIONALity. It would allow sidebars to become complete editor curated taxonomies by discussion on the sparsely watched template talk pages, which is not what they are designed for, and would have deleterious effects. Sirfurboy🏄 (talk) 06:45, 3 July 2026 (UTC)reply
The current work-in-progress proposal addresses your second concern by providing guidelines that help ensure the discussion isn't domineered solely by template talk page watchers, e.g., by making "best practice" suggestions like notifying the talk pages of all individual articles affected in a centralized discussion. As for your first concern about the principle, I address it here. Alexandraaaacs1989 (talk) 11:16, 3 July 2026 (UTC)reply
How hard is it for you all to use the notifier userscript to notify relevant pages of discussions? This whole dispute seems massively overblown. voorts (talk/contributions) 18:02, 3 July 2026 (UTC)reply
Is nobody going to answer this question? voorts (talk/contributions) 15:18, 4 July 2026 (UTC)reply
I've been trying to leave room for others to reply, but I can respond with my thoughts on this since no one else has. If you're suggesting we use the notifier userscript as a substitute for amending BIDI, I don't think this would address the central concern about the current wording of WP:BIDI seeming to prohibit the centralization of discussions about multiple articles, which de facto bans navboxes from using many non-BIDI links (even when doing so is appropriate). If we amend the policy's wording to allow centralized discussions, then using the notifier userscript seems like it would be a very useful tool. That's my current understanding of things. But if I'm completely missing the mark and you're just talking about using the notifier userscript to attract attention to the current page, it's something I noted for future use but felt was redundant since I already notified 12 users from related discussions, but feel free to correct me if using the template would still be useful in some other way. Alexandraaaacs1989 (talk) 22:59, 4 July 2026 (UTC)reply
Unarchiving this discussion. Hoping to reach some form of consensus. Alexandraaaacs1989 (talk) 20:30, 19 July 2026 (UTC)reply

WP:POPULATED

Does a Tehsil meet Populated, legally recognized places for notability, or does the Tehsil need to establish notability itself? It seems somewhere below a county and above a municipality level of division, with the Districts they are divided from being the equivalent of a county. I think it's attempting to inherit notability. Jerod Lycett (talk) 05:14, 21 July 2026 (UTC)reply

I suggest asking this at Wikipedia talk:Notability (geographic features). Note, however, that there has been a long running and contentious debate, spread over many sections on that page, about what "legally recognized" means, and how it applies outside the United States. I thought an RfC was about to open, but, not quite yet. Donald Albury 20:59, 21 July 2026 (UTC)reply
I was only focused on getting the guideline clarified for Tehsil (hence asking here where changes are made in the hopes that some level of division was determined through consensus), but it seems the phrase itself is what is problematic. I'll edit this to expand when I have time tomorrow. Jerod Lycett (talk) 23:50, 21 July 2026 (UTC)reply
Per this definition, "It is a subdistrict within a district including the designated populated place that serves as its administrative centre, with possible additional towns, and usually a number of villages.", Tehsils are clearly notable under WP:POPULATED. Looking over the list, we have units from 5,400 to 572,000 people. I think all are intrinsically notable per policy.-- Carwil (talk) 12:46, 29 July 2026 (UTC)reply
If they serve an actual administrative function, there should be enough sources on administration to have them pass GNG. CMD (talk) 01:37, 30 July 2026 (UTC)reply
That standard would constitute a complete removal of WP:NGEO. Jahaza (talk) 02:56, 30 July 2026 (UTC)reply
How does meeting GNG constitute a complete removal of NGEO? CMD (talk) 03:49, 30 July 2026 (UTC)reply
Judging at the one I looked at, these probably pass WP:GNG. Mangoe (talk) 03:00, 30 July 2026 (UTC)reply

RfC: NPOL & sub-national leaders of major political parties

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is overwhelming consensus against WP:NPOL covering sub-national party leaders. Chaotic Enby (in solidarity · talk · contribs) 10:16, 23 July 2026 (UTC)reply

Should sub-national leaders of major political parties (e.g., the chair of a U.S. Democratic or Republican state party) be covered by WP:NPOL? 20:38, 21 July 2026 (UTC)

See RFCBEFORE discussion.
Notified: Wikipedia talk:Notability. voorts (talk/contributions) 20:40, 21 July 2026 (UTC)reply

Survey (NPOL)

  • No The purpose of NPOL is to ensure that we have complete coverage of national and sub-national elected officials legislators, judges, and executive officials. State or province-wide party leadership should continue to be judged by GNG/NBASIC. voorts (talk/contributions) 20:38, 21 July 2026 (UTC)reply
    Just a note, NPOL does not mention "elected", only "legislative bodies". A recent example is Darline Graham who was not elected but is serving in the US legislature. I think the point of NPOL is those who represent and can make laws impacting their constituents at the state or national level, regardless of party affiliation (i.e. their decisions impact the represented group, not just the party). S0091 (talk) 20:58, 21 July 2026 (UTC)reply
    Clarified. voorts (talk/contributions) 21:04, 21 July 2026 (UTC)reply
  • No. These are often not public-facing and public-elected so they do not have the automatic visibility of national and subnational leaders. They can continue to be covered by GNG. —David Eppstein (talk) 20:57, 21 July 2026 (UTC)reply
  • No severely lacks a global view of various political systems. many which are not democratic much less a two-party systems and gets us into the quagmire of what is a "leader" and a "major party". S0091 (talk) 21:11, 21 July 2026 (UTC)reply
  • No They usually sit in meetings and talk people to death. Not public enough. GNG is enough. Yesterday, all my dreams... (talk) 21:14, 21 July 2026 (UTC)reply
  • No. I agree with voorts, David Eppstein, S0091, and Yesterday. These individuals are often obscure even within their own state. There is no presumption of notability and they should be held to GNG. —Myceteae‍🍄‍🟫 (talk) 21:17, 21 July 2026 (UTC)reply
  • No NPOL is too broad as it is. Covering people who do not make law nor governmental decision is exccessive. If they are truly notable, they will meet WP:GNG. If their position is notable, the position can have its own article with list of position holders. -- Nat Gertler (talk) 22:03, 21 July 2026 (UTC)reply
  • No per voorts, David Eppstein, S0091, and Yesterday. Many party leaders will meet GNG and there is no reason to presume notability for holding this party office (especially for someone who is temporary). --Enos733 (talk) 22:18, 21 July 2026 (UTC)reply
  • No, unless evidence is presented that these people overwhelmingly pass WP:BASIC, including historically and globally. pburka (talk) 23:57, 21 July 2026 (UTC)reply
  • No. I haven't seen an articulation of what problem is being solved here. Are we lacking meaningful content because there are many state party leaders who have not received significant coverage in reliable sources that are independent of the subject? Davidwbaker (talk) 00:59, 22 July 2026 (UTC)reply
  • No I'd add that an implicit point of NPOL (which applies equally to members of the judiciary) is that it accords notability because of the universal (jurisdictional) power vested in persons within specific offices; something clearly absent in the role of a political party chair. Regards, Goldsztajn (talk) 10:26, 22 July 2026 (UTC)reply
  • No I have to agree with everyone else, this seems unclear and unnecessary. -- LCU ActivelyDisinterested «@» °∆t° 11:44, 22 July 2026 (UTC)reply
  • No NPOL is fine the way it is and I agree that most people covered under this guideline would be incredibly obscure. Lynch44 13:58, 22 July 2026 (UTC)reply

Discussion (NPOL)

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.

'Official website' in infobox for deceased individuals

I first noticed this in relation to the Charlie Kirk biography, but it seems likely that the same issue must arise elsewhere. The documentation for template:Infobox person states "Official website only", and Wikipedia:External links states the following:

An official link is a link to a website or other Internet service that meets both of the following criteria:

1. The linked content is controlled by the subject (organization or individual person) of the Wikipedia article.

2. The linked content primarily covers the area for which the subject of the article is notable.

Given that Kirk is deceased, he clearly is no longer in control of the website linked (www.charliekirk.com [6]), and the website now contains significant content on topics that have arisen since his death. I raised this at Talk:Charlie Kirk [7], and there has been some rather inconclusive discussion at Wikipedia talk:External links [8], but nothing concrete arrived at, and accordingly I'd like to know how the broader community thinks such situations should be dealt with. In my opinion, we seem to need some form of clarification of general policy on this matter, since it appears that such 'official' links in infoboxes for the deceased aren't unusual. If this is actually the case, and this is seen as acceptable, I think we should at least be giving some guidance as to when such treatment is conmsidered appropriate and then making it clear to readers on what basis the website is provided. As of now, practice appears to be running in contradiction to a policy that seems unambiguous. AndyTheGrump (talk) 21:59, 30 July 2026 (UTC)reply

Individuals' estates can control their intellectual property/brand after death. I don't see the issue with linking to an official website of a deceased person. voorts (talk/contributions) 22:08, 30 July 2026 (UTC)reply
I've been involved in the discussion at the Kirk talk page. I agree with voorts that we should normally assume that these websites continue to be controlled by the deceased's estate, and that they can remain "official" for our purposes under most circumstances. I would carve out an exception for the (probably rare) instances where we have reliable sourcing that the website has been taken over after the death, by some party that is no longer friendly to the deceased, and might be taking the website in directions that would be contrary to the deceased's wishes. I wouldn't mind clarifying that exception in the policy, but I do regard it as something that would be unusual. --Tryptofish (talk) 22:20, 30 July 2026 (UTC)reply
Sorry, but I don't think that 'continue to be controlled by the deceased's estate' is really a thing, legally. A deceased persons estate is the property they owned. It isn't a legal entity. Such property will be passed on to others. AndyTheGrump (talk) 22:28, 30 July 2026 (UTC)reply
An estate is absolutely a legal entity. Estates can sue and be sued. voorts (talk/contributions) 22:31, 30 July 2026 (UTC)reply
And normally the estate is established by the person's will, so it will be assigned to trusted surviving relatives. I do realize that there can be (rare) exceptions where, over time, ownership of the estate passes from one to another and eventually becomes at odds with the deceased person. --Tryptofish (talk) 22:34, 30 July 2026 (UTC)reply
See, for example, Estate of Jeffrey Epstein. voorts (talk/contributions) 22:35, 30 July 2026 (UTC)reply
How about we stay on topic? If 'estates' are relevant to this discussion at all, it is only if and when it can be shown that they are actually in control of the website in question. And even then, if that is the case for a specific website, shouldn't we be clarifying who is running the website? This is the issue I'm trying to get resolved in this discussion, and it really isn't helped by people invoking hypothetical 'estates', 'trusts' etc. We have a policy saying one thing. We appear to have articles applying something else. Why is it so difficult to discuss the issue directly? AndyTheGrump (talk) 22:43, 30 July 2026 (UTC)reply
I am staying on topic. It is my view that we should allow external links to the official websites of deceased persons where those websites are run by their estates or some other relevant organization (e.g., if a musician's website is run by their label before and after death). An estate is usually "controlled by the subject" because it's created in line with their will. voorts (talk/contributions) 22:50, 30 July 2026 (UTC)reply
I think that is where I would land as well. For well known public figures, it can be assumed official websites and the like will be run by the estate of that person unless shown otherwise. As the estate is setup by the person and acts as an extention of their will, im not even sure its really in conflict with the guideline. PackMecEng (talk) 23:05, 30 July 2026 (UTC)reply
Sorry, but I'm not going to respond further to unsourced commentary about hypothetical estates, and even more hypothetical commentary about the terms under which they might be administered. I started this discussion in the hope that a mismatch between policy and practice could be resolved, and as far as I'm concerned, debating about imagined legal entities has never been seen as an appropriate way to resolve anything. AndyTheGrump (talk) 23:14, 30 July 2026 (UTC)reply
We're not debating about imagined legal entities. Can you please tone it down a notch? voorts (talk/contributions) 23:44, 30 July 2026 (UTC)reply

In case anyone is interested, a little spot survey shows that David Bowie, John Lennon, Michael Jackson, Prince, Jimi Hendrix, Amy Winehouse and George Michael all link to official sites in their infobox. Kurt Cobain and Elvis Presley do not (Elvis does seem to have a site of the sort we would link at [9] There is a kurtcobain.com but it doesn't appear to be run by anyone associated with him. One can choose to view that as a widespread error or an informal consensus, I suppose. Morwen (talk) 23:29, 30 July 2026 (UTC)reply

A quick look at the infobox websites from the bio's you linked suggests that many are strictly commercial enterprises, serving almost entirely as sales outlets. Is that the intended purpose of such links? I'd always assumed that the purpose of an 'official link' in a biography was to help readers find out more about the what subject has to say themselves, rather than as a link to a sales platform. AndyTheGrump (talk) 23:39, 30 July 2026 (UTC)reply
I'm guessing that most official websites of notable persons are (1) not actually maintained by that person and (2) designed to encourage readers to hand over money, such as by buying an album or a book, hiring someone for their services, or making a political contribution. voorts (talk/contributions) 23:47, 30 July 2026 (UTC)reply
I would think a great many official websites for living individuals serve a commercial interest. It's a stretch to say that ladygaga.com or beyonce.com give the reader the opportunity to see what the subject says about itself. The same policy provision also applies to brands and e-commerce sites like Amazon.com, where the official site has an explicitly commercial purpose. An official website seems to be a piece of basic information that is included by convention, regardless of the encyclopedic value of the site's content (barring certain restrictions, of course). —Myceteae‍🍄‍🟫 (talk) 21:52, 31 July 2026 (UTC)reply
Is anyone willing to actually discuss the substantive issue here: that we have an unambiguous mismatch between a policy, which states that an 'official website' must be controlled by the article subject, and practice, which seems to completely disregard this requirement? Or is the consensus that we should ignore this, and hope it goes away? AndyTheGrump (talk) 22:10, 31 July 2026 (UTC)reply
I say we amend the guideline to include trusts or their estates. They were created by the person while alive for the express purpose of representing their interests after death. PackMecEng (talk) 22:19, 31 July 2026 (UTC)reply
I assume we are going to need evidence that such 'trusts and estates' exist, and have been created for such purposes? Because so far, I've seen no evidence of any such trust or estate being in control of any of the 'official websites' for the articles discussed so far, never mind any evidence that they are representing any specific interests. AndyTheGrump (talk) 22:26, 31 July 2026 (UTC)reply
Ronald Reagan links to "official sites" in the External links section and the first is the Reagan Foundation. Richard Nixon also has an "official sites" subsection in the External links and links separately to an official White House biography, the Nixon Library and Museum, and the Nixon Foundation. Jahaza (talk) 22:37, 31 July 2026 (UTC)reply
Willem de Kooning doesn't have a link in the infobox, but links to the Willem de Kooning Foundation as the first of the External links. Jahaza (talk) 22:43, 31 July 2026 (UTC)reply
Good. Meanwhile, for none of the examples so far discussed in this thread (Kirk, Bowie, Lennon, Jackson etc) has anyone provided evidence of a 'trust' or 'estate' operating under the terms proposed ('representing their interests after death'). Do you think it reasonable that including an 'official website' link in an infobox for a deceased individual should require such evidence or not? AndyTheGrump (talk) 22:46, 31 July 2026 (UTC)reply
Do you really think someone like Charlie Kirk didn't have a will? voorts (talk/contributions) 23:44, 31 July 2026 (UTC)reply
I'd hope he did. I see no reason whatsoever to assume that he made provisions for any sort of 'trust' or whatever regarding his website, though with regard to Kirk, I suspect, looking at www.charliekirk.com/about-charlie-kirk, the website may well actually belong to Turning Point USA. This isn't just about Kirk though, and I don't think it is particularly helpful to get into specifics. The policy/practice mismatch is a general issue, and not a single-article one. AndyTheGrump (talk) 01:20, 1 August 2026 (UTC)reply
Andy, I don't think people are ignoring the issue. It's just that they disagree with you. --Tryptofish (talk) 22:23, 31 July 2026 (UTC)reply
If the issue isn't being ignored, where is a solution being offered? AndyTheGrump (talk) 22:28, 31 July 2026 (UTC)reply
OK, I think it's clear that there won't be consensus for saying that we can only have links to websites when the person is still alive, so the question of a solution seems to me to come down to having some additional language to clarify when the website of a deceased person might not be allowed. If you were to propose some specific language for that purpose, I think other editors would be able to engage with that. --Tryptofish (talk) 22:57, 31 July 2026 (UTC)reply
I think most people don't see what you characterize as a problem. Katzrockso (talk) 14:28, 1 August 2026 (UTC)reply
First of all, you brought up the purported purpose of official links, and in a manner that suggested this is relevant to interpreting their appropriateness in articles, so it is natural that people would respond. We're trying to get a handle on the scope of the issue, in service of understanding whether the policy is at odds with actual practice and, if so, what direction a solution would take. Provisionally, I agree with you that the practice appears to run afoul of the plain reading of one part of the guidance—controlled by the subject, which is defined per the piped links as an organization or corporation or a living or recently deceased person. Understanding how and why such links are actually used is helpful in determining whether there is an actual problem and identifying potential solutions. —Myceteae‍🍄‍🟫 (talk) 22:38, 31 July 2026 (UTC)reply
There's a useful article here from the Brooklyn Rail that discusses artists foundations and how there are many different types of official foundations that might be set up to survive an artist and might help in assessing the lay of the land. Jahaza (talk) 22:45, 31 July 2026 (UTC)reply
If such foundations have been set up, it is clearly something we should take into account for a particular article. We'd need evidence first though. AndyTheGrump (talk) 22:50, 31 July 2026 (UTC)reply
Do we have a process for verifying the ownership and control of purported official website of living subjects? —Myceteae‍🍄‍🟫 (talk) 00:23, 1 August 2026 (UTC)reply
Not a general process, no. I'd assume that beyond looking for sources (i.e., the website being linked from WP:RS, and if in doubt maybe checking who the domain is registered too, though that can be problematic), we'd tend to assume that if the website linked isn't the subject's, they'd complain. Not 100% foolproof, but at least we know who the owner is supposed to be. In the situation we are discussing (i.e. deceased subjects), we can't just assume that some hypothetical foundation or whatever is in control. AndyTheGrump (talk) 01:13, 1 August 2026 (UTC)reply
Why not? Thats what we do now with most official websites. Assume the subject is in control. Also do you not think these trusts or foundations are like a real thing? You keep using terms like hypothetical, scare quotes, and saying its property and not a legal entity that make me not sure you fully understand what they are or how they operate. PackMecEng (talk) 01:28, 1 August 2026 (UTC)reply
I say 'hypothetical' because people keep suggesting that a trust or foundation exists in relation to a specific deceased individual's website, without providing any evidence. As a general principle, Wikipedia requires verifiability, not vague claims about things that might possibly exist. And in any case, regardless of whether such a trust/foundation exists, it isn't the article subject, and policy as it stands says that the website must be controlled by the subject. Not by anyone or anything else. 'The subject'. Whom we can definitively say is not 'in control', being dead... AndyTheGrump (talk) 01:45, 1 August 2026 (UTC)reply
I assume the vast majority of official websites are added unceremoniously. They are usually obvious and not the sort of thing one gives a lot of thought to needing to verify. In the (presumably rare) case that the official website is questioned, it is either removed or discussed. I think there should be some reason to question the ownership, or some other concern about the website itself, other than the person having died. —Myceteae‍🍄‍🟫 (talk) 02:03, 1 August 2026 (UTC)reply
The reason to 'question the ownership' (or more relevant, 'control', since that is what policy specifies) for an infobox link for a dead person seems self evident. They can't be controlling it, which is a requirement for its inclusion, under policy. If you think this policy needs changing, fine. Make a proposal to change it. But please stop pretending the requirement doesn't exist. It does, and it is unambiguous. AndyTheGrump (talk) 04:46, 1 August 2026 (UTC)reply
  • My inclination is probably not in the infobox for deceased individuals (or individual officeholders who no longer hold that position and defunct corporations). I agree with Myceteae that these links are no longer controlled by the subject, and become disconnected with the subject. I have no problem with these links being in the "External Link" section, but I think they should be removed from the infobox. --Enos733 (talk) 23:02, 31 July 2026 (UTC)reply
    Yeah, I agree with this. Once the person is deceased, they no longer have control/a say in how they want their "official website" to look, function, etc. Sure, they could possibly leave a note to their loved ones, friends, marketing team or whoever, instructing them to manage their website a particular way after their death, but there's no guarantee that the group will actually follow through with the dead person's requests. So I would support removing the "Website" parameter off the infoboxes of deceased individuals' biographies. Some1 (talk) 02:15, 1 August 2026 (UTC)reply
    i have it on good authority that Jimi Hendrix's website is being run exactly as he specified in his will. :p Morwen (talk) 02:24, 1 August 2026 (UTC)reply
I think the issue concerns using "official" to describe the link and that no one has seriously suggested removing the link. A website controlled by others cannot be official. Should editors monitor a website every month to determine whether its message still corresponds to those that the subject would have? Just provide the link and let readers work out if a legal entity set up by the subject is still running the site in accordance with the subject's wishes. Johnuniq (talk) 03:18, 1 August 2026 (UTC)reply
The infobox link isn't actually labelled 'official': it's the placement that is really the issue, since it's presence there implies some sort of official status that other websites don't have. And it appears that this implication is being exploited for commercial reasons: e.g. the Hendrix biography mentioned above has a link, despite Hendrix dying in 1970, long before websites were a thing. And as much as the Sony Corporation would no doubt like to represent themselves as trustees of Jimmy's legacy, I can't think of any good reason why we should be offering them free links for their products. AndyTheGrump (talk) 03:32, 1 August 2026 (UTC)reply
I See that Janis Joplin appears also to have had the foresight to provide for a website on her demise, which occurred the same year as Jimmy. Were they perhaps informed of future technology by a time traveller? Or do the Sony Corporation and whoever it is that runs janisjoplin.com (your guess is as good as mine) own Ouija boards, and allow 'control' from the beyond? AndyTheGrump (talk) 12:27, 1 August 2026 (UTC)reply
  • Obviously, a dead person's website isn't controlled by that person. So obviously, the considerations that led Wikipedians to say "Official website only" don't apply in the same way. Duh.
Separately, and this is probably just me: I loathe the use of "individuals" to mean "people". It's like saying "utilize" instead of "use": just needless syllables. Wikipedia's badly-written enough without calling a spade an earth-inverting horticultural implement.—S Marshall T/C 09:25, 1 August 2026 (UTC)reply
So how should Wikipedia be dealing with this situation? What should we do to rectify a badly-written policy that doesn't match what people are claiming is normal practice? Or is it the practice that is the problem, rather than the policy? AndyTheGrump (talk) 12:10, 1 August 2026 (UTC)reply
Personally, I think we should update the documentation for Template:Infobox person to say "leave blank if the person is dead or long-term missing".—S Marshall T/C 12:33, 1 August 2026 (UTC)reply
Yup, I'm coming around to much the same conclusion myself. I intentionally held off making any specific suggestions initially, in the hope that some sort of consensus might arise, but it seems there are really only two camps on this: those who take the policy at face value, and accordingly only consider an infobox appropriate for those who at least have the potential to control a website on the basis of not being dead, and those who would rather that mortality didn't come into it, and are happy for commercial enterprises, and/or trusts and foundations that may or may not exist, should be permitted to pretend that they are the living embodiment of the deceased. And no, I'm not going to apologise for sarcasm here, given the way people have trotted out arguments based solely on hypotheticals, while ignoring evidence that such links are being exploited for purposes other than that intended. Maybe we need an RfC on this, though as I see it, the status quo isn't really an option, given its unresolved and contradictory state. If anyone can offer actual suggestions for a policy change (or clarification, if they wish to see it that way) that permits infobox links for deceased individuals under appropriate circumstances, we can consider that, but first we'd need a suggestion regarding what is 'appropriate'. AndyTheGrump (talk) 12:56, 1 August 2026 (UTC)reply
It's not a policy. PackMecEng (talk) 13:42, 1 August 2026 (UTC)reply
Are you suggesting that Wikipedia:External links should be ignored? Wikipedia:What Wikipedia is not (which most definitely is policy) seems to suggest otherwise: e.g. External links to commercial organizations are acceptable if they identify notable organizations which are the topic of the article. Hard to reconcile that with e.g. the links in the Joplin or Hendrix infoboxes. Jimmy Hendrix isn't the Sony Corporation. AndyTheGrump (talk) 13:53, 1 August 2026 (UTC)reply
Not what I said at all. You keep mis-stating what others are saying and why they are saying it and then saying its going against policy. WP:EL is not policy. PackMecEng (talk) 14:36, 1 August 2026 (UTC)reply
I have just quoted Wikipedia:What Wikipedia is not, which is policy. AndyTheGrump (talk) 15:06, 1 August 2026 (UTC)reply

In my view, the guideline as it stands is appropriate and sufficiently clear. It should be applied to the Charlie Kirk page, which is to say that the link should be removed. Dionysodorus (talk) 15:18, 1 August 2026 (UTC)reply

I don't see any compelling reason we shouldn't link these websites. It seems useful to the reader to see what their estate, or family, or etc, present, for the same reason it did as when they were alive. PARAKANYAA (talk) 17:59, 1 August 2026 (UTC)reply

I'm thinking a lot of this comes down to how we link to the website, as opposed to whether or not to link to it. I just looked at all the documentation for Template:Infobox person. (It has laughably many parameters, including things like whether to include inches in how tall someone is.) So, when we put such a url in the template, it gets displayed as "Website", not "official website", so readers are not exactly being told that the deceased person is still controlling the website, although we can certainly question whether that's implied. When I scroll way, way down, and find the instructions, however, it says: "Official website only. Unofficial websites should be placed under External links in the body of the article." It doesn't define "official" and "unofficial", and readers don't see those instructions. I'm asking myself if the official website of a living person becomes an unofficial website following that person's death, and it does not make sense to me to say that it does. For it to make that change, from official to unofficial, I would want to see reliable sourcing that tells me that the nature of the website has changed, as opposed to having Wikipedia make an automatic presumption of change. --Tryptofish (talk) 20:46, 1 August 2026 (UTC)reply

Right after posting that, I realized that I should also look again at WP:ELOFFICIAL, where official and unofficial actually are defined. And I'm thinking that a significant part of the problem here is the choice of words there, that says: "is controlled by the subject", and how that bumps up against the nonsensical situation of a dead person "controlling" anything. That guideline section deals with other things besides persons (fan sites and such), where it makes sense to frame things in terms of the verb "control", but we get into a problem here. The guideline section already talks about situations where an "official" website has been hijacked. Perhaps some clarifying language needs to be added there, that addresses websites that continue to be faithful to what a person would have wanted, after that person has died and no longer controls the website. --Tryptofish (talk) 21:17, 1 August 2026 (UTC)reply
Yeah, the guideline says the website must be "official" and meet the other two criteria. The discussion of fansites is instructive. Not that a website run by the family/trust/estate/whatever is equivalent to a fansite, but the guidance is explicit in repeating the control criterion when addressing another situation where one might argue that a website has something close to "official" or authorized status. —Myceteae‍🍄‍🟫 (talk) 21:26, 1 August 2026 (UTC)reply
I have suggested at Talk:Charlie Kirk#'Official website' and YouTube channel that perhaps it might be appropriate to link to the archived version of the website, as it was at the time of Kirk's death. If it seems like a good idea, one possibility might be to change the guideline in such a way as to suggest that, in cases where a dead subject's website changes significantly after a person's death, it might in general be appropriate to link to the archived version rather than the current version. Dionysodorus (talk) 21:27, 1 August 2026 (UTC)reply
I disagree with equating family or estate with fans at a fan site. For our purposes, fan sites resemble user-generated content. Any random person purporting to be a fan can change what it says at such sites. It normally will not be like that for the website of a dead person, where (if) the estate is closely watching that it remains faithful to that person's wishes.
As for using archive links, that's a worthwhile idea. But we should also consider when archives are out-of-date, while the current website is still controlled by people close to the deceased person's wishes, as well as when archives are difficult to load. --Tryptofish (talk) 21:32, 1 August 2026 (UTC)reply
I can think of a whole platoon of special cases and what-ifs with that. It might well need some editorial judgment to decide the exact version we should link to. I'm saying that what works in Charlie Kirk's case won't necessarily generalize very well. In Charlie Kirk's case we have the exact date and time of his death, which helps. But people also die or vanish in less well documented circumstances.—S Marshall T/C 21:39, 1 August 2026 (UTC)reply
@Tryptofish: I suppose we could write something like "In cases where the subject of the article is deceased, it may be appropriate to continue to include a live link to the subject's website if this has been maintained largely as it was at the time of the subject's death, but if the website has been substantially changed following the subject's death it may be appropriate to use an archived link to the website as it was when the subject died." That would cover the difficulties to which you refer, leaving appropriate room for editorial discretion. Dionysodorus (talk) 21:43, 1 August 2026 (UTC)reply
Yes, I'm thinking along those lines. Maybe it needs some wordsmithing, but I think brainstorming along those lines might address Andy's concerns, and be able to get consensus. --Tryptofish (talk) 21:46, 1 August 2026 (UTC)reply
I don't think we are in the position to determine whether a website was "substantially changed." We have a hard enough time dealing with our own policies. As I stated upthread, I think the bigger concern is continuing to link to the website in the infobox. - Enos733 (talk) 22:16, 1 August 2026 (UTC)reply
“But if reliable sources report that the website has been substantially changed following the subject's death […]”
I think for post-mortem removal of official links, the burden of proof has to be on the side of removal. Inclusion should be the status quo.
It is not notable to report that “XX’s website continues to be representative of XX”, and RS should not be expected to divert resources to report that kind of trivia.
But it is notable to report that “XX’s website does not continue to be representative of XX”, and when RS report that, we should remove the official link. Mikewem (talk) 22:31, 1 August 2026 (UTC)reply
I'm not suggesting that we should require reliable sources to determine whether the website has changed substantially or not: that would be absurd, since (as you say) this is not the kind of thing that reliable sources would discuss. Rather, I am suggesting that editors should exercise their judgement as to whether the website has changed substantially or not, and use the archived link if it has: in most cases this is likely to be obvious and uncontroversial, and if it is controversial in a given case it can be resolved through the normal consensus or dispute resolution processes.
It would be odd if we required reliable sources for such a purpose as this. We require reliable sources for content, but in general we make our own judgements about what content, sources and links are appropriate or inappropriate to include, precisely because reliable sources in their nature do not usually specify this for us. Dionysodorus (talk) 23:08, 1 August 2026 (UTC)reply
I assume, then, that articles about people who died years before the internet age should not have website links in the infobox (e.g., Janis Joplin). —Myceteae‍🍄‍🟫 (talk) 23:22, 1 August 2026 (UTC)reply
Well, no, I don't think they should. In my view, the link in Janis Joplin's infobox should be removed (or, at least, should not be presented as an "official website", even if the website presents itself as such), since there is no sense in which it can be controlled by the singer herself, as WP:ELOFFICIAL requires. Dionysodorus (talk) 23:36, 1 August 2026 (UTC)reply
  • Question: Should we have removed the links from Britney Spears's infobox for the duration of her conservatorship? I don't think this is too tangential. This is a much more clear-cut case where the subject is not in control of their own website. —Myceteae‍🍄‍🟫 (talk) 21:37, 1 August 2026 (UTC)reply
    I feel we should perhaps talk about the case of people who don't control their website because of mental or legal capacity in a separate discussion. It's relatively easy to think about for children or people who're in a coma or who've disappeared, but we don't want Wikipedians trying to diagnose people's mental health on the basis of news reports.—S Marshall T/C 21:42, 1 August 2026 (UTC)reply
    I think, again, that would depend on whether or not whoever was running the website was acting in her interests. Part of my point above was that "control" means different things when we are talking about individual people, and the guideline wording may not currently get that right. --Tryptofish (talk) 21:43, 1 August 2026 (UTC)reply
    In response to both replies above, I don't want to derail this focused conversation but I find these issues highly relevant and I don't think the determination is necessarily simple. In the case of Spears, she was quite explicitly and legally not in control of "official" communications. This requires no armchair "diagnosis" by Wikipedians. On the other hand, legally, this was considered to be "in her interest". The particulars surrounding Spears, as with Kirk or any other individual, may or may not generalize. As for children and people in comas, it's not obvious to me that these are easy, either. I don't want to get too in the weeds on other test cases but we should be considering the full scope of the guideline whether we decide to maintain the current wording or amend it to address deaths. —Myceteae‍🍄‍🟫 (talk) 22:18, 1 August 2026 (UTC)reply

Discussion at Wikipedia talk:No disclaimers § Disclaimers by WMF not exempt?

 You are invited to join the discussion at Wikipedia talk:No disclaimers § Disclaimers by WMF not exempt?. George Ho (talk) 23:17, 1 August 2026 (UTC)reply

Technical

The audio progress is unseen in dark mode

Tracked in Phabricator
Task T432793

Hi. I realized that in the dark mode the audio progress line is invisible, while in the light mode it's completely okay.


See this and this screenshot for comparison. Aminabzz (talk) 08:54, 21 July 2026 (UTC)reply

I'm on a funky hotel wifi that doesn't seem to like your screenshot upload host, so I can't load them. :( Can you file a task on Phabricator and attach them there? Use project tag "TimedMediaHandler".
Then I'll try to take a look over it this week during Wikimania. Dark mode bugs usually are easy CSS fixes that just need something accommodated with an alternate style, so hopefully we can knock out a fix pretty fast. brooke (talk) 09:27, 21 July 2026 (UTC)reply
Allright, I'll do that. BTW, I edited my post. I meant audio, not video. Aminabzz (talk) 22:18, 21 July 2026 (UTC)reply
@Brooke Vibber Update: I created the Phabricator task. Aminabzz (talk) 22:36, 21 July 2026 (UTC)reply
What Brooke asked is to upload the screenshots to Phabricator, not link from there. Nardog (talk) 00:29, 22 July 2026 (UTC)reply
Thanks, however I still can't reach the links -- can you attach the actual images to the task instead of linking them on an external host? Thanks! brooke (talk) 06:30, 22 July 2026 (UTC)reply
We never got the screenshots but the task was merged as a dupe to another task which did have screenshots and a reproducible example, so we're all good. :)
I tracked the problem down to Vector 2022-specific dark mode style overrides used on Wikimedia sites, and cobbled together a patch which seems to resolve it and several other bits in the player that were broken in dark mode on Vector 2022 with the Wikimedia style overrides.
Once through code review this should get merged in and roll out within a week or two.
Thanks for the big report! brooke (talk) 11:03, 25 July 2026 (UTC)reply
The url domain name has .ir as its tld, which might be why your wifi isn't a huge fan, it wouldn't surprise me if their internet service provider has just blocked the whole tld. Or the sight could just be down. It doesn't seem particularly eager to load, either. Mitchsavl (talk) 11:12, 29 July 2026 (UTC)reply

Is it THURSDAY or is it Firefox

Background: Vector legacy/2010, Firefox Beta (freshly updated to 154.0b1), source editor

Issue: I signed on, edited a page, and thought it weird when I tabbed out of the edit box to add an edit summary, it instead shifted to the "Insert / Wiki markup / Symbols / etc" dropdown just below the edit box. I don't remember this happening this morning when I made a few edits but I also don't remember tabbing to add an edit summary. I definitely know it wasn't happening yesterday.

Is this a THURSDAY thing or is my freshly-updated FF beta not playing nice? Thanks for the thoughts. Primefac (talk) 21:47, 23 July 2026 (UTC)reply

This might be autosuggest for the source editor which was rolled out earlier this week? Kowal2701 (talk, contribs) 22:26, 23 July 2026 (UTC)reply
Well, I just on a hunch turned off the Syntax highlighter and things return to "normal" tab use, so it could be (though I'm not seeing any indication of an autosuggest in my editor). Primefac (talk) 22:38, 23 July 2026 (UTC)reply
I cannot reproduce it using Firefox 150.0.1, so it is likely to be Firefox.析石父 (talk) 00:55, 24 July 2026 (UTC)reply
I'm on 155.0a1 and can't reproduce it. Jerod Lycett (talk) 00:12, 26 July 2026 (UTC)reply
Thumb won't preview, but enjoy. If it doesn't happen in Alpha then I guess they've fixed it... Primefac (talk) 00:53, 26 July 2026 (UTC)reply
I'm on alpha and can reproduce, but I'm a couple weeks out of date... I'll update and report back. LittlePuppers (talk) 04:26, 26 July 2026 (UTC)reply
I updated and it's still here. I don't tab to there though, so I have no idea when/why it changed. LittlePuppers (talk) 04:32, 26 July 2026 (UTC)reply
I do think it's likely a Firefox thing, my laptop only updated yesterday and right after I noticed the change in behaviour. I filed at bugzilla so we'll see how things get on. Primefac (talk) 09:43, 26 July 2026 (UTC)reply
Yeah, just tried in Edge and it doesn't happen there. Do you have a link to Bugzilla, for the curious? LittlePuppers (talk) 14:59, 26 July 2026 (UTC)reply
https://bugzilla.mozilla.org/show_bug.cgi?id=2057769 Primefac (talk) 15:36, 26 July 2026 (UTC)reply
Just to close the loop here, it was a Firefox regression and it looks like it's in the process of being patched. Thanks all for the thoughts. Primefac (talk) 22:19, 29 July 2026 (UTC)reply
@Primefac or anyone else following, I'm on Chrome, not Firefox, and this has started happening to me today so I'm inclined to think it's a Thursday thing. When my connection is slow, the page hangs noticeably before all the highlighting appears. (I haven't changed anything in my preferences recent recently, I'm using the latest version of Chrome, but this didn't happen 24 hours ago). HJ Mitchell | Penny for your thoughts? 20:37, 30 July 2026 (UTC)reply
That sounds like it's probably a separate issue. LittlePuppers (talk) 20:55, 30 July 2026 (UTC)reply
Agreed; that's been happening for a little bit for me, just figured it was my computer being slow to run scripts. Primefac (talk) 22:37, 30 July 2026 (UTC)reply

"not a valid map data page"

Tracked in Phabricator
Task T433008

Robben Island Marine Protected Area and 926 other articles, at this writing, are displaying messages like mapframe: Title "Robben Island Marine Protected Area.map" is not a valid map data page. They seem to come from {{maplink}}. commons:Data:Robben Island Marine Protected Area.map exists, appears to be working fine, and if I had to guess, was probably working fine at Robben Island Marine Protected Area at some point in the past. I don't see any templates used in this page that have been changed in the last few days. {{Maplink}} was last modified in 2018, and Module:Mapframe was last modified on 1 June 2026.

At the bottom of the article, a series of red error messages is displayed instead of {{Marine protected areas of South Africa map}}, which looks fine on its Template page. The above problem is present in both Parsoid and the legacy parser. – Jonesey95 (talk) 05:21, 24 July 2026 (UTC)reply

I've noticed that a bunch of other articles with Template:Maplink don't have this problem until the page is purged, then the error message appears and the map disappears. Steelkamp (talk) 05:29, 24 July 2026 (UTC)reply
This probably means that a WP:THURSDAY MediaWiki code update causes the issue, and pages are showing the error message when they are purged or edited. The count of articles has increased from 926 to 941 just in the last 15 minutes, so it will probably go much higher. [Update: I found T433008.]– Jonesey95 (talk) 05:37, 24 July 2026 (UTC)reply
The number has gone up to 1,269 Quake1234 (talk) 14:51, 24 July 2026 (UTC)reply
Yes, and Category:Pages with broken maps has increased to 1,500 pages. I hope the developers work on Fridays. – Jonesey95 (talk) 16:47, 24 July 2026 (UTC)reply
They don’t —TheDJ (talk • contribs) 18:18, 24 July 2026 (UTC)reply
Well, it looks like a volunteer developer from de.WP has submitted a patch. We'll see if anyone is willing to test and apply it. Off topic: Then why TF would they deploy new software on Thursdays? When I worked in IT, we NEVER changed anything at the end of the week. I liked having my weekends free and knowing that my systems were working for my customers while I was out rock-climbing or whatever. – Jonesey95 (talk) 21:14, 24 July 2026 (UTC)reply
To answer the question, the reason we get new software on Thursdays is to allow the WMF to do a staggered rollout: testwikis on Tuesday, non-Wikipedias on Wednesday, Wikipedias on Thursday. No I don't know why they don't move that one-day earlier but there's a trilemma between staggered rollouts, no end-of-week deployments, and a weekly release cadence all of which are good things which are mutually incompatible. * Pppery * in solidarity 23:32, 24 July 2026 (UTC)reply
IIRC, the Tuesday start was to avoid running into Monday holidays and Monday deploys of fixes for bugs found over the weekend. As for the "no deploys on Fridays" rule, looking through some recent Fridays in wikitech:Server Admin Log I do see some Friday deploys, including some that are things I really wouldn't expect given the strict language on wikitech:Deployments/Emergencies (which does include "Major loss of functionality / appearance", BTW). Anomie⚔ 00:28, 25 July 2026 (UTC)reply
Feels like one of those products people would naturally discuss on Reddit once more users discover it. ~2026-42024-47 (talk) 11:06, 29 July 2026 (UTC)reply
Since when don't they? Anomie⚔ 23:02, 24 July 2026 (UTC)reply
While we are here, can we break out Category:Articles with broken maps??? Ahecht you helped me do this with Category:Articles with script errors perhaps you can assist here? Zackmann (Talk to me/What I been doing) 23:22, 28 July 2026 (UTC)reply
@Zackmann08: The bug has now been fixed so Category:Pages with broken maps is down to 143 pages and it has a link to search articles so I don't see a big need for a split. The search link currently gives too many articles because search hasn't updated fully after the fix but that's a temporary issue. Category:Pages with script errors and its namespace-specific subcategories have around 1,600 pages in total so a split is more helpful there. If we want to split Category:Pages with broken maps then MediaWiki:Kartographer-broken-category could propbably make similar code to MediaWiki:Scribunto-common-error-category. I say "probably" because some MediaWiki messages don't allow wikitext and it's hard to tell which ones without trying it. PrimeHunter (talk) 12:07, 29 July 2026 (UTC)reply

So who busted Template:Maplink?

The |from= parameter doesn't work for any given mapdata link, and everything else is intact. ⠀⠀ .n 03:30, 27 July 2026 (UTC)reply

Related to phab:T433008, perhaps? Staraction (talk · contribs) 03:44, 27 July 2026 (UTC)reply
hm yeah definitely :sob: ⠀⠀ .n 03:48, 27 July 2026 (UTC)reply

Map error on M-47 (Michigan highway)

For some reason, the map feature on M-47 (Michigan highway) is displaying the error mapframe: Title "M-47 (Michigan highway).map" is not a valid map data page. Anyone know how to fix this? Ping @Imzadi1979: Ten Pound Hammer (they/them) • (What did I screw up now?) 04:23, 27 July 2026 (UTC)reply

@TenPoundHammer Maplink is busted right now. ⠀⠀ .n 07:07, 27 July 2026 (UTC)reply

Display better error message?

MediaWiki:Kartographer-error-title says: Title "$1" is not a valid map data page . That's a wrong error message at the moment and displayed in thousands of articles where many editors don't know what to do. They shouldn't do anything but just wait for the bug fix. Maybe we should customize the message until a fix is deployed. I suggest: "A bug prevents map display. A fix is underway." I have tested that the message allows wikilinks. PrimeHunter (talk) 03:24, 28 July 2026 (UTC)reply

this broadly makes sense to me but i would suggest not putting the ticket in. while it may provide some contrete reassurance it also might result in people coming to the ticket to urge the hurring up of a bugfix they're hard at work on.... Morwen (talk) 04:00, 28 July 2026 (UTC)reply
I agree with Morwen. Please implement this in plain text ASAP. It looks like a fix may be on the way in the next MediaWiki update; it is not clear why they did not roll out a patch more quickly, given the scale of the impact and the potential for editors removing things from pages in error. – Jonesey95 (talk) 14:22, 28 July 2026 (UTC)reply
I have saved it as plain text. See e.g. the effect in Robben Island Marine Protected Area where the infobox previously said mapframe: Title "Robben Island Marine Protected Area.map" is not a valid map data page. MediaWiki:Kartographer-error-title should be deleted after the bug fix is deployed but first check that the fix has propagated so the searches "not a valid map data page" or "bug prevents map display" don't give results caused by the bug. PrimeHunter (talk) 15:32, 28 July 2026 (UTC)reply
A bug fix has been deployed and appears to be working. The searches "not a valid map data page" and "bug prevents map display" still give some results but I haven't found any which actually display the eror message so it's just search which hasn't updated. Category:Pages with broken maps previously had 1000+ pages. Now there are only 143 and those I examined have other errors unrelated to the bug. PrimeHunter (talk) 11:48, 29 July 2026 (UTC)reply

I hope this belongs here but right after this issue has been fixed, I've tried opening maplink templates represented by a thumbnail (instead of just a link) and it only expands said thumbnail instead of the actual interactive map (eg. the infobox of North Carolina's 1st congressional district). Interestingly, if I append #/map/0 or #/map/1 after the URL, it opens up as normal. Indeed, if a link is used in lieu of a thumbnail (eg. "Interactive map version" on the map caption in North Carolina's congressional districts), it will go to the proper URL and interactive map as normal. –twotwofourtysix(talk || edits) 10:04, 1 August 2026 (UTC)reply

I've noticed this problem too! Some maps work fine (e.g. Dream Island) but others will only work in editing previews. (e.g. 2026 Minab school attack) – MrPersonHumanGuy (talk) 18:45, 1 August 2026 (UTC)reply
As it turns out, the still-working maps are transclusions of {{OSM Location map}}, which doesn't have the problem that {{maplink}} currently has. – MrPersonHumanGuy (talk) 18:58, 1 August 2026 (UTC)reply

Re: 429 'too many requests' on Media viewer

We talked about this two months ago, and for a while it seemed fixed, but it's been back now for a few days, rendering the media viewer unusable for me. The annoying part is that the desired image shows up for a fraction of a second, and only then is replaced with a broken image symbol. -- Seelefant (talk) Seelefant (talk) 09:32, 26 July 2026 (UTC)reply

Last time it happened, the recommendation by User:JTweed-WMF was If this is still happening, please copy the details on the error page and email them to bot-traffic@wikimedia.org so that we can investigate further. User:ASarabadani (WMF) also posted You can create a private phabricator ticket or simply send the information to asarabadani@wikimedia.org.
JTweed and ASarabadani, are these methods of reporting HTTP status 429 errors still actual? —⁠andrybak (talk) 09:31, 31 July 2026 (UTC)reply

Over complicated template populating categories

Can somebody technically minded take a look at Template:Conflicts in year category header and adjust it to change all the categories from Category:Conflicts in YYYY to Category:YYYY conflicts please? The categories are being renamed but they all have this on them and it's not obvious how to simply change it over. Thanks in advance. Timrollpickering (talk) 17:48, 26 July 2026 (UTC)reply

Timrollpickering, I've made the changes in Template:Conflicts in year category header/sandbox. — Qwerfjkltalk 18:41, 26 July 2026 (UTC)reply
Thanks, it's working fine. Timrollpickering (talk) 18:54, 26 July 2026 (UTC)reply
Timrollpickering, you may also want to move the template to {{YYYY conflicts category header}} or similar. — Qwerfjkltalk 08:47, 27 July 2026 (UTC)reply
Moved to Template:Year conflicts category header which matches the category names. Timrollpickering (talk) 09:37, 27 July 2026 (UTC)reply
For the future, it's usually not worth the time to move a template that is Close Enough to the intended name. Izno (talk) 17:26, 27 July 2026 (UTC)reply

Why doesn't the archive button show up for me anymore...

I have "User:Elli/OneClickArchiver.js" installed & was going to do some manual archiving on a talk page but my "Archive" button - for talk pages - is not showing up for everything. All I am seeing now is "Subscribe" at Talk:Woodlawn (Alexandria, Virginia) & at Talk:Mount Vernon but I can see "Archive" at Talk:Wilmington massacre. - Shearonink (talk) 04:28, 27 July 2026 (UTC)reply

@Shearonink: Have you asked at User talk:Elli/OneClickArchiver? Elli was replying to threads there as recently as 22 July. --Redrose64 🌹 (talk) 07:28, 27 July 2026 (UTC)reply
@Shearonink: I don't use the script but it was updated 17 July and the documentation added "This script requires archiving be setup on a page to work".[10] This is consistent with your examples where only Talk:Wilmington massacre has set up archiving. PrimeHunter (talk) 08:38, 27 July 2026 (UTC)reply
Sheesh...so in order for it to work now someone (like me) has to go set up the talk archive page. It used to do that automatically... oh well, thanks for letting me know. I hadn't asked at User talk:Elli/OneClickArchiver, I always ask about this kind of stuff here first. I'll ask Elli whhhhhy. Thanks, Shearonink (talk) 16:34, 27 July 2026 (UTC)reply
For anyone in a similar boat, there are some ongoing discussions about this change at User talk:Elli/OneClickArchiver, including User talk:Elli/OneClickArchiver#Update broke the tool (plus User talk:Elli/OneClickArchiver#Discussion format breaks tool). - Shearonink (talk) 18:22, 27 July 2026 (UTC)reply
Generally speaking, if there is a problem with a script that's in somebody's user space, and that user is active, it's best to ask that user first. They might not have VPT on their watchlist. Also, although several VPT regulars are JavaScript coders, very few of theme have WP:INTADMIN rights. --Redrose64 🌹 (talk) 19:12, 27 July 2026 (UTC)reply

Broken template

Hello. Please see the results of matches with a gray background here: 2026 FIBA U18 EuroBasket Division C. Today, eight hours ago, everything was working properly. But then someone messed something up, and I can't figure out what... Thanks, Maiō T. (talk) 15:57, 27 July 2026 (UTC)reply

That's to do with an edit request I handled recently. Someone beat me to the punch on reverting it, so I'm gonna start looking at trynna fix it now. Thanks for the notice. Aidan9382 (talk) 16:11, 27 July 2026 (UTC)reply

Tech News: 2026-31

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

  • Wishlist item Content Translation now supports dark mode, fulfilling a Community Wishlist request. This brings the tool in line with the accessibility features available in the Vector 2022 and Minerva skins, helping reduce visual fatigue for users translating content. [11]
  • DiscussionTools' source mode and the 2017 wikitext editor will now offer autocomplete for links ([[), templates ({{), HTML and parser tags (<), and magic words (__), making it quicker and easier to insert links, templates, and other wiki markup while editing. [12]
  • The Readers Growth team has concluded its experiment with mobile page previews and will not roll out the feature. Page Previews are a pop-up bottom sheet that appears when readers tap a blue link, showing a thumbnail, lead paragraph, and an option to open the article. The experiment showed flat retention and negative indicator metrics, suggesting that mobile web readers preferred navigating directly to linked articles rather than using page previews.
  • The Reader Experience team has seen encouraging early results from the Reading Lists feature, with 93% of participating users reporting that it was useful. Reading Lists help active readers save articles for future reading and support their learning goals on Wikimedia projects. The team plans further improvements before expanding the feature to more users.
  • The Explore Feed Refresh initiative was tested with new and casual Wikipedia app readers. The refreshed feed helps readers discover new and relevant content. After a 10.5% increase in engagement with the feed, Wikimedia Apps team has decided to scale the Home Feed redesign to iOS with the learnings from the Android release applied.
  • Recurrent item View all 23 community-submitted tasks that were resolved last week. For example, an issue where subject names in the Article Guidance feature were displayed with incorrect capitalization on French Wikipedia, has now been fixed. Subject names will now follow the correct capitalization rules for the language. [13]

Updates for technical contributors

  • After running several Account Creation Experiments to improve registration completion rates, a new version of the username field on Create Account has been rolled out. It includes a popover summarizing the username policy to provide clearer guidance during account creation. As part of this change, the messages createacct-helpusername and createacct-username-help that several communities have configured will no longer be used. If communities want to customize the guidance shown in the new popover, they can instead edit the following messages: createacct-username-policy-popover-bullet1, createacct-username-policy-popover-bullet2, and createacct-username-policy-popover-bullet3. [14]
  • Later this week, the CodeMirror syntax highlighter will offer themes. The themes can be picked from a dropdown menu in the full CodeMirror preferences dialog. For wikitext, available themes are default, colorblind-friendly (previously the colorblind preference option on Special:Preferences#mw-prefsection-editing) and no-highlighting. For code languages (i.e., CSS/JavaScript/JSON/Vue/Lua), there are several themes available. These same themes will eventually be available for wikitext, too. [15]
  • From now on, wikis can restrict editing in the "User" namespace to only the page owner and certain user groups. Read the configuration documentation to learn more.
  • Recurrent item Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 18:47, 27 July 2026 (UTC)reply

Re "From now on, wikis can restrict editing in the "User" namespace to only the page owner and certain user groups": If anyone here sees a proposal to make this happen on the English Wikipedia, please post a link to the discussion here at VPT. There would be significant technical ramifications to making this change on this site, so technically minded editors should be involved in any such discussion. – Jonesey95 (talk) 22:07, 27 July 2026 (UTC)reply
Plenty of user subpages are treated as a shared resource, to editors' mutual benefit and without objection. Moving them to Wikipedia: namespace would be a possible but fiddly piece of bureaucracy. I can see an argument for protecting only top-level user pages, but that doesn't seem to be an option. Certes (talk) 18:16, 1 August 2026 (UTC)reply
A minor issue with protecting top-level user pages is that some users copy-paste wikitext of userboxes, which ends up categorizing their top-level user pages as templates: newer examples and older examples. Judging by these two searches, there are at least 2-3 new cases of these per week. If top-level pages are protected, cleaning up these miscategorizations would be more complicated.
A similar issue is violations of WP:DRAFTNOCAT, but I don't know how prevalent it is on top-level user pages. —⁠andrybak (talk) 18:38, 1 August 2026 (UTC)reply
DiscussionTools' source mode and the 2017 wikitext editor will now offer autocomplete for links ([[), templates ({{), HTML and parser tags (<), and magic words (__), making it quicker and easier to insert links, templates, and other wiki markup while editing. [16] – very nice, this makes working with templates in discussion much nicer, similar to how recent introduction of template category browser and favorite templates did for editing process. —⁠andrybak (talk) 16:36, 1 August 2026 (UTC)reply

In the cs1|2 update notice at Help talk:Citation Style 1/Archive 100 § module suite update 30–31 August 2025, I wrote this wikilink which, at the time, produced a working wikilink:

[[Help_talk:Citation_Style_1/Archive_99#{{pipe}}page=_same_value_as_last_n-digits_of_{{pipe}}doi=|discussion]]

That no longer works there (rendered by parsoid) but apparently does work here (edit preview not rendered by parsoid):

discussion

It used to be that {{pipe}} and &#124; were not treated as wiki markup. Is this going to be a permanent breakage caused by parsoid? or merely teething pains that we must suffer through until someone decides to allow html numeric entities to represent wiki markup characters as just characters?

—Trappist the monk (talk) 21:20, 27 July 2026 (UTC)reply

Definitely a difference between Parsoid and the legacy parser. Submitted as T433320. (One quick troubleshooting method is to click "Switch to legacy parser", which appears in my right sidebar in Vector 2022, under "General".) – Jonesey95 (talk) 22:18, 27 July 2026 (UTC)reply
@Trappist the monk As a workaround, using %7C in place of {{pipe}} does appear to work, e.g. [[Help_talk:Citation_Style_1/Archive_99#%7Cpage=_same_value_as_last_n-digits_of_%7Cdoi=|discussion]] → discussion (rendered with parsoid here). --Ahecht (TALK
PAGE) 13:59, 28 July 2026 (UTC)reply
Of course, I should have thought of that. Thanks. The question still remains however, will parsoid forever treat html numeric entities as wiki markup?
—Trappist the monk (talk) 14:16, 28 July 2026 (UTC)reply
That is not information anyone but the content transform team has access to, so you will need to wait for the Phab task to reach completion or a decline. Izno (talk) 16:33, 28 July 2026 (UTC)reply

Discussion+, a script for opening various types of discussions

I've created Discussion+, a script that can be used to open various types of discussions. It currently supports the following:

  • RfC
    • Open RfC
    • Appeal RfC
  • RM
    • Open RM
    • Review RM Closure
  • User conduct
    • ANI Report
    • AE Report
    • AE Appeal
  • Content promotions
    • In the news
    • GA nomination

I intend to expand it to:

  • User conduct
    • AE quick report
    • AN3 report
  • Content promotions
    • GA reassessment
    • FA nomination
    • FA reassessment
    • DYK

Are there other forms of discussions that editors would appreciate this handling?

Further in the future, I intend to make it possible to use it to notify editors of already-open discussions, as well as to close discussions. BilledMammal (talk) 10:53, 28 July 2026 (UTC)reply

This seems very useful, perhaps add the feature for starting and closing discussions for other things such as split proposals, merge proposals, etc? Fortek67 (talk) 12:47, 28 July 2026 (UTC)reply

Rename article

Could someone help me move the contents of Estrella, Goodyear to Estrella, Arizona. Every time I've ever tried something like this I've messed it up. Thank you for your help! Magnolia677 (talk) 14:36, 28 July 2026 (UTC)reply

I have moved it to Estrella, Goodyear, Arizona, to match the pattern of other neighborhood articles like Arbor Lodge, Portland, Oregon. It could also be merged into Goodyear, Arizona; the neighborhood may not be independently notable. – Jonesey95 (talk) 15:05, 28 July 2026 (UTC)reply
And then Ahecht moved it to Estrella, Arizona. Consistency is not Wikipedia's strongest suit. – Jonesey95 (talk) 15:06, 28 July 2026 (UTC)reply
@Jonesey95 WP:USPLACE says to use "Placename, State" unless additional disambiguation is needed. There's only one Estrella in Arizona, so no additional disambiguation is needed. --Ahecht (TALK
PAGE) 15:09, 28 July 2026 (UTC)reply
Thank you both! Magnolia677 (talk) 15:27, 28 July 2026 (UTC)reply

Overzealous edit filter prevents linking to talk page archives

At Wikipedia:Archiving a source#Perma.cc there's a link to an RfC described as "recent" which isn't (2016). It's also been archived so the link is stale. I can't fix either problem because whenever I try, an edit filter blocks the edit "because it adds a link to archive.today or a related domain". But it doesn't! The section doesn't contain any such links. It does contain the string "archive.is" but that's in the title of the page with the RfC on it. The edit filter should not prevent us linking to any page on Wikipedia. Hairy Dude (talk) 18:47, 28 July 2026 (UTC)reply

Fixed the wording and the link to the talk archive, thanks for pointing that out. Someone else will need to see if the edit filter needs to/can be fixed. SarekOfVulcan (talk) 18:56, 28 July 2026 (UTC)reply
Pinging @Daniel Quinlan. --Ahecht (TALK
PAGE) 19:41, 28 July 2026 (UTC)reply
@SarekOfVulcan and Ahecht: I will update the filter to avoid this one. @Hairy Dude: Thanks for the report. If you ever run into similar issues with any filter in the future, please report the false positive to WP:EFFPR. Thanks! Daniel Quinlan (talk) 19:53, 28 July 2026 (UTC)reply
Thanks for the pointer. Hairy Dude (talk) 00:46, 29 July 2026 (UTC)reply

Broken bot spamming my talk page with the same message

See [17], [18], and [19]. Probably broken AI. Ricky the Dinosaur (talk) 05:18, 29 July 2026 (UTC)reply

This does appear to be inadvisably rapid tool use. That said, I would advice you to heed the advice of the message, even if it does link to an essay. CMD (talk) 05:41, 29 July 2026 (UTC)reply
Tracked in Phabricator
Task T66090

When you create an article, and another editor links that article at another page, you receive a "link notification" in your inbox, unless you opted out of it.

Now my question is, it is possible to receive these "link notifications" for any article, your perhaps interested in? Watching it doesn't seem to do anything. Fortek67 (talk) 11:09, 29 July 2026 (UTC)reply

No, not possible. Izno (talk) 15:42, 29 July 2026 (UTC)reply
But it has been requested before and I've just added a tracking link to the related Phabricator task (which I'm subscribed to). Graham87 (talk) 07:25, 30 July 2026 (UTC)reply
Well thanks for linking it. Although I doubt it ever gets added since this thread is 12 years old. I wonder if a user script for something like this would be difficult to develop? Fortek67 (talk) 12:47, 30 July 2026 (UTC)reply

Blocked username is sometimes struck, sometimes not

Recently Edittttor was blocked. I'm now seeing their username in strikeout style in many places, but not all. For example, in the attached screenshot from Template:Did you know nominations/Abdul El-Sayed, their username is not struck, but the corresponding talk link is. What's going on here? RoySmith (talk) 11:16, 29 July 2026 (UTC)reply

Looks like the redlink uses <a href="https://en.wikipedia.org/wiki/User:Edittttor?action=edit&redlink=1">, which isn't properly detected by the markblocked gadget. If I switch from Parsoid to the legacy parser, the link becomes <a href="/w/index.php?title=User:Edittttor&action=edit&redlink=1"> instead, which is detected properly. So either Parsoid needs to be changed to emit /w/index.php links for redlinks, or the gadget needs to be updated to remove URL parameters from /wiki/ links. --rchard2scout (talk) 11:41, 29 July 2026 (UTC)reply
I think this is a bug in the markblocked gadget. Since User:Edittttor is a red link, MediaWiki adds ?action=edit&redlink=1 to the URL. The gadget's regex doesn't stop at ?, so it ends up trying to parse Edittttor?action=edit&redlink=1 as the username, which fails, and the link gets skipped. The talk page link isn't a red link, so it doesn't get the extra query string and works fine. Changing const articleRegex = new RegExp( mw.config.get( 'wgArticlePath' ).replace( '$1', '' ) + '([^#]+)' ); to const articleRegex = new RegExp( mw.config.get( 'wgArticlePath' ).replace( '$1', '' ) + '([^#?]+)' ); should fix this. – DreamRimmer ■ 11:41, 29 July 2026 (UTC)reply
That can't be the whole story because the redlink is struck in the block log, and in edit histories, and in Wikipedia:Peer review/Abdul El-Sayed/archive1. RoySmith (talk) 11:49, 29 July 2026 (UTC)reply
@MSantos (WMF): could you take a look at this? Is this a parsoid issue? RoySmith (talk) 11:54, 29 July 2026 (UTC)reply
Red links starting with /w/index.php? are handled correctly, but links starting with /wiki/ are not. Wikipedia:Peer review/Abdul El-Sayed/archive1 renders links in the former format, which is why this happens. The change above should fix the issue for /wiki/ links. – DreamRimmer ■ 12:05, 29 July 2026 (UTC)reply
But why is parsoid producing different output for these two cases when the old parser did not? RoySmith-Mobile (talk) 17:00, 29 July 2026 (UTC)reply
@RoySmith It's not. Parsoid is enabled in the Template: namespace, which is why your first link doesn't work, but not in the Wikipedia: namespace, which is why your second link does (see Wikipedia:Village pump (technical)/Parsoid#Timeline). You can check at the bottom of the page: if it used Parsoid, it will say something like "This page was last edited on 29 July 2026, at 14:31. Page was rendered with Parsoid." --Ahecht (TALK
PAGE) 18:29, 29 July 2026 (UTC)reply
What??? Why are we running different parsers in different namespaces? RoySmith (talk) 18:31, 29 July 2026 (UTC)reply
Parsoid is being rolled out over a period of weeks or maybe months to namespaces on the English Wikipedia. It is causing a bit of confusion and difficulty in troubleshooting. In addition, some back-end processes like categorization are being handled by either the new parser or the legacy parser, causing some pages to work fine when viewed but still show up in a category that is not listed on the page, or similar weirdness. See this technical page for some information(?) about testing that the developers are doing to see if pages look different in Parsoid and the legacy parser. It appears that they are using this output to schedule the rollout to other namespaces, although it is unclear how. Diligent editors at VPT and other places have noticed and reported bugs in Parsoid, some of which have been fixed since it started being the default parser for some pages about a month ago. – Jonesey95 (talk) 19:51, 29 July 2026 (UTC)reply
Ugh. I knew it was being rolled out incrementally, but I wasn't paying attention to the details and assumed that meant wiki-by-wiki, not namespace-by-namespace. I guess there will be some pain for a while until this all stabilizes. Thanks for the explanation. RoySmith (talk) 20:07, 29 July 2026 (UTC)reply

Grey out Minor edit tick box for TAs

Tracked in Phabricator
Task T433628
Moved from Wikipedia:Village pump (proposals)

I have been editing as a TA for months, and using the Minor Edit tick box when it seemed appropriate. I have only recently realised that this setting is ignored for TAs. This is misleading, for people who are less likely to be familiar with editing Wikipedia. Could this box be greyed out for users for whom it will be ineffective? ~2026-42114-05 (talk) 04:09, 29 July 2026 (UTC)reply

I seem to be missing something, the "minor" interface selector doesn't normally appear for logged out users. Can you describe all the steps you are taking that lead to that element showing? — xaosflux Talk 13:33, 29 July 2026 (UTC)reply
Perhaps this is in one of the installed mobile apps? If so, which one? — xaosflux Talk 13:34, 29 July 2026 (UTC)reply
@~2026-42114-05: This post is the only edit by your current TA. If you make an edit where you see and tick minor edit then we may be able to tell how you made the edit. PrimeHunter (talk) 14:11, 29 July 2026 (UTC)reply
Check the related temporary accounts and you can see they all appear to be "Android app edit". Looking at the code, https://github.com/wikimedia/apps-android-wikipedia the minorEditCheckBox does not appear to have any conditional code to disable for TAs. A bug would need filling at https://phabricator.wikimedia.org KylieTastic (talk) 14:28, 29 July 2026 (UTC)reply
A previous issue was raise as T123876 but is was merged into another task T296952 and I assume got lost. KylieTastic (talk) 14:31, 29 July 2026 (UTC)reply

Birthday problem

Trying to get a decent interactive widget for the birthday problem article and had a thought: rather than just generating a bunch of random valid month-day combinations, wouldn't it be more fun to populate an experiment with real people? So fetching birthdays of random notable people. Is there any way this is doable in an article? I could prepopulate a list to randomly select from, but in addition to that being less convincing of randomness, a good-sized list is going to seriously bloat the size of the page. I know there are strict limitations on what can be fetched within an article, and something like scanning for random biographies and then parsing the dates in articles is not realistic, but I feel like I've seen wikidata templates/tools that might of use? Looking for help brainstorming wikidata possibilities, basically. — Rhododendrites talk \\ 15:00, 29 July 2026 (UTC)reply

Wow, I didn't know you could do stuff like that.
Maybe some combination of {{Random_page_in_category}} and {{Wikidata}}? I'm not sure how you'd check that they have birthday years listed, though. (Does your calculator gadget allow loops?) I'm also not sure what the performance/server load cost of that is. But at this point, if you come back in a couple hours I might have rabbit-holed myself into finding an answer for you.... LittlePuppers (talk) 15:48, 29 July 2026 (UTC)reply
Never mind, Random_page_in_category just provides a link... the wikidata template should be useful though. LittlePuppers (talk) 15:58, 29 July 2026 (UTC)reply
Yeah, probably best to just have a list of a few hundred popular people—that'll also make it more likely that people recognize them. LittlePuppers (talk) 16:44, 29 July 2026 (UTC)reply
I'm not really seeing anything in the wikibase API that would let you do this. :( Morwen (talk) 16:06, 29 July 2026 (UTC)reply
I think in terms of performance, it would be much better to work with a pre-calculated list (it could be stored on-wiki (with maybe a set of them that is rotated through) and be updated from time to time, perhaps using a bot). To find birthdays of notable people, I suggest using the day of the year articles (for example, July 1). isaacl (talk) 16:35, 29 July 2026 (UTC)reply
To be honest it would probably be better to curate the list anyway. You don't really want war criminals or serial killers appearing there do you? Morwen (talk) 16:39, 29 July 2026 (UTC)reply
Ha. It's a good point. I was thinking about all the controversy we saw years ago over the Monty Hall problem. That's why there's something like a "transparency" feature built into that widget -- I'm assuming that at least some of the people who use it might think it's rigged. So I'm carrying that mindset over to the birthday problem, and figure that a skeptical reader would be skeptical about a prepopulated list. Might be overthinking it, though. Maybe the way around that is to do an academic move of deferring to an existing list or category. I'll look around for a candidate. — Rhododendrites talk \\ 16:49, 29 July 2026 (UTC)reply
The names of the people aren't what generate skepticism, though: it's the randomness of selecting the birthdays. Since Wikipedia biographies are already a selected set from the general population, I don't think trying to make a random selection out of Wikipedia biographies will help much with that concern. I don't think there's any good way around the assumption that birthdays are randomly distributed. It may be instructive to provide a way to bias the selection, to show how the result is dependent on the assumption. For example, you could simulate the likelihood of duplication during the monthly birthday celebration for a large group of acquaintances. isaacl (talk) 17:15, 29 July 2026 (UTC)reply
I'm just talking about numbers. Seems easy to imagine a skeptical person not buying a random selection of 30 people from a curated list of 40, but assuaged by a random selection of 30 people from all million+ biographies on the project. Getting into biases in the widget is a fun idea, but it's already getting quite big as-is. :) — Rhododendrites talk \\ 17:26, 29 July 2026 (UTC)reply
And another thought - 99% of our biographies are people who might as well just have randomly generated names for all the name recognition they have. Try doing Special:RandomInCategory/Living people 20 times in a row some time and see how long many of them you've heard of. (I just did this myself and got one, although curiously that one was someone I've met in real life so go figure.) Morwen (talk) 17:32, 29 July 2026 (UTC)reply
Yep, I got 0 for 20. My methodology would probably be take the top few hundred biographies (probably doesn't have to be living people) by page views, sort out those without listed birthdays or with war crimes, and go from there. That's probably much more interesting for the general audience, even if it doesn't assuage the skeptics. LittlePuppers (talk) 17:49, 29 July 2026 (UTC)reply
I realized I was thinking about the problem from the other direction – finding representative names for the randomly selected birthdays – while you are thinking of gathering a set of names and then choosing randomly from them. I agree that it would be better to find lists of names for some suitably large categories where there shouldn't be any unnatural bias.(*) (There could be an option to choose between the different categories.) I still think not querying the database dynamically for names or birth dates is better for performance.
(*) For example, as I recall I've read that the birth dates for NHL hockey players are biased by the way players are sorted into age groups during their youth, as the oldest players within an age group generally perform better against the others in the same group. isaacl (talk) 17:44, 29 July 2026 (UTC)reply
If you only need to select a relatively small number of names from a larger list, and you are ok with the selection only changing each time the page is parsed, you can put the list in lua. I did something similar once with a template on commons to show a random selection of quality images. Only the items selected go into the page, but its a different selection every time the page gets parsed. Bawolff (talk) 18:28, 29 July 2026 (UTC)reply
I made a demo of what I mean at Module:Sandbox/bawolff/Birthday. It gives results like: Ray Kroc was born on Oct 5. Jack Nicklaus was born on Jan 21. Mark Spitz was born on Feb 10. Bawolff (talk) 21:01, 29 July 2026 (UTC)reply
Try Category:2025 deaths (11,884). There are plenty to pick from and their birth dates should be truly random. --Redrose64 🌹 (talk) 18:45, 29 July 2026 (UTC)reply

User:Mathbot needs a new owner

Crossposting at Wikipedia:Bots/Noticeboard#User:Mathbot needs a new owner for best coverage. User:Oleg Alexandrov has asked in a recent discussion:

Are there any poeple willing to maintain this bot? Last time I worked with Dreamrimmer who is listed as co-owner at https://toolsadmin.wikimedia.org/tools/id/mathbot. If he is around, or somebody else is willing to help adopt the bot, that would be great. It has been too long and I don't visit much or remember how things work anymore.

Note that Mathbot is a fairly important bot, as it cues up the new pages for AfD and maintains other aspects of AfD. BD2412 T 15:09, 29 July 2026 (UTC)reply

Mathbot co-maintainer here. I'm around if you need anything. – DreamRimmer ■ 15:37, 29 July 2026 (UTC)reply
@DreamRimmer: Mathbot's instructions currently say for questions to be asked on Oleg's talk page. Would you be okay with that instruction being changed to your talk page? BD2412 T 19:08, 29 July 2026 (UTC)reply

VE made default on mobile web following RfC

Hi all! To implement the result of a recent CENT-listed RfC, we have made VisualEditor the default for new editors on mobile web. Further information about our current and planned work on VE can be found in the discussion there. Please let us know if you spot any issues, and thanks as always for your collaboration! Cheers, Sdkb‑WMF talk 15:45, 29 July 2026 (UTC)reply

Sortable table not sorting for one column

At List of Irish counties by population, the table's "Change per year (%)" column doesn't sort some values correctly. Specifically those with one decimal place (most values have two decimal places). However when I looked at another similar table, List of Japanese prefectures by population#Prefectures of Japan ranked by population as of October 1, 2020, the "% Change" column seems to work fine for its mix of one and two decimal places. The main difference I can see between the two tables is the Irish table's use of Template:increaseNeutral on values in those columns, which the Japan table doesn't use. Thanks for any ideas, Declangi (talk) 00:04, 30 July 2026 (UTC)reply

The software was guessing the data sort type was string because of the templates you identified. I've both forced it to sort by number and removed the templates. You can add separate columns or forgo them. Izno (talk) 03:04, 30 July 2026 (UTC)reply
That is excellent work by you, many thanks and all looks well there now. Given that all the values in those columns are positive, not much need for embellishment. Declangi (talk) 04:08, 30 July 2026 (UTC)reply
Decimals would sort correctly with string sort. This was something different. The table used {{increaseNeutral}} which adds an image with alt text. Table sorting appears to have issues if images have alt text. The third column below has the former combination in the article. Maybe it for some reason sorts the part after the decimal point as a number by itself where 8 < 75.
Speculation without looking at the sort code: alt text is included in the text to sort (this appears consistent with results if the alt texts are different). Without a data-sort-type it treats the cell as a string but sorts digit substrings by number if the text before the number is identical. The decimal point is assumed to be a sentence-ending period so the number right after the "period" is treated by itself.
No alt text
No data-sort-type
Sorts correctly 		No alt text
data-sort-type=number
Sorts correctly 		alt text
No data-sort-type
Sorts incorrectly 		alt text
data-sort-type=number
Does not sort at all
0.75 0.75 Neutral increase 0.75 Neutral increase 0.75
0.95 0.95 Neutral increase 0.95 Neutral increase 0.95
0.8 0.8 Neutral increase 0.8 Neutral increase 0.8
PrimeHunter (talk) 11:23, 30 July 2026 (UTC)reply
I found phab:T42044: "tablesorter should sort images with alt text". So it's deliberate that alt text is included in sorting. Most users don't see or hear alt text and I guess almost no editors will think of alt text when making sortable tables so this seems unfortunate. In the present case it managed to break sorting even though all the alt texts were identical. PrimeHunter (talk) 11:41, 30 July 2026 (UTC)reply
Whether editors not using assistive technology consider the image probably depends on whether they consider the image as being semantic or extra/decorative. For the {{IncreaseNeutral}}/{{DecreaseNeutral}} style images, for example, it might depend on whether the image is indicating "this absolute value increased/decreased" versus "the value is an amount-changed and the image replaces the + or −". Anomie⚔ 15:16, 30 July 2026 (UTC)reply
If an image is the only content in a cell then it may be helpful to include it in sorting, for example causing identical icons to be grouped although the order of the groups may often appear arbitrary to a viewer. But if a cell both has an image and text then I think sorting should ignore the image, or maybe use it as a tiebreaker if cells otherwise have identical text. PrimeHunter (talk) 11:57, 30 July 2026 (UTC)reply

Display SVG not display

Tracked in Phabricator
Task T214738

I tried a upload a File:Panther Creek High School (Frisco, Texas) logo.svg but nothing displayed but it works with my Brave browser. You can download logo Panther Creek High School Frisco Texas. Ranch9613 💬 03:41, 30 July 2026 (UTC)reply

@Ranch9613: It looks like this SVG is failing to render, possibly due to the use of matrix() in the gradientTransform attributes. This could be due to this librsvg bug. Although, isn't a fair use image meant to be low-resolution? i.e. a lower resolution raster version of this logo might be required anyway, and switching to that will resolve the SVG problem. SWilson (WMF) (talk) 04:19, 30 July 2026 (UTC)reply
We provide logos pretty wide latitude from a non-free use perspective. Izno (talk) 14:06, 30 July 2026 (UTC)reply
I hope it's not time for another argument over non-free SVG "resolution" versus "level of detail". Anomie⚔ 15:19, 30 July 2026 (UTC)reply
I was just going on the text given for {{Non-free use rationale 2}}, about a low resolution image of an organization's logo in the article. But of course the image used in the article is 250px, so it is low-res. Not re-opening any argument! :-) SWilson (WMF) (talk) 05:52, 31 July 2026 (UTC)reply

Script validation

Two scripts have been advertised at ITN recently:

The source code for these warns that

Code that you insert on this page could contain malicious content capable of compromising your account. ... User scripts are not centrally supported and may malfunction or become inoperable due to software changes. ... If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump.

This is the village pump page. So is this code safe? What testing and validation has been done? What's to stop anyone changing the scripts at any time? Note the recent security incident which indicates that such scripts are a serious risk and vulnerability.

Andrew🐉(talk) 13:52, 30 July 2026 (UTC)reply

This message displays for all scripts that you might use. It is good for you to ask these questions. In some order:
Someone needs to assess whether the scripts are safe. This is not a usual activity, and is in the domain of things other volunteers might do. Random volunteers at VPT do not usually do so, but I suppose you can ask here.
It usually takes a deliberately hostile developer to make a script that will be malicious at the end of the day, and their efforts are usually (usually) easy to identify. From this perspective, the only testing and validation that actually needs to be done is usually on the part of the script developers in the course of reasonable script development.
Scripts in a specific user space can be modified only by WP:INTADMINs and the user named. Scripts in MediaWiki space can be modified only by interface admins. But otherwise, yes, they can be modified at any future date. (There are ways to avoid taking updates automatically if you review a good version and decide to use that version, but you will miss good faith updates such as bug fixes and feature additions without deliberately taking time to review the scripts routinely.) Izno (talk) 14:14, 30 July 2026 (UTC)reply

Rater dialog is unresponsive

Is anyone else experiencing an unresponsive Rater dialog? I've reported the issue, but I'd like to see if I'm not alone here. the Stefen 𝕋ower 21:40, 30 July 2026 (UTC)reply

You already raised this at User talk:Evad37/rater.js#Rater dialog is unresponsive. --Redrose64 🌹 (talk) 22:31, 30 July 2026 (UTC)reply
Indeed. I posted here additionally on purpose per the second clause of my last sentence, as this page has a lot more eyes. the Stefen 𝕋ower 00:52, 31 July 2026 (UTC)reply

Talk page title blank character space

I am seeing a blank space between 'Talk:' and the article name on all talk pages, so Talk:Supermarine Spitfire appears as Talk: Supermarine Spitfire. I noticed it because I create many archive talk pages and went to create one just now, I always check the new title thoroughly for spelling and spacing mistakes before hitting enter,

It might be related to the recent wiki-wide appearance changes of section headers on talk pages, I have not discovered where that originated from or if it is just a skin change. I won't create any more archive pages until this is resolved, it may be ok as is but I'd rather not have to delete pages and recreate them. Nimbus (Cumulus nimbus floats by) 11:17, 31 July 2026 (UTC)reply

Nimbus227, it's just a skin change. It was done a while ago to better delineate the namespace in the page title (you'll note that this page title also has a space after Wikipedia:). — Qwerfjkltalk 11:34, 31 July 2026 (UTC)reply
Ok, thanks. Notices of these changes don't seem to filter through to projects or users, perhaps I missed it. Nimbus (Cumulus nimbus floats by) 12:15, 31 July 2026 (UTC)reply
It’s a change introduced by discussion tools which only applies to talk pages (and pages in other namespaces used as talk pages), see Wikipedia:Village pump (technical)/Archive 231#Discussion Tools usability improvements becoming default. Johannnes89 (talk) 12:35, 31 July 2026 (UTC)reply
Thanks, that's exactly what I needed. I have reverted the change through my preferences. Nimbus (Cumulus nimbus floats by) 13:44, 31 July 2026 (UTC)reply
@Nimbus227: It's impossible to create a page with a space after the namespace colon in the actual page name so just create pages as usual whether or not you change preferences. The HTML says <span class="mw-page-title-separator">:</span>, and the site CSS inserts a space with this rule:
.ext-discussiontools-visualenhancements-enabled .mw-page-title-separator::after {
  content: ' ';
}
If you only want to remove the space then this in your CSS will do it:
.mw-page-title-separator::after {
  content: '' !important;
}
Some people may complain about using !important but it's OK when it's in your own CSS and not imposed on others. I used it to ensure it works everywhere mw-page-title-separator is used which may change in the future. PrimeHunter (talk) 13:50, 31 July 2026 (UTC)reply
I have managed to do many impossible things in my time on Wikipedia!! I create the archive pages by copying the parent talk page title and pasting it into the search box and adding /Archive 1 then hitting 'go' which produces the red link for creation. I tried this earlier and the space is automatically removed on pasting it in to the search box. It's academic now as I've edited my preferences to return to the previous appearance. I appreciate functionality changes but I am a Luddite and will continue to view the talk page history for the date of its latest comments. Nimbus (Cumulus nimbus floats by) 14:07, 31 July 2026 (UTC)reply
@Nimbus227 The space is actually never copied in the first place since it's a CSS feature and not part of the text. --Ahecht (TALK
PAGE) 14:46, 31 July 2026 (UTC)reply
I was not to know that, that's why I asked for advice here. This kind of problem could be avoided by better publicity of changes to default settings/behavior IMHO, a single post to wikiproject talk pages would be enough, most long term editors have those on their watchlists. Nimbus (Cumulus nimbus floats by) 15:11, 31 July 2026 (UTC)reply
@Nimbus227 The announcement was posted here, which is the proper venue for technical changes. Wikiproject talk pages are for discussing the topic covered by that wikiproject, not larger wikipedia administration. The rollout of Discussion Tools was also discussed in Tech News last November for people that subscribe to it, although I think it should've included an item in a more recent issue for the English Wikipedia rollout. --Ahecht (TALK
PAGE) 16:41, 31 July 2026 (UTC)reply
I agree it doesn't belong on various pages just to spread awareness, but there are always complaints when something changes. I have long considered to start a page about how to revert interface changes (including with personal CSS and scripts), or say if it's not possible. Would there be interest in that? It would include all types of causes, also users who changed preferences wihout knowing the consequences, accidentally switched between desktop and mobile, need to update a browser or uninstall a bad extension, and so on. There would also be general tips like trying a cache bypass, or trying safemode, logout, another wiki or another browser to narrow down possible causes. PrimeHunter (talk) 16:55, 31 July 2026 (UTC)reply
I don't see a particular issue with a one stop shop. Most of this information does already exist, just without a central pointer. Izno (talk) 00:55, 1 August 2026 (UTC)reply
Help:User style is one place with a number of customizations, but it really could use reworking by separating different style options to simplify finding and applying specific solutions.
(I have an idea about making a script that would allow you to check an option in one column, and the corresponding CSS rules would be populated in a box on the side that you could copy and paste into your common.css file. (In theory it could automatically update your common.css file (or common.js file if the tool were extended to handle Javscript customizations), but baby steps first.) But it's just at the conceptual stage, so I wouldn't want anyone to hold off on reworking Help:User style or creating any new help page.) isaacl (talk) 03:22, 1 August 2026 (UTC)reply

I would think that the percentage of editors with wiki technical sub-pages on their watchlist is very low. A user communication option could be use of watchlist banners that can be dismissed after being read, this is used for RfA nominations and for new editions of Signpost. Nimbus (Cumulus nimbus floats by) 17:43, 31 July 2026 (UTC)reply

There are too many changes that run the gamut from stylistic (this one) to potentially breaking (the rollout of Parsoid) to communicate using the watchlist et al. If you do not want to watch this page where the tech news carrying the notification was published, you can subscribe directly a page of your choice at meta:Global message delivery/Targets/Tech ambassadors. Izno (talk) 00:54, 1 August 2026 (UTC)reply
@Nimbus227 and Qwerfjkl: It's not a skin change. It's a side-effect of Discussion Tools: (i) if you disable that feature, the apparent space vanishes regardless of your skin; (ii) if it's enabled, the space is seen on all skins, even unmaintained ones like Cologne Blue and Modern. --Redrose64 🌹 (talk) 10:00, 1 August 2026 (UTC)reply
Redrose64, yes, I was mistaken. I've been opted into the beta feature for a while, and I vaguely remembered the VPT post about it. — Qwerfjkltalk 12:20, 1 August 2026 (UTC)reply

Relief maps

Is this just some screw up at my end (I did get an update this morning and Windows 11 is somewhat eccentric)? At pages like Southampton Island I'm not getting a relief map. I didn't notice this yesterday and it seems consistent throughout browsers (Chrome, Firefox, Edge). Doing this solves the problem. CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 16:51, 31 July 2026 (UTC)reply

The same problem exists on a second computer just updated. CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 16:53, 31 July 2026 (UTC)reply
Probably Special:Diff/1364530773/1366999373. @Hike395? Ponor (talk) 16:58, 31 July 2026 (UTC)reply
I've asked Hike395 to respond here. CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 17:03, 31 July 2026 (UTC)reply
Will investigate — hike395 (talk) 00:42, 1 August 2026 (UTC)reply
I wrote new code in Module:Location map to fix a problem introduced by the pushpin_map cleanup by Zackmann08. My new code did not correctly handle the case when image1 was missing. It was a simple code fix, now live. Fixed — hike395 (talk) 01:25, 1 August 2026 (UTC)reply
Thanks. CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 15:07, 1 August 2026 (UTC)reply

What is breaking the infobox at MetLife Stadium?

See Special:Diff/1367094907 for the diff in where I fixed the issue. When this is not fixed, above the stadium image, it displays "[[File:|250px|MetLife Stadium is located in New York City|class=notpageimage noviewer]]" and the label "MetLife Stadium" in a white background in the center of the broken text. And this is probably because of the | pushpin_map = parameter, which is probably breaking the infobox. What else is causing this, some template? — (In solidarity 🫡) SimpleObjects-9ei 🏖️/☀️/🥵 (see talk) 00:06, 1 August 2026 (UTC)reply

Something is not configured right. I couldn't say what. I've backed it up to New Jersey because that is clearly not broken. Izno (talk) 00:32, 1 August 2026 (UTC)reply
Looks like it's Special:Diff/1364530773/1366999373, same as #Relief maps above. Anomie⚔ 01:14, 1 August 2026 (UTC)reply
Fixed see above. — hike395 (talk) 01:25, 1 August 2026 (UTC)reply

Is it possible to mark my user essay as archived?

I noticed an editor randomly started editing my user essay User:guninvalid/Naming conventions of non-democratic elections despite the fact that the essay has been dormant since November and has no consensus. I'd like to mark this essay as archived. Is that possible? Just using Template:Archive doesn't feel quite right, but are there better optionsm guninvalid (talk) 17:07, 31 July 2026 (UTC)reply

There are {{Historical}} and {{Failed proposal}}. Nardog (talk) 17:59, 31 July 2026 (UTC)reply

Television series vs web series

Hello. I'd like to inquire about consistency regarding the spelling of television series vs. web series. I've noticed some pages use the term "television series," but in the cast's filmography, the series is listed under "web series." For example, the page Knock-Off (TV series) lists the television series, but the page Jo Bo-ah lists the television series under the web series section. So, which term should I use? Television series or web series? WillsonEP09 (talk) 04:13, 1 August 2026 (UTC)reply

@WillsonEP09 This doesn't seem to be a technology question ? —TheDJ (talk • contribs) 13:07, 1 August 2026 (UTC)reply
@WillsonEP09: It could be discussed at Wikipedia talk:WikiProject Television but try to be more precise. I don't know what you mean by "lists" in "Knock-Off (TV series) lists the television series". If you mean "TV series" in the article name then it doesn't say "television" and it isn't a list. "Television series" vs. "web series" is not about spelling but wording. PrimeHunter (talk) 16:27, 1 August 2026 (UTC)reply
To expand on TheDJ's comment, this page is for discussion on using the MediaWiki software underpinning Wikipedia, and not for questions regarding page content. Content-related questions that cover a broad category of articles but within a specific area of interest can be posed at the talk page of an appropriate active WikiProject, as mentioned by PrimeHunter. isaacl (talk) 16:36, 1 August 2026 (UTC)reply

Is there a way to make topics templates on portal pages display with outlines?

For example if you scroll down to the "Topics" section on Portal:European Union#Topics then it isn't displayed the same as on Template:European Union topics. I find the latter more readable but I guess others might not prefer for it to display like that on portal pages.

I was able to go into devtools, select a tr, th, or td element, and then disable the following CSS to make the table display normally. 

.mw-parser-output .PlainNavboxes .navbox, .mw-parser-output .PlainNavboxes .navbox th, .mw-parser-output .PlainNavboxes .navbox tr, .mw-parser-output .PlainNavboxes .navbox td, .mw-parser-output .PlainNavboxes .navbox-title, .mw-parser-output .PlainNavboxes .navbox-subgroup, .mw-parser-output .PlainNavboxes .navbox tr+tr>.navbox-abovebelow, .mw-parser-output .PlainNavboxes .navbox tr+tr>.navbox-group, .mw-parser-output .PlainNavboxes .navbox tr+tr>.navbox-image, .mw-parser-output .PlainNavboxes .navbox tr+tr>.navbox-list, .mw-parser-output .PlainNavboxes .navbox-even, .mw-parser-output .PlainNavboxes .navbox-odd, .mw-parser-output .PlainNavboxes .navbox span, .mw-parser-output .PlainNavboxes .navbox abbr {
	background-color: transparent!important;
	color: inherit!important;
	border-color: transparent!important;
	box-shadow: none!important;
}

But the only applies until the page is reloaded. I have the Stylus browser extension which I can use to apply custom CSS to websites which might help, like I could at least get some basic borders with it, but I wonder if there's a way to make these tables just display normally. BoardHum (talk) 06:36, 1 August 2026 (UTC)reply

It's due to {{Plain navboxes}} which uses Template:Plain navboxes/styles.css. Those !important annotations shouldn't be necessary; and because they've been used, it means that any personal CSS must itself also use !important to have any effect at all. --Redrose64 🌹 (talk) 09:33, 1 August 2026 (UTC)reply
Important is required to ensure that inline CSS is overridden, which is the clear point of the template. Izno (talk) 15:52, 1 August 2026 (UTC)reply

Shortcuts with the string 'RFC' at the beginning generate corrupted anchors

 Courtesy link: phab:T433782

Shortcut boxes made with template {{shortcut}} generate their own anchor via <span id="shortcut"> that can be conveniently linked to from a redirect to the embedded anchor when a section name is not available. I ran into a problem when trying to add a redirect to shortcut {{sh|WP:RFCSIGN}} which I recently added to WP:Rfc. The initial version of the redirect targeted Wikipedia:Requests for comment#WP:RFCSIGN, but that did not work, and I wanted to know why.

In running it down, I found something bizarre: the span id generated for the embedded anchor appears to work fine in all cases, except when the pagename of the shortcut starts with "RFC", such as "RFCSIGN". In these cases, the pagename portion of the span id is transformed, with the 'R' replaced with the Html entity &#82; instead of the 'R'. That this is the case, can be seen in the modified redirect, which is now working using the bizarre id, although the target looks just awful and inscrutable; see Wikipedia:RFCSIGNWikipedia:RFCSIGN.

I ran a bunch of tests in order to narrow down when this is happening, and this is as far as I got:

As near as I can make out, the condition that generates an entity instead of 'R' in the id is whenever the shortcut pagename begins with the upper-case string "RFC", and is longer than three characters.

The string 'RFC' does not appear in Module:Shortcut. Either there is some voodoo parsing going on, or perhaps there is some strange bit of legacy code left over for some reason I cannot guess. Any ideas? Happy to port this to Phab, but wanted to make sure there's not something I'm missing. Mathglot (talk) 19:25, 1 August 2026 (UTC)reply

This is probably the cause: https://github.com/wikimedia/mediawiki/blob/5c92a51f28990523d509c6171ac658fa82096859/includes/Parser/Sanitizer.php#L914
Solomon Ucko (talk) 20:10, 1 August 2026 (UTC)reply
Yes, can confirm. I experimented with the RFC examples in the Lua sandbox first, and then went to the MediaWiki Git repository and searched with git grep "'RFC'". The sanitization has to do with so called magic links (see function magicLinkCallback in Parser.php). The PMID links are affected the same way, which I checked in my Lua sandbox: Special:Permalink/1367221459#L-20--L-42. —⁠andrybak (talk) 20:19, 1 August 2026 (UTC)reply
Since WP:RFCSIGN works, as do WP:RFCST, WP:RFCBEFORE, WP:RFCCAT, WP:RFCEND, and others, what's the problem? --Redrose64 🌹 (talk) 20:27, 1 August 2026 (UTC)reply
The problem is that WP:RFCSIGNWP:RFCSIGN has to be an ugly and unintuitive redirect to Wikipedia:Requests for comment#WP:&#82;FCSIGN (note the HTML character entity for the first letter R in "RFCSIGN"), while the other examples get to link to regular section headers: WP:RFCSTWP:RFCST links to Wikipedia:Requests for comment#Creating an RfC, WP:RFCBEFOREWP:RFCBEFORE to Wikipedia:Requests for comment#Before starting the process, etc. —⁠andrybak (talk) 21:12, 1 August 2026 (UTC)reply
The problem is that none of the older shortcuts you linked meet the criteria of this discussion, which is about a redirect targeting the built-in embedded anchor created by the shortcut itself. All four redirects you mention are section links using nearby section names as the destination, so they don't need to use the built-in anchor, whereas RFCSIGN needs to, as it is not near the section header, but way down in bullet six, not even in the same screenview (on my 15-inch laptop). Like all shortcuts do, your four shortcuts generate their own embedded anchor, and had you linked them, you would find that they all fail as well: Wikipedia:Requests for comment#WP:RFCST, Wikipedia:Requests for comment#WP:RFCBEFORE, and so on; whereas for every policy and guideline except this one, they do work. (edit conflict) Mathglot (talk) 21:19, 1 August 2026 (UTC)reply
Andrybak, interesting; presumably at line 1734 of Parser.php. I wonder if either that routine or the Sanitizer linked by Solomon is being too aggressive in its 'sanitization'. The page at mw:Help:Magic links lists the intent for a magic link like this:
  • RFC 1234 → RFC 1234
which implies, without quite stating, that the blank is required for the magic link to be created, in which case something like RFCSIGN would be left alone, but the tests show that that is not the case. Is a possible solution here to alter the code so as to require the blank for the magic link? That would leave room for links like RFCSIGN to be created without interference.
Alternatively, I understand that code changes may be expensive, and I am willing to live with the situation as is (although I wish it were better documented; I'll probably update Template:Shortcut/doc with a note), but with one caveat. I am somewhat worried that the currently working, but admittedly very bizarre-looking redirect at Wikipedia:RFCSIGNWikipedia:RFCSIGN will attract well-meaning editors to alter it. In order to prevent that, I propose to keep the existing Wikipedia:RFCSIGN § Notes section at the redirect, and add a brief explanation there about what is going on, and retain the link to this discussion.
In the past, I have occasionally added a ==Notes== section to a redirect to explain something unusual about the redirect, but I have found that such Notes are often removed by other editors, and I usually give up trying to keep them rather than dispute it. However, removing such a note would be very undesirable in this case, as it would then open up the redirect even more to unwanted alteration. Perhaps I could create a short, mbox-based informational message template, with instructions that it could be appended to the end of redirect pages involving RFC-, PMID-, or ISBN-like shortcut destinations. If that doesn't work, we might have to request page protection if it's still a problem. However, all of this is predicated on the assumption that changing the code is hard; and if it isn't, or if it could be piggy-backed on whatever the next change in that area is, maybe that would be a cleaner solution. (edit conflict) Mathglot (talk) 21:03, 1 August 2026 (UTC)reply
In addition to checking for the required space after "ISBN", "PMID", and "RFC" in the sanitization code, Sanitizer.php could also read the configuration parameter $wgEnableMagicLinks, and skip the unnecessary sanitization altogether, depending on which kinds of magic links are disabled. —⁠andrybak (talk) 21:17, 1 August 2026 (UTC)reply
Andrybak, that sounds ideal. Who/what group is most informed about the status of these magic links and whether we need sanitization here? It sounds like the proximate cause(s) has(have) now been identified; I wonder if we are at the point where this can be condensed into a Phab ticket describing the essentials, and linking this discusion as background? Or should we wait for more input first? I'm happy to open a ticket, but it's clear to me that you have a much better understanding of what is going on as well as of the relevant software, and would probably write a better report than I would, so by all means feel free to start one; just lmk if you'd rather I do so. Thanks, Mathglot (talk) 21:34, 1 August 2026 (UTC)reply
I found the box banner at the top of Help:Magic links confusing; although the page is marked inactive, the box reads: Magic links were removed from the MediaWiki code in March 2021...; so, were they or weren't they? And if they were, then no reason to sanitize, iiuc, or am I confused? Related: phab:T145604. Mathglot (talk) 21:53, 1 August 2026 (UTC)reply
I think that the enwiki help page is just a bit misleading. They were disabled on enwiki in 2021 (phab:T275951), but they are still very much in the source code of MediaWiki itself. The wiki mediawiki.org has them enabled, as can be seen at mw:Help:Magic links. —⁠andrybak (talk) 22:26, 1 August 2026 (UTC)reply
You give me too much credit, I just grepped the source code for clues. I can read PHP code just enough, but the only teeny-tiny amount of experience that I have with it was over a decade ago.
Created phab:T433782 "Sanitization of magic links in attributes should be disabled if magic links are disabled". —⁠andrybak (talk) 22:26, 1 August 2026 (UTC)reply
Very, very nice; much more on point than I could have managed. Much appreciated. Mathglot (talk) 22:59, 1 August 2026 (UTC)reply
Special:ExpandTemplates shows that {{sh|WP:RFCSIGN}} produces wikitext (not HTML but merely wikitext) with <span id="WP:&amp;#82;FCSIGN"></span>. So the encoding is made in Module:Shortcut (by a called function) and not when the wikitext is parsed to generate HTML. There is a simple solution for known cases: Manually write <span id="WP:RFCSIGN"></span> in addition to calling {{sh}}.[20] The "R" will not be encoded. {{anchor|WP:RFCSIGN}} also works. It uses a module but not the same as {{sh|WP:RFCSIGN}}. PrimeHunter (talk) 23:27, 1 August 2026 (UTC)reply

Proposals

Proposal to limit In The News Ongoing items to 45 days

Should items in ITN Ongoing automatically roll off after 45 days? 03:25, 24 June 2026 (UTC)

Note: The RfC tag on this discussion has been removed twice, with the editors suggesting that this be treated as a WP:RFCBEFORE. For that reason I'll use this discussion to guide the opening of a new RfC, when discussion on this dies down. BilledMammal (talk) 01:30, 29 June 2026 (UTC)reply

Survey (ITN 45 days)

  • Support. We now have ten items in ITN ongoing. This is ridiculous, and a consequence of this has been that we now only have space for three items in ITN itself. It also has stopped being useful; a reader going to Russo-Ukrainian war (2022–present) will struggle to find recent news about the war, such as the attacks on Saint Petersburg and Moscow. If there are sufficiently notable events related to the conflict - such as the Kharkiv offensive, the sinking of the Moskva, or the fall of Pokrovosk - then we can create an ITN entry, and direct readers to the relevant article rather than one that takes a longer-term view.
This also won't cause ITN to be overloaded; even with only three articles listed the oldest is almost two weeks old, so having a few extra stories on topics currently covered under ITN ongoing won't be disruptive. In addition, the 45 day period will still allow us to include events like the Olympics and the World Cup for the full length of the event.
As a second choice abolish ITN Ongoing entirely, because something needs to be done. BilledMammal (talk) 03:25, 24 June 2026 (UTC) Edited per Natg 19 BilledMammal (talk) 04:58, 24 June 2026 (UTC)reply
  • Support in general, or at least that a review at ITN should be held to make sure the item is still being updated properly with ongoing significant news coverage (and not just gnoming type edits). Eg: to me it makes no sense yet to remove the Ukraine/Russian conflict, that still dominates the news, but every 45 days, or maybe 60, it should be put for an ITN review. That might help identify that there's a new timeline page, or a better target, or something along those lines. But I think we also need a better way to judge an ongoing item, like the Sudanese civil war is getting nowhere close to the attention of other ongoings, and the timeline is not updated since the 10th, so this is a prime candidate to go (which I will nominate immediately after this). We don't keep something in ongoing just because the event in ther real world is ongoing, there has to be a good volume of sourcing to keep it there and the article has to show sufficient updates. Masem (t) 04:27, 24 June 2026 (UTC)reply
  • Support in principle, as I agree that there are ongoing articles that are on ITN too long, so there should be some sort of review process. However, the conclusions being drawn are incorrect. ITN has always had between 3-5 items blurbed, and the length of the ongoing section is not a major factor for this. (Earlier today, there were 4 blurbs, and a few days ago there were 5 blurbs.) This is typically a concern for admins to maintain the balance of the main page (WP:ITNBALANCE), and admins will add or remove blurbs based on this. Strong oppose the option to remove ongoing altogether as that is not at all necessary. Natg 19 (talk) 04:49, 24 June 2026 (UTC)reply
  • Oppose mandatory removal after X days. Remove articles that have been listed there on a case-by-case basis. —Kusma (talk) 04:59, 24 June 2026 (UTC)reply
  • Support in general. We definitely need this limit for the ongoing section as it's very unreasonable to have more ongoing items than blurbs (at the moment of writing this comment, there are seven ongoing items and three blurbs). I understand that there are multiple ongoing conflicts and events of wider significance whose timeline articles receive regular updates, which doesn't fully abide by WP:ONGOING, but it doesn't mean that prolonged ongoing events should be kept for good. The concept of 'news' is to inform people about notable current events, and a time frame of 45 days is reasonably long enough so that most people learn about an event. Furthermore, as ongoing events extend well over time, people get used to them and their coverage becomes routine (see WP:ROUTINE and WP:RUNOFTHEMILL). As for the time limit, the longest event that we post to ongoing with known duration is the FIFA World Cup, which lasts 38 days in the current format, so 45 days sounds like a reasonable time. --Kiril Simeonovski (talk) 07:34, 24 June 2026 (UTC)reply
  • Support – The way I see this: if no one has done a blurb proposal for a news story covered by an Ongoing item for 45 days, then that ongoing-feature is likely no longer serving the original purpose. In general I am in favor of shorter-term ongoings. We can't possibly be massively overhauling an article constantly for over a year, and the front-page should not be filled with static content. ~Maplestrip/Mable (chat) 08:04, 24 June 2026 (UTC)reply

    if no one has done a blurb proposal for a news story covered by an Ongoing item for 45 days, then that ongoing-feature is likely no longer serving the original purpose

    Blurb discussions are often shut down explicitly since items are in ongoing (see the blurb noms for the Iran war as an example). Most editors on ITN see ongoing (which is somewhat true, although like many thing there, this has been overdone) as a way to offput blurbs for items frequently in the news, so not having a blurb proposal is largely by design. — Knightoftheswords 00:53, 25 June 2026 (UTC)reply
  • Oppose. I don't like the idea of automatic removal, there should be some involvement in deciding(we don't automatically remove ITN items). There's no need to formally require a review, as any editor is free to start a proposal to remove an item("the Ukraine war has been up too long, let's remove it.") Ongoing can and has posted a significant event from an Ongoing event when called for. ITN, due to its name, is often misunderstood as a source of news, when its intention is to highlight articles about the news. I've long advocated that it should be easier to post something to ITN to increase movement(and that more articles posted is a good thing, not a bad thing). Ongoing isn't meant to require a "massive overhaul" every day, simply timely and regular updates. 331dot (talk) 08:13, 24 June 2026 (UTC)reply
    • we don't automatically remove ITN items This is absolutely wrong. Blurbs roll off because the room of the ITN box is limited, and RDs roll off because the limit per WP:ITNRD is six recent deaths. In both cases, however, we automatically remove the oldest news and recent deaths. The only missing puzzle with no restriction on such removal is the ongoing section. An alternative to time limit is maximum number of ongoing items (in a similar way as we have for RDs). Otherwise, the section will continue to grow without control and occupy the largest part of the ITN box. --Kiril Simeonovski (talk) 08:54, 24 June 2026 (UTC)reply
      They don't roll off based on an arbitrary time period, they roll off as new ones arrive. Would be open to a limit on the number of listings for ongoing(since we also limit ITN). 331dot (talk) 08:56, 24 June 2026 (UTC)reply
      Exactly, and that's why we need a rule that old ongoing items should be removed as new ones arrive. One way is to set a time limit, the other way is to set a maximum number. --Kiril Simeonovski (talk) 09:00, 24 June 2026 (UTC)reply
      I'd rather see a limit on the number of items rather than a time period(which would suggest items would leave and not necessarily be replaced)
      Has this discussion been brought to the attention of ITN? 331dot (talk) 09:03, 24 June 2026 (UTC)reply
      No (see the procedural note in the 'Discussion' section below). --Kiril Simeonovski (talk) 09:06, 24 June 2026 (UTC)reply
  • Oppose. The solution isn't removal after an arbitrary time not abolishment of ongoing as a whole, rather the solution is to impose a maximum number and/or to periodically have a automatic renewal discussion (with no prejudice to keeping an item in ongoing if it meets the usual requirements). Thryduulf (talk) 09:07, 24 June 2026 (UTC)reply
  • Support. It's not really in the news if it's been there for 45+ days. FaviFake (talk) 09:17, 24 June 2026 (UTC)reply
    Then that's an argument that can be used in a discussion to remove the item; we don't need an arbitrary time limit to do that.(which, as I said, would mean things would be removed but not necessarily replaced, as with ITN proper.) 331dot (talk) 09:27, 24 June 2026 (UTC)reply
    That's not always true, for example the Russia-Ukraine war is still ongoing after more than 45 days. Thryduulf (talk) 09:32, 24 June 2026 (UTC)reply
    Yes, and in that case it's no longer relevant enough to still be included here. It could be replaced with an article about a ore recent event in the war, for example. FaviFake (talk) 09:55, 24 June 2026 (UTC)reply
    It is certainly relevant enough, if being "in the news" is the measure. On the other hand, if you have the feeling that it should be replaced with something more recent, probably others feel that, too. Maybe that feeling is based on a view that would argue for calling the module "Breaking News" instead, which would be more aligned to the way you view what should be covered there. On the other hand, if a war is going on (or more precisely, being covered daily) then I think I would be shocked *not* to find it there. To some extent, it comes down to a core question of what this module is really for. Mathglot (talk) 10:29, 24 June 2026 (UTC)reply
    Ongoing is motivated by the Olympic summaries that we had used to post long time before it existed, and the key moment that led to its introduction was when the concept was expanded to the Arab Spring protests in order to prevent the ITN section from overflooding with blurbs on seemingly related events. Hence, its original purpose was to prevent multiple blurbs documenting a single event from being posted at the same time, not to keep major ongoing events on the main page simply because they're ongoing, and that's why WP:ONGOING requires regular updates to the article. As time went by, however, we significantly departed from the original purpose and began repeatedly invoking WP:IAR by posting timeline articles in brackets to justify that an item should still be kept (note that WP:ONGOING nowhere mentions that updates to sub-articles are sufficient). So, the answer to your core question is that 'ongoing' isn't as descriptive as it sounds. --Kiril Simeonovski (talk) 11:46, 24 June 2026 (UTC)reply
  • Oppose in current form. While ongoing section is getting longer, it is also a result of that there more high impact continuing events than before in the various parts of the world. Having an arbitrary cutoff does not reflect the ongoing nature of these events. Instead, we can focus on other aspects such as if the ongoing entry has timely updates, instead of editors getting prodded to update the item when the entry comes up for discussion because the lack of timely updates. What for have it on the main page if the readers are not being kept abreast with developments on a day to day basis? – robertsky (talk) 09:43, 24 June 2026 (UTC)reply
  • Oppose automatic time. I think a main purpose of ongoing is to save space and time, without it, all (most) the blurbs would be about ongoing matters. But I would support limiting the number, which would require more finely detailed editorial judgement. Alanscottwalker (talk) 13:07, 24 June 2026 (UTC)reply
  • Oppose , for example the Russia-Ukraine war still is ongoing and still has plenty of developments. That something is lasting for long is not a reason to exclude it from the ITN sections, especially since it's still newsworthy. Headbomb {t · c · p · b} 20:11, 24 June 2026 (UTC)reply
  • Oppose per Robertsky. Just since they're are more noteworthy events happening at a time doesn't mean that we need to start automatically dropping stories. Besides, a few of those entries could prolly just be removed via independent noms. — Knightoftheswords 00:51, 25 June 2026 (UTC)reply
  • Oppose per Robertsky's comment on there being "more high impact continuing events" and Headbomb's comment on newsworthiness. S5A-0043🚎(Talk) 03:59, 25 June 2026 (UTC)reply
  • Oppose per Headbomb. GenevieveDEon (talk) 10:11, 25 June 2026 (UTC)reply
  • Support in general. I think a time limit on Ongoing is preferable to a limit on the number of items. If an ongoing story is still worthy of being kept on ITN, it can be approved for another 45 day period by discussion. --Metropolitan90 (talk) 13:45, 25 June 2026 (UTC)reply
  • Support 45 days in most cases is ample, and requests for extensions can be considered case by case.--Wehwalt (talk) 15:03, 25 June 2026 (UTC)reply
  • Oppose as arbitrary. Why 45 days? Ongoing events don't just stop being relevant after a certain period of time has passed. I get the bar for an Ongoing item leaves open the possibility of way too many items in Ongoing, but the solution should be raising the bar for inclusion, not early removal. If not, I think we should consider a maximum number of Ongoing items, wherein one is removed when we're adding a new Ongoing item at a certain point. For example, if we have a limit of five, adding a new item after five would bump one item out, say, the article with the lowest volume of substantial edits in the past week. But a blanket limit isn't productive to the purpose of the section, IMO. DarkSide830 (talk) 02:01, 26 June 2026 (UTC)reply
  • Oppose. Is the current process for removing an item from Ongoing insufficient? Or is the complaint that !voters in these removal discussions are "wrong"? If you truly think that there are items that should be removed, propose their removal. If ITN !voters are "wrong", then propose stricter criteria for "Ongoing" and get it changed. I don't think a simple day limit is the way to make criteria stricter, though. (As a side comment, I only count 7 topics in Ongoing, not 10 - it's 10 links but 7 topics.) SnowFire (talk) 16:58, 26 June 2026 (UTC)reply
  • Oppose per Headbomb and Robertsky. To a reader, it would not be clear why some items that are ongoing are not on the list; right now the dichotomy between the regular blurbs/ongoing/recent deaths is intuitive but the proposed delineation is very much not. If there are issues with specific articles staying on there then they can be dealt with individually. Mir Novov (contribs | talk) 11:53, 27 June 2026 (UTC)reply
  • Oppose per Robertsky, more ongoing means more events going on. You can add a discussion on removal of events that is not anymore ongoing on ITN. Warm Regards, Miminity (Talk?) (me contribs) 12:00, 1 July 2026 (UTC)reply
  • Oppose as removal after 45 days is very arbitary. However, I would support opening RfCs for removing individual items in ITN Ongoing. FlammablePizza (talk) 16:48, 3 July 2026 (UTC)reply
There is no need for separate RfCs to remove individual items. The existing process allows for individual ongoing items to be nominated for removal directly at WP:ITN/C (and items have been removed recently in the past month). Natg 19 (talk) 16:53, 3 July 2026 (UTC)reply
  • Oppose – As mentioned by plenty above, 45 days is arbitrary. Nice4What (talk · contribs) ♥ 03:47, 4 July 2026 (UTC)reply
  • Oppose per above, no need for an arbitrary time limit. I also do not see the current number of ongoing items, which reflects the number of actual ongoing events in the world, as a problem to be solved. Moreover, I think this RfC is uncalled for as there was not any attempt to discuss this proposal on the ITN talk page (per WP:RFCBEFORE). Davey2116 (talk) 07:15, 5 July 2026 (UTC)reply
  • Oppose automatic removal, but support a mandatory review after 45 days. Age alone is a poor measure of relevance: some stories fade quickly, while major conflicts or multi-stage events remain widely covered and substantially updated for months. After 45 days, continued inclusion should require renewed consensus under WP:ONGOING; otherwise, the item should be removed. Itliano355 (talk) 04:20, 14 July 2026 (UTC)reply
  • Support per Andrew below—very few of these are getting any page views. If nobody's reading them, what's the point in having them?– Closed Limelike Curves (talk) 14:53, 27 July 2026 (UTC)reply
  • Oppose If this was in effect, Covid-19 would have slipped away in, what, April 2020? Some stories are big, long, and ongoing, and our processes should respect that.Deckocard21 (talk) 01:43, 30 July 2026 (UTC)reply
    And some stories are ongoing for less than 45 days, but this would discourage removing them if they become stale before that arbitrary point. Thryduulf (talk) 09:52, 30 July 2026 (UTC)reply
  • Oppose Too arbitrary. It's better for us to simply reassess ongoing items from time to time as needed, which we do already. Ongoing is honestly one of the least problematic sections of ITN. The criteria for posting to & pulling from Ongoing actually make sense, at least compared to blurbs. I understand that we recently had more items than usual, but we've already swung in the opposite direction. As of writing, there's only 2 things in Ongoing, 3-4 depending on how you want to count them, and I don't think we ever reached 10. There's also the question of whether "too many ongoing items" is a problem, and my answer is no. ITN more often has the problem of failing to post things, not due to a lack of news or a lack of quality wiki articles, but instead due to a shortage of admins willing to post or because the community can't get it together and agree to post anything. We recently got to the point where there were only 2-3 blurbs total and had the most empty space of any main page section. Ongoing is just more functional.  Vanilla  Wizard 💙 23:56, 31 July 2026 (UTC)reply

Discussion (ITN 45 days)

  • Procedural note: I don't see any evidence of WP:RFCBEFORE's

    you should try first to resolve your issues other ways. Try discussing the matter with any other parties on the related talk page. If you can reach a consensus or have your questions answered through discussion, then there is no need to start an RfC.

    For this situation, that would be an attempt to hold regular discussion on the matter at WT:ITN. To my knowledge, this has not occurred. Left guide (talk) 03:50, 24 June 2026 (UTC)reply
    • I've boldly removed the RfC tag. Formal RfCs represent an enormous investment of time from our community of volunteers, and to launch this without regard for RFCBEFORE/even trying to resolve concerns at the appropriate talk page is disrespectful of those people. I don't actually see any archived WT:ITN comments from BilledMammal in this calendar year, let alone comments on ITN's ongoing section, before today. Ed [talk] [OMT] 04:30, 24 June 2026 (UTC)reply
      • I've reverted, per my explanation below and the fact that WP:RFCBEFORE is a suggestion, not a requirement. BilledMammal (talk) 04:34, 24 June 2026 (UTC)reply
        Re-removed, essentially for the reasons Ed stated; this works fine as a proposal discussion. It's fine to advertise this in other projects and venues to get additional opinions if you like (have you?), and this discussion can be the one that fulfills the "before" requirement for a subsequent Rfc, but it doesn't fulfill it for itself. Then again, perhaps an Rfc won't be needed subsequently, unless this one becomes hopelessly deadlocked. Let's let the discussion continue, and see what we can learn about the situation and the issue in question. Mathglot (talk) 08:29, 24 June 2026 (UTC)reply
    Discussion at WT:ITN might allow us to reduce the current number of articles listed in ITN ongoing - although I think it is more likely to turn into a trainwreck - but it can't resolve the overall situation or prevent us from arriving here again. I think opening this RfC directly was the best option under the circumstances. BilledMammal (talk) 04:32, 24 June 2026 (UTC)reply
    Not following. Why would a discussion at WT:ITN that resulted in a consensus to permanently cap the number of ongoing entries not be able to "resolve the overall situation or prevent us from arriving here again"? After all, ongoing started with a proposal on WT:ITN.
    Also, I edit-conflicted when trying to add to my comment above that I do not have a concern with the topic of the RfC. I've certainly posted about concerns with ITN multiple times over the years! However, we have processes for a reason. I strongly object to you reverting my removal of the RfC tag, and would once again point out that you are parachuting into this situation and disrespecting the most important resource we have—editorial time. Shame, really. Ed [talk] [OMT] 04:43, 24 June 2026 (UTC)reply
    In my view, any discussion that resulted in a consensus to permanently cap the number of ongoing entries should be a formal discussion - we shouldn't be changing highly visible processes without broad visibility and input. BilledMammal (talk) 04:50, 24 June 2026 (UTC)reply
    Gotcha. That is an opinion, or really a question, that should have been asked as part of the RFCBEFORE that you decided to ignore. Plenty of changes happen on the main page "without broad visibility and input"; should Wikipedia talk:Did you know § Applying WP:EASTEREGG to hooks considered harmful happen on Talk:Main Page? Would you propose that all RfCs that aim to change the manual of style for all our articles be held here? Isn't the point of a RfC tag (as well as WP:CENT, etc.) to bring people into RfCs regardless of where they're happening? Etc. Ed [talk] [OMT] 05:17, 24 June 2026 (UTC)reply
  • I !voted on the proposal, but I agree with others that this should've started at the ITN talk page. It was a shock to see this "complaint" opened without prior discussion at the ITN project, as in my opinion , this is more of an ITN internal matter. Natg 19 (talk) 05:02, 24 June 2026 (UTC)reply
    Processes with significant impact on the encyclopedia - and I include those controlling the main page in that - should in my view not be an internal matter, but a matter for the broader community. BilledMammal (talk) 05:07, 24 June 2026 (UTC)reply
    Then what's the point of WT:ITN? Might as well redirect it here if that premise is true. Left guide (talk) 05:11, 24 June 2026 (UTC)reply
    Then you are free to solicit input from the project more broadly- but ITN should at least be made aware of this discussion, if not it being held there. 331dot (talk) 09:14, 24 June 2026 (UTC)reply
To be fair, ITN was notified of this discussion - BilledMammal did the requisite notification template: Wikipedia talk:In the news#Wikipedia:Village pump (proposals) has an RfC. The main objection here is that this should have been discussed there first. Natg 19 (talk) 16:59, 24 June 2026 (UTC)reply
  • Comment: the initial motivation or justification for the discussion appears to be the view that the presence of ten items in the ongoing list "is ridiculous". I am not a frequent consumer of ITN, but I don't understand why that is ridiculous. For example, on my device, the "From today's featured article" appears to the left of ITN and is longer than it by about two lines. By my reckoning, six additional items could be added to the ongoings, making the two modules about the same length, which would be easy on the eyes. Then again, I suppose it depends to an extent on the length of the FA excerpt. But I don't see a reason a priori why the ongoing list shouldn't have 16 (or 26) items. Is there some previous discussion about either the list length, or the comparative lengths of the FA and the ITN modules? Is there some attempt to keep them roughly the same vertical height on devices that support two columns, either formally, or by conventional practice? Or are they entirely independent, as far as length is concerned? Mathglot (talk) 10:10, 24 June 2026 (UTC)reply
    The goal is "balance", by which it is meant that the length of the TFA+DKY column should be approximately equal to the length of the ITN+On this day column. As I look at it now, the right (ITN+OTD) column is about two lines shorter than the left.
    Looking at the most recent 10 archived snapshots of the main page (i.e. 19 June to 23 June 2nd version): 19, 19b, 20, 20b, 21 and 21b were all balanced, in 22 and 22b the left column was about 2 lines longer and 23 and 23b the right column was about 2 lines longer. Thryduulf (talk) 10:42, 24 June 2026 (UTC)reply
    It's the idea of micromanaging such entries to "balance" the two-column view that is ridiculous. The majority of our readers use the mobile view which only has one column and so it's not an issue at all for them. And even the readers that use the desktop view won't care that much about a bit of white space. This also depends on other factors like the monitor size, viewing preferences, browser settings and so forth and so it's impossible to make it exquisite for everyone.
    My view is that Ongoing should be limited because of diminishing returns and less is more. There's always plenty ongoing in the world and we should focus on the items that are dominating the news, not trying to cover everything or promote particular protests.
    Andrew🐉(talk) 12:40, 24 June 2026 (UTC)reply
    @Mathglot: The most ridiculous thing (if any) is that we have only three blurbs documenting news stories in a section called 'In the news', and the reason for that is not their length, which sometimes happens to be, but the excessive room occupied by the ongoing and RD sections. Moreover, WP:ITNBLURB begins with Most In The News postings come in the form of blurbs., but the problem is that this is no longer the case. Therefore, either we change the ITN-related policies so that we no longer put weight on the blurbs or refrain from defending the content posted to ongoing because it's still significant. The room for ITN is limited, so it's a perfect trade-off between blurbs, ongoing items and RDs. --Kiril Simeonovski (talk) 12:58, 24 June 2026 (UTC)reply
    Only one of those blurbs is fresh news from this week; the other two are 10 days old and no longer in the news. Space for more blurbs is not needed until ITN figures out how to increase the rate at which it posts them. Andrew🐉(talk) 14:32, 24 June 2026 (UTC)reply
It only shows that we fail to serve ITN's purpose. --Kiril Simeonovski (talk) 17:41, 24 June 2026 (UTC)reply

Request for comment on adding this week's article for improvement to the main page

This is a proposal to adapt this week's article for improvement (TWAFI) to focus primarily on helping create new editors while also improving articles. Each week a new article that is not contentious, a biography of a living person, a medical topic, or otherwise non-ideal for new editors (as determined by consensus) would be shown on the main page with accompanying text that encourages newcomers to improve it. Guidance and suggestions will also be given when editing via an edit notice. The selected article would normally remain unprotected while on the main page to allow for prospective editors to edit at any time.

Should TWAFI be shown on the main page? InfernoHues (talk) 05:19, 2 July 2026 (UTC)reply


  • A - Yes
  • B - No

If shown, what mockup should be used as the starting template? (rank from most to least preferred)

If shown, where should the section be placed on the main page? (rank from most to least preferred)

Background

Workshopping for this RFC occurred at Wikipedia:Village pump (proposals)/This week's article for improvement, and initial discussions can be seen here, here and here.

Articles for Improvement was previously trialled as a section on the main page in 2013. For example, see the Main Page on 10 May 2013 when the section listed Fashion accessory – List of cheeses – Life science. The trial was considered a failure and the section then pulled. An extensive status report on the project was published in the Signpost following the trial.

Survey (TWAFI)

  • A - I highly recommend reading the initial statement by Bremps in the workshopping page for much more detail on the goals of this proposal. The current sections on the main page can feel 'closed off' to potential editors, so having a section dedicated to newcomers would be welcome. While not enforceable, experienced editors should be encouraged to be extra kind and patient to people editing the page, and to explain any reverts in detail without jargon.
    I prefer M.3, M.2, M.1 in that order. The most focus should be on the improvements to be made. For placement, I prefer P.1, P.2, then P.3. P.1 would make the box more easily visible on mobile, while P.2 would do so on desktop. As the majority of people worldwide use phones to use the internet optimizing for that makes sense. This should be high up on the page in order to attract new users, who are less likely to scroll down. InfernoHues (talk) 05:19, 2 July 2026 (UTC)reply
  • P3, P2, and P1, and M2, M1, M3. 🪐Kepler-1229b | talk | contribs🪐 05:26, 2 July 2026 (UTC)reply
  • M2 should, however, have the links bolded. 🪐Kepler-1229b | talk | contribs🪐 17:37, 2 July 2026 (UTC)reply
  • A, P3, P2, P1, M3, M2, M1. This seems like a great idea to attract new editors. In solidarity, FantasticWikiUser(Ts and Cs) 05:49, 2 July 2026 (UTC)reply
  • Support/A. M3>M2>M1 for emphasis on improvement; Aaron Liu/sapphaline proposal (above all)>P1≈P2>P3>>P4 or similar. 7amiþ solidarity · 💬 · 📊 · 🇺🇸 05:58, 2 July 2026 (UTC)reply
  • A, M2>3>1, P2>3>1 – I think this proposal has an excellent chance of helping create new editors by making readers aware that they specifically can edit here while also providing them with immediate guidance and a place to do so.
    For mockups I prefer 2 to start because it's direct, short and very clear. The tone is a departure from our usual dry style, but I believe using a more direct and human approach will lead to greater engagement. The article info given is just enough for new editors to know if it's something they'd like to engage with, without adding too much information or distracting links and muddying the messaging. It also provides an obvious way to begin (click here!). For position I prefer higher, more eyes means more chances someone makes their first edit.
    I'd also like to preempt some potential objections based on workshop feedback. There will be some unconstructive editing, but it will be confined to a single page, easy to handle, and well worth handling if it means new editors join the project. For concerns about potential strife between experienced and new editors, WP:BITE provides a strong backing to ensure behavior is collegial and friendly, guidance will be given to experienced editors as well about what conduct is expected, and I have faith that our editorship will be able to act constructively and aid newcomers. For editors preferring a different approach entirely, I too think we should try other approaches, but in addition to TWAFI and not instead of. fifteen thousand two hundred twenty four (talk) 06:11, 2 July 2026 (UTC)reply
  • B in a similar vein to a portion of WP:ITNCRIT, i.e. articles appearing on the main page are evaluated based on the quality of the article and its updated content (this is invoked too harshly at times, but that is an aside). There is a time and place to draw attention to articles that need improvement; the main page is not the forum to do so unless we subject articles to a standards check and tidy them up first (which partially defeats the purpose and just creates another hassle to deal with). Moreover, the main page is primarily for readers, which is also why we exist. Catering to editors or attempting to draw in new contributors should be done carefully; this is not the way. Additionally, I imagine the extreme visibility would make the selected article a magnet for vandalism and unconstructive editing becoming another burden for patrollers. — Godsy (TALKCONT) 06:36, 2 July 2026 (UTC)reply
    I will vote though: P4 (i.e. User:Godsy/main page mockup) & M1. — Godsy (TALKCONT) 11:18, 2 July 2026 (UTC)reply
    ITN quality standards don't clearly apply since TWAFI isn't intended as a way to inform readers about a topic, and the messaging of "this page needs improvement" will make that clear to readers as well. As for there is a time and place to draw attention to articles that need improvement, the first sentence of the RfC clarifies that this process will focus primarily on helping create new editors. Improving articles, while good, is a secondary goal to creating new editors who can then improve many articles. Your point about the main page being primarily for readers is unclear to me, all editors start as readers, so active efforts to seek new editors by necessity must target reader venues.
    Unconstructive editing will be confined to a single page that is highly monitored, will be easy to handle, and will be well worth handling if it means more new editors. fifteen thousand two hundred twenty four (talk) 07:21, 2 July 2026 (UTC)reply
    If ITNCRIT applies here, then I am a pigeon and each article on Wikipedia is actually a watermelon. This argument makes absolutely no sense. Also, why is it okay to bombard users every now and then (especially on mobile clients) with a page-long ad asking for donations from the reader, but NOT okay to have a small section of the main page dedicated to getting readers to become editors? Ilov3gam3z (talk) 11:37, 2 July 2026 (UTC)reply
    The users who would be against AFI are much more likely to be against the banners too. That's a much longer debate. In solidarity, Aaron Liu (talk) 20:15, 2 July 2026 (UTC)reply
  • A, M3>M2, P2>P3 – I prefer the wording of M3 the most, as it's the most inviting to potential new editors by encouraging them to contribute. For the same reason, I find the M1 is the most ambiguous and uninviting. In solidarity, nil nz 06:38, 2 July 2026 (UTC)reply
  • A, I think this is really excellent. M3>M2>M1, per Nil NZ I think M3 is the most inviting to newcomers, though use cases and limitations is odd wording. P1>P2>P3 per InfernoHues, there's symbolic value in making TFA and TAFI the two most prominent, and P1 does this for mobile viewers while P2 is for desktop. Kowal2701 (talk, contribs) 07:38, 2 July 2026 (UTC)reply
    That wording is awkward, but it's trying to convey that the suggestions can be tailored to whatever article is selected. fifteen thousand two hundred twenty four (talk) 08:22, 2 July 2026 (UTC)reply
    Could’ve put [insert text here], but no worries Kowal2701 (talk, contribs) 08:26, 2 July 2026 (UTC)reply
  • A, predicated on P1 failing. M2 is my favorite, followed by a huge drop off and then M3 and M1. On placement, P2 then P3 and oppose it all if P1. I have serious doubts that this will accomplish anything, certainly not article improvement and I am very doubtful about gaining editors, but I don't think anybody cares about OTD and, well, ITN is ITN, so its fine in the right column if it doesn't bother with TFA and DYK balancing-wise. I have also made my feelings known about the fact that I don't think any of the mockups are that great (why are we linking be bold or the Teahouse on the main page??), but M2 is best for only including minimal distractions. 1brianm7 (talk) 07:53, 2 July 2026 (UTC)reply
    To quote my very first comments on this proposal, 53 days ago, If there is consensus for this, it should probably not be weekly, but daily. Most of the content which does reach the main page in ITN and DYK (presumably OTND as well, but I know nothing about that) is improvable, but almost all of the improvements happen quickly I stand by that and would support daily over weekly. I think any hopes of article improvement are a pipe dream unless we abandoned editor recruitment, and if we abandon that count me against any position above TFP or TFL. In my eyes, we are shoving an edit button in the face of the uninitiated in the hopes that they randomly get bit by the itch. I think I now prefer P3 to P2, by a smidge, and am equally as supportive of proposals that would not interfere with the operation of DYK or TFA, such as but not exclusively P4. 1brianm7 (talk) 12:51, 5 July 2026 (UTC)reply
    Random idea: replace TFL with AfI on days TFL don't appear (that being Tuesday, Thurs, Sat and Sun)? Hason-LEK-SIN ● Let’s chat! ● My contribs 13:16, 5 July 2026 (UTC)reply
    I'll support daily (TAFI) so a wider variety of interests can be caught, but only if we implement a random or semi-random selection process (too much work otherwise). 7amiþ solidarity · 💬 · 📊 · 🇺🇸 17:10, 5 July 2026 (UTC)reply
  • A, M2>M1>M3, P3>P1>P2 per my comment on the discussion. M2 is more new editor friendly. P3 is the best because harly anyone really cares about OTD. Warm Regards, Miminity (Talk?) (me contribs) 08:41, 2 July 2026 (UTC)reply
  • A: Recruiting new editors is essential for the success of Wikipedia and this proposal sounds like a good way to achieve this. M3: The important feature here are the prominent examples of what can be improved. I have no preference about placement. — Preceding unsigned comment added by Joe vom Titan (talk • contribs) 09:00, 2 July 2026 (UTC)reply
  • A, M.2 > M.3 > M.1, P.2 > P.1 > P.3. FaviFake (talk) 09:54, 2 July 2026 (UTC)reply
  • A, M3>M2>M1, P2>P3>P1 I begrudgingly accept this is a good idea despite not personally liking what it does to the current main page, as I'm not the target audience here. M3 over M2 over M1 as M3 gives good info and M1 is unwieldy. As for the placement: I see what people are saying about putting it next to TFA, and I do like that, but P1 is off the table for me because of the decision to prioritize ITN and OTD over DYK there. I'd support putting TAFI where DYK is if DYK was placed where ITN is and ITN was placed where OTD is. People supporting P1 have not given a rationale for this, and I can't think of a satisfactory one. Also isn't there some way we can make TAFI 2nd on mobile and go where ITN currently is on desktop? –Maltazarian ᚾparleyinvestigateᛅ 10:05, 2 July 2026 (UTC)reply
  • A: Support. The better Wikipedia gets, the harder it will become to edit. Take, for example, Mobile, Alabama. This article has grown naturally and has been brought up to date and up to snuff through both informal and formal review processes over decades. It has: over 30 photographs taken by Wikipedia editors, a dozen or so public domain images, over 300 citations (including to out-of-print university press books), and dozens of formatting templates like {{Infobox settlement}}. You can contrast this against the earliest version of the article. On 11 January 2002, RjLesch wrote: "City in Alabama, United States of America. Four members of the Baseball Hall of Fame were born in Mobile: Hank Aaron, Willie McCovey, Satchel Paige and Ozzie Smith." That's it. The strategies used to bring in editors circa 2002 won't be applicable today. We need ways to onboard new editors rather than encouraging them to boldly make good faith edits and then immediately reverting. One line of opposition to this proposal came from concerns around having so many people work on the same article; I actually think this is a strength because it gives folks who want welcome new editors a designated article to watch. Additionally, as an admin, I'll volunteer to watchlist WP:ERRORS for the duration of the trial run. Rjjiii (talk) 10:07, 2 July 2026 (UTC)reply
    @Rjjiii any preference for which mockup to start with and positioning? fifteen thousand two hundred twenty four (talk) 10:58, 2 July 2026 (UTC)reply
  • A, M2 > M3 > M1, P1 = P2 > P3. Thank you all for workshopping this into an RfC. I really think this is an important way to engage new editors, and for that reason the placement on the MP should be front and center. Agnostic on P1/P2 since they're more prominent on mobile/desktop respectively. From the mockups, M2 is the most snappy and funnels potential editors most directly with the prominent call to action. YuniToumei (talk) 11:09, 2 July 2026 (UTC)reply
  • Support. A, M3 > M2 > M1. P2 > P3 > P1. Thank you to the other editors in the previous village pump discussion to working this into an RfC! I sincerely hope this passes. — Preceding unsigned comment added by Ilov3gam3z (talk • contribs) 11:31, 2 July 2026 (UTC)reply
  • B The idea has potential and the main page could use some fresh ideas. But there are numerous problems with this proposal as it stands including
    1. The proposed process works on a weekly cycle but main page sections have a daily cycle. An article such as List of Syrian cheeses does not merit a full week of exposure on the main page when our featured articles only get a day.
    2. The improvement process lacks structure and specifics. For example, the mockup suggests Articulated bus. This is a very mature article which was created over 20 years ago and has had over 800 editors since. It only has one cleanup template and that was added in 2017. The first thing I would do to improve that article is remove that template as it is obviously stale and confusing.
    3. The article selection process is not random as has been misleadingly suggested. Instead, there is a nomination process which is adversarial with Support/Oppose votes. In my experience of ITN, this is toxic as it generates conflict and chat rather than actual improvement. ITN limits the possibilities to those topics which are in the news but this is so open that I expect the nominations would soon overflow.
    4. An article which is on the main page for a week is in the spotlight. This is the worst possible place for new editors who will want to make their mistakes in a quieter and less conspicuous setting. The spotlight will tend to attract a different sort of editor.
    5. This idea has been tried before and failed. I don't get the impression that this is any different.
  • Andrew🐉(talk) 11:32, 2 July 2026 (UTC)reply
    1. There is no rule stating that everything on the main page has to be daily. ITN disregards this, too.
    2. Articulated bus was the AFI (Article for Improvement) that day, so that is why. Blame AFI, not TWAFI. (Side note: I am sure that this will boost attention to AFI and their picks will get better)
    3. We really do not have consensus on how to vote them in, if they should be automatic or hand done.
    4. Well then some editors will simply not use TWAFI and will edit in more remote corners of the site. I see no problem with this. As long as we bring in even one new and good editor, this is a success in my book.
    5. We are in a much worse predicament then we were the last time we tried this. Editor retention and gain of editors is down immensely and we are being drowned with AI vandalism. We need new editors at any cost. Also, this proposal seeks to have a lot less moving parts (the human element) in hopes of not doing what bogged down the last proposal like this one. We have done a lot of work to differentiate the two. Ilov3gam3z (talk) 11:45, 2 July 2026 (UTC)reply
    At the worst case, we do a trial run and at the end it fails and we remove TWAFI from the main page. At least give it a try. Ilov3gam3z (talk) 11:46, 2 July 2026 (UTC)reply
    That's kind of what I'm thinking. If this is a complete flop then WP:CCC. –Maltazarian ᚾparleyinvestigateᛅ 12:03, 2 July 2026 (UTC)reply
    I itch to rebut the badgering but this is not the place for threaded adversarial discussion, which tends to be toxic. Instead, I've been looking at the List of Syrian cheeses which is so problematic that it demonstrates how clueless this process is. Its issues include:
    1. It turns out to be a list of Levantine cheeses and so the current page title is misleading.
    2. The Levant is a highly controversial place as it includes places like Armenia, Israel, Palestine, Syria, Lebanon and other hot spots.
    3. The controversies in this region are not just geographical and religious but also extend to the foods such as the famously lame case of Hummus and friends.
    4. Looking at the history of the page, it started as Syrian cheese and its entire content was [stub] really good mida de tern cheese. kind of like feta but moreod ld ir So, this is not a serious topic IMO; it's more of a joke.
    5. These issues make this a really bad starting point for a new editor. Highlighting it on the main page for a week would make Wikipedia a laughing stock.
    Andrew🐉(talk) 12:39, 2 July 2026 (UTC)reply
    We would obviously be more careful about our selections if the proposal were to gain consensus. –Maltazarian ᚾparleyinvestigateᛅ 13:05, 2 July 2026 (UTC)reply
    No, you obviously wouldn't be more careful because no care was taken in this high-profile case. "You never get a second chance to make a first impression" and this is especially important with new editors. The AFI crew clearly can't be trusted. Andrew🐉(talk) 13:09, 2 July 2026 (UTC)reply

    "The AFI crew clearly can't be trusted."

    Do you have to put down your fellow editors to make your point? If there are so many problems with this article, then the AFI crew is doing it's job and doing it well. When we implement TWAFI, AFI will obviously have a slightly different purpose and more people will join the group of AFI editors with the purpose of working on TWAFI specifically. As such, the AFI's will become more new-editor friendly. We can, at the very least, give this idea a trial run and if it fails remove it. No harm done whatsoever. Ilov3gam3z (talk) 13:46, 2 July 2026 (UTC)reply
    The idea already had a trial run and it failed. Looking at the list of AFI accomplishments, they seem to peter out in 2016. The project switched from a daily schedule to a weekly schedule around then and so its glory days are long past.
    There are other fresher ideas and initiatives so perhaps they should be given some exposure on the main page instead. For example, when I browse the Wikipedia app lately, I'm invited to add a picture to an article by its Suggested edits. I've tried this a few times and it works well. It's a reasonably well-designed process because it's based on existing usage in another language and the tool walks the editor through the process in an straightforward way. Adding a picture to an article that hasn't got one makes a big difference and so it's quite satisfying.
    Other ongoing activity on my radar includes the Guild of Copy Editors drive for July and meetups in Chicago, London, San Diego and elsewhere. New editors would get a lot more out of such activities than AFI work in my experience. But it doesn't have to be either/or. A new section on the main page should list all such outreach and improvement activity, not just one single article.
    Andrew🐉(talk) 14:21, 2 July 2026 (UTC)reply
    "This other idea (which in your case is the Guild of Copy Editors and suggested edits on the user’s Homepage) will work/is working in attracting newcomers, so this is not needed."
    Wonderful! Let us implement both. —@Bremps in the original VPP discussion/workshopping.
    The main goal of TWAFI on the main page is to increase visibility of articles that need attention so new editors will gave a good place to start. This can complement with the other two initiatives we mentioned.
    "But (attracting newcomers) isn't the main goal of TWAFI" well, we can change that.
    And also, why are you just pinpointing on specific articles (Syrian cheese, articulated buses, politics appearing on AFI) instead of looking at TWAFI as a whole? Hason-LEK-SIN ● Let’s chat! ● My contribs 23:27, 4 July 2026 (UTC)reply
    Agree wholeheartedly with this. TWAFI is (and was very well stated in the previous discussion) a two-pronged proposal. 1: Improve the content of the articles in question. And 2: Acquire new editors to combat declining editor retention rates and the phenomena of old editors leaving Wikipedia. Also, no offense, but Andrew, your mention of specific articles rather then the whole proposal reads to me as a whataboutism. Ilov3gam3z (talk) 23:42, 4 July 2026 (UTC)reply
    To turn the "We" into a "You" is a choice of words that sticks out. What was intended to be conveyed by doing that? –Maltazarian ᚾparleyinvestigateᛅ 04:15, 3 July 2026 (UTC)reply
    It's just ordinary English grammar. I'm not sure who "we" is supposed to be though as there are only 8 active editors listed at WP:AFIP and you guys aren't amongst them. Andrew🐉(talk) 10:47, 3 July 2026 (UTC)reply
    The EnWiki community.. –Maltazarian ᚾparleyinvestigateᛅ 12:58, 3 July 2026 (UTC)reply
    I've been through the history of this proposal now. It started in 2024 with a post by Bremps at Talk:Main Page. That is so long ago now that I'd forgotten that I commented at the time. There was no consensus for this as there were 6 formal opposes and plenty of other comment pointing to problems with the proposal. Problems which are coming up again now because they haven't been addressed.
    Bremps has kept pushing the idea regardless but has failed to engage with the project which still operates this feature, just dismissing it as nearly dormant. So, it's not the current AFI crew that is responsible for the obvious defects in this proposal; they have been pursuing their existing agenda of prioritising the improvement of important topics like Chess. The main responsibility rests on Bremps who has been building a castle in the air in the ivory tower of the idea lab.
    Andrew🐉(talk) 14:45, 4 July 2026 (UTC)reply
    Looking at the graph of editors who have made at least ten edits in a month plotted against date of first edit, I don't perceive much significant change in editor retention comparing 2012 to, say, the past four years (medium-term retention seems to have gotten a bit better, if anything). The active editor counts over the last 5 years seems roughly stable (perhaps a slight upwards trend this year). The new registered users counts are decreasing, but if the editor retention stats are indeed roughly stable, then the drop hasn't affected how many editors stay around and edit. isaacl (talk) 16:06, 3 July 2026 (UTC)reply
    ITN often wades into politics. AFI has guidelines to never wade too closely into politics. I do not think this will be nearly as toxic as ITN, and for that argument to be a demerit, AFI would have to be more toxic than ITN, which is impossible. In solidarity, Aaron Liu (talk) 17:40, 2 July 2026 (UTC)reply
    Politics was actually nominated successfully at AFI. The actual prohibition seems to be "controversial" articles, meaning those with "heated discussion, edit warring, or questioned notability" and so they might be any kind of topic. The nomination discussions often seem to raise the issue of "importance" which is just like ITN's "significance". AFI is currently a backwater but if its articles get a week on the main page, we should expect some escalation. Andrew🐉(talk) 19:54, 2 July 2026 (UTC)reply
    Well in the past, AFI was aimed at people who were already editors. Should this proposal gain consensus, the criteria would accordingly shift (if not officially, de facto) because of the new crop of editors who would be interested in the process. Importance shouldn't be a factor for the proposed purpose. The goal would be to find articles that need improvement, but not so much that they can't be on the main page. InfernoHues (talk) 20:00, 2 July 2026 (UTC)reply
    If you read the fine print of this proposal (the discussion before the RfC) you would know that we will try to steer clear of contentious topics. AFI was aimed at things to be fixed by experienced editors, now we will simply aim it towards problems to be fixed by new editors. Ilov3gam3z (talk) 20:09, 2 July 2026 (UTC)reply
    I don't understand your disconnect here. Your argument reads (at least to me) "I know we will avoid contentious topics but that might happen anyway (mechanisn?) and cause arguments and edit warring in the contentious article (which, as detailed in this discussion wont happen)." ??? Ilov3gam3z (talk) 20:13, 2 July 2026 (UTC)reply
    calm In solidarity, Aaron Liu (talk) 20:16, 2 July 2026 (UTC)reply
    I do admit the irony, but I consider Politics the article as not too close into politics because it has very little heat. Importance might be an issue, but there's always enough articles whose topics completely avoid that debate because everybody agrees they're important enough, such as Articulated bus. Unlike ITN, there's no pressure for the items to feel current (and nominations take a very long time to become stale), so we'd still have a healthy AFI queue. In solidarity, Aaron Liu (talk) 20:12, 2 July 2026 (UTC)reply
    Bendy buses used to be quite a hot topic in London and getting rid of them was one of Boris's big achievements as London mayor. There's a current AFI nomination for the Reform candidate in Makerfield and that's about as political as it gets. It hasn't had much attention and no-one seems bothered that it is so political. Andrew🐉(talk) 20:35, 2 July 2026 (UTC)reply
    That's still not hot enough that it becomes contentious in editing.
    I would oppose Robert Kenyon as an AFI candidate; besides the other reasons, it is a BLP. No one seems bothered about the political part because the AfD nom is an even bigger and obvious reason to oppose it. Note that receiving no supports results in an automatic fail. In solidarity, Aaron Liu (talk) 21:20, 2 July 2026 (UTC)reply
  • B (No) or place it below the four main sections (TFA, ITN, DYK, OTD). Which would readers rather see on the main page: a box telling them to improve a random article (that they most likely have no interest in editing), or a box that lists current world events? I know I'd choose the latter, because a large, static section on the main page whose content changes once, weekly is, imo, boring. Plus, the primary purpose of the proposed TWAFI template is to apparently "create" new editors, but I'm having a difficult time believing that it'll accomplish that. If few existing editors are editing List of Syrian cheeses (this current week's article for improvement), why would a brand new editor be interested in improving that article? From their POV, the article looks to be in already decent shape, especially if it's after Day 2 of being featured. Besides, "improving" the article means the new editor must take time to do research on Syrian cheese and add a reliable source to the article. If they get reverted because they added unsourced content, original research, or an unreliable source? That'll discourage them from further editing. And as another editor said above, the article selected for TWAFI will be a magnet for vandalism and LTAs, especially if it's placed so prominently on the main page and with a call to action to edit it. That being said, I don't mind it being on the main page, but I don't see any benefits to having it placed above the four main MP sections. Some1 (talk) 11:34, 2 July 2026 (UTC)reply
    Prior TWAFI articles, such as List of Syrian cheeses, were not chosen with a primary focus of engaging new editors. The revert argument is non-specific to TWAFI, any new editor could be reverted at any article, the difference here is that a TWAFI page will be monitored by editors acutely aware of WP:BITE and who will be actively seeking to assist newcomers. fifteen thousand two hundred twenty four (talk) 12:27, 2 July 2026 (UTC)reply
    If I had to choose, I would place the TWAFI box below Today's featured picture. For the main page, dynamic, quality content should be the primary focus, with attempts to recruit new editors second. Some1 (talk) 22:35, 2 July 2026 (UTC)reply
    @Some1: I suggested P4 (User:Godsy/main page mockup) above, which I believe is similar to what you are suggesting. — Godsy (TALKCONT) 23:29, 2 July 2026 (UTC)reply
    Thanks for creating the mockup... Seems like having 2 boxes in the left column and 3 boxes in the right column will make the MP look uneven on desktop view (there's a large empty space in the DYK box). Looking at the proposed placement options above in the OP, all of them will also have that same issue on desktop mode. I prefer what's in User:ONUnicorn/sandbox, but with the TWAFI template in a shade of yellow or another color. An alternative would be to place the TFP box in the first column below DYK and the TWAFI box in the second column below OTD; that way there's 3 boxes in each column. Some1 (talk) 23:48, 2 July 2026 (UTC) Forgot there's a "Today's featured list", so striking. Some1 (talk) 00:33, 3 July 2026 (UTC)reply
    You could also show more of TFA to fill up the space. More DYKs are an option as well, but it might not be possible to promote that many hooks. InfernoHues (talk) 00:05, 3 July 2026 (UTC)reply
    I concur that the imbalance is a problem. The bottom does seem to be the best course of action for that reason and to keep the traditional, longstanding stuff in the expected locations. — Godsy (TALKCONT) 01:53, 3 July 2026 (UTC)reply
  • A x20. This is a very good idea because thats exactly what Wikipedia should do to encourage more newcomers to start editing tasks, one of the best features about Wikipedia. M.1>M.3>M.2 and P.2>P.3>P.1
    (talk with this worm) 12:39, 2 July 2026 (UTC)reply
  • B Per Some1's recent comments. If it must be done, send it as far down the page as possible.--Wehwalt (talk) 13:11, 2 July 2026 (UTC)reply
  • I very much vote A!
    My the mockup version I prefer is M.2 and the position I prefer is P.1.
    --I sometimes eat bananas, and you can talk to me here: (talk) 13:22, 2 July 2026 (UTC)reply
  • A and M3 > M2 > M1. As for placement, I actually don't prefer any of the placements except for P3, but like Wehwalt and Some1, this should probably be placed below the existing content (e.g. where TFL is located). However, if we had to choose, then P3 > P2 > P1. I really prefer that TWAFI not be placed above DYK and would want that to be the absolute last resort, as DYK has already been closely vetted, and that would very negatively affect DYK pageviews. I am less opposed to putting it above ITN (which is less closely vetted than DYK) and OTD (which is even less closely vetted than either ITN or DYK). – Epicgenius (talk) 13:22, 2 July 2026 (UTC)reply
    I echo this concern about hiding DYK. It's a place editors can showcase articles they worked on without requiring it to get all the way to FA level, and is, in my experience, very popular among editors for that reason. It's a great incentive to get editors putting some effort into articles, and a more valuable part of the main page than ITN and OTD are. –Maltazarian ᚾparleyinvestigateᛅ 14:07, 2 July 2026 (UTC)reply
    I would agree that it should not go above DYK. I feel that this would work well as a landscape bar at the bottom like TFL. MallardTV Talk to me! 16:42, 2 July 2026 (UTC)reply
  • A and M3 > M2 > M1 and P1 > P3 > P2, with the caveat that in P1, I'd rather have it below DYK instead of above. --SarekOfVulcan (talk) 13:50, 2 July 2026 (UTC)reply
    Having TWAFI below DYK would be suitable for me, too. – Epicgenius (talk) 13:58, 2 July 2026 (UTC)reply
  • A, support P2 > P3 > P1 and M2 > M3 > M1 per my comments in the previous discussion. Agree with Epicgenius that having it above less closely vetted sections like ITN and OTD is preferable to having it above DYK. I don't like the idea of setting it up for failure by making it as invisible as possible to conclude that people aren't interested. Chaotic Enby (in solidarity · talk · contribs) 15:04, 2 July 2026 (UTC)reply
  • A (support), for largely the same reasons that have been discussed to date. Regarding the language, my order of preference is M3 > M1 = M2. Regarding placement, my order of the three proposed placements is P1 > P3 > P2, but a hypothetical P4 that places TWAFI below DYK would be on par or even better than P1 imo. ModernDayTrilobite (talk • contribs) 15:05, 2 July 2026 (UTC)reply
  • No opinion on whether we should, but do not disrupt the top four boxes.--Launchballer 15:10, 2 July 2026 (UTC)reply
  • A, M3, P1 Ktkvtsh (talk) 15:19, 2 July 2026 (UTC)reply
  • A, M.3> M.2> M.1, P.None of the above, mainly per Epicgenius. This is a great idea that deserves visibility, but I reluctantly think it seems more suited to a place further down the page (i.e. above "Other areas of Wikipedia") to avoid obscuring any featured/vetted content. If we must choose now, P.3 > P.2 > P.1 seems the most reasonable. UpTheOctave! • 8va? 15:55, 2 July 2026 (UTC)reply
  • B (oppose) per Andrew and Some1. It does not appear that there is enough vetting at AFI, and also don't feel that this is something that would help new editors. In addition, the "weekly" cycle thing is a concern, as that makes the MP stale. ITN also has a problem with this, but that is a separate issue. Natg 19 (talk) 17:29, 2 July 2026 (UTC)reply
    If this is approved, I prefer M2 or M3, as M1 has a generic title bar and does not have an "appeal" to edit. In addition, I do like the idea of "ways to contribute" or "how to contribute", which presumably has specific suggestions and is not just boilerplate language. No preferences on positions. Natg 19 (talk) 17:33, 2 July 2026 (UTC)reply
    For what it's worth, there was some discussion on making it daily, but weekly was chosen to start with since we don't know for sure how effective this will be yet (will all basic improvements be made in a day, or will the full week be needed). InfernoHues (talk) 18:06, 2 July 2026 (UTC)reply
  • A, M3, P3 In the News should come first, then an article for improvement. M3 has explicit suggestions for how to imporve the article. --Enos733 (talk) 17:36, 2 July 2026 (UTC)reply
  • A as I find oppose arguments unconvincing (per replies above) and prefer M.3: Potential improvers should know most how they can actually change up the article. M2 does have these suggestions but without the bulleting, it's so hidden that the last !voter did not see it. It's much less important to summarize what the article is about, because this is about improving the article, not telling you what the article's about right now. Which is also why I think M.3's first paragraph should be trimmed to just one sentence (M3A?).
    I have mixed feelings about placement as all of the available options unbalance the columns. I do agree that it should be ideally visible without scrolling, though, as that's what most of the people we want to attract do. In solidarity, Aaron Liu (talk) 17:53, 2 July 2026 (UTC)reply
  • B (opposed). There should be various prominent links that invite editing, but having direct links to an article to edit on the Main Page with little explanation what needs to be done is not going to do much good. I expect a lot of the edits will be simple ENGVAR violations "fixing" the spelling or grammar. —Kusma (talk) 18:49, 2 July 2026 (UTC)reply
  • A, worth trying. M2 > M1 > M3, simplest call to action and least WP:INSTRUCTIONCREEP. P2 > P3 > P1, make it visible, don't touch the left column of the main page. ~ A412 talk! 19:08, 2 July 2026 (UTC)reply
  • B (Oppose). The main page is for quality content that benefits readers, not primarily for recruitment of new editors. I also agree with concerns expressed above that having an article in need of improvement up on the main page for a week while most of the quality content appears for only a day is out of step with our priority of serving up quality, fresh, relevant and timely articles. Dclemens1971 (talk) 21:32, 2 July 2026 (UTC)reply
  • A, with the following template ranking: M.2>M.3>M.1. For positioning: Aaron Liu's proposal>P.2>P.1>P.3. We can and should be doing more to recruit new editors. The template and positioning rankings I put in order of what I think would be most attention-arresting. Bremps... 21:41, 2 July 2026 (UTC)reply
  • B (Oppose). The Main Page is already cluttered, and drawing readers into editing is already one of the purposes of DYK. (That's one of the reasons I opposed having GAs added to new and recently expanded articles in DYK, and I would regard undoing that change and reinstating the statement in the DYK section that these are among Wikipedia's most recent articles and "you can edit them" as a better way to encourage people to try editing.) I also share the concern that featuring the same article for improvement for a week while content selected for its quality is only featured for one day is something of an insult to those who worked hard to polish the quality content. Even ITN and Recent Deaths turn over faster than weekly. The underlying problem is that TWAFI is a suggestion among a multitude of maintenance and improvement tasks, including a large number of articles that are equally or more in need of improvement; it's an artificial focus, while what we need to ensure readers are aware of is that editing in general is welcome, no matter what they want to fix or add. (Yes, they can even edit TFA.) Showcasing one article as in need of improvement actually undercuts the message that this is an encyclopaedia, but it's also an open wiki. Yngvadottir (talk) 22:31, 2 July 2026 (UTC)reply
    Unfortunately TFA is now automatically semi-protected for two days; see Wikipedia:Perennial proposals#Protect featured articles. That is part of why I enthusiastically supported this from the workshop stage. In solidarity, Aaron Liu (talk) 23:00, 2 July 2026 (UTC)reply
    Maybe we should contact the TFA editors to change this? Ilov3gam3z (talk) 15:14, 5 July 2026 (UTC)reply
    You are not overcoming this overwhelming consensus without some extraordinary new information. In solidarity, Aaron Liu (talk) 21:38, 7 July 2026 (UTC)reply
  • A (Support) I know the WMF is somewhat controversial right now, but support in the spirit of meta:Wikimedia Foundation Annual Plan/2026-2027 (even if it's mostly corperate nonsense). This furthers those goals much better than the image carosal that met so much backlash a few weeks ago. Would prefer M1 as it provides article specific contribution advice, and this is purely cosmetic and not practical, but I'd put it below most of the content, probably above POTD, because I like how the mockups look in wider format. We may need to implement more thorough vetting at AFI if they do get onto the main page. ⇖ /.°°.\ ⇗ (They/Them/Their) 23:11, 2 July 2026 (UTC)reply
    But if I had to choose, probably P2 ⇖ /.°°.\ ⇗ (They/Them/Their) 23:24, 2 July 2026 (UTC)reply
  • A (Support); however, I would propose it be Today's article for improvement rather than This week's article for improvement as a week is a long time to placing an article on the frontpage that is in need of improvement, especially with the amount of real-estate that will be committed. As far as preferences go, P3 -> P2 -> P1 & M3 -> M2 -> M1 in those orders. TarnishedPathtalk 01:09, 3 July 2026 (UTC)reply
  • A No preferences for the mocks. Any would do, in my opinion. I strongly recommend P1 or a variation that puts this in the left column. ITN could use more space at times as sometimes it is either the the content in the left column being too short, or the DYK OTD section being too long that leads to entries in ITN being bumped off (temporarily). With WP:ITNBALANCE as it is, we may have to sacrifice more space than before. – robertsky (talk) 02:33, 3 July 2026 (UTC)reply
    To be frank, I don't think ITN (or OTD) uses the space it currently has particularly well. Why give it more? 1brianm7 (talk) 03:26, 3 July 2026 (UTC)reply
    ITNBALANCE reduces the space that ITN has. With this proposed section, ITN... would like be virtually gone? Unless ITNBALANCE excludes the TAFI section from consideration for balance between the two columns. – robertsky (talk) 03:33, 3 July 2026 (UTC)reply
    Yeah, I've said before in the workshop that I don't think the concerns about balancing and size have been adequately accounted for, and have supported concision to make the TWAFI box as small as possible. I would hope that OTD also shrinks itself if this is successful, especially since it's my understanding that OTD has the least community buy-in. And I expect more people to realize that these mockups are really too big without doing much of anything with the space once they are implemented. With this proposed section, ITN... would like be virtually gone? that's one of the strongest arguments I've heard for this proposal /hj 1brianm7 (talk) 03:58, 3 July 2026 (UTC)reply
    I don't see why TFA couldn't be made longer if needed to fill in the space, just show more of the article. You could also increase DYK, but that's harder. InfernoHues (talk) 04:02, 3 July 2026 (UTC)reply
    We could also make the two sides take 50% instead of the current 60-40 balance we have now. That, plus making TFA longer would likely solve the balance problem. ScienceD90 (she/her) (talk) 04:11, 3 July 2026 (UTC)reply
    The current balance is 55-45, not 60-40. And still, I'd oppose rebalancing, because I think ITN and OTD (and possible soon TWAFI) are really quite bad at using the space they have. 1brianm7 (talk) 04:20, 3 July 2026 (UTC)reply
    I think we might want to create a new section about the balancing issue instead of just having it in the middle of the survey section, so we can get more ideas on fixing it. ScienceD90 (she/her) (talk) 04:38, 3 July 2026 (UTC)reply
  • A (Support) I think this would be an improvement as it helps new editors find a page that could use improvement. I vote M.3>M.2>M.1. I think M.3 is th best choice because it lists out what needs to be done on the article. M.2 has the advantage of being smaller but the list is not as visually clear, instead being embedded in the paragraph. M.1 is the worst option as it just copies the lead. For the placement, I vote P.2>P.3>P.1. I think this section should be at the top so the most editors see it. I have ranked the placements based in how high the new section would be. ScienceD90 (she/her) (talk) 02:39, 3 July 2026 (UTC)reply
  • A, we can easily remove it if it doesn't live up to expectations. That being said, it has to be executed in a way that's mindful of TFA. It's ridiculous to have our best editors toil away to write a featured article for the hopes of getting 1/7 of the exposure some randomly selected article will. With that in mind, M3>M2>M1 (though the exact wording will need some improvement), and P3>P2>P1, though I wouldn't be opposed to putting it under TFP as some have suggested. JustARandomSquid (talk) 07:35, 3 July 2026 (UTC)reply
  • A, as when last discussed I'm generally supportive of this idea. However, on placement, I've come around to a long horizontal placement like the mockups in the past discussion. This makes it more visible, but also makes it easier to remove if there is an issue/no appropriate article for that week without disrupting the rest of the main page (think of how TFL appears and disappears without causing issues). CMD (talk) 09:11, 3 July 2026 (UTC)reply
    @CMD do you have any preference for which mockup should be used as the starting template? fifteen thousand two hundred twenty four (talk) 10:15, 3 July 2026 (UTC)reply
    Thanks, missed that part of the multi-question. M3>M2, oppose M1. CMD (talk) 10:57, 3 July 2026 (UTC)reply
  • A, no preference for placement. Agree with TarnishedPath that Today's article for improvement would be better than keeping one article on the front page for a week. Whonting (talk) 10:54, 3 July 2026 (UTC)reply
  • A - Support, just like I did in the previous discussion. For the mockup preferences, without any other suggestions/own mockups: M3 > M2 > M1. For the placement, no preference (lean P.2) since I usually look at the whole Main page, however, my concern is that this would bury the other parts of the main page (especially ITN)
    Side note for M3, as Ilov3gam3z mentioned, they are okay with removing the indentation
Hason-LEK-SIN ● Let’s chat! ● My contribs 14:26, 3 July 2026 (UTC)reply
  • B (oppose) per others above. In addition to the opposing comments already made, I just feel this initiative will fail to solve the problem it's trying to solve. The process to identify the articles to improve (Wikipedia:Articles for improvement) seems to stand on weak footing - there were a lot of comments above on List of Syrian cheeses, which at least is an article can could use some love, but next scheduled on is Chess, a very complete article that will flabbergast new editors - what are they expected to improve there? I also feel that this is completely the wrong approach to get new editors. Wikipedia should rather build a social media presence, have a daily "article to improve" post on Instagram, for instance, and attract new and younger editors where they actually are spending their time. Even if this TWAFI proposal here goes through, my expectation is that it will change nothing. In terms of position (in case this goes through) I echo others: don't mess with the parts on the main page that work for this hail-mary expirement. Khuft (talk) 18:39, 3 July 2026 (UTC)reply
    Good point about Chess. That was not nominated because it would be suitable for newbies but because it was a former featured article and was level-4 vital. That nomination was in 2023 and the AFI pipeline is full of such high-stakes articles. Pivoting the project to be a training ground hasn't been thought through and simply won't work as there's no way that the chess project's fanatics will let newbies mess with their most important article. The article has had over 3,800 editors to date and is already semi-protected due to vandalism. Andrew🐉(talk) 19:11, 3 July 2026 (UTC)reply
    I personally think the chess article is at least GA level, and I dread it going through a flurry of edits. Edits to it from new or anonymous editors are usually not very good. MaxBrowne2 (talk) 02:55, 4 July 2026 (UTC)reply
    This was a bad idea. It's not a matter of WP:OWN, rather wiping years of intelligent article evolution by inexperienced editor(s). Who thunk this up?? --IHTS (talk) 06:08, 7 July 2026 (UTC)reply
    The edit history of Chess, now AFI for two days, says otherwise. In solidarity, Aaron Liu (talk) 21:40, 7 July 2026 (UTC)reply
    My take is that an inexperienced editor, Chuddite, has rushed in to do some bold restructuring of the Chess article without prior discussion. More experienced editors are now talking about reverting this: we should revert to the earlier and superior organization ... Agreed. Revert. ... I hope we don't get too many more "improvements". And that's without any completely new editors attracted by a post on the main page. They wouldn't be able to edit the article because it is still protected. Andrew🐉(talk) 22:34, 7 July 2026 (UTC)reply
    My take is that it's still a net positive. The first comment you're quoting starts with Some of the recent reorganization is bad., my emphasis on Some. In solidarity, Aaron Liu (talk) 00:54, 8 July 2026 (UTC)reply
    When making the RfC, we didn't consider what articles would be chosen. Bremps, the proposer, said the articles would have to be randomly chosen. I think TWAfI needs to be C-class or less, too.
    To quote Bremps: "This other idea will work/is working in attracting newcomers, so this is not needed." Wonderful! Let us implement both. 7amiþ solidarity · 💬 · 📊 · 🇺🇸 19:14, 3 July 2026 (UTC)reply
    The worry I have is that there are several people who have said that as part of the process X will happen, but no one saying (not even Bremps) that they will personally work on making X happen. I think a lot of details can be worked out through local discussion, but I'd feel a lot more reassured if there were actual volunteers stepping up and saying they will be working on the details and participating in the day-to-day work. isaacl (talk) 21:39, 3 July 2026 (UTC)reply
    I'll definitely be around when this is getting off the ground to weigh in and help, but I definitely imagine this to be non-adversarial and relatively light when the novelty wears off. Bremps... 22:01, 3 July 2026 (UTC)reply
    I'll definitely be there to help as well. InfernoHues (talk) 22:59, 3 July 2026 (UTC)reply
    I'll be there to help, too. 7amiþ solidarity · 💬 · 📊 · 🇺🇸 00:35, 4 July 2026 (UTC)reply
    I will personally work on making X happen. fifteen thousand two hundred twenty four (talk) 04:01, 4 July 2026 (UTC)reply
    I suggest getting the process going now, producing weekly versions of what would be posted to the main page, to better understand the day-to-day work required, and what automation may be desirable. I think establishing a track record of having content prepped, enqueued, and ready, as well as finding volunteers to implement any required automation, would help reassure the community that the initiative can regularly update the main page. isaacl (talk) 16:50, 4 July 2026 (UTC)reply
    Bremps signed up as a participant of TWAFI in August 2025. They are not now listed as an active member of that project because the only thing they seemed to do was post a link to the Idea Lab which seems to be the actual place this idea was cooked up. So far as I can tell, Bremps has never nominated an article for TWAFI nor even discussed someone else's nomination. They seem to have zero experience of the project and yet they propose to take it over, transform it and put it on the main page. But note that they are not an admin and admin rights are essential for main page activity. Andrew🐉(talk) 07:14, 4 July 2026 (UTC)reply
    This is not a proposal for Bremps to take over or head TWAFI, it's a proposal for a new community process, of which there are many community members offering their support.
    Concerning needing admin permissions, 7 admins have supported this proposal so far. fifteen thousand two hundred twenty four (talk) 07:35, 4 July 2026 (UTC)reply
    This is not a new process; it's the existing process of Articles for Improvement which has existed since 2012. This RfC is only to determine whether the current article for improvement should be posted in a section on the main page. And this idea isn't new either as this was already tried in 2013. Andrew🐉(talk) 14:58, 4 July 2026 (UTC)reply
  • A. I think this is an excellent proposal and will help recruit new editors to Wikipedia and bring more attention to articles that really need it. I prefer M2, M3, M1, especially M2 because it suggests to newcomers what kind of improvements can be made to the article and gives an easy link to start editing. However I oppose all of the proposed placement options. I agree with concerns that there needs to be a clear distinction between featured content and an invite to participate in editing. Therefore, I think TWAFI should be in another color such as yellow or orange and placed below the featured content, like this:
I think this could be a good way to implement the proposal while keeping all existing main page content visible. Just a thought. MidnightMayhem (talk) 00:49, 4 July 2026 (UTC)reply
The problem with this is that then most people won't see it, which defeats the purpose. --I sometimes eat bananas, and you can talk to me here: (talk) 02:06, 4 July 2026 (UTC)reply
I like the colour difference, but the burying at the very bottom though… 🫩 Hason-LEK-SIN ● Let’s chat! ● My contribs 06:28, 4 July 2026 (UTC)reply
The idea of placing TWAFI down there with the featured picture did come up in the previous discussion. It was generally rejected because not many people would see it. In fact, several people admitted they did not even know there was a featured picture section on the Main Page. ScienceD90 (she/her) (talk) 11:59, 4 July 2026 (UTC)reply
  • A. Great idea. Opposers who suggest there are many other maintenance tasks to get into are missing that many people don't know they can edit Wikipedia at all. DYK doesn't motivate them to edit; they don't know they can write DYKs and have no idea how articles are chosen for it. I am not terribly particular about position or mockup, but I don't like how P1 puts it above DYK. The FA and DYKs ought to have high billing on the page and this shouldn't displace them. In solidarity, asilvering (talk) 02:51, 4 July 2026 (UTC)reply
  • B (Oppose) per Andrew. Also, I believe new editors are likely to edit within their own niches, rather than edit related to Syrian cheese just because the Main Page suggested it. Nice4What (talk · contribs) ♥ 03:46, 4 July 2026 (UTC)reply
  • B. I'd rather see this on the Community Portal, not MainPage. There is no way to predict whether a wikiarticle will improve enough after a week of collaborative editing to be featured on MainPage. Prefer featuring FAs on MainPage. And then, there is DYK to feature recently upgraded wikiarticles. After TWAFI, improved wikiarticles can go through GA review and qualify for DYK to get on MainPage. --PFHLai (talk) 08:48, 4 July 2026 (UTC)reply
    The point of TWAfI really isn't to improve articles but to help editor retention. As @asilvering pointed out, many people don't know that DYKs are for them to write. I also doubt that most people know a Community Portal even exists (as a moderately new editor, I sure didn't). 7amiþ solidarity · 💬 · 📊 · 🇺🇸 14:30, 4 July 2026 (UTC)reply
    7amithorn is only 2 months old and so still has much to learn. Articles for Improvement is 14 years old and its formal goals do not include editor retention:

    The project's four main tasks are to:

    • Coordinate and collaborate to improve articles.
    • Identify candidate articles.
    • Select the order they appear on the community portal in the Articles for improvement section.
    • Assess and track our accomplishments.
Andrew🐉(talk) 15:31, 4 July 2026 (UTC)reply
Or it could be that 7amiþ is talking about the refocused version of TWAFI proposed here, the topic of discussion, which in the first sentence states This is a proposal to adapt this week's article for improvement (TWAFI) to focus primarily on helping create new editors. From my 3 year 9 month old account, fifteen thousand two hundred twenty four (talk) 15:51, 4 July 2026 (UTC)reply
That's preamble which seems to be a false premise. The specific and only RfC question is Should TWAFI be shown on the main page?
Note that there's already an existing project devoted specifically to editor retention. It's WikiProject Editor Retention. Trying to repurpose AFI to do the same thing is silly and further demonstrates that this proposal has not been thought through.
Andrew🐉(talk) 16:04, 4 July 2026 (UTC)reply
I agree with Andrew. As I noted above, I feel the whole initiative is starry-eyed passion project without a clear strategy to achieve its goals. Is it aimed at finding new editors or at editor retention (two completely different goals)? If the first, why do we think a random "article to improve" like List of Syrian cheeses, or Chess, would attract new editors? Do potential new editors even go to the main page, or do they access the info they need via links to specific pages via Google (or an LLM)? Wouldn't it make more sense, as I mentioned above, to reach out to younger, potential editors via e.g. social media? If the aim is editor retention, how is throwing a random article at people that have disconnected from editing (probably because they have jobs and a family nowadays) going to rekindle the fire of editing? Will they really go and look out for Syrian cheeses in order to improve that article? Will they scan the Chess article to see where they can potentially improve the grammar? Sorry for the snarky tone, but I feel a lot of effort is going into a white elephant initiative. Khuft (talk) 16:17, 4 July 2026 (UTC)reply
The selection isn't Special:Random, there's criteria given in the second sentence of the RfC, one of which is that pages cannot be "non-ideal for new editors". One way an article for improvement could help attract new editors is by making them personally aware that they can edit (not everyone is aware of this) and that we actively want them to edit (ditto), and then providing them with an immediate place to try editing (with suggestions and help).
We can and should try multiple ways to bolster editorship. I don't see why trying social media outreach (not really something we can handle on our own, though the WMF does do some, did you know there's a Wikipedia roblox game?) would mean we can't also try TWAFI.
As for retention vs onboarding, I believe that an accessible, positive, and structured first edit experience, as this proposal aims to provide, would lead to more new editors who also stick around longer. fifteen thousand two hundred twenty four (talk) 17:08, 4 July 2026 (UTC)reply
I say new editors. With all the articles selected, there's eventually bound to be one whom someone's interested enough to take a look at and see how they could improve. The main page has extremely more page views than we have editors, (is generally not scraped by LLMs due to its lack of information,) and an appearance on the main page tends to attract improvement even by new editors.

Wouldn't it make more sense, as I mentioned above, to reach out to younger, potential editors via e.g. social media?

Is this proposal preventing that? In solidarity, Aaron Liu (talk) 17:17, 4 July 2026 (UTC)reply
I wrote most of that preamble. I don't appreciate having my efforts characterized as being a false premise (AGF?), regardless, the preamble is what opens and defines the RFC, This is a proposal to ..., and is binding. If you're curious why it's worded how it is see this thread. fifteen thousand two hundred twenty four (talk) 16:22, 4 July 2026 (UTC)reply
It is not compliant with WP:RFCBRIEF or WP:RFCNEUTRAL. The final question is simple and clear but the preamble isn't and so shouldn't be there. Andrew🐉(talk) 17:23, 4 July 2026 (UTC)reply
Both those link to the same place. If you believe the RFC is procedurally unsound (though you appear to be alone in this assessment thus far), then feel free to move for a procedural close. fifteen thousand two hundred twenty four (talk) 17:28, 4 July 2026 (UTC)reply
I've re-read the opening statement and I entirely fail to see what you could mean in saying that it isn't brief and neutral. The preamble briefly states the goal of the proposal, without making any claim as to whether or not it will be achieved, and other than that only contains information about what an affirmative consensus would actually entail.
I check every RfCs opened, in part to check if their opening statements are compliant and suggest fixes they aren't, and this one is better than the vast majority of them. –Maltazarian ᚾparleyinvestigateᛅ 21:11, 4 July 2026 (UTC)reply
Yeah, I think this RFC is fine too. And I'm saying that as somebody who isn't on board with the entire idea, either. (Just saying, I found being pointed to stuff like TWAFI rather demoralizing when I was getting into editing: I didn't know where to start, the topics often weren't of any interest to me, and I didn't know where to start with finding sources. Being told "this is a good place to start" and then failing just made me feel inadequate. But I'm not the only editor, and others seem to see something in this, so I wish them nothing but luck.) GreenLipstickLesbian💌🧸 21:23, 4 July 2026 (UTC)reply
Yeah, it's fair to say this won't work for everyone. I personally found the similar WP:Task Center very useful when I started, and used it often. My biggest issue was that I would get no feedback if what I was doing was "correct." That's why I supported this proposal, as kind of an extension of that. InfernoHues (talk) 21:28, 4 July 2026 (UTC)reply
Yeah, i definitely feel that lack of feedback thing. I know was really lucky to run into the Women in Red project several years ago; a bunch of enthusiastic editors willing to help out but also let me make mistakes, is something I wish I could give to all editors. That and their monthly editing drives/newsletters I was subscribed to still keep me going. GreenLipstickLesbian💌🧸 05:40, 5 July 2026 (UTC)reply
@Andrew Davidson, please don't be condescending. In my opinion, it's precisely the opinions of newer editors that matter more when we're talking about efforts to create new editors. In solidarity, asilvering (talk) 20:29, 4 July 2026 (UTC)reply
I have them a level one warning. See it on their talk page. Please tell me if this is appropriate. Ilov3gam3z (talk) 23:13, 4 July 2026 (UTC)reply
As for my reasoning, among other things, the '2 months old comment' seems to me to be a direct violation of WP:NPA. Ilov3gam3z (talk) 23:15, 4 July 2026 (UTC)reply
  • A, M2>M3>M1 and P2>P3>P1. I'd also be fine with the alternate suggestions of placing it below DYK or in a box above TFP, but I don't like the idea of placing it above DYK. I agree with TarnishedPath and with some of the opposers that the weekly cycle is not ideal, so I think moving to a "Today's article for improvement" is worth considering as a next step once things are running smoothly if this is implemented. MCE89 (talk) 18:37, 4 July 2026 (UTC)reply
  • A, but oppose all of P.1, P.2, P.3 I think this is a good idea in order to draw in new editors. However, more important to me is that the four mainstays of the Main Page (TFA, ITN, DYK, OTD) should stay in place. If I had to pick one of those for TWAFI to displace, it'd be DYK (in other words P.1 is the least bad of the three options), but honestly I still prefer DYK for that space over TWAFI. I like Godsy's P.4 and MidnightMayhem's P.5. No preference among the mockups M.1, M.2, M.3. Davey2116 (talk) 07:15, 5 July 2026 (UTC)reply
  • A. Per it being a good idea. jp×g🗯️ 07:49, 5 July 2026 (UTC)reply
    @JPxG do you have any mockup and positioning preferences? fifteen thousand two hundred twenty four (talk) 08:58, 5 July 2026 (UTC)reply
  • A: I've read through every oppose argument and did not find any to be compelling. I'm not sure why people are making a big deal about whether this is aimed at editor recruitment or editor retention; regardless of what effect it has on those this will make AFI a more useful place. (At the minute it seems to be largely ineffective.) Also support keeping the article for improvement on the main page for a full week as one day is not enough for significant change. No opinion on placement. Stockhausenfan (talk) 11:09, 5 July 2026 (UTC)reply
  • B (Oppose) as impractical; realistically what I foresee will happen is that the suggested article would become a magnet for vandalism and consequently be semi-protected, defeating the purpose of this project. And anecdotally very few "new" editors make talk-page edit requests. I would be fine with a trial lasting, say, two-three months to gauge the editing patterns induced by this project though. JavaHurricane 14:57, 5 July 2026 (UTC)reply
    There should probably be a stipulation in this proposal once implemented that articles chosen must not be protected and can't be for the week of. Ilov3gam3z (talk) 15:04, 5 July 2026 (UTC)reply
    That's even more impractical. JavaHurricane 07:11, 6 July 2026 (UTC)reply
    That's what they said about an encyclopedia anyone can edit. "It'll just be vandalism." Turned out not to be true. Levivich (talk) 15:06, 5 July 2026 (UTC)reply
    I wonder why we protect the TFA preemptively nowadays, then. Or why DYKs regularly and quickly make their way to RFPP. JavaHurricane 07:08, 6 July 2026 (UTC)reply
    Because men have forgotten God. jp×g🗯️ 20:00, 7 July 2026 (UTC)reply
    What? FaviFake (talk) 21:41, 7 July 2026 (UTC)reply
    ??? Ilov3gam3z (talk) 21:57, 7 July 2026 (UTC)reply
    Pretty sure they mean that highly productive editors (men) have forgotten god (the necessity of privileging newbies for the project's sustainability) Kowal2701 (talk, contribs) 22:20, 7 July 2026 (UTC)reply
    I think this is a joke—an incredibly funny one which we should enjoy at that, in fact.
    (If we're opting for serious interpretations of something biblical, I can equally-validly interpret it as "people (anonymous and new editors) have forgotten how to have good things (biblically, God)". I envision some prosperous years of religious sect-building and excommunications over this.) In solidarity, Aaron Liu (talk) 00:57, 8 July 2026 (UTC)reply
  • A, M1, P2 - M1 seems to best match the rest of the main page, and I like the placement of P2: the juxtaposition between TFA and an article needing improvement encapsulates the idea of Wikipedia quite nicely: what articles start as, and what they can become. I'd support A with any of the other M's or P's as well. If we want a human written encyclopedia, we're gonna need humans to write it, and this seems like a good idea to try to increase recruitment. Let's see if it makes a difference. Levivich (talk) 15:10, 5 July 2026 (UTC)reply
  • A I was summoned so I'll offer my opinion. I do still think that AFI and Vital articles could be merged, and unfortunately have not gotten enough momentum between the projects to actually get anything definitive. If we're making changes, would want to toss that discussion in to see if anyone else is interested in such a merge. GeogSage (⚔Chat?⚔) 20:39, 5 July 2026 (UTC)reply
  • A – P2 – This is an excellent idea that really shows what Wikipedia is about. I am fully in favor of showing the website as an ever-improving and ever-evolving reference work. ~Maplestrip/Mable (chat) 07:56, 6 July 2026 (UTC)reply
  • A. M2 > M1 > M3 but all mockups are acceptable to me. Location wise, I like both P3 or full-width box somewhere below the two columns bit but I would accept any location. I suggest trying it out to see how it goes, and then see if a week is too long for one article.
I found the Article for Improvement extremely compelling when I was a new editor first learning the ropes, and I think we should make it as easy as possible for people to find these kinds of high-quality on-ramps to editing. I expect having it on the main page would also bring me back to looking in on the articles, especially to make sure all was going well with the newcomers. I think experienced editors are perfectly capable of curating appropriate article choices for the main page, i.e., articles with low-stakes and approachable flaws. ~ le 🌸 valyn (talk) 22:33, 6 July 2026 (UTC)reply
  • A, M3 > M2 > M1. Though, I would prefer if this were to be daily and for multiple articles to be improved. I have no opinion on the positioning. Beta Beta Beta - talk 01:25, 7 July 2026 (UTC)reply
  • A, M3 > M2 > M1, M3 > M1 > M2 if the "How to contribute" box in M1 isn't collapsed by default. And I think TWAFI should come before all other boxes, i.e. be in the following position:
    TWAFI
    TFA
    DYK
    ITN
    OTD
    sapphaline (talk) 09:17, 7 July 2026 (UTC)reply
    What do you think of my mockup? In solidarity, Aaron Liu (talk) 21:41, 7 July 2026 (UTC)reply
    I agree with all your points, but I think placing it below DYK and OTD would be better since we still want to highlight the featured articles and all the other content above. Atakes Ris (talk) 10:56, 10 July 2026 (UTC)reply
  • A M1, M2, M3 this seems like a really good idea, i think TWAFI should go at the bottom of the right hand side or below the news. Jabba550  | ✉ in solidarity 12:32, 7 July 2026 (UTC)reply
  • B. If done anyway, oppose all of P1, P2, and P3, and suggest a P4 instead that pushes this feature down beneath OTD. First of all let me say that I love calls to action, and I think that encouraging people to consider becoming editors is important. In fact, this kind of collaboration is great. However, this is too wide a collaboration. A successful collaboration is like... 10 people in a classroom or a Discord channel. Opening up a collaboration to a zillion contributors is a formula for heartbreak if the goal is any improvement more than skin-deep. We want a welcoming newbie experience, yes, but a newbie experience that involves being reverted or heavily rewritten by random other people aren't it. And heck, even in the case of just ~10 contributors, there's always the risk that two editors take time to work on the article and seriously research it, but go different directions. And then a drive-by collaborator just stops in long enough to make unneeded style edits to annoy them. This problem is much worse with a Wikipedia-wide invitation. So yes to today's article for improvement for WikiProjects or subreddits or Discord channels, no to the main page. SnowFire (talk) 22:49, 10 July 2026 (UTC)reply
  • A. I don't care exactly how it's done, but this is something we should do. Attracting new editors is crucial, and I'll take any plausible idea for it. Toadspike [Talk] 22:09, 11 July 2026 (UTC)reply
  • A, M3>2>1, P2>3>1. I also agree that the contrast between the FA and TWAFI is clearer when they are placed side-by-side, and the second and third mockups are more encouraging to new editors. I also suspect there are a reasonable nember of semi-experienced editors who don't know about AfI, and introducing them to the process could counter the unconstructive edits by newcomers. Somepinkdude (talk | contribs), in solidarity 16:25, 12 July 2026 (UTC)reply
  • A, M2>3>1, strongly prefer P2 - This seems like a no-brainer way to improve the Main Page. I do feel like the concerns about too many editors on one article are valid, but I think that it is more important that we encourage editing and I think AFI needs the support. Regarding the placement, if we do end up doing this it'd be best to have it at the top to contrast with TFA. Eman7blue42 (talk page | recent edits) 22:56, 12 July 2026 (UTC)reply
  • B The more I think about it, the more I'm convinced that this will quickly become "This Week's Vandalized Article", especially if the proposals to prohibit protecting the page go through. It would be the only page prominently linked to from that main page that isn't protected, and will require constant and vigilant oversight from RC patrollers and admins. The only way I could see this working is if we didn't actually link to the page, but instead had a message similar to M2 without the link to the page and that, instead of "Click here to start editing", had a link to Click here to view this and other articles in need of improvement! that links to Wikipedia:Articles for improvement/Articles. --Ahecht (TALK
    PAGE    )     17:26, 16 July 2026 (UTC)reply
    Ahecht, am I missing something? Currently, only the featured article is protected out of the boldlinks on the main page. InfernoHues (talk) 19:24, 16 July 2026 (UTC)reply
    I'm not referring to boldlinks, I'm referring to items that have an entire box devoted to them, namely the Featured Article and Featured Picture. --Ahecht (TALK
    PAGE    )     20:29, 16 July 2026 (UTC)reply
    The featured picture isn't protected. InfernoHues (talk) 21:10, 16 July 2026 (UTC)reply
  • B & none of the placement options. If this does pass it should be below the other content, in the same slot as TFL, and limited to one day per week. This idea does not showcase quality encyclopaedia content, quite the opposite - it's specifically picking a bad article that needs work. The Main Page is supposed to present material that demonstrates the value of Wikipedia and is useful to readers, not content for editors or designed to recruit new ones. Bold links from the Main Page are held to minimum standards of quality, by all existing sections, which this wouldn't meet. I have no objection to TWAFI existing, or being advertised to existing editors, but I don't think it should be on the Main Page or otherwise advertised to readers. Modest Genius talk 19:04, 16 July 2026 (UTC)reply
    The main idea of having this is by having an article that demonstrates the point about the free encyclopaedia that anyone can edit (see the initial workshopping/RFCBEFORE). I don't think the main page was ever intended to always show articles with quality content, otherwise having DYK for new articles and "other areas of Wikipedia" would not have existed. Even if it is, remember, consensus can change, and most people in this discussion say this is probably the best way to bring in editors.
    Although, I do agree that this feature could be "advertised" to current editors, probably through Special:Homepage, though that might mean a lower success rate. Hason-LEK-SIN ● Let’s chat! ● My contribs 23:01, 16 July 2026 (UTC)reply
I don't know if DYK is necessarily "high quality content", but they do have minimum quality standards and a "presentability" standard, which TWAFI is the opposite of. Natg 19 (talk) 00:49, 17 July 2026 (UTC)reply
To add to Hanson's comment, looking at the Main Page, there's tons of free, encyclopedic content, but editing only gets three mentions: the tagline and two boldlinks way down at the bottom. To use a metaphor, if I had a book that was half about cheese and half about bread, I would want to place both on the cover. The Main Page feels like a cover of pure bread. 7amiþ reform · 💬 · 📊 00:52, 17 July 2026 (UTC)reply
Why don't we just add a huge EDIT NOW! button or something to the "Welcome to Wikipedia" banner on the MP? (Or redesign that banner in general?) It'll probably attract more editors than the TWAFI template. Some1 (talk) 01:02, 17 July 2026 (UTC)reply
Sure, that'd work nicely. (TBH I sww TWAfI as a huge EDIT NOW box, but also trying to answer the follow-up: "Edit... what?") 7amiþ reform · 💬 · 📊 01:17, 17 July 2026 (UTC)reply
But you wouldn't want a book about cheese to have a cover that's half cheese, and half how to write & print a book. The behind the scenes stuff should remain there. The vast majority of our readers already know that they can edit articles - it's already stated right at the top of the Main Page - they just choose not to. Modest Genius talk 10:19, 17 July 2026 (UTC)reply
Surveys indicate that, while most readers know that they can they edit, few of them do so and there are three main reasons for this:
  1. Lack of expertise
  2. Satisfaction with the existing content
  3. Fear of rejection
The first two are fine as we don't want change for change's sake by clueless newbies. But we could do more to make everyone feel welcome and suggest some low-hanging fruit for them to pick in a safe way.
The best example I've seen lately is the Suggested edits feature which has been offered to me in the app. These are carefully tailored to be specific and suitable for newbies. They will scale well for our millions of readers and so will build confidence without clashes. We should try to put such a personalised feature on the main page near the "anyone can edit" intro. Andrew🐉(talk) 11:12, 17 July 2026 (UTC)reply
( peanut gallery comment) Fear of rejection basically summarizes half of my work here: edit/comment, then wait around for someone to tell me how wrong I am. No matter what ends up getting approved, I believe it MUST help editor confidence. 7amiþ reform · 💬 · 📊 01:42, 18 July 2026 (UTC)reply
  • B There are already tens of articles across a wide range of interests linked on the main page every day that could be edited and improved by anyone who cares to, rather than choosing one by committee that will likely interest a tiny fraction. Stephen 00:41, 17 July 2026 (UTC)reply
    From Bremps, the proposer (here): First, the selection will be done by RNG, as it is currently. This sounds jarring to anyone who participates in ITN or DYK, but I believe this is the best method. No one gets to play favorites or horse-trade support votes. I believe that otherwise, this will be a major issue as everyone tries to get their pet article in the line for improvement. 7amiþ reform · 💬 · 📊 00:55, 17 July 2026 (UTC)reply
    That comment sorta confused me when I first read it. Almost all ITN posts comes in RDs, which doesn't have any horse-trading or favorites, and ITN noms are a whole process that also almost never has anyone playing favorite or horse-trading (the only possible favorites that occur is with the US and UK, which are pretty wide scopes). DYKs and RDs can be almost anything, if RD the person just has to have died and not be a stub and the DYK just has to be recently improved and not a stub (interestingness is a very low bar). I think OTD, TFA, and TFP all have much better arguments as occurring via horse trading and favorites, but I still wouldn't really say so. 1brianm7 (talk) 02:48, 17 July 2026 (UTC)reply
    The RfC text does not say that articles will be chosen randomly, though that was in the original proposal. InfernoHues (talk) 02:50, 17 July 2026 (UTC)reply
    sorry. What I meant to say was more like "it would be preferable for TWAfI to be randomly generated, here's Bremps's reason [insert here]" 7amiþ reform · 💬 · 📊 02:53, 17 July 2026 (UTC)reply
    The Article for Improvement is already an ongoing practice. The RfC is about if it should be put on the main page or not. --I sometimes eat bananas, and you can talk to me here: (talk) 17:35, 20 July 2026 (UTC)reply
  • B As an idea to attract and engage new editors, I think this is a well-intentioned but flawed idea. You're asking them to go from front page to problematic article to somehow discerning what is currently wrong with it editing it to producing an end result that is better and conforms to all Wikipedia policies and practices. I think that's a recipe for disaster, both in terms of the damage done to articles that already need improvement and the discouragement of new editors who feel slapped down as soon as they try to answer a call for help. Note that some of those "articles for improvement" are already B-class. The improvements they need are likely to be beyond the scope of an untrained beginner. I think it would be more useful to have a section explicitly calling for new editors and showing them the first steps they should take in order to become editors here, The Wikipedia Adventure for example, and from there to editing a subject that interests them and which they know about, rather than whatever random article "needs improvement" today Chuntuk (talk) 14:37, 28 July 2026 (UTC)reply
    M1 and M3 both have a list of things that need to be improved in the article, and if any editor needs more specific instructions, they could ask the volunteers who promised to be there (see replies). Also, I personally support making TwAfI C-class or lower. 7amiþ reform · 💬 · 📊 15:27, 28 July 2026 (UTC)reply
    If I'm a new editor, how do I know where to get help? If you're one of the volunteers, how do you know I need it? Chuntuk (talk) 19:22, 28 July 2026 (UTC)reply
    how do I know where to get help? – You will notice that all three mockups state that questions can be asked either at the teahouse or the talk page, with links. Additionally the RFC states Guidance and suggestions will also be given when editing via an edit notice, how to get help falls under guidance.
    how do you know I need it? – Volunteers will be monitoring and evaluating edits to the article and its talk page. The Teahouse is already monitored by volunteers assisting newcomers. fifteen thousand two hundred twenty four (talk) 19:49, 28 July 2026 (UTC)reply
    The issue about B-class articles has been addressed in the discussion section with the proposal to limit AfI to C-class or below. Stockhausenfan (talk) 13:21, 29 July 2026 (UTC)reply
  • B; I admire the intention behind this idea in regards to attracting new editors but I just don’t see it being that effective. People without edting experience aren’t going to decide to randomly edit a topic they may have no interest in; since they don’t have Wikipedia-editor-brain yet they will be less likely to notice things they want to change in the article. Even if they do, there’s no guarantee that the edits they’ll make won’t simply be reverted due to their lack of experience, potentially putting them off editing for good. Mir Novov (contribs | talk) 15:57, 28 July 2026 (UTC)reply
  • A There are many bad articles that could use cleanup. This would be a great way to get them fixed. NewAccount7295 (talk) 19:04, 31 July 2026 (UTC)reply
    @NewAccount7295, any !vote on the placement and preferred templates? 7amiþ reform · 💬 · 📊 04:44, 1 August 2026 (UTC)reply
    P3>P1>P2 (I especially dislike P2); and M3/M2>M1 since it is important to tell the reader how they can improve the article, not just that they can. M3 is probably the best of those since it is the most descriptive of how. I personally think that none of the placements look amazing since they leave a gap but it is worth getting bad articles improved. NewAccount7295 (talk) 15:44, 1 August 2026 (UTC)reply
    Another option would be to place it horizontally above or under Today's Featured Picture. (Even some of those opposing this have suggested that could still work) The only issue with that is that not as many people might scroll down, and it could have less impact as a result. However, we should not let the debate about how to place this get in the way of the fact that this needs to be added to the Main Page as the benefits to adding it, described by other people in this discussion, outweigh any negatives in my opinion. NewAccount7295 (talk) 16:29, 1 August 2026 (UTC)reply
  • A, placed below DYK: I believe that it is important to make potenial editors see not only what has been done, but also what there still is to do. That said, Wikipedia has a purpose of being an online encyclopedia first, and providing such information is what people come to see. I'd prefer to avoid allowing improving the encyclopedia to get in the way of being one, and pushing encyclopedia content further down the page could get in the way. Mitchsavl (talk) 04:38, 1 August 2026 (UTC)reply

Discussion (TWAFI)

As a side note, why was the Chicago Bulls nominated for TWAFI? It had a B grade, which isn't usual for TWAFI. While "researching" for this comment, I found the nomination of the Bulls, which mentioned that it isn't really deserving the B due to the multiple missing citations. And truth to be told, they were right: using the VE editing suggestions feature, the Bulls article had 31 editing suggestions, compared to 8 from the Lakers, 20 from the Celtics, 21 from the Spurs, and 29 from the *deep breaths* Knicks. What!? Huh!? The Knicks have almost the same number of uncited statements as the Bulls!?
Oh, and these numbers are after I have gone ahead and removed duplicated wikilinks the system suggested, by myself, leaving only "Add a citation" suggestions. Okay yeah, I see why that article was nominated for TWAFI.
Please save my brain, I've been watching too much NBA content than what is considered healthy... Hason-LEK-SIN ● Let’s chat! ● My contribs 14:28, 19 July 2026 (UTC)reply
In my experience working in the GOCE, they are less concerned with improving articles in the sense of "adding missing information and expanding", more "making articles more clear and clarifying issues with the existing text". -- Reconrabbit (talk) 16:16, 19 July 2026 (UTC)reply
Noted, checks out. Hason-LEK-SIN ● Let’s chat! ● My contribs 22:54, 19 July 2026 (UTC)reply
  • Perhaps we could choose two seperate AfIs, and the one on the main page is C-class or lower? Perhaps we could even require all AfIs to be below B-class. This way, most good-faith, competent edits won't reduce the value of its content, and it's easier for newcomers to add information to an article with major gaps. Somepinkdude (talk | contribs), in solidarity — Preceding undated comment added 18:04, 26 July 2026 (UTC)reply
I strongly support making TWAfI below B-class (C, Start, or Stub). SPD nicely summarized my rationale. 7amiþ reform · 💬 · 📊 05:11, 27 July 2026 (UTC)reply
Yes the argument for this is strong. Stockhausenfan (talk) 15:13, 27 July 2026 (UTC)reply

Should we disallow opening parallel RM and AfD discussions?

Right now, nothing stops someone from opening a requested move on an article's title while an AfD discussion about that same article is still running, and vice versa. In the case of Robinson list, for example, we ended up with four separate discussions about basically the same question. (See Special:Permalink/1362924519 and Special:Permalink/1362895939.) Since the creation of parallel RMs and AfDs happens relatively frequently, I'm thinking this could be solved with a simple rule: if an article already has an open AfD, no new RM should be started on it until that AfD closes, and, vice versa, if an article already has an open RM, no new AfD should be started on it until the RM closes. If any RM or AfD is started, they can be procedurally closed.

Having an RM and an AfD about the same article creates a risk of contradictory outcomes: an AfD could close one way and a concurrent RM could point the other way. What's the point of discussing the name of an article if the article might not exist in a week? An AfD that's considering a merge is, for example, is effectively already a discussion about scope and naming. The proposed rule wouldn't stop anyone from raising the naming or merge question, it would just mean raising it in the existing discussion, or starting a new one after the old one ended, which usually happens in a week. If someone thinks the AfD is heading the wrong way, or thinks a merge target's name is wrong, they should post a comment in the open discussion. This is already covered in part by WP:AFD4: If an AfD discussion is already open but you would like to propose an alternative target or outcome (e.g., merge the article instead of deleting it), do not create a second nomination. Instead, consider contributing to the open discussion.

I'm not sure if there could be edge cases where this wouldn't work well, this is just the first solution that came to mind. What do you think? FaviFake (talk) 10:51, 7 July 2026 (UTC)reply

Courtesy pings: Paditor, Nathannah, Kirbylegal, Spartaz, Elemimele, Wcquidditch, Pburka, BarrelProof, Jruderman, GrinningIodize, Thincat, SchreiberBike as participants in the discussions I cited. Notified: Wikipedia talk:Articles for deletion, Wikipedia talk:Merging, Wikipedia talk:Deletion process, Wikipedia talk:Speedy keep and Wikipedia talk:Requested moves. FaviFake (talk) 10:58, 7 July 2026 (UTC)reply
This just seems like common sense to me. Mangoe (talk) 11:10, 7 July 2026 (UTC)reply
It's not common sense to everyone. Even despite the fact that I only monitor the merge nominations at AfD, I see editors opening a RM during an AfD about once a week. Having a clear rule that allows the newer discussion to be procedurally closed would help immensely. FaviFake (talk) 12:12, 7 July 2026 (UTC)reply
I meant that it is common sense to shut down parallel discussions in general. Of course people start them, because people tend to focus on their present concerns and try to deal with them immediately. Mangoe (talk) 12:32, 8 July 2026 (UTC)reply
I've addressed this in my comment below. FaviFake (talk) 13:25, 8 July 2026 (UTC)reply
(edit conflict) Parallel discussions are pretty much never a good idea, so I'd support something like this. All that needs to happen is for one of the discussions to be procedurally closed in favour of the other. Which discussion should be closed will depend on the circumstances, but obviously if the outcome of one depends on or could be impacted by the outcome of the other the dependent one should be closed. For example we will normally procedurally close an RfD if there is an ongoing AfD, RM or merge discussion about the target page. Thryduulf (talk) 11:11, 7 July 2026 (UTC)reply
(edit conflict) I don't see anything wrong with having a discussion about deletion that starts after an RM is opened. When someone comments in an RM discussion that a topic is not notable so an article should be deleted, it is commonly replied that the RM is about what the title(s) should be, not whether the articles should exist. And if we have a poorly named article that might not be appropriate as an article at all, both issues should be discussed and resolved, although different questions arise in those discussions. When there are multiple different RMs open for the same article at the same time, it is common for all but one of them to be procedurally closed. It is often agreed to wait for a deletion discussion to close before trying to close a parallel RM. —⁠ ⁠BarrelProof (talk) 11:15, 7 July 2026 (UTC)reply
Sorry @FaviFake I was unaware of that. I am a reletively new editor on here but have it noted for future. Thinking about it in hindsight (of which we all know is 20/20). I would support this proposal. Kirbylegal (talk) 14:21, 7 July 2026 (UTC)reply
Surprised this is common. It makes no sense to open an RM for an article at AfD, there are multiple AfD outcomes that could render an RM moot. This reasoning would not apply in the other direction though, and making it automatic for an RM to close upon an AfD feels like it opens a potential avenue to disrupt RMs. CMD (talk) 14:25, 7 July 2026 (UTC)reply
Yup, unfortunately it is relatively common. Another example I can think of off the top of my head would be The Eagle (gay bars), where at one point there were seven parallel discussions about the article, including a RM opened 2 days after the previous six discussions were opened. In cases like this, a rule allowing the new RM to be procedurally closed would at least help with the mess.
Maybe opening an AfD during a RM could be allowed only in urgent cases, such as current event or severe policy violations? FaviFake (talk) 14:37, 7 July 2026 (UTC)reply
What's an "urgent" AfD? — Very Polite Person (talk/contribs) 14:48, 7 July 2026 (UTC)reply
Something that technically doesn't fit any of the narrow WP:CSD criteria, but really needs to not be here. You could IAR delete it if it's that urgent, but establishing consensus properly is rarely a bad thing. SarekOfVulcan (talk) 19:21, 7 July 2026 (UTC)reply
@Chipmunkdavis, I'm not surprised that this is common. Merge discussions were only merged into AFD a few months ago. It usually takes people a couple of years to adjust to a significant process change. WhatamIdoing (talk) 04:52, 17 July 2026 (UTC)reply
To the extent that would have made a different to the cases mentioned it should be a slight improvement, an RM should not be opened for an article with an AfD discussion whether or not AfD includes the merge process. CMD (talk) 05:02, 17 July 2026 (UTC)reply
I tend to agree, but then I'm obviously comfortable !voting to merge at AFD, since I do that at a rate approximately three to four times as often as that's been an AFD result (~25% for me vs ~7% for AFD before RM was folded into it). WhatamIdoing (talk) 05:13, 17 July 2026 (UTC)reply
Agreed that is an AfD is open a Requested Move or ideally any heavy maintenance tagging on the article should be blocked - not "may", "should", or "could". Once something is a LIVE afd page, "standing down" shouldn't be a could-be or may-be, but an automatic "no".
What about if a Requested Move is active/already there (even by minutes) and someone else tossed up the AfD?
I do not support the idea that either has primacy by whatever arbitrary letters present in the URL or surrounding project page history/legacies.
I don't know the best answer but this FEELS like a rare binary we have the opportunity to streamline/summarily pre-murder shenanigans and drama.
  • If AfD live = no +RM added allowed binary rule, you don't get to start a new RM, and everyone will revert you freely till you're spitting mad if needed.
^ no brainer, easy slam dunk fix.
  • If RM live = we can't say you CAN'T afd newly, but then what?
^ not a no-brainer? — Very Polite Person (talk/contribs) 14:41, 7 July 2026 (UTC)reply
@FaviFake, thank you for bringing this to my attention. I would support a rule that restricts RMs during AfDs as you've described. I apologize for opening a second AfD discussion for Robinson list, as I was not aware of Wikipedia:AFD4 at the time. GrinningIodize (talk) 15:08, 7 July 2026 (UTC)reply
No worries! As I said in my comments above, the problem is widespread so I just picked that discussion as an example! FaviFake (talk) 15:10, 7 July 2026 (UTC)reply
The order of operations matters some. If the AFD is posted first, an RM discussion that will be rendered moot by deletion or merger is a waste of the community's time. AFDs often generate article improvements and sometimes substantial changes to article content and sourcing that may be relevant to the RM so even when the article is kept, letting the AFD play out before starting an RM is sensible. If the RM starts first, it's not necessarily a waste of time to start an AFD, although my preference is always to wait. —Myceteae‍🍄‍🟫 (talk) 15:20, 7 July 2026 (UTC)reply
I mostly agree, but how can we turn the last part into a more rigid rule? Just saying it is not recommended won't help solve the problem. There's definitely no reason to hurry if the article has low page views, but I can see why an AfD could be started parallel to a RM if the article is about a current, rapidly evolving event. In some cases, I can see why it might be best not to wait for a RM to fully close before starting an AfD, but for more low-stakes articles people should just wait. What concrete criteria should an article satisfy to be eligible for being nominated at AfD and RM concurrently? FaviFake (talk) 17:17, 7 July 2026 (UTC)reply
I'm not sure we should have a firm prohibition on starting AFDs after RMs because I'm not sure what the criteria would be. I'm more inclined to support procedurally closing all RMs that start during an active AFD. It seems like this is the actual locus of the problem, anyway. I'm far more active on RM than AFD and I rarely see this. —Myceteae‍🍄‍🟫 (talk) 18:00, 7 July 2026 (UTC)reply
I don't think it's necessary to have a policy. I have already seen people procedurally close either an AfD or RM because a parallel discussion is ongoing. I trust our closers to exercise common sense. Katzrockso (talk) 18:10, 7 July 2026 (UTC)reply
I often refrain from closing RMs about the same article because I'm usually involved and it could be argued the closure wouldn't qualify as WP:MULTI. I'd like there to be a clear rule that allows me to close these RMs even in borderline cases. FaviFake (talk) 18:21, 7 July 2026 (UTC)reply
I thought about WP:MULTI but I'm not sure it applies, anyway, since these discussions address fundamentally different questions, although of course the issues often overlap. Is this only an issue with merge proposals at AFD, and has the problem increased since the PAM–AFD merger? The scope and content issues effecting mergers have more overlap with article title considerations than GNG, copyvio, etc. issues that inspire article deletion nominations, so I could see how this happens. —Myceteae‍🍄‍🟫 (talk) 18:32, 7 July 2026 (UTC)reply
Yeah, that's what makes me uncomfortable with closing these RMs procedurally. About the problem increasing: I don't know, I've only started to monitor merge nominations and AfD more generally only after PAM was wound down. FaviFake (talk) 19:08, 7 July 2026 (UTC)reply
Given that an AfD can result in a keep and move the page result, I would support procedurally closing RMs opened during an active AfD discussion. It's already an accepted practice in WP:RMEC; Furthermore, any editor may end such a move request with a procedural close: to centralize related discussions that should have been a multi-page discussion.
Do we need anything further than that? Perhaps slightly clarifying that sentence to explicitly include AfD Katzrockso (talk) 19:16, 7 July 2026 (UTC)reply
to centralize related discussions that should have been a multi-page discussion does not cover these situations, except perhaps those involving the Eagle gay bars, which was an extreme example of extraneous and unnecessary discussions. I read that part of the guidance as applying to a situation where a bunch of similar move requests on different pages are closed procedurally to consolidate what should have been a a single proposal for multiple moves conducted on a single page. —Myceteae‍🍄‍🟫 (talk) 19:30, 7 July 2026 (UTC)reply
I can see how someone might read it that way. I wouldn't oppose a new short bullet point adding "when the article is already at Wikipedia:Articles for deletion" to that section of WP:RMEC. Katzrockso (talk) 23:14, 7 July 2026 (UTC)reply
I'm leaning towards supporting this. It's a pretty substantial change to the RM closing instructions so hopefully more editors will weigh in. —Myceteae‍🍄‍🟫 (talk) 01:37, 8 July 2026 (UTC)reply
There needs to be an allowance for situations such as where the AfD has an apparent consensus that RM is the better course of action and an RM is opened before the AfD is formally closed. In cases like that the RM should stand and the AfD closed. It's probably less common than inappropriate RMs while an article is at AfD but less common is not never. Thryduulf (talk) 02:09, 8 July 2026 (UTC)reply
That's a fair point. We can add a footnote to accommodate this situation. Katzrockso (talk) 03:58, 8 July 2026 (UTC)reply
That would still be allowed. As long as there aren't any open AfD discussions about an article, editors can open new RMs. FaviFake (talk) 09:08, 8 July 2026 (UTC)reply
@FaviFake I think you missed the point that it should be allowed to open an RM when there is an open AfD in a few limited circumstances. Thryduulf (talk) 09:22, 8 July 2026 (UTC)reply
I must've missed it; where was that suggested? I thought that exception only applied to opening an AfD when there is an open RM, not vice versa. FaviFake (talk) 09:25, 8 July 2026 (UTC)reply
I suggested it, and explained the rationale for it, in the comment you replied to. Thryduulf (talk) 09:34, 8 July 2026 (UTC)reply
Well, not really. A RM should never be opened if there is an ongoing AfD, but in case it is opened before the AfD is closed, the latter should be closed rather than the former. I don't think we should allow open[ing] an RM when there is an open AfD in a few limited circumstances. We can simply say that, in case someone incorrectly opens a RM during an AfD, in some cases it might be best to fix the issue by closing the AfD rather than the RM. FaviFake (talk) 09:43, 8 July 2026 (UTC)reply
The point is that in the situation I described, opening the RM isn't incorrect. Thryduulf (talk) 10:12, 8 July 2026 (UTC)reply
@FaviFake, I think I've missed something important. Here, you say "As long as there aren't any open AfD discussions about an article, editors can open new RMs". However, in practice, when editors do that, you unilaterally turn their RMs into AFDs (examples: [22] [23] [24] [25]), and just the other week, you were telling me that all RMs have to happen at AFD.
Do you possibly mean something like "Unless editors who want to talk about a merge use at least one template, tag, notification, category, or take some other other noticeable/monitorable actions, then I guess we won't be able to notice every single discussion about merging articles, but whenever I do notice it, I'll do my best to force that discussion to happen at AFD"? Because I think that other people have a different idea of what it means to "open a new RM". WhatamIdoing (talk) 05:08, 17 July 2026 (UTC)reply
I believe you are conflating RM and PAM. I've never moved a RM discussion to AfD, and I only move formal PAM proposals, not all merge discussions. If a merge proposal does not use the formal {{PAM templates}}, then it's a simple talk page discussion and shouldn't be moved, as I've explained on my talk page. FaviFake (talk) 11:51, 17 July 2026 (UTC)reply
Yes, you're right. I was thinking about WP:PM instead of WP:RM. WhatamIdoing (talk) 21:17, 17 July 2026 (UTC)reply
I'm not an expert on Wikipedia procedures but it seems like if consensus has been reached, by definition the AfD is complete and should be closed—in other words, an editor shouldn't rely on consensus to start the RM unless they're also closing the AfD as having reached consensus. That said I think this addition would be essentially harmless, and I'd support the change with or without it. Elliptical Reasoning (talk) 18:17, 17 July 2026 (UTC)reply
OK, figured out where my non-expertise came in, I hadn't realized those things had different privilege requirements. Disregard the objection above. Elliptical Reasoning (talk) 18:32, 17 July 2026 (UTC)reply
(in reply to this comment) If there is enough consensus at AfD, it should be closed first, otherwise we'd go back to having two parallel discussions. The AfD needs to be closed first, otherwise it will continue to attract editors and it will likely become harder to close it over time. FaviFake (talk) 10:15, 8 July 2026 (UTC)reply
Generally yes, but there may be exceptions, but procedurally closing an RM just to close an AfD with consensus to open an RM is pointless bureaucracy.
More generally, an RM and an XfD affecting the same page should almost never be open at the same time. Where they are, one of them should be closed. In most cases where AfD is involved the RM should be discussion that is closed, but most is not all. In most cases where RfD is involved the RfD should be the discussion that is closed, but most is not all.
Another example of an exception to the general case would be a well-established ongoing RM that has lots of thoughtful comments none of which are suggesting deletion or merging but during which someone opens a borderline frivolous AfD.
Ultimately what we want to do is make it clear that one discussion should be closed without being too rigid about which discussion that should be. Thryduulf (talk) 10:21, 8 July 2026 (UTC)reply
You are both correct and I'm not sure we need to dwell on edge cases. If an AFD is winding down and it appears quite clear that consensus is 'keep and proceed to RM', editors should virtually always wait for a formal AFD close before initiating the RM. RMs are rarely urgent and waiting a few days keeps things "clean". But on the occasion where someone does jump the gun and start the RM because it is SNOWing at AFD, a reasonable would-be closer should let the RM proceed. This is well within the closer's discretion. WP:RMEC, WP:SNOW, and other early closure provisions allow for early closure but closers are expected to consider other factors particular to the discussion at hand. Also, as I've said elsewhere and at least some others agree, it matters which discussion is started first. If the AFD starts first, the RM should almost always be procedurally closed. If the RM starts first, starting a separate deletion nomination is less problematic, although my strong preference is to almost always wait for the RM to close. If we add a bullet to WP:RMEC it should say something like "When an AFD discussion is ongoing and was started first, where the AFD outcome may render the RM question moot and where concurrent discussions are counterproductive". That needs major wordsmithing but approximates what I think we are trying to get at. —Myceteae‍🍄‍🟫 (talk) 19:26, 8 July 2026 (UTC)reply
And perhaps closers can use some light encouragement to procedurally close these more often, without mandating that every such discussion be closed. As @Thryduulf indicated, procedural closes (for this an other reasons) seem to be more common at RFD. We do still sometimes see prolonged, complex discussions left open while a parallel RM or other discussion plays out. But the culture of each of these venues is a bit different—sometimes for good reason—and RFD is more permissive of quick determinations to close discussions procedurally. —Myceteae‍🍄‍🟫 (talk) 18:26, 7 July 2026 (UTC)reply
The current RM at Talk:Atlantic (Dufresne album) is a good example of a case where a deletion discussion and an RM can run completely independently of each other without causing any problems. —⁠ ⁠BarrelProof (talk) 20:25, 7 July 2026 (UTC)reply
You call this a good example?
If the article gets deleted before the RM discussion closes, we can [...] stop worrying about what its title should be.
All of the replies mention AfD in one way or another, making the !votes unnecessarily conditional. Also, I can't seem to find any AfD discussion for that article...? FaviFake (talk) 21:49, 7 July 2026 (UTC)reply
Yes, I think it's a good example. Perhaps I should have used the word "could" rather than "can", since no AfD has been opened, as you noticed. But the possibility of an AfD has been discussed, and the opinion has been expressed that such a discussion could take place independently without causing a problem. —⁠ ⁠BarrelProof (talk) 22:08, 7 July 2026 (UTC)reply
Fine example. —Alalch E. 19:55, 8 July 2026 (UTC)reply
I think merge discussions also need to be included. Merges often emerge as a soft delete for article material anyways User:Bluethricecreamman (Talk·Contribs) 22:10, 7 July 2026 (UTC)reply
Merge discussions occur at AFD, and FaviFake clarified that the concurrent AFD–RM discussions they encounter have all involved AFD merge proposals. —Myceteae‍🍄‍🟫 (talk) 22:18, 7 July 2026 (UTC)reply
  • I'm not sure if the two processes are symmetrical. In practice, rm usually requires editors to examine reliable sources to determine the common name. That same sourcing exercise often answers the notability question as well. If enough independent rs cannot be found, rm is unlikely to get very far in the first place. Accesscrawl (talk) 10:44, 8 July 2026 (UTC)reply
  • Oppose (do not disallow). Wikipedia:Avoid instruction creep. Concurrent AfD and RM is proven to work. I have had good experiences with concurrent AfD and RM -- from the top of my head: Killing of Shani Louk -- October 30 AfD and the concurrent RM. I'm not convinced that anything about how the linked discussions concerning Robinson list went suggests adding a new written norm to any policy or guideline.—Alalch E. 19:55, 8 July 2026 (UTC)reply
    This is a great example, which I recommend reading, because it challenges many intuitions here. Both the AFD and RM were orderly and effective. Both presented serious and important questions. Both benefitted from running separately yet simultaneously, because this kept them focused while avoiding unnecessary bureaucratic delay.
    Now consider various factors to decide whether the RM should have been procedurally closed right then. First, the RM was created 48 minutes after the AFD – but why should it have mattered here, whether it was 48 minutes after or before? Second, in hindsight, we see that the AFD turned out as SNOW keep – but at the time, could a would-be early-closer have assumed what the AFD outcome would be? (Only one day before, a closer of a prior discussion had concluded there was no consensus and permitted the immediate AFD.) Third, I began by emphasizing that both the AFD and RM were highly productive – but (devil's advocate) was it so obvious that that would happen, or is that also colored by hindsight?
    I don't mean to pick on these factors; in fact, I agree with Myceteae that they're excellent factors to consider – with discretion and judgment. I was struck by reading one comment above, and troubled by the latter part of it: "I often refrain from closing RMs about the same article because I'm usually involved ... I'd like there to be a clear rule that allows me to close these RMs even in borderline cases." I, for one, do not want involved people anywhere near closing borderline cases. Adumbrativus (talk) 07:21, 11 July 2026 (UTC)reply
    I agree, there are several good points here, and it may just be that Killing of Shani Louk is an example of the sort of concurrent discussion that should be allowed to stand even if we adopt a guideline to generally close one of these. And if we do adopt that provision, the close is still best done by an uninvolved editor if there is any hint that it is a borderline case. Well meaning would-be closers should always consider whether their involvement will give the appearance of impropriety, even if they believe most other reasonable closers would have made the same call. An involved close is likelier to invite scrutiny, controversy, and further disputes, contrary to the goal of holding one orderly discussion at a time. —Myceteae‍🍄‍🟫 (talk) 17:55, 11 July 2026 (UTC)reply
Not sure that I get a bolded opinion as I was pinged but I agree with FaviFake, RM should be subordinate to a deletion discussion and therefore should not be allowed to run concurrently to an AFD unless there is a special reason to allow it l, which I'm sure needs no instruction but can be agreed by a consensus at the AFD. Spartaz Humbug! 17:08, 10 July 2026 (UTC)reply
but can be agreed by a consensus at the AFD. ...or potentially at the RM. Noting, again, that I think this should be a fairly rare occurrence, I think editors in RM are empowered to argue for the legitimacy of the discussion itself, in addition to the merits of the move proposal. This arises in other, more common situations at RM, for example when someone calls for a procedural or early close on the grounds that it is too soon after the prior RM. It would be up to the closer to weigh the merits of keeping the RM open vs. the problems associated with running concurrent discussions. Also, it's fine to leave a bolded !vote. FaviFake indicated that they pinged everyone involved in the recent AFD discussions, with no evidence of biased canvassing. —Myceteae‍🍄‍🟫 (talk) 17:48, 10 July 2026 (UTC)reply
I disagree that RM should have equality in making that call. One venue needs to be subordinate to the other. Spartaz Humbug! 23:10, 10 July 2026 (UTC)reply
I completely disagree. It should be about the strength of the arguments presented at RM for an exception to the (proposed new) usual practice. It makes no sense to derail an AFD discussion to assess the merits of whether some other discussion should be allowed to proceed. The community can decide that AFD usually supersedes RM but AFD participants are not some Supreme Court that gets to decide whether other venues have jurisdiction on a case-by-case basis. —Myceteae‍🍄‍🟫 (talk) 23:27, 10 July 2026 (UTC)reply
I agree with Myceteae and disagree that one venue needs to be subordinate. A productive RM should not be derailed by a frivolous AfD (or vice versa) for example. Which is the best venue is entirely dependent on the individual circumstances so we need to allow editors discretion to close the discussion that needs to be closed, regardless of which one that is. Thryduulf (talk) 11:23, 11 July 2026 (UTC)reply
Another example of a RM that was just closed as moot because it was opened during the AfD discussion: Talk:Do not call list § Requested move 6 July 2026. FaviFake (talk) 09:05, 16 July 2026 (UTC)reply
I would consider the multiple merge proposals involving Robinson list and Do not call list and this RM all part of one big incident. It's not clear whether this is a representative example or is an extreme case of a pair of articles that for some reason inspired a flurry of mutually exclusive proposals all at once. —Myceteae‍🍄‍🟫 (talk) 22:05, 16 July 2026 (UTC)reply
Right, that's true. What I can say is that, based on my experience (again, I've been monitoring all articles nominated specifically for merging since April 2026), most of the few concurrent RMs I saw were failures. I'm not sure if there's a way to get more concrete data but that's just what I've been seeing myself. Is there a way to get more data on this practise? FaviFake (talk) 22:37, 16 July 2026 (UTC)reply
It'd be difficult, but I think if someone were both determined and had some computer skills, a general estimate could be found. You'd have to line up the timestamps on the AFDs with the timestamps for talk-page sections. The talk-page sections can't be reliably identified, but Twinkle has a standard format, so you could try to use that to find most of them. WhatamIdoing (talk) 05:18, 17 July 2026 (UTC)reply
To look at these moving forward, it seems like it would be trivial to build a report or maintenance category of articles that are currently co-listed at RM and AFD. That would help characterize and monitor this problem now and, if there is a decision to change the RMEC criteria, would provide a tool or identifying candidate discussions for procedural closure. —Myceteae‍🍄‍🟫 (talk) 16:14, 17 July 2026 (UTC)reply
AfD takes precedence over RM. An AfD is a more serious question. An AfD usually goes to the quality of the sourcing. An RM needs to consider the sourcing. An AfD delete or merge renders the RM moot. So, if an AfD is opened during a RM, pause the RM. Exceptions may occur.
If the RM would solve the problem alleged at AfD, that sounds like a speedy keep, a WP:BEFORE failure, for the AfD. A consensus to rename can occur at AfD. A consensus to delete is not valid in an RM. SmokeyJoe (talk) 13:26, 17 July 2026 (UTC)reply
I'm not sure. Imagine the case of a recent death. It's common for editors to try to delete those articles; it's also common for editors to debate whether it should be called "Death of...", "Killing of...", "Murder of...", "Assassination of...", etc. I don't see any reason why editors need to stop talking about what the name should be on the talk page, especially when the AFD looks unlikely to result in deleting or merging the article away. Sure, if it does get deleted or merged away, the discussion is moot, but editors can volunteer their time on anything they want, including discussions that would only matter under certain circumstances. WhatamIdoing (talk) 21:43, 17 July 2026 (UTC)reply
I think it is more common for these articles, which are of dubious notability, to be unilaterally draftified by a new page patroller. I watch it happen, and I’m not sure that it is a bad thing.
when I say “pause the RM”, I mean (probably) delist it, and certainly stop the RM clock, but that doesn’t mean forbid further posts to the RM section. SmokeyJoe (talk) 23:32, 17 July 2026 (UTC)reply
New page patroller here. I'm pretty sure that you're right about the first point, but it's worth noting that our backlog is immense and it's growing by the hundreds-to-thousands every week, so it usually takes a pretty long time for a given article to get patrolled; by the time that a patroller ends up at a page, it may be far too late to draftify it under WP:NOTBACKDOOR.
I've personally witnessed unpatrolled articles from over a decade ago. GrinningIodize (articles without a Wikidata item) (talk) 14:11, 18 July 2026 (UTC)reply
Very old unpatrolled articles? Aren’t they all old redirects that were overwritten by a new article? There was some talk of doing something to account for that. -SmokeyJoe (talk) 07:57, 19 July 2026 (UTC)reply
The section title word “disallow” is too strong. I recommend “discourage”. Opening an RM during an AfD should be “discouraged”. This does not mean discouraging talk page posts about title matters.
However, opening an AfD during an RM is more than ok, if a thorough WP:BEFORE has been done and a good AfD nomination is written, and it references the ongoing RM. The opening of a frivolous AfD is a serious problem, a running RM or not. SmokeyJoe (talk) 00:38, 18 July 2026 (UTC)reply
if a thorough WP:BEFORE has been done and a good AfD nomination is written
Note that WP:BEFORE checks (or more precisely, points C and D) don't need to be performed if the nominator is not proposing deletion. FaviFake (talk) 15:53, 18 July 2026 (UTC)reply
User:FaviFake, yes, sure. Where the AfD is proposing deletion, I think it is extremely likely to be justified to take precedence over an RM, but subject to it being a good, not frivolous, nomination. Reminding AfD nominators of BEFORE encourages better, non-frivolous AfD nominations.
If the AfD nomination is for a merge, I still lean to it taking precedence over an RM, but with less confidence. Maybe, interrupting an RM due to a proposal to merge, should require two editors to support the merge (aka a seconder to pause the RM in favour of discussing a bigger option of a merge). SmokeyJoe (talk) 00:35, 19 July 2026 (UTC)reply
Huh, that may be a good idea! We could decide that, in more unclear cases, the proposal to close the overlapping RM must be seconded by someone else. That could be the clear-cut criterion we need. FaviFake (talk) 10:34, 19 July 2026 (UTC)reply
How exactly would this work? It sounds like this would effectively give the seconder a WP:SUPERVOTE to close discussions regardless of the opinions of other editors. Suppose 10 editors are actively engaged in an RM that they feel is legitimate. An eleventh editor chimes in to say we should close this because there's already an open AFD. A twelfth editor (the seconder) comes along, agrees with 11, and closes the RM. And what is the procedure? Does the initial editor indicate their intent/desire to procedurally close through some special venue or documentation? How are would-be seconders recruited? —Myceteae‍🍄‍🟫 (talk) 17:23, 19 July 2026 (UTC)reply
It sounds like this would effectively give the seconder a WP:SUPERVOTE to close discussions regardless of the opinions of other editors
Well, in a way yes, but that's only because the RM likely shouldn't have been started in the first place and has stood on fragile grounds since its creation. It is rare for editors to propose closing a RM because an AFD exists, so if there are 2 people who share this opinion, then the RM most definitely should be closed.
Does the initial editor indicate their intent/desire to procedurally close through some special venue or documentation?
They would simply comment under the RM or AfD discussion stating clearly that they believe the RM should be procedurally closed, and then a second editor may reply to that comment or come up with the same suggestion on their own in the other discussion. If any editor sees these two comments and the RM hasn't ran its course, they are always allowed to procedurally close it in favour of the AfD discussion. Or, the seconder can close it themselves directly if they notice the first comment. They don't have to post a second comment per se, they can simply write a quick procedural closure statement indicating why the two discussions are incompatible. This system is similar to PROD: 1 person tags the article and gives an explanation, while the other one checks that it's procedurally correct and performs the deletion. We should avoid having unnecessary bureaucracy for these time-sensitive decisions.
Wait, I just had a new idea! What if, instead of permanently closing the RM, it were closed temporarily? In all the various scenarios proposed here, the problem isn't the RM itself! The actual issue is that the AfD and the RM are open at the same time! We could just decide that any editor, even involved editors, can temporarily close the RM if there is a parallel AfD discussion, and then any editor, even involved editors, is allowed to re-open the RM if the nominated page isn't deleted or redirected at AfD. This is the perfect solution because it solves the problem of two parallel open discussions, while allowing the RM to continue if it is still relevant, without losing the previous comments! FaviFake (talk) 22:57, 19 July 2026 (UTC)reply
It is rare for editors to propose closing a RM because an AFD exists. Right, per your statements here, isn't this largely because there is no consensus or guideline encouraging such closures? If we change that then presumably there will be more of these. I'm trying to understand how this would operate under the current system or under a new guideline that spells out some criteria for early closure. Either way, I'm skeptical and not in support of endorsing a supervote mechanism based on my understanding of how this might operate.
As for temporary closure, I'm uneasy about that approach, too. When discussions are closed for any significant length of time and then re-opened, results are mixed. Often the discussion has gone stale. There may be relevant arguments raised at AFD (even if the result was 'keep') and significant changes to the article content during the course of the AFD that impact the RM determination. When there's a big gap in the discussion and important intervening developments have occurred, it can be difficult for new participants to jump in and for closers to determine the meaning and relevance of early !votes—these problems arise at RM, anyway, and are sometimes unavoidable, but I wouldn't want to build them in. Procedurally, we don't have a mechanism to 'pause' an RM other than to close and then re-open it. It can be disorienting when a discussion flips back and forth between open and closed and the history of what has happened and why is often not clear. Presumably, such early or temporary closes could be subject to WP:MRV, which would further complicate things.
In some (many? most?) cases, it is actually better to procedurally close the first discussion and then launch a fresh one once the AFD has concluded. This allows for the proposal to be reworked if necessary and for the nominator to highlight discussions and other developments between the opening of the first and subsequent RM. To be clear, I'm not yet fully onboard with routinely closing these RMs early, but that may be less disruptive. —Myceteae‍🍄‍🟫 (talk) 23:21, 19 July 2026 (UTC)reply
Right, per your statements here, isn't this largely because there is no consensus or guideline encouraging such closures?
I doubt that two users will satisfy all of these conditions:
  • be aware that this obscure procedure even exists
  • have the same opinion
  • be willing to close a discussion early, even if they are allowed to, and have the script / technical skills to do it
  • happen to land find themselves on a rare RM for an article that currently is also at AfD
Again, I think the similarities of this system and PROD still guarantee ''enough layers of cheese relatively to the weight of such a temporary closure.
When discussions are closed for any significant length of time and then re-opened, results are mixed.
AfDs don't usually last a long time, they're usually closed within two weeks and most are closed earlier. And, as was said by many opposers in this discussion, RM and AfD discussions fundamentally tackle different questions. One is: "should this article exist?", while the other is: "given that it exists, how should it be called?". They don't necessarily have to collide, which is why the reason behind this whole thread is just to prevent pointless discussions about the title of an article if we don't know whether it will continue to exist as a standalone article.
it can be difficult for new participants to jump in and for closers to determine the meaning and relevance of early !votes [...] the history of what has happened and why is often not clear
We could use a message like this, similar to the {{Merge MfD note}} that also helps closers in a similar way:
This requested move was temporarily closed on August 1 because there was a parallel AfD discussion. Now that the AfD has been closed, the discussion has been reopened. {{esig}}
Presumably, such early or temporary closes could be subject to WP:MRV, which would further complicate things.
We can just decide that they cannot be reviewed at MRV. A move review will virtually never be closed faster than the AfD, and the closure will be "overturned" anyway after the AfD ends (which, again, usually happens relatively quickly!). If even such a benign closure is so controversial, it likely means the two discussions wouldn't have been able to co-exist harmoniously without causing a mess in the first place.
In some (many? most?) cases, it is actually better to procedurally close the first discussion and then launch a fresh one once the AFD has concluded.
That can still be allowed! If an editor in good faith decides to create a new RM before anyone has re-opened the one that closed temporarily, then the new discussion takes precedence and the previous discussion is moot due to the other developments between the opening of the first and subsequent RM. Sure, there may be some odd edge cases, but having two parallel RM/AFD discussions is (relatively) so rare that editors can just use commons sense. Our main goal should remain to prevent two discussions from running at the same time, and this proposal achieves that. FaviFake (talk) 00:06, 20 July 2026 (UTC)reply
I'm honestly more confused about how this is supposed to work and I don't see the similarities to PROD. If we think it's unlikely that two editors who agree with an early/temporary closure and know about this obscure procedure will find each other, what benefit is there to the procedure in the first place? If we accept, for the sake of argument, that concurrent RMs and AFDs are a problem, then an intervention that is unlikely to be carried out is not much of a solution.
To me, this sounds like the opposite of PROD in terms of effecting the more drastic outcome. With PROD, any single editor can object and prevent the drastic outcome (soft deletion). With this, any seconder can unilaterally impose the drastic outcome (procedural close) even over the objection of 10 other editors. To be fair, procedural closure is less drastic than soft deletion.
If we were to implement something like this, a note modeled after {{Merge MfD note}} would make sense.
I mostly agree with your takes on MRV and the duration of AFDs. But implementing all this still seems quite convoluted and more likely to irritate editors than to streamline effective discussions. RM regulars tend to be sticklers for following closing instructions. This includes latitude for complex or unique closes, but there's an expectation that they can be challenged. Say I'm one of the 10 editors who wanted the RM to proceed. I go to the talk page of the closer (the 'seconder') to challenge it. They inform me of this obscure procedure. I think that's bogus and take it to MRV. After perhaps a few days or a week, my MRV is procedurally closed. Or maybe someone has chimed in and said they agree the RM should be re-opened, what then? Does another supervoting closer at MRV get to make a unilateral call?
Also, while I agree that AFDs usually run shorter than MRVs, I'm assuming that the types of articles that get concurrently nominated at AFD and RM have a lot of issues and therefore might be prone to longer discussions. And I do think that a two week 'pause' in a discussion is not ideal, even if it is possible to revive a fruitful discussion after such time has passed. —Myceteae‍🍄‍🟫 (talk) 02:05, 20 July 2026 (UTC)reply
an intervention that is unlikely to be carried out is not much of a solution
That was mostly in reply to your suggestion that if this procedure is enacted, then presumably there will be more of these editors closing these discussions. (Which is what we generally want in the first place, since concurrent RM discussions currently are almost never closed early.) I'm just trying to come up with a set of criteria that's as deterministic and straightforward as possible without being too bureaucratic to effectively close these discussions in a reasonable amount of time.
Maybe, in addition to 2 involved editors agreeing, we can establish that even 1 single editor can close the RM temporarily, provided that they are completely uninvolved in both discussions.
any seconder can unilaterally impose the drastic outcome (procedural close)
Sure, but just like PROD, any editor can re-open the discussion once the AfD is closed, which makes their closure very weak. I doubt that the arguments at the RM would massively overlap with those at the AfD, as those venue fundamentally have different objectives, so I don't think a temporary closure would be as "drastic" as you describe. With the simple orange MfD-like note and the assumption that in most cases the arguments are still valid if the article is kept, I think this system doesn't impact or "disorient" the RM discussion to a noticeable degree. And if the early !votes are rendered irrelevant after the AfD is closed, it means the system successfully halted a discussion that was going to fail anyway!
Does another supervoting closer at MRV get to make a unilateral call?
This sounds very unlikely to actually happen, but: if the AfD hasn't been closed yet, they would procedurally close the MRV and tell the appellant to wait; and if the AfD discussion has been closed, they would procedurally close the MRV and tell the appellant to reopen the RM or create a new one. These RMs intentionally stand on such fragile grounds precisely because AfD looms over them.
I'm assuming that the types of articles that get concurrently nominated at AFD and RM have a lot of issues and therefore might be prone to longer discussions.
That isn't necessarily the case. In this example, every AfD discussion was closed in a week or less.
a two week 'pause' in a discussion is not ideal, even if it is possible to revive a fruitful discussion after such time has passed
Well, maybe that's where we disagree. Sure, a discussion being paused for 2 weeks is not a perfect situation, but I think it's much more ideal that a 2-week-long discussion that is rendered moot by the mighty AfD discussion. That's the problem I'm trying to come up with a solution for. FaviFake (talk) 13:44, 20 July 2026 (UTC)reply
Thanks for the detailed reply. I think we have common goals about facilitating effective discussions but have different perspectives on what constitutes a problem and which solutions make sense. I think there's a difference between "this discussion could have waited" versus "this is disruptive" and of course there are many shades of grey in between. In looking the Robinson list–Do not call list situation, there were three concurrent discussions with substantial overlap. With the benefit of hindsight, I think a reasonable editor could have closed one or two of those per WP:MULTI with a dash of WP:IAR and common sense, without needing the support of a new guideline. In fairness, such bold action may have been controversial, but who knows? But if Robinson list was an outlier, and most of the time the RM and AFD questions are clearly distinct—which they should be—and the discussions proceed without much disruption or confusion, then I'm not convinced we need to 'fix' anything. —Myceteae‍🍄‍🟫 (talk) 16:41, 20 July 2026 (UTC)reply
The Eagle gay bars situation was also a bit of a mess but arguably it was the RM proposal that saved it. Six of the seven concurrent discussions were AFDs. I'm hard pressed to say that the RM was the problem. —Myceteae‍🍄‍🟫 (talk) 16:50, 20 July 2026 (UTC)reply
  • Oppose (do not disallow) per Alach E. I don't buy this notion that AFD is somehow "more important" than RM, and I think it's silly for editors to imply that there is some sort of turf war between the two processes. They are both important, and cover different things; RM is particularly important for high-visibility articles where the choice of title is sometimes controversial and requires careful analysis, while of course AFD is most often concerning topics of borderline notability. Obviously if an article is eventually deleted, that does render any ongoing RM moot, but I don't think we should prohibit editors from discussing the title at an RM in the normal fashion just because someone has decided to put the article up for AFD... there's likely to be cross-pollination anyway, an editor who wants to move the article will probably also vote "keep" in the AFD for example.  — Amakuru (talk) 17:26, 17 July 2026 (UTC)reply
    AfD isn't even that powerful as AfC can supersede it and vice versa (which is a factual statement, I did it myself). — Very Polite Person (talk/contribs) 17:47, 17 July 2026 (UTC)reply
    The issue of high visibility articles is a good point. @WhatamIdoing's examples of "Murder of …" articles in reply to @SmokeyJoe above very often in this category. I think I've commented elsewhere in this thread that RMs are rarely urgent, but getting the proper title for a high traffic article involving BLP and current event concerns is important. Such high profile articles often attract a lot of participants at RM and AFD and have rapidly changing facts on the ground that make it difficult to assess whether opinions in early !votes are applicable to the current state of affairs. All of this can prolong discussions. It would be a bad practice to lock a problematic title in place while an AFD goes on for 2+ weeks. —Myceteae‍🍄‍🟫 (talk) 23:23, 17 July 2026 (UTC)reply
  • Allow parallel discussions… but… mandate that both discussions should have a link to the other. Blueboar (talk) 21:53, 17 July 2026 (UTC)reply
    Agree. People coming to contribute to an RM should be aware if there is a proposal to delete, which includes deletion of all the talk page posts. SmokeyJoe (talk) 23:35, 17 July 2026 (UTC)reply
    I agree. The concurrent discussions should be cross-linked fairly prominently. —Myceteae‍🍄‍🟫 (talk) 14:32, 22 July 2026 (UTC)reply
  • Allow concurrent discussions. I think concurrent discussions should usually be avoided but after much consideration I don't see cause to implement a new rule or standard. When an RM proposal arises during the course of an AFD, or vice-versa, I would encourage editors to wait for the first discussion to close in most cases. Editors launching the second discussion should ideally make a clear case for why the new discussion is distinct and should occur now. Editors may occasionally boldly close a discussion that is deemed disruptive, confusing, or duplicative following the normal standards but the mere existence of a concurrent RM and AFD is not sufficient. It might help to create a maintenance category or report that shows all pages that are currently co-listed at AFD and RM. This would help identify a pattern and whether there is a need for further intervention. —Myceteae‍🍄‍🟫 (talk) 14:31, 22 July 2026 (UTC)reply
why stop there? Why not lock the cathedral of lies in their entirety so we own "the truth"? Ices333 (talk) 17:31, 25 July 2026 (UTC)reply
— Ices333 (talk • contribs) has made few or no other edits outside this topic. —⁠ ⁠BarrelProof (talk) 19:02, 25 July 2026 (UTC)reply

What percentage of users understand WMF?

In a pump discussion at here someone correctly stated that most users do not understand what WMF is. As I stated there, I also think that a very small percentage of internet users understand what WMF is, how it operates and that it attempts not to be involved in content. We should clarify this. I propose that any new user should receive a link to a message explaining this aling with a welcome message, and banners on pages should do so once I a while. If we are here to "provide knowledge" let us start with this. Yesterday, all my dreams... (talk) 16:37, 18 July 2026 (UTC)reply

There are a lot of things that editors need to learn to be successful on wikipedia, but understanding WMF is probably the least important. Schazjmd (talk) 18:35, 18 July 2026 (UTC)reply
Yeah, I tend to agree. It ultimately is important but you can go pretty far without knowing about WMF. When an entry-level employee is hired, they don't usually start by reading the bylaws and learning about the corporate structure. Maybe that's a poor comparison, and heck, probably more employees should understand these things. I'm also not sure what it means to understand WMF. Do I understand WMF? I don't know how I would answer that. —Myceteae‍🍄‍🟫 (talk) 17:44, 19 July 2026 (UTC)reply
They probably mean "understand what the WMF means/is" ~2026-40532-03 (talk) 12:14, 20 July 2026 (UTC)reply
Well, yes, I understood that. I don't mean to be obtuse here but to understand is a complex concept. There's probably some Dunning-Kruger at play here. I would probably say I understand WMF with less confidence today than I might have five years ago, and certainly 10, even though I understand it more now than I did then. —Myceteae‍🍄‍🟫 (talk) 17:05, 20 July 2026 (UTC)reply
As an example, I am a fairly inexperienced editor, who has never looked into what WMF is, and I would guess it's the parent organisation of Wikipedia, and wouldn't be certain what else it does other than that.
To me the relevant question is, why would this matter for editing Wikipedia? MaelstromOfSilence (talk) 15:06, 24 July 2026 (UTC)reply
I agree this is the relevant question, and I agree with Schazjmd that this is pretty far down the list of must-know topics for new editors. —Myceteae‍🍄‍🟫 (talk) 21:05, 26 July 2026 (UTC)reply
I didn't even know what WMF was referring to until someone said parent organization of Wikipedia. Wikimedia foundation or something, controls all wiki projects like wiktionary and the specieswiki stuff like that. I don't fully understand it though probably.
-- LightningThrower (talk) 21:25, 26 July 2026 (UTC)reply
The story goes that if people start understanding, it will immediately be replaced with something even more difficult to understand. Rumour has it that this has already happened. Hawkeye7 (discuss) 22:52, 26 July 2026 (UTC)reply
Yeah, Wikimedia Foundation (WMF) owns and operates Wikipedia and other Wikimedia sister projects such as Wiktionary. On one hand, anything and everything that WMF does, or that is done to WMF, impacts Wikipedia. And as a general matter, I think it's good for folks to know and care about the structure. But on the other hand, one can get very far in contributing to Wikipedia without even knowing WMF exists. The learning curve can be overwhelming and we have so much discussion about editor recruitment, retention, and the experience of new editors; I just don't think it makes sense to pile on. —Myceteae‍🍄‍🟫 (talk) 22:53, 26 July 2026 (UTC)reply

FFAC/FAC

I recently got the FFL star changed to make the FA stars consistent, In order to have consistency throughout all the FA stars, can we also change the FFAC/FFLC and FAC/FLC images to and respectively? I uploaded these two years ago but never proposed actually adding them. splains (💬/📝) 23:30, 27 July 2026 (UTC)reply

Could you make your proposal more specific? What pages should be updated, exactly? FaviFake (talk) 22:49, 31 July 2026 (UTC)reply

Grey out Minor edit tick box for TAs

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.

Moved to Wikipedia:Village pump (technical)

I have been editing as a TA for months, and using the Minor Edit tick box when it seemed appropriate. I have only recently realised that this setting is ignored for TAs. This is misleading, for people who are less likely to be familiar with editing Wikipedia. Could this box be greyed out for users for whom it will be ineffective? ~2026-42114-05 (talk) 04:09, 29 July 2026 (UTC)reply

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.

Proposal to require independent sourcing for all political endorsements

I propose removing the provision in Wikipedia:Political endorsements that allows local consensus to overrule our general policy that facts be sourced to independent reliable sources for organizational endorsements. Specifically, I propose striking the following sentence from the guideline: Local consensus can determine whether a specific list requires independent sources or sources connected to the organization itself, such as its website or official social media accounts.

WP:RFCBEFORE discussion here. Prior RFC here. Dcpoliticaljunkie (talk) 20:36, 29 July 2026 (UTC)reply

Survey (endorsements)

  • Support: With the amount of horserace coverage every campaign gets, if no independent sources are covering an endorsement, it lacks WP:WEIGHT. Dcpoliticaljunkie (talk) 20:36, 29 July 2026 (UTC)reply
  • Support I didn't think the carve-out was a good idea seven years ago when I proposed that RfC. — Rhododendrites talk \\ 23:25, 29 July 2026 (UTC)reply
  • Support per WP:VNOT and WP:DUE, as other editors have pointed out. A social media post or other statement endorsing a candidate is a primary source for the endorsement. It might be verifiable, but that doesn't make it due for inclusion. Inclusion of endorsements should require secondary sources. It should also require independent sources, because, e.g., a list of endorsements published by a campaign might be secondary and verifiable, but it doesn't establish WP:DUE. We should only include endorsements when reliable, secondary, independent sources (like history books and newspaper articles) establish that inclusion of the endorsement is due. Levivich (talk) 00:19, 30 July 2026 (UTC)reply
    • Comment. This is not meant to be a put-down: from what I know, WP:VNOT necessitates consensus but not necessarily "sources need to be this type", and WP:DUE does not necessitate source secondariness or independence. DUE only needs sources to be "reliable", and WP:RSPRIMARY separates secondariness and reliability by saying "Wikipedia articles should be based mainly on reliable secondary sources" and even saying primary sources "can be both reliable and useful in certain situations". Needless to say, these issues of VNOT and DUE are quite annoying. LightNightLights (talk • contribs) 01:01, 30 July 2026 (UTC) (edited 02:47, 30 July 2026 (UTC))reply
    I don't read the current guidance as suggesting an exception to DUE or VNOT. And it doesn't allow for citing a source from the campaign, only sources from the endorsing organization itself. DUE is contextual and can be assessed in a number of ways. For example, only including organizations with blue links to articles would be a reasonable bar to set in national and other high profile races. —Myceteae‍🍄‍🟫 (talk) 02:29, 30 July 2026 (UTC)reply
    ...and WP:BESTSOURCES if we're going to nitpick over various parts of WP:NPOV (emphasis added): In principle, all articles should be based on reliable, independent, secondary published sources with a reputation for fact-checking and accuracy. When writing about a topic, basing content on the best respected and most authoritative reliable sources helps to prevent bias, undue weight, and other NPOV issues.
    Wikipedia policies aren't laws. They're not well-written. Just because the words "independent" or "secondary" don't appear in the specific section WP:DUE doesn't mean that one can make a determination about what content should be included in an article from non-independent or primary sources. But in case there was any doubt about this, there's the WP:BESTSOURCES section of NPOV.
    Bottom line: to determine if content should be included in Wikipedia, we must look to the highest-quality, most-reliable, most recent, secondary, independent, published sources. That's what our core content policies and guidelines say when you put them together, even if it's spread out across a bunch of different pages and sections, like WP:VNOT, WP:DUE, WP:BALANCE, WP:BESTSOURCES, WP:REPUTABLE, WP:AGEMATTERS, and a bunch of other places. Levivich (talk) 21:21, 30 July 2026 (UTC)reply
    You can certainly make an argument that that is the case. It is certainly not what is written in the policies and guidelines. I think we should go by what is written in the policies and guidelines, not what words editors wish were in the policies and guidelines.
    That section of WP:BESTSOURCES does not have the 20-year consensus you claim below - it was added relatively recently (a few years ago, if I'm remembering right). It's certainly a good thing, but it's a goal to aspire to, not the end-all of every discussion and certainly not a license to excise every non-secondary non-independent source from discussion altogether.
    WP:BESTSOURCES, despite your allusion to the other WP:UPPERCASE in WP:NPOV, is the only place in the NPOV policy where the word "independent" is contained. WP:AGEMATTERS has nothing to do with independent sources, so it's curious why it's being cited here.
    However, both WP:REPUTABLE and WP:BESTSOURCES say that articles should be based on "reliable, independent, published sources". That is certainly not the same thing as saying that any use of a non-independent source to supplement particular information is not permissible or should be completely banned. I completely agree with the WP:BESTSOURCES statement that articles should be based on reliable, independent, published sources. I do not agree that non-independent sources should be banned, which is probably why that is supported by none of the policies and guidelines you've cited. Katzrockso (talk) 23:58, 30 July 2026 (UTC)reply
    That's a lot to cover: what I quoted from our PAGs is in fact written in our PAGs. I claim no 20-year consensus below. (There's no plausible way to understand the words "20-year veteran" as referring to the age of consensus rather than the age of an account.) Nobody is trying to excise or ban every non-secondary non-independent source. NPOV isn't the only policy that talks about having independent sources, another example is WP:RS. WP:AGEMATTERS was being cited here because the prior sentence said most recent. Based on ... is certainly not the same thing as saying that any use of a non-independent source to supplement particular information is not permissible or should be completely banned, so it's a good thing that nobody is arguing that any use of a non-independent source to supplement particular information is not permissible or should be completely banned. I do not agree that non-independent sources should be banned either, and so I'm glad that's not required by any PAGs.
    And yet I believe endorsements are the type of content that should be cited to the reliable, independent, secondary sources that our PAGs say articles should be based on.
    I don't know why you wrote that long series of fabrications, misinterpretations, strawman arguments, and putting words in my mouth I never said, requiring me to write this long correction, but I'd appreciate it if you didn't do that to me again. Levivich (talk) 00:23, 31 July 2026 (UTC)reply
    Policy does not support looking to the "we must look to the highest-quality, most-reliable, most recent, secondary, independent, published sources" to establish what is WP:DUE, not only because these are often contradictory and exclusive. We don't look to sources that don't exist, but evaluate those that actually exist and see which ones are the best to base our articles on (which is different than the inclusionary criteria for particular elements of content). Moreover, the policy that determines whether or not we include things remains WP:WEIGHT and WP:BALANCE, which once again do not mention the independence of sources. I once again think that editors should read the words that in a policy, not the words that they wish were in a policy.
    For example, WP:AGEMATTERS explicitly points out that the "most recent" source is certainly not always the most reliable source, so we should not simply look for the "most recent" source, but the WP:BESTSOURCE when evaluated holistically. There are numerous reasons why we might prefer an older source to a newer one. "Most recent" is certainly not a good summarization of WP:AGEMATTERS.
    Adding in auxiliary information like endorsements is certainly not the same as writing the bulk of our articles. Indeed, WP:SELFSOURCE states the great majority of any article must be drawn from independent sources. I don't find any conflict whatsoever between WP:RS, WP:NPOV (specifically WP:REPUTABLE and WP:BESTSOURCES) and using a non-independent source to verify an endorsement, because using a source is not the same as basing an article on a source.
    The argument presented here is effectively one that non-independent sources should be banned - you present no distinctive argument that wouldn't apply to every single use of a non-independent source. Indeed, there is no particularity to the argument here specific to the context in question - political endorsements. That suggests, or rather proves, that the issue is not specific to political endorsements, but with the use of non-independent sources altogether. Whether or not you take your argument to its logical conclusion is no import to me, you can call it fabrications, misinterpretations, strawman arguments, and putting words in my mouth I never said or whatever you like.
    If we are talking about fabrications, misinterpretations, strawman arguments, and putting words in my mouth I never said, we can start with this:

    what I quoted from our PAGs is in fact written in our PAGs

    I never stated or suggested that the quotes you provided were in any way made up. What I suggested was the the accompanying commentary misrepresents existing PAG, which is a charge I still contend is true. Katzrockso (talk) 02:34, 31 July 2026 (UTC)reply
    You said It is certainly not what is written in the policies and guidelines, but what I'm saying is in our PAGs, is in our PAGs. I'll show you in a moment. But first my Bernie impression: I am once again asking that you not put words in my mouth. Nobody is calling for banning all non-independent sources. Just because someone thinks non-independent sources shouldn't be used to source political endorsements doesn't mean they think non-independent sources shouldn't be used for anything. You can call that the argument's "logical conclusion," but it's actually a strawman argument: you're arguing against something (a total ban) that nobody is arguing in favor of.
    Now, the first sentence of WP:BALANCE, key words bolded:

    An article should not give undue weight to minor aspects of its subject but should strive to treat each aspect with a weight proportional to its treatment in the body of reliable, published material on the subject.

    If no independent RS is writing about an endorsement, if the only people writing about an endorsement are the endorser and endorsee (both non-independent), then that is, indisputably, a low proportion of coverage in RS, it's like 1 or 2 sources out of all sources when only non-independent sources are writing about it and no independent sources are writing about it. Because of this low proportion of RS covering the endorsement, it's a "minor aspect" to which we should not give "undue weight."
    WP:WEIGHT aka WP:DUE analysis is the same:

    Generally, the views of tiny minorities should not be included at all, except perhaps in a "See also" to an article about those specific views.

    If an endorsement is only published by the endorser and/or endorsee (who are non-independent), and no other RS are writing about it (so no independent RS), then it's a "tiny minority" (1 or 2 sources out of all sources) and so that view should not be included at all.
    In sum: if the only place an endorsement is published is in non-independent sources, such as a social media post by an endorser, or a campaign website, then that means the endorsement is a tiny proportion of RS, a tiny minority of RS, and therefore the endorsement should not be included, per WP:BALANCE and WP:DUE, even though those sections don't have the word "independent" in them. Levivich (talk) 04:39, 31 July 2026 (UTC)reply
  • Support It's time that the local tolerance for this be deprecated per VNOT and DUE. Generally concur with the above comments. -Ad Orientem (talk) 00:38, 30 July 2026 (UTC)reply
  • Support Why even would we allow local consensus to override higher level authority? That's stupid. — Very Polite Person (talk/contribs) 00:53, 30 July 2026 (UTC)reply
  • Mildly oppose Just to give some background information to others here, I'd have to imagine that this discussion is coming from the 'discussion' that we had here? I would like to point out that the provision regarding organization endorsements explicitly says that there isn't a consensus regarding sourcing, so I don't exactly agree that local consensus is overruling the rule. I very much do prefer independent sourcing when available, but there are definitely places where it just won't be. If an endorsement isn't mentioned in an independent article, I don't think it inherently means that they aren't notable, especially in elections like state legislatures that do get far less media coverage than national or statewide ones. These types of endorsements are also helpful in things like nonpartisan elections and help readers get a better idea of the candidates that were or did run. I would go along with the rule if the carve-out does get removed, but I do think that it could remove some important information for a lot of elections that just don't get as much media attention as they deserve.ABlitzz (talk) 01:42, 30 July 2026 (UTC)reply
    Thanks, that's helpful. I was about to ask for links to articles that were viewed as including problematic examples and/or to prior discussions about this. —Myceteae‍🍄‍🟫 (talk) 02:20, 30 July 2026 (UTC)reply
  • Support I do believe that independent sourcing is necessary. --Enos733 (talk) 04:49, 30 July 2026 (UTC)reply
  • Support. If reliable and independent secondary sources can't be bothered to cover an endorsement, neither should we.Cortador (talk) 11:03, 30 July 2026 (UTC)reply
  • Oppose on principle. I'm not fond of the way some people increasingly like to claim that every individual fact (that they dislike) in an article has to pass WP:N-level sourcing to be included, rather than using editorial judgement and consensus to determine what is relevant to the topic. As Myceteae noted below, the opening statement of this RFC itself is already erroneously biased in that direction. Anomie⚔ 14:35, 30 July 2026 (UTC)reply
    What is important to a topic is ultimately determined by reliable and independent sources. Once we as editors start determining that based on primary sources, it's just original research. Cortador (talk) 16:02, 30 July 2026 (UTC)reply
    Yes, that's exactly the kind of bogus argument I'm talking about. Thanks for the example. Anomie⚔ 18:21, 30 July 2026 (UTC)reply
    Thank you for your clear, policy-based argument. Cortador (talk) 18:38, 30 July 2026 (UTC)reply
    You're welcome. It's nice when someone appreciates what the policies actually say rather than fictions like "OR requires multiple independent sources, not just reliable ones". Anomie⚔ 19:09, 30 July 2026 (UTC)reply
    Whom are you citing? Cortador (talk) 20:50, 30 July 2026 (UTC)reply
    Anomie, did you seriously just call our core content policies WP:V and WP:OR "bogus"? That's wild from a 20-year veteran. WP:BESTSOURCES literally says: In principle, all articles should be based on reliable, independent, secondary published sources with a reputation for fact-checking and accuracy. So arguing that endorsements shouldn't be included unless they're in reliable, independent, secondary published sources is ... very much in line with very old and very widely accepted core Wikipedia policy. I'm not sure how you can characterize that as "bogus." Levivich (talk) 19:01, 30 July 2026 (UTC)reply
    No, and I think I'll not engage with your falsehoods. Anomie⚔ 19:09, 30 July 2026 (UTC)reply
    "Bogus"? "Falsehoods"? Suggesting I'm a troll? In response to people saying "we should have independent sources"? What's with this ridiculously-unwarranted hostility? What the heck has gotten into you today? Levivich (talk) 20:42, 30 July 2026 (UTC)reply
    What is the material—such as facts, allegations, and ideas—for which no reliable source has ever been published in question here? Katzrockso (talk) 20:55, 30 July 2026 (UTC)reply
  • Oppose per AnomieX. This is just an extension of the primary sourcing paranoia - WP:DUE says precisely nothing about the independence of a source or whether it is primary, secondary or tertiary. Editors often attribute to particular policies meaning that is contained nowhere within them, and unfortunately DUE is in the club. From the original RfC, the point that I find most pertinent is that newspaper endorsements are organizational endorsements that could be of relevance to our articles, but tend to receive less coverage than other types of endorsements. When mandating secondary, independent sourcing, editors must consider whether these secondary, independent sources will tend to produce a bias in their coverage that will tend to affect our coverage. In this case, I don't think this bar has been met.
As for WP:VNOT, this is of tangential relevance to this guideline, as it is silent on the independence of sources or whether they are PTS. Indeed, it simply says that consensus can decide that a verifiable fact does not improve an article. This applies to everything, including content sourced to independent, reliable, secondary sources.Katzrockso (talk) 20:54, 30 July 2026 (UTC)reply
I'd be curious if anyone could find even one newspaper endorsement that should be in an article that is not mentioned by any independent source. In practice, the bit we're debating here has nothing to do with newspaper endorsements and everything to do with, say, a barely notable advocacy group that issues two hundred endorsements that nobody reports on but make it into two hundred separate Wikipedia lists. — Rhododendrites talk \\ 21:31, 30 July 2026 (UTC)reply
When you define "should be in the article" as "has independent sourcing" and then find that every example that should be in the article has independent sourcing, it's hardly surprising. Katzrockso (talk) 21:44, 30 July 2026 (UTC)reply
I'm not sure how that responds to what I said. To rephrase: what's an example of a newspaper endorsement that was not covered by an independent source? (because there are an awful lot of the other kind, where we cite social media posts of local advocacy groups to add them en masse). — Rhododendrites talk \\ 21:46, 30 July 2026 (UTC)reply
Any newspaper from a small region covering an endorsement from another newspaper from that region is, from a certain POV, not an independent source (given that they're business rivals and whatnot). So I'm going to guess... the vast majority of newspaper endorsements can't be covered by an independent RS? GreenLipstickLesbian💌🧸 22:20, 30 July 2026 (UTC)reply
I'm not sure I've ever seen the "it's not independent if the subject is a competitor/rival of the source" argument, but certainly haven't seen consensus for that. — Rhododendrites talk \\ 22:53, 30 July 2026 (UTC)reply
WP:IIS states that an independent source lacks conflicts of interest (i.e., there is no potential for personal, financial, or political gain to be made from the existence of the publication). Katzrockso (talk) 23:11, 30 July 2026 (UTC)reply
This is now a tangent. If someone would like to make the case that e.g. we can't use CNN or NBC to report on FOX because they're not independent, or that relationship is somehow radically different at a different geographic scale, that's probably a discussion for another place. I'm happy to be pinged there, but cannot imagine any real consensus for it beyond a "yeah, I sorta guess you could say there's technically a COI, but no that's not a reason to decide they lose their independence". I could be wrong, but again we're getting away from the point here. — Rhododendrites talk \\ 23:18, 30 July 2026 (UTC)reply
Nobody's arguing that strawman; I hope I'm not putting words in Katzrockso's mouth, but I like to think we've been pretty clear than independence is not the be all and end all when it comes to newspapers reporting on each other. (Though the potential COI is something I do take into consideration when I'm sourcing and writing articles; I hope you're not asking me not to?)GreenLipstickLesbian💌🧸 23:24, 30 July 2026 (UTC)reply
The mistake here is thinking that non-independent sources are some "bad" category of sources that we need to completely eschew. They certainly need to be used more carefully, but they aren't supposed to be some verboten evil that needs to be excised from every article, despite the increasing tendency to characterize anything that isn't an SIRS as such.
I don't see how by the definition of independent sources used by Wikipedia, they are independent. If you'd like to propose a change to the WP:IIS essay or WP:ORGIND guideline, I wouldn't be necessarily opposed. For what it's worth, WP:ORGIND also specifies that competitors are not independent;

Independence of the author (or functional independence): the author must be unrelated to the company, organization, or product. Related persons include organization's personnel, owners, investors, (sub)contractors, vendors, distributors, suppliers, other business partners and associates, customers, competitors, sponsors and sponsorees (including astroturfing), and other parties that have something, financially or otherwise, to gain or lose.

Katzrockso (talk) 23:48, 30 July 2026 (UTC)reply
I don't think that's a good thing, but I also don't think the only remedy to the problem is this proposal. Katzrockso (talk) 22:27, 30 July 2026 (UTC)reply
+1. GreenLipstickLesbian💌🧸 22:41, 30 July 2026 (UTC)reply
I would say that this is probably where I'm at as well. I can see the concerns that people have and are bringing up, but I think that, for the most part, the guidelines are fine as they are currently. ABlitzz (talk) 23:30, 30 July 2026 (UTC)reply
  • Support Lists of endorsements seem to be a blatant violation of WP:SOAP which is policy and states that Wikipedia is not a soapbox...or a vehicle for propaganda, advertising, and showcasing. The proposal raises the bar and so is a move in the right direction. Andrew🐉(talk) 21:01, 30 July 2026 (UTC)reply
  • Support, this is how we decide whether something is worth mentioning. Things that are not worth mentioning probably aren't worth mentioning. Thebiguglyalien (talk) 01:23, 31 July 2026 (UTC)reply
  • Oppose (Just to be up front, my opposition stems from my opposition to the rigid applications of criteria #2 generally, eventhough I agree with the principles behind it) Endorsements are, by definition exercises of expression of bias, of advocacy of a subjective opinion. Lists are means to comprehensively present relevant factual information in an organized manner for ease of consumption. Lists of endorsements therefore would by definition conflict with various basic WP principles, but their continual existence are tolerated/accepted/even desired by some of us because they comprehensively enumerate relevant factual information in a succinct, organized manner, allowing reader to draw insights and informed assessment.
If we accept that premise, then rejecting an undisputed entry that meets criteria 1 & 3 by rigidly enforcing the independent aspect of criteria 2 without any consideration of weighing of other facts (such as the reliability aspect of criteria 2, local context, scale of the contest, substantive relevance or significance of a particular entry to the particular context) is to me quite illogical. 1) Given endorsement is an expression of bias, an unindependent source, such as the endorser themselves, actually is the ultimate reliable source. 2) Existence of independent source is generally an strong indicator of notability but only an reasonably good indicator of relevance. Some inconsequential endorsement get attention because they are unique or interesting or even entertaining, while some clearly consequential endorsement get no little media play because they were expected or boring but nonetheless impactful. For example, endorsements of politicians by celebraties like actors or singers often get covered in the news for their entertainment value, because they are interesting and unusual, but they rarely have meaningful impact on electoral outcome. An endorsement from a former office holder that retired long ago may general little press interest while having huge impact (especially in internal contests like primaries or nomination fights where older voters, and long time party activists are have greater presence.)
Ultimately, the purpose of this policy is to ensure entries included in such lists are realiable, notable, relevant and consequential. Exisitence of independent sources would be decent indicators for those things but not conclusive proof, and the absence of independent sources certainly does not conclusively disprove any of those things. If the notability of the endorser, the factual reliability of the endorsement, and its relevance to the the subject election are not in dispute, exclusion would arguably amount to censorship. JacobW2 (talk) 15:10, 31 July 2026 (UTC)reply
  • Support per my reasoning at Talk:2026 New Democratic Party leadership election (archive link) and the preceding discussion in that archive page. Goes against multiple P&Gs otherwise, including WP:DUE, WP:PROMO and WP:ABOUTSELF ―"Ghost of Dan Gurney" (hihi) 21:54, 31 July 2026 (UTC)reply
  • Support per above. There's a reason local consensus can't overrule global consensus, especially on notability. FaviFake (talk) 22:51, 31 July 2026 (UTC)reply
    Notability has to do with whether an article should exist for a topic, it has nothing to do with whether content should be included in an article. Katzrockso (talk) 23:54, 31 July 2026 (UTC)reply
  • Oppose - What to do about noteworthy endorsements by media outlets that are covered by the outlet's competitors is an excellent point. (Plus, there's the issue of organizations and independent sources potentially disagreeing that I brought up below.) WP:DUE would apply regardless and seems orthogonal to this issue. Gnomingstuff (talk) 23:03, 31 July 2026 (UTC)reply
    • Still hoping for even one (and preferably more) example of noteworthy endorsements by media outlets that are covered by the outlet's competitors, but this is the last time I'll mention it. It's a big flood gate to leave open for a hypothetical. — Rhododendrites talk \\ 23:18, 31 July 2026 (UTC)reply
      I can't find any independent coverage of The Detroit Metro Times endorsement of Abdul El-Sayed as an example. According to our article, it's the largest circulating newspaper in the Detroit Metro area, which is the largest city in Michigan. I think that's pretty noteworthy. Katzrockso (talk) 00:02, 1 August 2026 (UTC)reply
      • Well, largest circulating weekly :) but regardless we have an article about it and I, too, cannot find independent coverage. Thanks for digging up an example. I'm more inclined to support an exception for certain kinds of companies/organizations (like notable media outlets), but still not quite convinced it's in our best interest to include every endorsement by every organization or company, regardless of what they are or how much they're written about. — Rhododendrites talk \\ 00:27, 1 August 2026 (UTC)reply
        Who said we have to include every endorsement by every organization or company, with or without independent sources? Anomie⚔ 01:07, 1 August 2026 (UTC)reply
        I completely agree that we shouldn't be including every endorsement by every organization or company. The status quo of guideline doesn't require this, and if that is what happens in practice, I would support any effort to trim non-notable and non-noteworthy organizations. Katzrockso (talk) 03:04, 1 August 2026 (UTC)reply
        As the person who has added a lot of the endorsements to the Michigan Senate race's article, which is the article that kind of seems to have started all of this, I'm just wanting to give some of my own thoughts here. There have definitely been a lot of endorsements listed in articles that I haven't added simply because the endorsers don't have a Wikipedia page. If they have a Wikipedia page, I'll usually add them because that's a symbol, in my mind, that they're notable enough to be added. If they have no Wikipedia page, then I'll typically avoid adding them to articles unless there's another reason that would make sense (i.e. a local or House election where a candidate is endorsed by a notable person in the city/district but the endorser doesn't have a Wikipedia page). Personally, my opinion is that if there is a source that follows the guidelines and the endorser is notable enough due to having a page here or some other reason, then there's no reason not to add in the endorsement ABlitzz (talk) 13:06, 1 August 2026 (UTC)reply
        Joe Celebrity might be notable for his movie career… but that does not mean his political opinions are worth noting. Blueboar (talk) 13:45, 1 August 2026 (UTC)reply
        I can understand the point you're making there, but wouldn't editors be interfering with the neutrality of the page if we're able to just decide who is relevant and who isn't? As long as the endorser has a good source and page, I really don't see a reason why they shouldn't be included. Under your example, it could also show the start of Joe Celebrity getting more involved in the political scene and becoming prominent in both movies and politics. ABlitzz (talk) 15:23, 1 August 2026 (UTC)reply
        The status quo requires independent sources for individual persons endorsing a candidate, so that isn't a question at the moment. Katzrockso (talk) 20:57, 1 August 2026 (UTC)reply
  • Oppose The inclusion/exclusion of a particular endorsement that lacks independent sourcing can always be debated on the article's talk page, just like with any other disputed content. Some1 (talk) 23:42, 31 July 2026 (UTC)reply
  • Oppose. I'm just not seeing any evidence of an actual problem here that needs solving. At 2026 United States Senate election in Michigan § Endorsements, there are far fewer organizations listed than individuals. As others have noted, celebrity and other "big name" endorsements are prone to garnering at least some media coverage even when their encyclopedic value is questionable. PACs and political organizations, whose endorsements may be less newsworthy, may be a more meaningful reflection of a candidate's ideology and support base. Looking at other articles that were shared at Talk:2026 United States Senate election in Michigan#Organizational endorsements, most have much shorter endorsement lists. Weighting these lists towards celebrities and other individuals is of no value to these articles. The current guidance is in no way an exception to WP:DUE or any other broadly applicable policy or guideline. —Myceteae‍🍄‍🟫 (talk) 18:54, 1 August 2026 (UTC)reply

Discussion (endorsements)

RfC: ITN and sham elections

Should any of the following be added to WP:ITNBLURB:

  1. If reliable independent sources generally describe an election as not free and fair, ITN should generally not report or indicate this characterization.
  2. If reliable independent sources generally describe an election as not free and fair and Wikipedia has an article surrounding this, consensus at ITN can develop to report or indicate this characterization.
  3. If reliable independent sources generally describe an election as not free and fair, consensus at ITN can develop to report or indicate this characterization.
  4. If reliable independent sources generally describe an election as not free and fair, ITN should generally report or indicate this characterization.

Should the following be added to WP:ITN/R:

  2. If reliable independent sources generally describe an election as not free and fair, consensus at ITN can form against posting the election.

1brianm7 (talk) 16:48, 30 July 2026 (UTC)reply

Background and examples

Background: At In the news, consensus has that the results of general elections are always significant and should be posted if the article is of sufficient quality. There has been an extended disagreement surrounding the posting of what some editors term "sham elections", those that are not free and fair. The most recent extended discussion on this topic is at Wikipedia talk:In the news#Sham elections, prompted by the nomination of the Guinean parliamentary election, and the second-most recent extended discussion is at Wikipedia talk:In the news/Archive 110#Legitimacy of elections, prompted by the nomination of the Russian presidential election.

The following are blurbs that were posted or proposed for ITN that follow each style:

1brianm7 (talk) 16:48, 30 July 2026 (UTC)reply

Survey (ITN elections)

  • Remove elections from ITN/R as the current formulation too often results in insignificant elections in microstates being posted while elections which are actually important such as the Mayor of NYC, the Scottish government or the Indian state legislative assemblies are denied. The nominal RfC question is badly formed because ITN/R doesn't determine the format of blurbs. The fact that such postings are often contentious is a further reason to have open discussion without any ITN/R constraints which lead some to suppose that elections should be posted in a mechanical, monotonous way. Andrew🐉(talk) 20:10, 30 July 2026 (UTC)reply
Your constant prejudice against the politics of small nations is duly noted. Again. However, the course of action you are calling for does not form part of any of the proposals currently under discussion. GenevieveDEon (talk) 21:14, 30 July 2026 (UTC)reply
ITN/R is explicit prejudice − an arbitrary list of supposedly important topics regardless of the actual coverage and facts. My position is that we should judge topics on their merits, not by preconceived prejudice. Andrew🐉(talk) 22:05, 30 July 2026 (UTC)reply
I think Andrew and Masem's allegations of non-NPOV selective posting and WP:RGW on WT:ITN are credible and should be investigated. Thebiguglyalien (talk) 01:15, 31 July 2026 (UTC)reply
I can agree that ITN should be more open to posting sub-national elections; the most recent NYC election was inarguably one of the biggest political news stories in the world last year. But instead of posting it, ITN - as per usual - shot itself in the foot by caring more about strict adherence to its incoherent set of unwritten rules than doing anything resembling what it's supposed to do. But I don't think this would be solved by removing national elections from ITN/R. ITN/R blurbs and RD postings are the only semi-functional parts of ITN precisely because they bypass these debates over what is "significant." We just need to stop making the mistake of acting like anything that's not ITN/R is automatically not blurbworthy at all. That, and nuke ITNSIGNIF, and maybe also replace our whole ITN/C community with different editors who'll be able to form a consensus to fix the broken mess that is ITN, because with every passing year I lose faith that the bunch we have now will ever be able to agree to do that.  Vanilla  Wizard 💙 21:01, 31 July 2026 (UTC)reply
  • Oppose instruction creep that doesn't appear to be well-justified by prior discussions. This more or less aligns with options 3/4, but I'm not seeing a reason why we need a separate instruction about this that wouldn't simply be subject to regular workshopping of the ITN hook to reflect RS coverage. Even when blatantly unfair, election results tend to be significant (if nothing else, confirming the intended continuity of the ruling regime), protests resulting from rigged elections can also be quite significant, and judging fairness is itself a gradient, not a binary. That having been said, I think that Andrew D's concerns above could perhaps be resolved by adding a clause that ITN should also run blurbs for elections for cities and dependencies with a population in excess of [2 million? 5 million? 10 million?] signed, Rosguill talk 20:21, 30 July 2026 (UTC)reply
  • Oppose instruction creep. I don't see any evidence that the status quo (option 3) is not working. How a blurb should be worded depends on the circumstances of the individual election and every other option is too rigid to account for this. I don't see any benefit in explicitly stating that consensus may be for or against mentioning how free and fair an election is. Thryduulf (talk) 20:48, 30 July 2026 (UTC)reply
    I would be glad if this RfC establishes 3 as a status quo. Some admins have removed any wording not in the fashion of "wins" from the main page, even when it was established at the nomination (link to ERRORS discussion). 1brianm7 (talk) 21:03, 30 July 2026 (UTC)reply
  • Oppose either of the options numbered 1, support any of the others, with a preference for option 3 - I think it's misleading to have a policy against mentioning the unfairness of an election if that unfairness is widely reported in reliable independent sources. I'm less concerned with the exact phrasing of the rule, but I do see the concern about instruction creep. With option 4, although I am in favour of its sentiments, there is the risk that the requirement to include such a reference might lead to such stories not being posted at all, because the nature of the reference cannot be agreed. Options 2 and 3 are both close to my understanding of the status quo, and clarify it. I do not think that we should specifically be avoiding posting elections simply because they are unfair - but I do have a preference for mentioning the unfairness. GenevieveDEon (talk) 21:14, 30 July 2026 (UTC)reply
    either of the options numbered 1 - I've rerenumbered the second option 1 to #5 to reduce confusion 1brianm7 (talk) 23:36, 30 July 2026 (UTC) reply
  • Remove ITN, first choice. Remove elections from ITN/R, second choice. Follow the sources, third choice. If the sources say it's a "sham" election, say that so-and-so won a "sham election." If they say it's a "rigged" election, ITN should say so-and-so won a "rigged election." If they say it's an "election with widely-reported irregularities," then we should say so-and-so won an "election with widely-reported irregularities." Levivich (talk) 21:25, 30 July 2026 (UTC)reply
    Follow the sources on ITN? An interesting idea, but we'd need to set up a sort of crash course at WT:ITN so they understand how sources are used on Wikipedia. Thebiguglyalien (talk) 01:13, 31 July 2026 (UTC)reply
  • Remove elections from ITN/R. This would solve the current problem and a host of others.Katzrockso (talk) 22:51, 30 July 2026 (UTC)reply
    It wouldn't really, since all those controversial / sham elections would be nominated under the normal ITN process... Khuft (talk) 18:59, 31 July 2026 (UTC)reply
  • Generally oppose, free is not a binary, fair is not a binary. Reporting purported election results without going over the same arguments repeatedly seems the purpose of the ITN/R entry, mandating freeness and fairness assessments will not aid with that goal. CMD (talk) 01:31, 31 July 2026 (UTC)reply
  • Oppose cover all in the same way and don't judge. The reader is not stupid and sees bias. Let's not give them more opportunity to see it.--Wehwalt (talk) 12:42, 31 July 2026 (UTC)reply
    If RS say one thing is an election, and another thing is a sham election, and we call both things an "election," we're misleading the reader. If RS say one thing is "X", and another thing is "called 'X' but not actually X," and we call both things "X", we're lying to the reader. On the main page. Dropping "sham" or "rigged" before "election" would be a lie of omission.
    "Free" and "fair" aren't just adjectives describing some kinds of elections, they're prerequisites for something to even be an "election." We shouldn't use the word "elect" when the reality is "appoint" (or "self-appoint"), even if government propaganda uses the word "elect." Levivich (talk) 13:26, 31 July 2026 (UTC)reply
  • Can editors opposing any changes mention whether they think the status quo is along the lines of "ITN participants can propose and gain consensus for blurbs that report or indicate an election not being free or fair" or whether it is "Any blurb that mentions an election not being free and fair is procedurally invalid and will be altered by ITN admins to omit it", and whether that extends to the subtle games with wording Masem mentioned below), even if ITN participants supported such a blurb. Anyhow, Support 3>4, oppose 1 and 2; whether an election was a sham is the second-most important thing after the result, on equal significance with the election happening. Support 5 - the fact that a military dictator decided they needed a fancy new title is not inherently significant. 1brianm7 (talk) 14:03, 31 July 2026 (UTC)reply
    Can editors opposing any changes mention whether they think the status quo is along the lines of "ITN participants can propose and gain consensus for blurbs that report or indicate an election not being free or fair" or whether it is "Any blurb that mentions an election not being free and fair is procedurally invalid and will be altered by ITN admins to omit it" this is a false dichotomy. Editors can reach a consensus to mention that, but if they haven't then it won't be included in the blurb. If admins are altering blurbs against consensus that's a problem that none of the changes proposed here can solve. Thryduulf (talk) 14:29, 31 July 2026 (UTC)reply
    I'm kinda at a loss here. Admins are doing that (see the discussion I linked in my reply to you above). When asked why, they said that's how it has always been done and to start a discussion at WT:ITN if you want it changed. I did, there was no consensus, so I started this RfC. What should I have done? 1brianm7 (talk) 14:47, 31 July 2026 (UTC)reply
    A significant contingent of editors respond to proposals to mention or indicate sham-ness by saying that there is an unwritten rule to never do so. I can't think of a way to prevent that simpler than a written rule saying that it is allowed. 1brianm7 (talk) 15:08, 31 July 2026 (UTC)reply
  • Oppose change, keep status quo / keep elections in ITN/R – "X is declared the winner of" is just a wordier way of saying "X wins". As mentioned before, the arguments on whether an election is "free or fair" is arbitrary and ITN editors will never agree. If protests are significant enough where they would normally merit a blurb, it would make sense to merge the two blurbs together. If reliable sources are reporting on a specific aspect of an election, such as voter turnout in the 2021 New Caledonia referendum or the recent Hong Kong election (in which the pro-China camp, pro-democracy camp, and international media all focused primarily on turnout), then it would also be appropriate to include that in the blurb when also reflected by the targeted article. Nice4What (talk · contribs) ♥ 14:35, 31 July 2026 (UTC)reply
  • Support this initiative in general; agnostic re exact wordings. I never really agreed with the "consensus" that we should use standardised wording when posting election results (sham or not). Our guidance should be what reputable sources say, and if they tend towards questioning the freedom and fairness of certain elections, we should be free to editorialise accordingly. (And: Keep all elections at ITN/R - not sure why that is even being questioned here as irrelevant to this proposal - the Russian "election" will be nominated anyway when it happens, whether as ITN or as ITN/R) Khuft (talk) 19:07, 31 July 2026 (UTC)reply
  • Follow the sources/target article language above all else. I guess this is an anything except 1 with a preference for 4 !vote? But it really does just depend on what the sources say. Wikipedia is not a publisher of original thought, ITN even less so. It should just be a chain of repetition: ITN should follow what the article says, the article should follow what the sources say, simple as. This should be the only thing that determines whether the language of the blurb can or should suggest that an election is contested, not what us at ITN have to say about it.
As CMD pointed out, it is not possible for us to cleanly and objectively separate "real" elections from "sham" elections because most countries on Earth don't fit neatly into a binary between true democracies and true dictatorships; it's a spectrum and most of the world is somewhere in the middle, and where exactly a country falls on that spectrum will vary from election to election as countries either backslide or democratize over time. This is why it needs to be determined on a case by case basis, based on what the sources say and how much weight article writers assign to those sources, how an election should be described. If the article can say the election was described by international observers as neither free nor fair, then ITN can. If the article can't say it, ITN can't say it. Easy as that, no need to complicate things or debate it at ITN/C. If this is contested, contest it at the article talk page, not ITN/C. The less leeway ITN gives itself, the better. Not just with regard to election blurbs, but all blurb discussions, because this mindset that ITN is somehow separate from the articles it features & gets to act as its own decisionmaking body with minimal objective instructions is really the root of every one of ITN's problems. Oppose removing elections from ITN/R, agree with Khuft that it's not really clear why that's even being discussed.
 Vanilla  Wizard 💙 20:41, 31 July 2026 (UTC)reply
  • Oppose. It's not for us to judge elections in such a way; we can note that observers view an election as unfair. Instructions creep, too. 331dot (talk) 20:55, 31 July 2026 (UTC)reply
    To be fair to the nom, the options provided are about how/if we should follow the sources, not leaving it up to us to judge elections ourselves. Noting that observers view an election as unfair is roughly options 2-4, but opposing all of them and forming no consensus here would leave us stuck with the current situation where the editors feel they are allowed to judge elections themselves. ITN doesn't have an instruction creep problem, but I wish it did. It has a "there are no instructions" problem.  Vanilla  Wizard 💙 21:16, 31 July 2026 (UTC)reply
    Exactly that we have no instructions. I'd note that about half of the oppose votes are doing so because there is no need to spell out the status quo (one) and another half are doing so because there is no need to spell out the status quo (roughly two or three). 1brianm7 (talk) 21:52, 31 July 2026 (UTC)reply
  • Oppose / keep status quo Pretty much agree with Nice4What. Readers can always click on the blurb's wikilink to the election page to learn more about the election, including its controversies. If "reliable independent sources generally describe an election as not free and fair", then that would usually be covered in the article's lead. Some1 (talk) 23:24, 31 July 2026 (UTC)reply
    From news style: To "bury the lead" is to begin the article with background information or details of secondary importance to the readers, forcing them to read more deeply into an article than they should have to in order to discover the essential points. - perhaps we should just adopt the format "John Smith is set to continue as president of example.", we wouldn't be deceiving the reader anymore (if they don't click on the link, which most won't) 1brianm7 (talk) 00:52, 1 August 2026 (UTC)reply
  • Oppose any changes. Any articles we post where they are described as shams should say as much in the articles in question. We don't need to editorialize in the blurbs or in what we post. All election blurbs say anyway are "[person] was elected as [title] of [country]", and that is all that needs being said in most cases. The article is the ideal place for expansion upon the circumstances around the election. DarkSide830 (talk) 01:08, 1 August 2026 (UTC)reply
    I think that's the whole issue that is being flagged here... "X was elected" implies a democratic process was adhered to, which isn't the case in sham elections. It is editorialising, but in the opposite direction (if that makes any sense) because it doesn't follow what reputable sources would be saying. Khuft (talk) 10:15, 1 August 2026 (UTC)reply
    "X was elected" implies a democratic process was adhered to I don't think that's true. It implies that an election was held and that that X was declared the winner of that election, but it doesn't imply anything about the nature of the election - after all whether a process is "democratic" or not is neither a binary nor objective, whether the defined process (whatever its nature) was followed is frequently not knowable until days or weeks (at least) afterwards and sometimes contentious. For example whether the 2020 United States presidential election was "democratic" and whether the defined process was followed depends on who you ask - e.g. those who believe Donald Trump's claims, those who believe the Electoral college is not democratic, etc. Thryduulf (talk) 20:04, 1 August 2026 (UTC)reply
  • Oppose change This proposal seems to rely on a biased view that free and fair elections is the control stage and any departure from it needs to be indicated. In the same way we don't characterise elections as 'free and fair', there's no point to do so if they're 'non-free and unfair'. In any case, the reader can view the article for further details. Democracy is a view, not a universal rule. --Kiril Simeonovski (talk) 21:08, 1 August 2026 (UTC)reply

Discussion (ITN elections)

An issue that I've raised is that the determination of what is or isn't a sham election, or what is or isn't a free-and-fair election, is not an objective meausure. There are election watchdog groups that will review an election and sometime after the election will assess the free-and-fairness but not in time for ITN's purposes; and even if these groups deem an election to be a sham, their statements should be included with attribution as other similar groups (like SPLC for hate groups), to keep it out of wikivoice. Which leaves us with journalism commentators making that assessment at the time of the election, which we should avoid resting too much weight on even if it seems clear they are correct. ITN's blurbs need to stay factual as they are all in wikivoice - we don't have room for attribution or sourcing like article space has, so trying to force in a claim that an election was a sham or not free-and-fair just doesn't work. We can play subtle games with the wording, de-emphaizing "win" and more "selected" or "named" in the cases of such elections like in Russia, though we should also be consist with that across known free-and-fair elections too. Masem (t) 13:37, 31 July 2026 (UTC)reply

It is also worth noting that there are times when different observers have different opinions about how free and fair a given election is (although usually only in degree). Thryduulf (talk) 13:58, 31 July 2026 (UTC)reply
The alternative just as problematic - we present an election as-if it were a true election ("Russia elects" or "Putin wins"). "wins" and "elects" have specific implications and invoke particular meaning for a reader, so it is simply not neutrally reporting the facts if in fact we are reporting on a sham election. Instead, we would be misinforming our readers. Katzrockso (talk) 22:09, 31 July 2026 (UTC)reply
+1 - If there is clearly a dispute over whether an "election" was really an election at all, and there is due weight to note this in an article lead, then presenting the event as an election in Wikivoice with no qualifiers is very much an NPOV vio. NPOV is about giving due weight to relevant perspectives, failing to do this is not neutral. The only sensible solution is to assess the sources and the article content to determine whether there is due weight to present an election as contested. Writing "Vladimir Putin wins the Russian presidential election" with no asterisks as though it were a totally normal and legitimate election is just as much of a WP:WEIGHT vio as "Joe Biden is declared the winner of the United States presidential election amid allegations of fraud"; both unduly promote a WP:FRINGE perspective.  Vanilla  Wizard 💙 23:11, 31 July 2026 (UTC)reply
The problem is whether an election is a sham or not , regardless of how many journalists are commenting on it within the days of that election, is subjective and cannot be said in wikivoice. It falls under NPOV that the claims should be attributed and given context which is fine in the article body, but in the short sentence we have at ITN, we have no room for attribution and context. (This is true for all ITN blurbs, they have to be presented in wikivoice so must be demonstrated fact and not subjective assessments). WEIGHT obviously applies in article space as to put the sham aspect up high in the lede, but obviously outside wikivoice, eg: "Putin wins the Russian president election in what many observers consider as a sham election." but that's language that can't work at ITN. Masem (t) 01:12, 1 August 2026 (UTC)reply
That's why there are wording formats we can say that do not imply that the election was a fair one without going there, like "X is elected as president in the 2026 Y election." That applies if the election was fair or not, but we should be using that same format for all elections so that we're clearly not putting our finger down on the marker. Masem (t) 01:07, 1 August 2026 (UTC)reply

Remove deprecated "Start a new discussion" button

As a follow up to issues with comment metadata mentioned at VPIL, I propose removing/replacing the above button on any discussion pages where it still exists, such as WP:AINB. This button predates discussion tools and doesn't add metadata when new sections are created the way the newer "Add topic" button does - see test edits [26] and [27]. Add topic floats so the old one could probably just be removed entirely (as appears to have already happened in some locations), but I wouldn't be adverse to replacing it with a duplicate instead if people prefer that.

Would also be interested in any other ideas to minimize similar issues on discussion pages, although I think aside from that they're mostly caused by manual edits so there may not be much else that can be done. ChompyTheGogoat (talk) 14:30, 31 July 2026 (UTC)reply

You didn't sign your comment in the first edit. Discussion tools relies on timestamped signatures to detect comments. Also note the generic add topic button doesn't allow for preloaded content. isaacl (talk) 16:17, 31 July 2026 (UTC)reply
That's my point. I'm not used to adding my signature manually because discussion tools handle that 99% of the time and made that exact mistake the first time I clicked on this button instead, and I've seen others do the same.
For preloaded content, you're referring to tools like Twinkle? I don't know enough about such things to know why Add topic wouldn't allow that, or if the functionality could be added to it, but a simple solution would be to leave this entry mode functional but remove the actual buttons, so that it's ONLY utilized by such tools (which typically preload the signature too afaik) and not manually. ChompyTheGogoat (talk) 16:30, 31 July 2026 (UTC)reply
@ChompyTheGogoat Preloaded content refers to the default text that is included when you click the "Start a new discussion" link at WP:AINB ({{AIC status|cleanup_status=requested|tracking_subpage=}} <!-- Valid statuses: requested, ongoing, unnecessary, completed. Update if needed! --> :::{{subst:void|Write your report below this line and sign with ~~~~}}). The good news is that that preload text explicitly says to sign with ~~~~, and if you do so all the "metadata" you mentioned will be added. For cases where there isn't preloaded text, adding &dtenable=1 to the url used by the button will cause it use Discussion tools, as you can see at WP:TEAHOUSE. --Ahecht (TALK
PAGE) 16:49, 31 July 2026 (UTC)reply
@ChompyTheGogoat, isaacl: Actually, it turns out that Discussion tools does support preloaded text. Just add &dtenable=1&dtpreload=1 to the URL and the button will open a Discussion Tools reply with the preloaded text. I would propose doing so on places like WP:AINB. --Ahecht (TALK
PAGE) 16:56, 31 July 2026 (UTC)reply
That works for me. (FYI, I'm assuming your struck out link was meant to be WP:TEAHOUSE?) ChompyTheGogoat (talk) 17:07, 31 July 2026 (UTC)reply

Idea lab

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

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)reply
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)reply
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)reply
There are some interesting subpages in this project. Like this one. Where did this come from? Sesquilinear (talk) 23:32, 3 July 2026 (UTC)reply
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)reply
  • 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)reply
    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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
But why keep it when we abandoned it for Consensus Point of View long ago? Hawkeye7 (discuss) 04:21, 6 July 2026 (UTC)reply
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)reply
@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)reply
I think thats a pretty good idea. User:Bluethricecreamman (Talk·Contribs) 21:10, 5 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
@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)reply
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)reply
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)reply

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

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

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

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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
Yes, ANI especially specialises in public humiliation, not great considering we’re all volunteers Kowal2701 (talk, contribs) 08:54, 30 June 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
Gnomingstuff's comment isn't a simple '''Support''' ~~~~ or '''Oppose''' ~~~~. sapphaline (talk) 17:42, 30 June 2026 (UTC)reply
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)reply
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)reply
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)reply
The AE participation restriction helps as well. SuperPianoMan9167 (talk) 20:26, 30 June 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
I think ANI being intimidating probably stops newer editors from reporting actionable conduct. InfernoHues (talk) 16:07, 2 July 2026 (UTC)reply
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)reply
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)reply
Guess I'll have to make a prototype then! Chaotic Enby (in solidarity · talk · contribs) 20:51, 2 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
Making it overly bureaucratic isn't the way to go
Why not? Governments run on bureaucracies. FaviFake (talk) 22:44, 31 July 2026 (UTC)reply
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)reply
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)reply
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)reply
I think that could work too, fellow CE. CaptainEek Edits Ho Cap'n!⚓ 17:52, 13 July 2026 (UTC)reply
Now we just need to get @The C of E on board! Chaotic Enby (in solidarity · talk · contribs) 18:03, 13 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply

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

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

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

notified WP:WER, WP:MENTOR, WT:AIC Kowal2701 (talk, contribs) 18:47, 7 July 2026 (UTC)reply
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)reply
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)reply
I'm aware of a handful of users like this, Aldorwyn of Rivendell is worth mentioning here. ‑‑gurkubondinn 17:28, 8 July 2026 (UTC)reply
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)reply
also Boomgaarden93 Kowal2701 (talk, contribs) 20:59, 7 July 2026 (UTC)reply
PeepeeDino has been doing some cleanup as well Gnomingstuff (talk) 20:01, 7 July 2026 (UTC)reply
PeepeeDino deserves a statue, I'll go make a wish Kowal2701 (talk, contribs) 21:01, 7 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
@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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
This is entirely optional too. No one is forced to either ask for or provide help. ChompyTheGogoat (talk) 04:11, 12 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
Notified: Wikipedia:Mentorship noticeboard. —ClaudineChionh (she/her · talk · email) 03:26, 8 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
idk I am wary of clique vibes Gnomingstuff (talk) 14:33, 8 July 2026 (UTC)reply
Agree we should avoid clique vibes an “on behalf of” goes to far. Dw31415 (talk) 14:47, 8 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
Would "The Vibe Coder" be a good enough substitute for "brainrot kid"? Somepinkdude (talk | contribs), in solidarity 22:14, 19 July 2026 (UTC)reply
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)reply
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)reply
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)reply
FWIW another type is the sock, spammer, LTA Kowal2701 (talk, contribs) 17:59, 9 July 2026 (UTC)reply
+1 on making it a user essay Dw31415 (talk) 17:43, 9 July 2026 (UTC)reply
+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)reply
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)reply
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)reply
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)reply
for what it's worth I don't see this excuse used very often on wiki Gnomingstuff (talk) 04:05, 10 July 2026 (UTC)reply
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)reply
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)reply
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)reply
@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)reply
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)reply

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)reply
(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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply

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

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

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

  • 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)reply
    I think the newcomer intro including what NOT to do is the most actionable. We have multiple current cases of good faith newbies who've written LLM content that now has to be dealt with, that might have been avoidable if they'd known it's not allowed before they started editing - which would prevent them from being discouraged by having a bunch of their first content removed. A simple checkbox that they understand and agree to WP:NOLLM would help prevent those cases and give the bad actors less of a leg to stand on. ChompyTheGogoat (talk) 18:52, 29 July 2026 (UTC)reply
    Yes, yes, a thousand times yes! It is tragic when people just don't know. I'm thinking in particular of the newcomer who enthusiastically joined an editathon, did a hundred good faith edits in an evening--they were a good sport about it, but what an awful introduction to Wikipedia! This seems like an easy change, good PR (reinforces the "for humans by humans" theme), no obvious downside other than cluttering signup a bit. To me that's well worth avoiding the (real) scenario I just described. M kuhner (talk) 18:54, 29 July 2026 (UTC)reply
    This was the first one that came to mind (but I scrolled past several others just looking for it). I think we'd want to try to find a way to implement it for returning post-LLM editors too, since that's a smaller but notable known group. They've made substantial edits to numerous live articles that cleanup has had to go over, in addition to their drafts, and they willingly participated at AINB as soon as they were informed that it's not allowed. These are exactly the editors we should be trying to retain. ChompyTheGogoat (talk) 19:31, 29 July 2026 (UTC)reply
    the edit-a-thon ones are particularly frustrating because these things sometimes have days or even weeks of training, so you would think there would be time to say "don't use AI" Gnomingstuff (talk) 18:37, 30 July 2026 (UTC)reply

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

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)reply
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)reply
? 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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
Great idea! Chaotic Enby (in solidarity · talk · contribs) 22:47, 19 July 2026 (UTC)reply
Yeah this is nice. Ilov3gam3z (talk) 00:13, 20 July 2026 (UTC)reply

"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)reply
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)reply
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)reply
(sentence or paragraph, mind you) Ilov3gam3z (talk) 17:16, 24 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
... 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)reply
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)reply
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)reply
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)reply

Automatically grant new page reviewer rights in certain circumstances

The initiator of this thread doesn't oppose the closure, so closing... (non-admin closure) --George Ho (talk) 10:56, 22 July 2026 (UTC)reply

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

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)reply
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)reply
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)reply
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)reply
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)reply
Why NPR and not autopatrolled? Autopatrolled doesn't require you to do anything, unlike NPR. sapphaline (talk) 08:11, 15 July 2026 (UTC)reply
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)reply
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)reply
"1000 unreverted, undeleted mainspace edits" in all time, not in a month/year/etc. sapphaline (talk) 10:02, 16 July 2026 (UTC)reply
I can confirm that this is my intended meaning. GrinningIodize (articles without a Wikidata item) (talk) 15:36, 16 July 2026 (UTC)reply
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)reply
Are there any people with 100,000+ edits who don't have autopatrolled? sapphaline (talk) 12:13, 15 July 2026 (UTC)reply
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)reply
100,000 edits seem extremely high. I would say 5 years + 5000 mainspace edits. Some1 (talk) 22:45, 15 July 2026 (UTC)reply
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)reply
(By 'long-term' I mean 20,000-200,000 edits over 15+ years.) Helpful Raccoon (talk) 01:10, 16 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
Should have clarified: A second pair of eyes from an experienced, knowledgeable editor. Jerod Lycett (talk) 05:18, 21 July 2026 (UTC)reply
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)reply

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

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

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

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)reply
@GrinningIodize: You okay with the whole thread being closed then? George Ho (talk) 03:07, 21 July 2026 (UTC)reply
I suppose that's alright with me. GrinningIodize (articles without a Wikidata item) (talk) 14:59, 21 July 2026 (UTC)reply
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)reply

Please go to Wikibin and search halfhill [28], you will get the article. Yesterday, all my dreams... (talk) 18:13, 16 July 2026 (UTC)reply
Or use Wayback Machine[29]. sapphaline (talk) 10:33, 19 July 2026 (UTC)reply
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)reply
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)reply
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)reply
Wikibin triggered my antivirus software, which seems a bad omen. CMD (talk) 02:59, 24 July 2026 (UTC)reply
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)reply
I'm only aware of WP:ATODAY, which is just the one site. WhatamIdoing (talk) 16:09, 24 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
That's what I needed, thanks! -- LWG talk (VOPOV) 16:35, 24 July 2026 (UTC)reply
You can get the page length, sha1, and tags from the API too, e.g. [30]. Anomie⚔ 22:57, 24 July 2026 (UTC)reply

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

Nothing needs to be done about it. WhatamIdoing (talk) 20:28, 19 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
  • 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)reply
    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)reply
    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)reply
    Yeah, I'm not entirely sure of the point of WikiProjects. Jerod Lycett (talk) 05:50, 21 July 2026 (UTC)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    Um... Which less active Wikiprojects then? George Ho (talk) 04:35, 27 July 2026 (UTC)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    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)reply
    You might be interested in the system shown at Wikipedia:WikiProject Medicine/Discussions. WhatamIdoing (talk) 06:58, 27 July 2026 (UTC)reply
    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)reply

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.

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

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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
@Velocifyer You can see your mentor at your Special:Homepage, if you have that enabled. CMD (talk) 14:36, 29 July 2026 (UTC)reply
@Velocifyer, your mentor is currently AlphaBetaGamma. They were almost certainly assigned to you when you created your account, or possibly when you explicitly opted in to mentorship. Can you see them in the Mentor module on Special:Homepage? Cheers, SunloungerFrog (talk) 19:45, 29 July 2026 (UTC)reply
I don't see them on [[Special:Hompage]. Velocifyer (talk) 21:06, 29 July 2026 (UTC)reply
You might have the newcomer page disabled in your preferences. ChompyTheGogoat (talk) 21:31, 29 July 2026 (UTC)reply

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

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)reply
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)reply
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)reply
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)reply
please say whatever it is you are trying to say directly Gnomingstuff (talk) 01:19, 24 July 2026 (UTC)reply
User appears to be a troll, and possibly a sock. ChompyTheGogoat (talk) 04:39, 25 July 2026 (UTC)reply
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)reply

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

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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
If the concern is abuse, why not limit it to semiconfirmed users? Amyipdev (talk) 00:44, 28 July 2026 (UTC)reply
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)reply
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)reply
Some anti-vandalism tools mark reverts of vandalism as 'minor'. WhatamIdoing (talk) 15:32, 28 July 2026 (UTC)reply

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:

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

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)reply
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)reply
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)reply
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)reply
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)reply
Support – Per nom, explained pretty well and would make it consistent. FaviFake (talk) 22:33, 31 July 2026 (UTC)reply

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

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

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

I smiled at that because there was an article today on BBC [33] 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)reply
Wikipedia shouldn't be known for a fight of flight culture. CostalCal (talk) 23:01, 28 July 2026 (UTC)reply
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)reply
Got it. CostalCal (talk) 02:06, 29 July 2026 (UTC)reply
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)reply
Trust me, we find out soon enough if we hang around for long. ChompyTheGogoat (talk) 18:55, 29 July 2026 (UTC)reply
I wonder about WP:Discord. In solidarity, Aaron Liu (talk) 14:23, 29 July 2026 (UTC)reply
This does seem aligned with Wikipedia:WikiProject Editor Retention, as has been suggested. I'm not on Wikipedia:Discord, but I can see the appeal of some place off-wiki that is closely associated with the project. I imagine various pros and cons to having all of these conversations on-wiki. I think there is something to this, just not sure what is should look like. —Myceteae‍🍄‍🟫 (talk) 19:32, 29 July 2026 (UTC)reply
The editor retention wikiproject was not set up to provide emotional support to editors or to discuss specific situations, but as a place for editors to discuss ideas regarding editor retention. isaacl (talk) 22:09, 29 July 2026 (UTC)reply
I wasn't suggesting using the editor retention project for emotional support, though I see now that I was unclear. Rather, I was suggesting folks there might be interested in or might already have ideas about this. I think it also makes sense to discuss here, and is more visible. I'll place a notice of this discussion on that project's talk page. —Myceteae‍🍄‍🟫 (talk) 22:57, 29 July 2026 (UTC)reply
How about this, I feel as if this is the best concept.
The name can be something like Wikipedia:Editor Support Circle
A peer space for editors going through a hard stretch (burnout, a permission loss, conflict, or just feeling discouraged) to talk it through with others who've been there.
Post under a new section with your username, saying how you're feeling and roughly what happened.
Example: "I lost my NPP flag after months of warnings. I know I moved too fast, but it still really hurts, and I don't know if I want to keep going."
Volunteers who've opted into the project reply. At first acknowledging the feeling, then (if the person wants it) help build a realistic game plan together.
A reply example reply: "That sounds rough, losing something you worked hard for. A lot of us have been through a version of this. Want to talk through what getting back on track might look like, when you're ready?"
The main goal for this is to give editors a space with no admin escalation, no policy citations unless asked for. This isn't a noticeboard.
Any user who meets Semi-protection (10 edits and 4 days) can post on here. CostalCal (talk) 22:25, 29 July 2026 (UTC)reply
A key challenge I see is finding enough people to provide support in a productive manner, without taking sides. Perhaps you can run a trial for a period of time and evaluate how helpful it was. Personally, I don't think any restrictions are needed on who can seek support. isaacl (talk) 22:44, 29 July 2026 (UTC)reply
On a related note, I think new editors can be encouraged to talk to their assigned mentor about any challenges they are facing regarding participation. I do think expectations need to be set (both with a support venue and with mentorship): personal emotional issues that go beyond interactions on Wikipedia aren't within the scope of Wikipedia editors to handle. isaacl (talk) 22:48, 29 July 2026 (UTC)reply
I think hosting it off-Wiki would be better, so that people can post anonymously if they don't want to be linked to their account (without any fear of socking accusations). ChompyTheGogoat (talk) 22:50, 29 July 2026 (UTC)reply
That sounds rough, losing something you worked hard for. A lot of us have been through a version of this. Want to talk through what getting back on track might look like, when you're ready?
I can't speak for anyone else, but I would find this incredibly obnoxious. If I wanted to get canned therapy-style responses then I'd just pay an actual trained therapist. Gnomingstuff (talk) 15:02, 31 July 2026 (UTC)reply
That phrasing honestly sounds like AI chatbot therapy. ChompyTheGogoat (talk) 15:15, 31 July 2026 (UTC)reply
@CostalCal: I'm sorry you're having a tough time, and thank you for bringing this up. We really can't afford to lose good editors who make some mistakes and get burned. As noted, the editor retention wikiproject isn't a place for support, but mentors are there to help editors one-on-one, and I think in theory, everyone who's created an account in the past few years is assigned a mentor, even if they never need one. What you're describing is a bit beyond the kinds of help that mentors usually provide, so I think we'd need to hear from some active mentors and I'm going to mention this discussion at the new mentorship noticeboard.
I also think that having these discussions on-wiki is maybe not the best idea, as editor support of this nature could go into territory that you don't want preserved indefinitely in revision histories. Maybe after an initial post requesting support, this could be followed up off-wiki, though everyone has our own preferences regarding email, Discord, or other communication channel. —ClaudineChionh (she/her · talk · email) 23:24, 29 July 2026 (UTC)reply
I think we need to be cautious about private communication channels. As I alluded to, I think there is a risk of a volunteer being given information that they'd rather not be privy to, or for which they aren't willing to provide support. isaacl (talk) 00:12, 30 July 2026 (UTC)reply
It would be "use at your own discretion", of course, and a disclaimer would probably be a good idea - something describing that the intended purpose is to discuss matters related to Wikipedia and expecting people to more or less follow TP guidelines here, just with anonymity to keep their concerns separate from their account - not a free for all/substitute for therapy. I wouldn't recommend Gmail - I think Discord is probably the best option for limited fully anonymous support. No records or tracking. ChompyTheGogoat (talk) 07:15, 30 July 2026 (UTC)reply
I think that private communications have problems, but public communications are terrible, and on-wiki comments are subject to Anything you say can and will be used against you forever. WhatamIdoing (talk) 20:01, 31 July 2026 (UTC)reply
Indeed. I would not suggest that anyone do this kind of thing on-wiki. @ChompyTheGogoat, Discord does have records - anyone can join and search back through all the posts in public channels. There's no simple way to delete a direct message thread, either. But I do agree that it's much better than having that kind of discussion fully in public.
I would encourage editors to make offwiki wikifriends wherever they can - via in-person meetups, chat programs, email, whatever. People with strong social bonds are more likely to stick around. But I'd also advise anyone feeling burnt out to go rant about it to someone who isn't a Wikipedian. It's a different kind of therapeutic. Also, they're quite likely to tell you that whatever you're mad about is a dumb thing to be mad about, in the grand scheme of things, which can be a necessary reality check. In solidarity, asilvering (talk) 22:18, 31 July 2026 (UTC)reply
My mistake - I must have confused it with something that has vanishing messages.
I agree that it's important to have off-wiki friends to talk to as well, but I think there may be times that people want to talk about specifics that are too difficult to explain to anyone who isn't an editor. ChompyTheGogoat (talk) 00:03, 1 August 2026 (UTC)reply
@ClaudineChionh, @ChompyTheGogoat, and @Isaacl I hear your suggestions. I agree that posting anonymously on an off-wiki is a serious possibility. I want this to be how your behavior/thoughts affects your Wikipedia life, not a fix my entire life platform. User:ClaudineChionh, thank you for putting this on the Wikipedia:Mentorship noticeboard talk page. @User:Isaacl brings up a good point when saying that brining this to Discord or Gmail may hurt privacy and may hurt engagement with user. This project will probably need some time and attention to sort out. I proposed this less than 30 hours ago. CostalCal (talk) 00:37, 30 July 2026 (UTC)reply
I think we're asking for trouble with this. What we want is to encourage editors to detach their personal emotions from Wikipedia, providing this kind of support only does the exact opposite; it encourages people who have let onwiki business affect their real mental state to stay in the ecosystem instead of disconnecting.
The main thing that stressed editors need to hear is that if you're at a point where business on Wikipedia is causing you real mental distress, you are far too invested in Wikipedia, and you need to log off, touch some grass, pet a cat, hug somebody, go for a run; whatever. Leave for however long you need to leave until you can return with a level head. There is literally not a single thing on Wikipedia worth getting yourself in real-life stress over. Athanelar (talk) 13:02, 30 July 2026 (UTC)reply
I think that it's okay if experienced editors want to take a WikiBreak. I don't think they should feel obligated to talk it out first. Sometimes people want to step away, for a short time or a long time, and that's okay. SomeoneDreaming (talk) 14:38, 30 July 2026 (UTC)reply

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

  • 1. Grief counseling can not be done in public. It must be private. But no mechanism for that has been suggested.
  • 2. Finding enough counselors will be a challenge. And who said they know how to counsel?
  • 3. Informing all experienced users that the project exists and convincing them to open up and use it may be difficult.

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

This isn't intended to replace real therapy. Community support is important for mental health too - I think it should be peer to peer interaction, not something with self designated "counselors". I'd see this as an intermediate step, when people are just frustrated and need to get things off their chest. Knowing when to walk away is important too, but they're different solutions depending on the situation. Sometimes venting and feeling heard is all it takes for someone to move on from something. Getting outside input might help people recognize when a break IS called for too - I agree that "stay at all costs" wouldn't be a healthy mindset to base it on. ChompyTheGogoat (talk) 05:42, 31 July 2026 (UTC)reply
I agree. Yesterday, all my dreams... is the only editor in this thread to interpret this, or to refer to this as, "counseling" and specifically "grief counseling". There are plenty of valid concerns expressed and limitations identified throughout this thread, but I don't think it's helpful to put the entire idea under the "grief counseling" umbrella. Also, support or guidance might include recommendations to step away or limit participation, even if temporarily. —Myceteae‍🍄‍🟫 (talk) 20:33, 31 July 2026 (UTC)reply
@Yesterday, all my dreams..., @ChompyTheGogoat, and @SomeoneDreaming Wiki-break suggestions are mostly effective. I also agree, that telling people to stay without a doubt is sometimes not the best advice. Honestly, with how this has been going, I am starting to doubt if my plan will succeed. It looks to be too logistically challenging, and the off-wiki/on-wiki privacy concerns are valid. However, I am a firm believer in a change to Wikipedia's culture. We can't just expect everyone to know what they are doing 100% of the time. CostalCal (talk) 23:58, 31 July 2026 (UTC)reply
I want to add that if Grief counseling were to be private, that means that the counselors actions could not easily be reviewed. Editors depend on each other to hold each other accountable and if it were private, you could have somebody offering very bad advice go undetected for some time. - Otherwise (Antibacklog Aktion!) (talk?) 21:49, 31 July 2026 (UTC)reply
Yeah, that kind of one on one interaction is best left to real therapists. I definitely think this would need to be more of a group environment (if it happens at all) so you can potentially get input from multiple people. ChompyTheGogoat (talk) 00:00, 1 August 2026 (UTC)reply

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

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[34] with the Spanish Wikipedia version [35], for instance. Seems like the user didn't carry the sources/references over. Some1 (talk) 03:54, 29 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
Would the bot just tag them or would it revert the edits? Velocifyer (talk) 14:15, 29 July 2026 (UTC)reply
Reverting would be difficult, as some of these edits have existed for quite a while. Adding the {{Format footnotes}} template would likely be best, as its documentation says to add it to pages containing "manual numbers" instead of proper citations. FlammablePizza (talk) 14:32, 30 July 2026 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
These are almost always an indicator that the article was AI-generated. sapphaline (talk) 12:25, 29 July 2026 (UTC)reply
Or as Some1 notes above, translated/copy-pasted between windows or programs without paying attention. -- Reconrabbit (talk) 13:39, 29 July 2026 (UTC)reply
Using an insource: search [36] 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)reply
[37] would be a better search, though there's a ton of false positives. sapphaline (talk) 13:19, 29 July 2026 (UTC)reply
[38] has few false positives but only finds 84 cases. It may be useful to find genuine problems which this search misses and improve it to cover them. Certes (talk) 17:28, 29 July 2026 (UTC)reply
This is helpful, thank you! I've run into "[1]" style fake footnotes on articles with content copy-pasted from Grokipedia, so I'm interested in looking for more of that. This type of search is great in combination with mw:Who Wrote That?. Dreamyshade (talk) 20:29, 29 July 2026 (UTC)reply
1346 in Ireland is interesting: its fake footnotes started out as useless wikilinks to numbers such as [[1]]. I removed bad links to small integers some time ago. Those that remain do refer to the integer or glyph, though in most cases we could reasonably have assumed that the reader already knows what 1 is. Certes (talk) 21:38, 29 July 2026 (UTC)reply
I would argue that (assuming the source actually supports the article) that it should be treated as a general reference. In references it says [1] to [16] are all from the same source. It says nothing at all about reference [17], which seems odd. Mitchsavl (talk) 21:56, 29 July 2026 (UTC)reply
World Surf League gained many of its fake footnotes in this revision. They don't seem to match any of the actual (unnumbered) footnotes present at the time, but do look convincing in their <sup>...</sup> tags. I think it's simply the number of times the individual has won the event: [2] means second win, etc. WikiBlame was useful here. Certes (talk) 21:54, 29 July 2026 (UTC)reply
2C-B (a drug) has [4] etc. in quotes within the references section. The quotes are unusually long and may be lifted straight from the cited paywalled source, which presumably has a Wikipedia-style reference section of its own (not included). So they look like references used by cited works. The main issue here may be whether we want or are allowed to include such long verbatim quotes. Certes (talk) 22:11, 29 July 2026 (UTC)reply
In War crimes in the Syrian civil war, reference 33 is itself a list of numbered references. It's not clear which of them, if any, support the article's claims marked with a real [33] footnote. I'll stop now, as sadly it seems that every article has a different problem and there's unlikely to be a one-size-fits-all solution which could be semi-automated. Certes (talk) 22:14, 29 July 2026 (UTC)reply

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

For reference regarding currently available methods: on desktop, you can use the home button on your keyboard. The default browser on Android devices unfortunately doesn't have the tap-on-status-bar shortcut offered by iOS to scroll to the top, so you'd have to install an extension that implements this functionality (or use another browser; reportedly the Samsung web browser provides a method to scroll to the top). isaacl (talk) 16:51, 29 July 2026 (UTC)reply
I am not asking for help; I am asking for this to be a feature on Wikipedia itself as it would help lots of editors and readers, not just for me. Fence127 (talk) 17:04, 29 July 2026 (UTC)reply
I thank you for the info though. Fence127 (talk) 17:06, 29 July 2026 (UTC)reply
You're welcome. I provided this info for all editors and readers, as it will help them on all web sites, not just Wikipedia. isaacl (talk) 17:22, 29 July 2026 (UTC)reply
What about it being added to Wikipedia for accessibility and convenience purposes? Fence127 (talk) 17:23, 29 July 2026 (UTC)reply
Personally, I think universal methods that apply to all web sites are more useful and satisfy both accessibliity and convenience. isaacl (talk) 17:28, 29 July 2026 (UTC)reply
I don't have this issue on most websites, because they don't hide my notifications and other important links at the top when I'm miles down a discussion page. Most that do involve that much scrolling have set up a sidebar or some such workaround. We already have "Return to reply"; it shouldn't be that difficult to implement a comparable "Back to top" option. Even on desktop it can be mildly annoying since my user menu won't appear if I'm 1mm shy of the very top of the page. (I'd prefer a floating menu TBH, but presumably that would take more work.) ChompyTheGogoat (talk) 19:01, 29 July 2026 (UTC)reply
FWIW I have no less than three browsers on my phone, and none of them have that function. It's just not native to the environment because we don't need it. A lot of extensions don't work on mobile either, so you're asking people to track down a custom one built specifically for Android phones to solve a problem we don't have on most websites. ChompyTheGogoat (talk) 19:04, 29 July 2026 (UTC)reply
Hell, I've got a floating Add Topic on upscroll already on discussion pages (replaced by the Return to reply once a comment is started). Just drop Back To Top next to that. Solved. ChompyTheGogoat (talk) 19:39, 29 July 2026 (UTC)reply
Wikipedia:Back to top allows you to add a back to top button alongside section headers. Apparently it only works on pages you can edit, although that is likely to be most of them. Thryduulf (talk) 18:29, 29 July 2026 (UTC)reply
I believe that its unlikely to ever be added to core MediaWiki. In my opinion, it has potential to be an optional gadget at best. I did try making a userscript here though and it is a pretty nice feature to have. FlammablePizza (talk) 16:53, 30 July 2026 (UTC)reply
For me, the script doesn't work. Fence127 (talk) 17:19, 30 July 2026 (UTC)reply
I just checked and it looks like you didn't install it. You have to copy that installation line found in the script's instructions and put it in your common.js file at User:Fence127/common.js FlammablePizza (talk) 17:26, 30 July 2026 (UTC)reply
Ok. Fence127 (talk) 17:30, 30 July 2026 (UTC)reply
Nada. ChompyTheGogoat (talk) 23:08, 30 July 2026 (UTC)reply
@Fence127: A template for this exists, {{skip to top}} (as well as the oppposite, {{skip to bottom}}). It's used, for example, at Wikipedia:Help desk. However, a past discussion at Wikipedia talk:Village pump (technical) § Skip to top and bottom showed that some editors really dislike these template and objected to their addition to village pump pages. I imagine doing this for all editors by default via some other method may see similar objections.
Regardless, some editors do like these templates and wanted them on every page, and one of the participants made a script to accomplish that. See User:Qwerfjkl/scripts/skipToTopAndBottom.js. – Scyrme (talk/solidarity) 23:27, 30 July 2026 (UTC)reply
Why not make it an optional setting? Trying to fix everything with user end scripts is both annoying and problematic (I've already installed two that failed - this makes at least three created for the same purpose). ChompyTheGogoat (talk) 23:43, 30 July 2026 (UTC)reply
Make sure you forcibly reload the page after installing a user script (ctrl+f5). There are quite a few userscripts, but its because many people prefer different styles or functionality. The default script is the most unintrusive and adds it to section headers, but doesn't work on all pages. Qwerjkl's adds both skip to top and bottom buttons. I made mine to match the built-in theme closer (both light and dark modes) than some other scripts and also be unintrusive. FlammablePizza (talk) 23:52, 30 July 2026 (UTC)reply
That's not a thing on mobile. I have to manually clear my cache - which makes script workarounds extra annoying - which I did, and they still don't work. Even in desktop mode. ChompyTheGogoat (talk) 00:27, 31 July 2026 (UTC)reply
Totally agree. Fence127 (talk) 06:44, 31 July 2026 (UTC)reply
Much testing later:
I got Back to top working (after modifying the script). It only shows on expanded section headers, and NOT on any discussion pages that I tried, including ones like here and Teahouse as well as Talk pages. That's where I really need it, so it's effectively useless.
I got FP's Scroll to top working - in desktop mode only, and my default browser on my phone refused to recognize it. Once again, useless where I need it most.
Finally, Skip to top and bottom more or less works in both mobile and desktop on all pages using my default browser on my phone. The float action is a bit funky, and there's a duplicate pair in desktop mode on Teahouse, which appears to have it installed manually (which created confusion while I was testing). I appreciate having both options, since I frequently have to scroll down as well to toggle in and out of desktop mode for the sake of functionality (this could stand to be easier too).
It took me three scripts and three browsers across two devices to find a reasonably workable solution for something that could be as easy as a single preference checkbox. This is how a lot of things on Wikipedia are, and it gets extremely frustrating just trying to force the website to be reasonably functional. Don't even get me started on how difficult editing is from mobile in the first place. At least now I can stop accidentally reloading the page and being autoscrolled back down when I'm attempting to scroll to the top just to access my menu. ChompyTheGogoat (talk) 09:52, 31 July 2026 (UTC)reply
Oh, cool - they like to randomly disappear on my actual desktop computer. At least I have a mouse and scroll wheel here. ChompyTheGogoat (talk) 09:55, 31 July 2026 (UTC)reply
FYI, I can't use my account on my PC. Fence127 (talk) 10:02, 31 July 2026 (UTC)reply
I can, but mostly use my phone these days for reasons. And it appears these buttons vanish as soon as I submit a comment on either device, making it only semi-functional. Sigh ChompyTheGogoat (talk) 10:07, 31 July 2026 (UTC)reply

There likely needs to be a 'project' type thing for missing towns and settlements

I was browsing the pages on Florida county roads -don't ask- and saw a lot of red links. Mostly for towns and settlements, too. I always thought every town that has people and every former town worth talking about had an article, but alas I was proven wrong. How naive of me but it is what it is.

Since there are thousands of settlements in my state (Georgia, as seen on my user page) alone, and hundreds of thousands across the USA and Europe, many of which have no representation or knowledge outside of natives and family of natives, there likely needs to be a sort of WikiProject in this area.

I wouldn't be too surprised if this exists already and I simply never heard of it, and I appreciate opinions on the matter. This is just the ramblings of a nerdy parakeet though and if this didn't take up any steam then it's nothing new for me. Have a great day editors! TheNerdy Parakeet (talk) 21:23, 29 July 2026 (UTC)reply

Update- upon doing some actual research instead of saying my thoughts and seeming not knowledgeable I found Wikipedia:WikiProject Cities and now my words of 'there needs to be a project for this' look foolish, at least to me. But I found that my take is not covered in the project, so at least I had a semi-original thought. TheNerdy Parakeet (talk) 21:34, 29 July 2026 (UTC)reply
(edit conflict) WP:Wikiproject Cities exists. There needs to be enough material on a given town to be able to write about it though, as well as an editor who cares enough to bother. That's likely not the case for many small towns. ChompyTheGogoat (talk) 21:35, 29 July 2026 (UTC)reply
WP:WPGEOG also exists, as do multiple related descendant projects. Wikiprojects in my experience suffer from low participation. Editors generally spend more time actually editing the articles they are interested in, and the projects provide some essays and guidance, but little in the way of collaborative assistance on specific articles. GeogSage (⚔Chat?⚔) 21:44, 29 July 2026 (UTC)reply
WP:NPLACE (aka WP:GEOLAND and other shortcuts) has notability guidelines for settlements. I believe it has caused some consternation in the past when large numbers of stubs of were created for tiny settlements. WikiProjects are a mixed bag. Some are quite active, most are not. You might have better luck looking at more locally based projects focused on a state or country. Wikipedia:WikiProject Georgia (U.S. state) appears inactive but Wikipedia:WikiProject Florida has quite a bit of activity on its talk page. —Myceteae‍🍄‍🟫 (talk) 22:09, 29 July 2026 (UTC)reply
Thanks for all the tips! I appreciate the help and will probably use these WikiProjects to further my idea. Happy editing! TheNerdy Parakeet (talk) 13:49, 30 July 2026 (UTC)reply
You're welcome, happy editing to you! —Myceteae‍🍄‍🟫 (talk) 14:24, 30 July 2026 (UTC)reply

Sub-referencing

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

I think this is a really good change; it will make citing books, journal articles, etc. so much easier. voorts (talk/contributions) 00:07, 30 July 2026 (UTC)reply
Oh good - I just stumbled across an article badly in need of such a thing. ChompyTheGogoat (talk) 07:06, 30 July 2026 (UTC)reply
Maybe, but not until sub-referencing has been established here for a while such that there is clear evidence that it works in practice on the English Wikipedia for various types of articles (including large lists that make extensive use of the same publication). Only when editors can clearly see whether it is actually a significant improvement over the alternatives will any discussion about deprecating any type of referencing style have a chance of being productive, especially as there was a lot of scepticism at Wikipedia talk:Citing sources#Support or oppose deprecation that subreferencing is an improvement over {{rp}}. Thryduulf (talk) 09:41, 30 July 2026 (UTC)reply
I support this in principle (and in general think we should make citations more consistent) but IMO it is best to hold off on determining this until subreferences have been enabled and we’ve had a few months to battle-test them. Mir Novov (contribs | talk) 12:12, 30 July 2026 (UTC)reply
I agree with Thryduulf and Mir Novov. I'm looking forward to sub-referencing, and plan to convert several articles that I created to that style when it's rolled out, but we need to put it through its paces and demonstrate that it's both workable in practice and is an improvement on sfn/rp before proposing widespread conversion. Schazjmd (talk) 13:11, 30 July 2026 (UTC)reply
What is there to test? It's already active on several wikis and there's full documentation of how it works/what it looks like. voorts (talk/contributions) 13:17, 30 July 2026 (UTC)reply
It isn't in use on the English Wikipedia yet. Editors don't know how it works in practice with the articles they read and write on this wiki in combination with all the policies, style guidelines, templates, conventions, etc. that we use on this wiki. There is no experience of how much effort it takes to convert from either sfn or rp to subreferencing. I don't understand why you're in such a rush here? Thryduulf (talk) 14:41, 30 July 2026 (UTC)reply
I'm not in a rush. I figured I'd get the conversation started since it should be coming over here soon. I'm also not sure how any of this could possibly conflict with any PAGs. It looks like a very straightforward system. voorts (talk/contributions) 15:14, 30 July 2026 (UTC)reply
However likely it may or may not seem, until I've seen it actually stress tested I'm not going to say that can't possibly conflict with anything. Thryduulf (talk) 15:26, 30 July 2026 (UTC)reply
This looks promising, but mandating sub-referencing and deprecating {{sfn}} and {{rp}} would be a major departure from WP:CITEVAR. —Myceteae‍🍄‍🟫 (talk) 14:58, 30 July 2026 (UTC)reply
There's some precedent in the deprecation of parenthetical referencing. Anomie⚔ 15:02, 30 July 2026 (UTC)reply
Good point. I don't think we can't deprecate these but it would be a big change. It's reasonable to have some discussion now though I agree with the sentiment many have expressed that we can't fully anticipate the impact until these go live. —Myceteae‍🍄‍🟫 (talk) 18:53, 30 July 2026 (UTC)reply
Thinking about it probably wouldn't hurt, but actually pushing for deprecation needs to wait until editors here have some experience with the new mechanism, as others above have already stated. Personally, I suspect that {{rp}} would be easy to bot-convert the majority of uses (assuming we could get consensus to actually do it), but {{sfn}} would likely need human attention and people discussing trade-offs between conversion using inline refs versus LDR. {{r}} possibly also needs some consideration; it seems to be a kitchen-sink that tries to do everything, so someone would need to re-plumb the {{rp}}-like parts of it.
When the time comes to have the deprecation discussions, I suspect we might get better results by tackling {{rp}} and {{sfn}} separately instead of trying to discuss both in the same discussion. In particular, I'd expect a combined discussion to get bogged down with people arguing to keep {{sfn}} (e.g. people who really like having a "bibliography" section ordered alphabetically by author, while sub-refs would order it by first use) while ignoring {{rp}}. Anomie⚔ 15:01, 30 July 2026 (UTC)reply
How does this make {{sfn}} "obsolete" when it doesn't produce an alphabetical list of sources? I could understand if you just think an alphabetical bibliography is redundant and unnecessary, so prefer other referencing styles, but that's a personal preference; it doesn't make {{sfn}} obsolete, it just makes it not to your taste.
My main problem with sub-referencing compared to {{sfn}} is not actually the lack of bibliography. It's that subrefs are less concise in the source code than {{sfn}} citations and that, like "main references", subrefs still use entirely arbitrary labels instead of consistently using last names and years like {{sfn}}. As with typical <ref>...</ref> references, that often results in duplication of references as well as making it easier to provide incomplete references (missing authors, missing dates) without any warnings, error tracking, or pushback.
Compare: <ref name="ARBITRARYLABEL" details="p.&nbsp;23." /> to {{sfn|Johnson|Smith|2005|p=23}}. The subref doesn't seem any easier to use, is less concise, may require finding the arbitrary label a previous editor decided to give your source, and doesn't handle the &nbsp; for you. My point isn't that sub-referencing is bad actually. My point is only that it's not a straight upgrade to {{sfn}}, which handles some things better and other things (like, eg, references that don't use {{cite}} templates) worse.
If you like sub-referencing, great, but by itself it won't make {{sfn}} obsolete. – Scyrme (talk/solidarity) 17:15, 30 July 2026 (UTC)reply
I use sfn only because I have to and rp absolutely sucks. It would've been great if this feature existed when I started editing. I'm less concerned about wiki text. voorts (talk/contributions) 17:20, 30 July 2026 (UTC)reply
It's not just wikitext though. Tracking down where short refs came from when the labels are arbitrary is more difficult. A lot of <ref>...</ref> references have labels like ":0", ":1", ":2". For a subref with such a label, it would be impossible to track down where it came from if content is copied from one article into another without copying in the mainref. You can try a search for the text itself, but sometimes the copied text comes from an old revision (so does not appear in search results). WikiBlame can help, but only if the edit summary provides attribution. {{sfn}} has similar problems, but at least with {{sfn}} there's a chance you can find the source again even without finding the original article the content was copied from. While Wikipedia requires copied content to be attributed, in practice this isn't always done. – Scyrme (talk/solidarity) 17:55, 30 July 2026 (UTC)reply
The ":0", ":1", ":2" references names are going to be going away too. See meta:WMDE_Technical_Wishes/References/VisualEditor automatic reference names. --Ahecht (TALK
PAGE) 18:09, 30 July 2026 (UTC)reply
Unless I'm misunderstanding something, those proposals would still produce extremely vague labels eg. "olympics" or "web_reference_1". Some participants on its Talk page supported author+year based labels; hopefully that that approach is what ends up being applied (where feasible, obviously). Even if the new automated system turns out to be excellent, a lot of articles already exist with weird and vague ref labels so I'm still concerned about the arbitrary labels. – Scyrme (talk/solidarity) 18:37, 30 July 2026 (UTC)reply
It may not produce an alphabetical bibliography, but it's also not as incredibly fragile as {{sfn}} which fails in any number of hard-to-debug ways on a regular basis due to things like two sources with the same last name in the same year, nested citation templates that require explicit whitelisting, etc. If you look in the WP:VPT archives, 8 out of the last 10 have someone seeking help with a Harv/Sfn no-target error. --Ahecht (TALK
PAGE) 18:03, 30 July 2026 (UTC)reply
Do people actually object if you change the "arbitrary label" to a systematic one? Anomie⚔ 18:38, 30 July 2026 (UTC)reply
I've never seen anyone object, but how many editors actually do that rather than copying whatever ref names are already there? – Scyrme (talk/solidarity) 18:52, 30 July 2026 (UTC)reply
The ones like you who care about it? Like everything else around here? 🙂 Anomie⚔ 19:05, 30 July 2026 (UTC)reply
Outnumbered by the editors who don't and continue to call references things like "ReferenceA2" (What does the "A2" even mean? There is no "A1"), or "PSSOM" (A partial acronym of the title; useless out of context), or "moved" (not an author, not a keyword from the title, just vague topical word association). These are real examples.
Maybe more editors will care if the rollout of subrefs results in the equivalent of sfn no-target errors because of content being copied around. Or maybe I've misunderstood something and subrefs are immune to this problem somehow, idk. – Scyrme (talk/solidarity) 20:35, 30 July 2026 (UTC)reply
I have a similar objection to replacing rp with this until the old extends= syntax is added. In solidarity, Aaron Liu (talk) 00:09, 31 July 2026 (UTC)reply
While I also wish they'd have gone with the extends syntax, I doubt they'll change course now when they haven't already. What exactly do you prefer about {{rp}}, that would be solved by the extends syntax? Anomie⚔ 14:00, 31 July 2026 (UTC)reply
It doesn't really present much of an advantage: <ref name="label" details="p.&nbsp;42." /> vs. <ref name="label" />{{rp|p=42}}, it's not much of a difference and the latter seems much easier to type. I feel like at least once I'd forget to add that period in the details attribute (yeah I'm still not over the semantics of content inside an attribute...). Stylistically, I also prefer seeing the page number as a superscript. (If the concern is that "[1]:42" is so obtuse that we're better off deleting the template, why not deprecate the colon style instead and change it to "[1] p. 42" or AMA style?)
Extends would've offered irreplaceable value of reusing <ref name="h2g2" extends="label">p. 42</ref> like normal references:<ref name="h2g2" />. In solidarity, Aaron Liu (talk) 14:52, 31 July 2026 (UTC)reply
{{rp}} doesn't work well with visual editor. This change is meant to make it easier to subreference for everyone. I think we need to move away from the idea that everything needs to be built for power users who edit in wikitext, unless we want editorship to continue declining. voorts (talk/contributions) 15:08, 31 July 2026 (UTC)reply
Could you elaborate on "doesn't work well"? I see no problem with it for me (except that it adds the full template name, which I don't think is a problem). I started out editing mainspace with visual editor for everything but tables, (and now I edit with the wikieditor for everything but tables), and I don't remember any difficulty with RP either. In solidarity, Aaron Liu (talk) 16:11, 31 July 2026 (UTC)reply
Personally, If the concern is that "[1]:42" is so obtuse that we're better off deleting the template is indeed the main problem I have with {{rp}}. Now that I look into AMA style, I at least see why some people may like {{rp}}: [1]: 42  is not terribly different from AMA's 1(p42). But I think the subref style still makes more sense for hypertext. Anomie⚔ 17:53, 31 July 2026 (UTC)reply
Agreed. Editors (particularly new ones) using virtual editor shouldn't need to use multiple templates for a single reference. It's clunky both for editors and readers. voorts (talk/contributions) 17:57, 31 July 2026 (UTC)reply
FYI, I was referring to the reading experience rather than the editing experience. Anomie⚔ 22:54, 31 July 2026 (UTC)reply
Besides my proposal to replace the colon with "p. ", rp actually already supports AMA style, too:[1](p42) I guess the encyclopedia would still be well (and dandy, even) if we replaced rp with hovered footnotes. A small problem I have with the current implementation is that you need to go down the references section to see the parent of the subreference and then click the correct link to go back up, but that is a very fixable implementation detail. In solidarity, Aaron Liu (talk) 21:55, 31 July 2026 (UTC)reply
Seems to work fine with the mw:Help:Reference Previews feature when I try it on testwiki. Wikipedia:Tools/Navigation popups does have the problem you describe. I don't know about mw:Reference Tooltips, that doesn't seem to be installed on testwiki to try it. Anomie⚔ 23:07, 31 July 2026 (UTC)reply
Oops, I had that installed so long I forgot it wasn't default :) You're right. In solidarity, Aaron Liu (talk) 19:24, 1 August 2026 (UTC)reply
I'm looking forward to seeing subreferencing being used on enwiki, but this is a conversation to have once it's been in use for awhile and editors have had experience of it. -- LCU ActivelyDisinterested «@» °∆t° 19:07, 30 July 2026 (UTC)reply
I agree, and I add that the most important part of 'experience' isn't necessarily the bit where some edge case only appears in one in a million articles, and therefore seven times here; the mist important part is people having seen this "weird" (aka "new") thing a few times. WhatamIdoing (talk) 01:22, 1 August 2026 (UTC)reply
It's just going to end up like that "15 competing standards' XKCD comic. PARAKANYAA (talk) 20:07, 1 August 2026 (UTC)reply
Link to the '15 competing standards' XKCD for anyone not familiar. Thryduulf (talk) 20:18, 1 August 2026 (UTC)reply
Unfortunately, this feels spot on. —Myceteae‍🍄‍🟫 (talk) 21:18, 1 August 2026 (UTC)reply

Talk Pages

Hi all,

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

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

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

I think that would get confusing due to how nested discussions are formatted. This comment needs to go below yours so that people know who I'm replying to. ChompyTheGogoat (talk) 23:46, 30 July 2026 (UTC)reply
I think they mean that replies should be left in a newest-to-oldest order instead of oldest-to-newest (like I've done right now). Honestly, I think that's a software problem. We could have long had a button to sort comments in either order if there was normal machine-readable metadata of discussions, if that metadata wasn't so easy to break, if the indentation wasn't so easy to break, etc. sapphaline (talk) 11:05, 31 July 2026 (UTC)reply
I'm not a fan of that within discussions. It gets messy (and as you noted, breaks easily). I'd be open to it as a sorting option for top level threads (which I think could handle metadata better via NTT). If implemented I would suggest also adding an option to either sort by Topic Started or Latest Comment, as well as being able to toggle between Z>A or A>Z. There'd be far too much pushback against just changing it automatically. ChompyTheGogoat (talk) 11:20, 31 July 2026 (UTC)reply
I think individual topics should remain as is and the wiki text remains as is (for purpose of mass archiving/editing) but an option to visually sort the view of topics from chronological/reverse chronological by topic creation and or “newest comment” would satisfy different people’s needs. For example on a long talk page where I read everything I’d love to quickly find the 4-newest comments either within one topic or across multiple topics. ~ In solidarity 🦝 Shushugah (talk) 11:49, 31 July 2026 (UTC)reply
Yeah, that's what I was getting at - I may not have explained it well. ChompyTheGogoat (talk) 12:24, 31 July 2026 (UTC)reply
@Shushugah, you might find commons:User:Jack who built the house/Convenient Discussions useful. It highlights all new comments ("new" since your previous visit) on talk pages. In the sidebar, it tells you how many new comments there are and you can use the arrows to quickly go from one to another. Huge timesaver. Schazjmd (talk) 13:39, 31 July 2026 (UTC)reply
Only works in desktop mode. Also tends to bog down my browser. Definitely useful overall, but this sort option would be a lighter/more convenient solution, especially on mobile. ChompyTheGogoat (talk) 14:00, 31 July 2026 (UTC)reply
I use CD on a phone and a tablet all the time, in fact I'm replying with CD on a phone right now. —ClaudineChionh (she/her · talk · email) 00:35, 1 August 2026 (UTC)reply
In desktop mode. I have it installed, it doesn't work in mobile mode, and bogs down in desktop. Like I said. Desktop is bulky and doesn't behave well on a small screen, but I have to swap back and forth sometimes because mobile doesn't have as much functionality - particularly when a discussion thread is umpteen levels of nesting deep and it tries to feed me comments in columns that are a single character wide, because everything here is built for desktop and often not well adapted to mobile. The app somehow manages to be even worse. ChompyTheGogoat (talk) 03:29, 1 August 2026 (UTC)reply
Oh, I see – I should have noted that I always use desktop mode (with the Timeless skin) and only use the app under duress. —ClaudineChionh (she/her · talk · email) 03:34, 1 August 2026 (UTC)reply
I'd just forgotten to uninstall it. Gone now. This might be the first time I've ever encountered a mobile website that's more functional than a single purpose app. ChompyTheGogoat (talk) 04:18, 1 August 2026 (UTC)reply
Yep that is pretty much my idea. Equivalent-Text2598 (talk) 12:56, 31 July 2026 (UTC)reply
Sorry, I meant threads. Equivalent-Text2598 (talk) 23:57, 30 July 2026 (UTC)reply
Some of you younger folk may not be aware that these arguments have been occurring in various places on the internet since before Wikipedia was born (I blame Microsoft Outlook). —ClaudineChionh (she/her · talk · email) 00:33, 1 August 2026 (UTC)reply
I pre-date Wikipedia as well. Amazingly, technology has progressed somewhat in the interim, and most websites tend to update functionality occasionally in order to improve the user experience. ChompyTheGogoat (talk) 03:33, 1 August 2026 (UTC)reply

Current events coverage

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

This is a perennial proposal, should we really have waited six months to cover things like 2025 Potomac River mid-air collision? Editors shouldn't rush to create articles about breaking news events, but equally they should not rush to nominate them for deletion either. My preference would be that any AfD whose rationale is or significantly includes things like NOTNEWS or recency would be speedily closed if initiated less then 5 days after the event (the speedy close would be completely without prejudice to a nomination once the event is 5 days or more old, the first AfD would simply be treated as if it never happened). Thryduulf (talk) 20:13, 31 July 2026 (UTC)reply
Some things will obviously continue to be notable, like that plane crash. Other things, like most of the crimes that get articles created about them, will not. voorts (talk/contributions) 20:20, 31 July 2026 (UTC)reply
I'm going to give into the urge for once, and provide a copy of NOTNEWS for anyone who hasn't read it in, oh, say, ever:

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

  1. Original reporting. Wikipedia should not offer first-hand news reports. Wikipedia does have many encyclopedia articles on topics of historical significance that are currently in the news, and can be updated with recently verified information.
  2. News reports. Wikipedia considers the enduring notability of persons and events. While news coverage can be useful source material for encyclopedic topics, most newsworthy events do not qualify for inclusion and Wikipedia is not written in news style. For example, routine news coverage of announcements, events, sports, or celebrities, while sometimes useful, is not by itself a sufficient basis for inclusion of the subject of that coverage (see Wikipedia:Notability (events) § Routine coverage for more on this with regard to routine events). Also, while including information on recent developments is sometimes appropriate, breaking news should not be emphasized or otherwise treated differently from other information.
I suspect that the main difficulty is editors having differing opinions of what constitutes a "significant" current event. For example, I remember someone arguing that 2025 conclave should not have been created until after it was over (or was it until the first scholarly papers had been published?), whereas other editors might draw the line much lower, at approximately two different newspapers covering the same crime. WhatamIdoing (talk) 01:30, 1 August 2026 (UTC)reply
Arguing that we shouldn't have an article on the conclave is incredibly silly. If you use a modicum of common sense, it's obvious that a papal election meets NEVENT. voorts (talk/contributions) 02:07, 1 August 2026 (UTC)reply
I think the underlying principle that people struggle with (or forget entirely) is that there should be a reasonable expectation of continuing coverage and discussion beyond the immediate future. Will people still care about this in six months? A year? Five? Ten? It's often impossible to predict with certainty, but that should be the thought process before deciding whether an article is justified. The more sure of it you are, the more likely it is that the article passes NOTNEWS. Major elections with near-infinite international coverage? Beyond any doubt. Small town petty crimes? Not so much. Between those extremes is lots of grey area, but checking similar past events to see whether they've stood the test of time can often be helpful. ChompyTheGogoat (talk) 04:05, 1 August 2026 (UTC)reply
I understand the concern, but I do not think it can be resolved simply through rules and regulations. The creation of such articles is part of the organic way in which Wikipedia has developed. It began as an encyclopaedia, but it has also become a unique and invaluable record of (very) recent history. Rather than resisting that reality, I think we should accept it and think about what to do with the mass of older current-event articles that may not be very notable. Lova Falk (talk) 10:26, 1 August 2026 (UTC)reply
I'm not proposing additional rules, just to keep that general concept in mind when debating over whether an article is justified, or if we should hold off to see how it develops. How much coverage it gets immediately isn't the point. And no, I don't think there's much additional value in just immediately restating what regular news sources are saying. That's the whole point of NOTNEWS. ChompyTheGogoat (talk) 11:29, 1 August 2026 (UTC)reply
Fair enough. I understand that you are not proposing new rules, but arguing that the existing principle behind NOTNEWS should carry more weight when articles are created or discussed. My point was mainly that we should embrace the reality of how Wikipedia has developed. Lova Falk (talk) 15:16, 1 August 2026 (UTC)reply
That's not "the whole point of NOTNEWS". The first point of NOTNEWS is that Wikipedia editors should "restate what sources are saying" and not go interview eyewitnesses themselves to create an original news report.
I realize that for people who've grown up with Wikipedia that this is basically unthinkable, but in 2002, editors thought it was worth noting that Wikipedia is not "A news report. Wikipedia should not offer news reports on breaking stories. However, creating background encyclopedia articles on topics currently in the news is an excellent idea" because it was "thinkable".
Later, that general comment developed into an item in WP:IINFO saying (e.g., in 2006) "Wikipedia should not offer first-hand news reports on breaking stories (however, our sister project Wikinews does exactly that). Wikipedia does have many encyclopedia articles on topics of historical significance that are currently in the news", got longer (e.g., in 2008), eventually split into its own section, and in 2009, swiped the shortcut NOTNEWS from Wikipedia:News articles (which in turn had swiped it from NEVENT). WhatamIdoing (talk) 18:31, 1 August 2026 (UTC)reply
It's often impossible to predict with certainty Not really, and that's part of the problem here. It is sometimes obvious that an event won't make it past a news cycle, but editors insist we keep an article and wait. voorts (talk/contributions) 15:26, 1 August 2026 (UTC)reply
Oh, I'm sure some are obvious, but plenty aren't. In those cases I think it's better to wait at least a little while to see how it plays out rather than creating it and then taking it to AfD later (if anyone remembers to). It's not the end of the world for us to not have an article immediately, since events with questionable notability aren't going to be as major (and news coverage exists for that reason). ChompyTheGogoat (talk) 15:40, 1 August 2026 (UTC)reply
I'm not sure that you have to "remember"; anyone who really disliked this kind of article could just go to Category:2006 or Category:2016 and systematically sort through the articles to figure out which ones were probably worth deleting. WhatamIdoing (talk) 18:34, 1 August 2026 (UTC)reply
Wikipedia talk:Speedy keep/Archive 7#Speedy close for recent events of unclear notability is a year old RFC which may be related/give the community's broad temperature on recently created articles. Tazerdadog (talk) 16:26, 1 August 2026 (UTC)reply
I'm sympathetic to the idea that we shouldn't rush to make event articles but no matter what the policy says if no one is going to vote delete it does not matter. Notability ultimately is what you can get people to agree on at AfD, nothing more. The case that I assume spawned this request had literally 0 delete votes. As someone with experience editing about it, I also disagree with the assertion that it is easy to predict what will and won't receive sustained coverage; in this case the article that is being asserted as non-notable especially, while I'd rather us not have an article currently, it is very similar to the Death of Kendrick Johnson, which received years and years of coverage and has scholarly coverage. PARAKANYAA (talk) 18:05, 1 August 2026 (UTC)reply
This wasn't spawned by any particular AfD, just reflections on my experience at AfD. voorts (talk/contributions) 18:28, 1 August 2026 (UTC)reply
I agree with @PARAKANYAA that Notability ultimately is what you can get people to agree on at AfD. This is not apparent to everyone, but it is true. WhatamIdoing (talk) 18:35, 1 August 2026 (UTC)reply
Its going to be hard to stop people creating articles on events when they happen, but we can require better demonstration somwhere between 3 and 6 months after the event happened that the event has demonstrated long-term notability, either via GNG or NEVENT. And the problem is that at AFD, many of these attempts get slammed by editors that reply "lots of news sources in the article, its notable", not addressing the issue that most of those are primary or that they are a burst of coverage rather than enduring. We need to make sure AFD admins are not swayed by those arguments when others are pointing out the GNG/NEVENT issues. Masem (t) 18:20, 1 August 2026 (UTC)reply
"We need to make sure AFD admins are not swayed by those arguments when others are pointing out the GNG/NEVENT issues" - they're not even swayed by blatant GNG failures now. If there are enough votes for something, that is how it will be closed, even if it is not a vote. PARAKANYAA (talk) 22:36, 1 August 2026 (UTC)reply

Nonexistent page creation prompt on mobile

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

Can you show an example? I just clicked around and every page I tried in either mode had some kind of option to do so, albeit sometimes buried amongst other suggestions. I do not appreciate when I follow a redlink in mobile and it autoloads the editor, because that version takes over the entire screen and I have to back out of it to access other options. That appears to only happen with redlinks though, not search or a direct URL. ChompyTheGogoat (talk) 23:14, 1 August 2026 (UTC)reply
When I search for "corticolimbic", for example I get the following message at the top of the results using desktop:
The page "Corticolimbic" does not exist. You can click on "Corticolimbic" to create the page directly, or you may create a draft and submit it for review, but consider checking the search results below to see whether the topic is already covered..
This message does not appear when using Mobile view. — ♠ Ixtal ( T / C ) ⁂ Non nobis solum ♠ 23:24, 1 August 2026 (UTC)reply

WMF

Wikipedia:Village pump (WMF)

Miscellaneous

Invitation

Guidance for DRN

I am discussing this here rather than at the DRN talk page because the DRN talk page is not very active. There is a controversy about the front page guidance. Under the Request Dispute Resolution button, there are 7 paragraphs. The seventh paragraph is headed Follow moderator instructions, and then says:

There will be times when the moderator may issue an instruction. It is expected of you to follow their instruction and you can always ask the volunteer on their talk page for clarification, if not already provided. Examples are about civility, don't bite the newcomers, etc.

The history shows that the paragraph was added on 22 May 2020, and that it was added by Galendalia, who was indefinitely blocked for sockpuppetry and competence issues in July 2020. However, the volunteers at DRN have not noticed that the instruction was improperly added, and, to the best of my knowledge, the volunteers consider it a useful provision.

A user objects to this provision and wants it removed. I can't see why a user objects to a provision saying to follow moderator instructions, unless they want to ignore the moderator and dominate a DRN discussion, but I don't know their reason. So I have a few questions. First, is there a way that the volunteers at DRN can ratify or regularize that instruction? For instance, can it be deleted, and then reentered by a good-standing editor? Second, where and how should the objecting editor provide their case for removing that rule? Third, is VPM an appropriate forum for this discussion? If not, where should we discuss? Robert McClenon (talk) 07:46, 21 July 2026 (UTC)reply

Meh, I don't think an instruction counts as improperly added if the user in question got blocked later. Fait accompli is not ideal, but there is a level of silent consensus after half a decade, and we'd probably want some explicit consensus to remove it at this point. Chaotic Enby (in solidarity · talk · contribs) 08:02, 21 July 2026 (UTC)reply

  • Third, is VPM an appropriate forum for this discussion? If not, where should we discuss?

Well, DRN is mentioned in the WP:DR#Dispute resolution noticeboard. Perhaps move this thread to WP:VPP. Indeed, finding ways to resolve dispute is an official policy, right? George Ho (talk) 09:11, 21 July 2026 (UTC)reply
Hmm... On the other hand, maybe VPM would be the right venue for wider attention? George Ho (talk) 11:45, 21 July 2026 (UTC)reply
First, is there a way that the volunteers at DRN can ratify or regularize that instruction? I think you can simply hold a discussion assessing consensus about the current wording. No need to remove and re-add. If anything, I think there is value in maintaining a "clean" history to show how long the wording has been in place, assuming it has been followed and accepted, mostly without incident, ever since. You don't even need to hold the discussion, but since someone has challenged it, it's reasonable to do so. I agree with Chaotic Enby's take. Problematic editors make useful contributions all the time. It's fairly common for editors to question the wording of policies and guidelines on the talk page, and for the current wording to be affirmed. Sometimes an {{efn}} is added linking to key discussions when wording was added or affirmed. I don't know that a formal discussion and {{efn}} is necessary it this is just to satisfy a single dissenting editor, but these are options if the volunteers want to visibly and explicitly affirm the instructions. I'm not well-versed in DNR, but as I understand it, it is a voluntary process and is treated as a WikiProject. This calls for pretty broad deference to local consensus among the active participants. If there were widespread dissatisfaction from the community, that may call for reform, but this doesn't appear to be the case. —Myceteae‍🍄‍🟫 (talk) 15:17, 21 July 2026 (UTC)reply
(comment from involved editor) Is there anyone other than geHo who objects that we should follow volunteer instructions at the forum to have disputes mediated by a volunteer? As I've mentioned multiple times previously, WP:EDITCONSENSUS is consensus, and now I'll add that it is the most common form of consensus. Until someone else says a word, I would emphatically oppose opening a discussion. In solidarity, Aaron Liu (talk) 01:08, 22 July 2026 (UTC)reply
Totally fair and reasonable. I was waxing about various options, probably more than necessary, but overall I agree. It's clear that this has been discussed somewhere since folks seem to know about it. If DNR editors want to point to prior discussions or do something more formal, there are ways to do so, but it doesn't sound necessary. I fully agree that EDITCON is valid, which is part of what I meant by saying that there is value in maintaining the original addition to clearly show that this has been accepted for years now, regardless of how it got there in the first place. If it gets removed and re-added, there should be some reference in the edit history as to why, but that seems like a whole lot of rigamarole just to maintain the status quo. —Myceteae‍🍄‍🟫 (talk) 01:18, 22 July 2026 (UTC)reply
Comment: I'm involved in the dispute where this initially came up, and I have to say that particular rule is basically the most useful part of DRN. Without it, the whole thing kinda devolves into just another talk page battleground during a dispute. GeogSage (⚔Chat?⚔) 01:36, 22 July 2026 (UTC)reply
Comment: I'm also involved in the dispute, and I have to say that that rule is pretty useful to the DRN. Otherwise it would become a back-and-forth chaos which would achieve nothing, Against a discussion, but maybe @George Ho can state out his points neutrally here to see where the misunderstanding stems.
Sincerely,
16dvnk (talk) 02:10, 22 July 2026 (UTC)reply

Where is the actual disagreement? In general, it is best to avoid instructing editors. However, the whole point of DRN is to have a moderated discussion and that means a moderator has to give instructions when required. Participation at DRN is voluntary and if someone doesn't want to be instructed they can ignore it, although they might have to also drop whatever the underlying issue is if they can't get clear support. Guidance that has existed unchallenged for an extended period has consensus regardless of its author. It has to stay in place until there is a clear consensus on its talk to change it. VPM is a good place to discuss this issue—VPP is for a significant proposal after initial discussion shows consensus. Johnuniq (talk) 02:27, 22 July 2026 (UTC)reply

I honestly wasn't sure whether to follow moderator instructions that are labelled "essays". Nevertheless, I won't try to rebut people's support for the "follow moderator instructions". I just am hesitant to support the addition just because everyone here has no opposition against it. Indeed, as I see, Robert has frequently volunteered the DRN cases, especially within the past year.
Found ones closed not by Robert but other volunteers (in chronological order):
That's not to say that Robert is the "dictator" that I have made him ought to be. Well, he's not a dictator. Rather closures done by someone other than Robert have been... infrequent if neither occasional nor rare.
Furthermore, Robert himself may... or may not have benefitted from the "Follow moderator instructions" rule, but I dunno how interested other volunteers have been in the DRN process overall. The closures not done by Robert may have been... perhaps easy, be a case a failure... or not.
Oh, and this isn't the case of trying to oppose the addition done by the now-blocked sockpuppetry. Rather I'm trying to lean toward neutral in light of feedback above by others. George Ho (talk) 07:41, 22 July 2026 (UTC)reply
Comment,
In my opinion, this discussion has already resulted in a clear consensus. There has been unanimous support from other neutral editors that the rule should be allowed to stay. The core dispute between @Robert McClenon and @George Ho seems to have been resolved, with @George Ho in the previous message affirming other's support for the rule. They have also stated that he is "[not] trying to oppose the addition done by the now-blocked sockpuppetry" and "trying to learn toward neutral in light of feedback above by others". Hence, I believe that this discussion is effectively over. I do not see any disagreement on this matter and on the close. As such, we should focus back to the NPOVN and the talk page of the article of the primary content dispute. I may stand corrected, and I apologize in advance for that. Thank you very much for your attention.
Sincerely,
16dvnk (talk) 12:00, 22 July 2026 (UTC)reply
*sigh* Tried to point out how active the DRN volunteers (who aren't Robert) have been, but I guess I'll raise the matter about DRN activity again someday. George Ho (talk) 17:15, 22 July 2026 (UTC)reply
There have been very few volunteers willing to mediate discussions at the Wikipedia:Dispute resolution noticeboard for years – so few, that if Robert stops, DRN might get closed.
Participating in DRN discussions is 100% voluntary. If you don't want to engage in a discussion at DRN, you can reply to an invitation with words like "I don't want to participate in DRN" or "I think we should use [name of other noticeboard or dispute resolution process] instead of DRN for this dispute". (And then stop posting in that discussion: It's confusing when someone says "I'm not going to participate in DRN", but then they keep participating in the discussion.) WhatamIdoing (talk) 18:39, 25 July 2026 (UTC)reply

There have been very few volunteers willing to mediate discussions at the Wikipedia:Dispute resolution noticeboard for years – so few, that if Robert stops, DRN might get closed.

I suppose no process or venue would replace DRN even after potential "historical"-marking, would it? George Ho (talk) 19:03, 25 July 2026 (UTC)reply
I'm not sure of your intent in discussing hypotheticals. I think discussion will be more focused by looking at a specific problem: key English Wikipedia processes shouldn't rely on one volunteer. What can be done to attract more people to help out? Would a different format encourage more volunteers? Is it just too much work for unpaid community members to do? If it's unsustainable and the community doesn't want to seek assistance from paid moderators, what different process can be put in place to resolve disputes that is sustainable? isaacl (talk) 21:37, 25 July 2026 (UTC)reply
That is something to be raised someday at WP:VPIL, isn't it? George Ho (talk) 22:22, 25 July 2026 (UTC)reply
Again, I don't see much point in discussing a hypothetical question about where something could be discussed in the future. That can be sorted out when the discussion is actually held. (It's an existing process so refining it could be discussed here, but if you want to discuss it at the idea lab, that could be done too. Or don't discuss it if you're not up for it right now.) isaacl (talk) 22:33, 25 July 2026 (UTC)reply
I recently raised this matter at WT:DRN#Any other frequent volunteers? five days ago, but I've still awaited replies there. George Ho (talk) 22:49, 25 July 2026 (UTC)reply
Thank you @George Ho for your concerns over the DRN if @Robert McClenon does not mediate. This is a valid point about the DRN process. However, I once again affirm that we should focus on the content, and not the past DRN procedure flaw, which is irrelevant. We can resolve the "few volunteers" problem after the core content dispute, since we simply do not have time to investigate such issues (originally about Superpower dispute, then a failed DRN over an "essay" prompted a clarification, but now it seems that we are beating a horse's carcass over these issues). I suggest we focus on the content dispute and not spiral over into such issues for now. I welcome others to resolve the manpower issue at the DRN at another time, but now is certainly not a great timing. Thank you for your attention.
Sincerely,
16dvnk (talk) 02:22, 26 July 2026 (UTC)reply
Okay. We had two issues here. First, we have an editor who made a poorly considered statement, that the rule to follow moderator instructions was problematic, and persisted in defending the statement for a while but then agreed with a consensus of editors that is should be seen as a consensus-based rule. So there isn't a remaining issue. Second, we have some rules that a moderator can use to conduct moderated discussion, that have incorrect short descriptions that refer to themselves as "Essay on editing Wikipedia". That short description confused at least one editor into thinking that there were essays because they said that they are essays. I am not sure why they had that description, but it may have been a default description for pages created in project space, or a gnome trying to be helpful but being mistaken. I will change the short descriptions, because they are inaccurate and caused confusion.
Also, I agree that the editors should collaborate with a previously uninvolved volunteer at the Neutral Point of View Noticeboard. I would suggest that it would be better to wait for a volunteer than to continue restarting your positions. Robert McClenon (talk) 13:57, 22 July 2026 (UTC)reply
 Courtesy link: Wikipedia:Neutral point of view/Noticeboard § Superpower lede and content
This appears to be the NPOV/N discussion in question. I agree that the VPM question is settled. —Myceteae‍🍄‍🟫 (talk) 14:11, 22 July 2026 (UTC)reply
It has that short description due to the {{essay}} template, which you have now removed and which I agree probably wasn't appropriate. In solidarity, Aaron Liu (talk) 22:08, 22 July 2026 (UTC)reply
Shall Robert then do the same to other rules listed at WP:DRN Rule Guide and other unlisted rules, like WP:DRN Rule G? George Ho (talk) 22:18, 22 July 2026 (UTC)reply
Probably. In fact I would encourage nesting them under WP:DRN. In solidarity, Aaron Liu (talk) 22:23, 22 July 2026 (UTC)reply
What is the question about the rules that are referred to as essays? I already said that I would remove that tag from them, and I have removed it from some of them, and not from the others. I am aware that I haven't finished. What is the question? Robert McClenon (talk) 19:19, 23 July 2026 (UTC)reply
Hopefully, my question here should be clearer: if I want a volunteer to resolve disputes rightfully, then must I follow the DRN moderator rules (enforced by any other volunteer besides you) and to treat them as if they're guidelines... or more than just "essays"? George Ho (talk) 19:54, 23 July 2026 (UTC)reply
They're instructions, just like "Please add new topics at the bottom of the page". In solidarity, Aaron Liu (talk) 22:59, 23 July 2026 (UTC)reply
Remember, we are all volunteers here. You do not have to follow any instructions, but if you choose not to abide by the usual procedures in a forum, no one else is obliged to help you, and your refusal to participate in a collegial manner may be held against you. Donald Albury 23:19, 23 July 2026 (UTC)reply
I don't understand the question. Why would you ask a volunteer to resolve disputes rightfully if you don't plan to work with the volunteer? You have no obligation to ask for assistance at a noticeboard, and you have no obligation to continue to work with the volunteer who answered your inquiry, but if you weren't planning to do as the volunteer says, why did you go there? If you thought that you would work with the volunteer, but then you discovered that you and they didn't agree, you have a right to discontinue working with them. I don't understand the question. Robert McClenon (talk) 23:49, 23 July 2026 (UTC)reply

Why would you ask a volunteer to resolve disputes rightfully if you don't plan to work with the volunteer?

Well... You often volunteer there, and I hadn't been sure whether you and I can work things out. Honestly, you and I have interacted at other venues, and I'm unsure whether they've been good thus far. I thought your tone was stern... kinda stern... and hostile and very rigid when I brought an image to DRV and when I mentioned an extra source at an AFC review on Tyson Apostol, though you said not to exceed the maximum number of sources you wanna review.
Furthermore, I hoped everyone would go for an RFC, but then after the DRN failed, I was pushed back from further brainstorming an RFC and then reluctantly sought for sources that can validate my arguments. Too bad multiple sources proved otherwise.

If you thought that you would work with the volunteer, but then you discovered that you and they didn't agree, you have a right to discontinue working with them.

Totally unaware of that kind of right. Still, I really thought the DRN request would success rather than fail. George Ho (talk) 00:36, 24 July 2026 (UTC)reply
Okay, User:George Ho. You dislike me. That is your privilege. You don't need a reason to dislike me. You only have a duty to be civil, and you have been civil. You have a right to discontinue interaction with me any time that I pop up as a DRN volunteer or AFC reviewer. Your question still doesn't make sense. Why would you go to a noticeboard and disregard the instructions from the volunteer at the noticeboard? Or do you have a question? Robert McClenon (talk) 01:33, 24 July 2026 (UTC)reply

  • Why would you go to a noticeboard and disregard the instructions from the volunteer at the noticeboard?

    Is this a rhetorical question? If not, then why still wanting me to clearly answer this question further? I answered as much as I can, but still you want me to be clearer than before. So here goes: I just thought that you would continue the process but then warn us again about disregarding your instructions. I never really thought you would abruptly close the request as a failure in effort to especially enforce the instructions. Also, I had been unsure whether any other DRN volunteer would take their own instructions as seriously as you have been. Never meant to treat the DRN process as a test. However, perhaps I should've pinged you first about the Rules before replying to the other editor about the Rules, but then you might have abrupt close the discussion still, anyways. Also, I really thought back-and-forth discussion wouldn't be much of a huge deal as long as it's minimally done without disrupting the process, but I didn't think my explicit disregard for the Rules (previously labeled an "essay") would lead to huge consequences. Well, now here we are.

    Or do you have a question?

    What do you think would happen to the DRN without you frequently volunteering? What happens when you cut down your DRN volunteer work? —George Ho (talk) 02:31, 24 July 2026 (UTC)reply
    It might be time to move on. Further responses won't help. Johnuniq (talk) 05:47, 24 July 2026 (UTC)reply
    Thank you @George Ho and @Robert McClenon for their attempts to resolve the DRN conflict. Now, let us de-escalate and focus on the content dispute in the article talk page and the NPOVN entry.
    Friendly reminder: at those venues, please AGF, be civil, and avoid rhetorical questions.
    Thank you for your attention and understanding.
    Sincerely,
    16dvnk (talk) 14:07, 24 July 2026 (UTC)reply

Strange messages on talk page

Sorry if this is a useless waste of talk page space, but I came across some weird talk page messages at Talk:Fair use that don't look like mistakes given they were sent repeatedly at different times. Wondering what people think of them. GreenAndWhiteA320 (talk) 12:57, 22 July 2026 (UTC)reply

I have removed them… it looks like vandalism (or at least nonsense) to me. Blueboar (talk) 13:08, 22 July 2026 (UTC)reply
this is probably one of the hundreds of people who mistake talk pages for Google or ChatGPT Gnomingstuff (talk) 12:52, 24 July 2026 (UTC)reply
Sometimes people get lost on the internet, and might mistakenly navigate to a Wikipedia talk page thinking it's a forum for discussion of some topic completely unrelated to Wikipedia. This can happen on any talk page, but is more likely to happen for pages that get linked to a lot.
As for why our article on Fair use would attract such folks, I expect it's because we link to it in the File Upload Wizard, as well as a lot of templates used for files. MEN KISSING (she/they) Talk to me, I don't bite! - Solidarity 05:04, 25 July 2026 (UTC)reply

Request for comment (the future of Abstract Wikipedia)

You are invited to voice your opinions in a request for comment about the future of Abstract Wikipedia. Thank you! Kowal2701 (talk) 12:24, 24 July 2026 (UTC) reply

Unfortunately, this appears to be another indication that the Wikimedia Foundation Board has an antithetically different outlook on artificial intelligence from the outlook of the English Wikipedia community on artificial intelligence. Robert McClenon (talk) 18:20, 27 July 2026 (UTC)reply
This is GOFAI though, not LLMs. Dingolover6969 (talk) 22:46, 1 August 2026 (UTC)reply

Intercultural Open University Foundation

I'm not sure IOUF still exists. Can someone check that? E.g. at https://www.kvk.nl/zoeken/ it does not exist. Organization no. 41003178 has been erased. tgeorgescu (talk) 03:47, 26 July 2026 (UTC)reply

The institution's current webpage appeared at the top of a search in DuckDuckGo. Discussion of any problem with its existance and/or sourcing needs to take place on the article's talk page, not here. Donald Albury 18:16, 26 July 2026 (UTC)reply
This question would be better suited for the reference desk. Joe vom Titan (talk) 18:11, 27 July 2026 (UTC)reply

Template:Choropleth map includes disputed territories against consensus

Not long ago, a new template for maps was developed and is currently in beta. It uses off-site data to define the territory of countries, and unfortunately that means it includes territories that there may be consensus not to include in maps on Wikipedia. The example I noticed was Crimea, which by consensus should preferably be denoted as a disputed territory, rather than just any old part of Russia.

It is technically possible to manually define which regions you color as part of Russia or any other country, but the vast majority of editors will either not notice, not know how, or not even think about this being a potential issue. I tried to get a discussion about solutions going on the template talk page, but it's very quiet. The main contributor to the template was noncommital when contacted directly.

The issue I see here is, these maps can quickly spread to hundreds of pages, making cleanup difficult, and it happens on pages that have no obvious connection to the territory or its article (on whose talk page we'd normally establish consensus about how to treat it). For example, I reverted to the old maps on pages like United States embargo against Cuba and Duty to rescue over the inclusion of Crimea. So this situation means we would silently get more and more maps that violate the actual consensus established about various disputed territories. On the other hand, the new template is quite useful and user-friendly, so we probably wouldn't want to go back to just SVG maps. So how do we fix this? Or do we just accept the situation? Sakkura (talk) 15:30, 29 July 2026 (UTC)reply

Technical aside, what is the desired behavior here? If you have a map that gives different colors to Russia and Ukraine should Crimea be considered part of neither country and thus left white unless "Crimea" is given as a separate entity to color? If you have a map that gives different countries different colors on a matter unrelated to geopolitics there is no way to avoid making some sort of geopolitical decision on which colors to give to which regions. * Pppery * in solidarity 15:56, 29 July 2026 (UTC)reply
And are their any issues here other than Crimea? * Pppery * in solidarity 15:57, 29 July 2026 (UTC)reply
I have created d:Data:ChoroplethMap (without Crimea).map that doesn't declare Crimea as part of Russia (leaving it uncolored unless something is specifically specified for it). It would be technically trivial to modify the template to pass that as the default (change Module:ChoroplethMap#L-30), but I'm not familiar enough with the social implications here to do that myself. * Pppery * in solidarity 16:15, 29 July 2026 (UTC)reply
That should be c:Data:ChoroplethMap (without Crimea).map?
—Trappist the monk (talk) 16:23, 29 July 2026 (UTC)reply
Yes. * Pppery * in solidarity 16:23, 29 July 2026 (UTC)reply
I think modifying the default behavior like that for each case as it comes up would be ideal. Then it doesn't have to be re-litigated on a hundred different pages, and usage of the template just inherently makes maps that match whatever consensus is arrived at in the proper forum. Sakkura (talk) 16:46, 29 July 2026 (UTC)reply
The template already has the "source" parameter to load c:Data:ChoroplethMap (without Crimea).map, see Template:Choropleth map#Alternative source for an example on how to use it. Sophivorus (talk) 12:54, 30 July 2026 (UTC)reply
Perhaps it would be desirable to rename c:Data:ChoroplethMap (without Crimea).map to c:Data:ChoroplethMap (enwiki).map, use it as default here in the English Wikipedia and have it reflect all the current local consensus (not just Crimea). Sophivorus (talk) 13:03, 30 July 2026 (UTC)reply

Dmitry Volkov (entrepreneur)

Hello. Information has been added to the article that violates the balance of the narrative and does not have secondary sources (Wikipedia:Reliable sources and undue weight). Previously, such information was removed from the article. A warning was issued. Now the information has been added to the article again. Most of the information does not relate to Volkov, but for some reason it is included in his article. A discussion was previously opened here, but it was unsuccessful. ~2026-42190-90 (talk) 09:13, 30 July 2026 (UTC)reply

Open letters on sexual harassment during Wikimania 2026

A member of Wikimedia Korea and a member of Wikimedia Community User Group Malaysia were sexually assaulted during Wikimania 2026. Both groups' leaders (User:Jjw, User:Tofeiku) have published open letters, asking for an investigation into the assaults and for measures to be taken so that nothing like this happens again.

These open letters should not be buried in Meta subpages, so I am bringing them here for more attention.

User:Mdennis (WMF) has responded to both letters:

ltbdl (talk) 14:08, 30 July 2026 (UTC)reply

RfC at WT:AFC

 You are invited to join the discussion at Wikipedia talk:Articles for creation § RfC: Condensing or collapsing decline notices (except for the latest one on each draft). – MrPersonHumanGuy (talk) 19:54, 31 July 2026 (UTC)reply

Asterisks in sup tags

I have noticed, recently, that a number of wikipedia articles have asterisks that are in superscript tags, which is probably wrong because a normal asterisk already functions like a superscript character (compare * vs *). I don't really have time to fix all of them, so I mention it here in the hopes that other people will carry the effort forward if interested. (Also, some of the pages are probably right, because superscripted text with an asterisk in it would have a superscript asterisk — but most of the examples are standalone asterisks.) Dingolover6969 (talk) 22:59, 1 August 2026 (UTC)reply

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(all)&oldid=1092610382"