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.
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:
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.
I'm skilled in both the origin and target languages.
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.
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, complete with all its citations'
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?
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.
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.
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 andWP: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
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.—SMarshallT/C08:36, 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.
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.
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.
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!
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.
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 FrenchPonor (talk) 18:05, 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
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.
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
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
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
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
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
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
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
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.
"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
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
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.
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
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
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?
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. —Rhododendritestalk \\ 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?
As a non-contributor to MfD who has read this thread, my answers to your questions are:
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.
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.
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.
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
@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 ‡ edits00: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. —Cryptic00: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
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
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
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
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.
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
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. 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
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 ‡ edits03:35, 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 ‡ edits04: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 ‡ edits03: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
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
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
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
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.
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.
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)reply
We don’t need exhaustive rules and exceptions. When someone is told their contributions are negative, they should consider the feedback, not insist that there’s not a rule elsewhere disallowing what they like to do. SmokeyJoe (talk) 02:19, 16 July 2026 (UTC)reply
I am not sure having separate yes and no sections is the right format for this type of RFC. But probably too late to change that. Ah well. –Novem Linguae (talk) 12:59, 16 July 2026 (UTC)reply
I think you're right. @Voorts, I'm not sure why you chose this format, but the having separate support and oppose sections should really only be used when the quality of the arguments is unimportant, and when the options really are binary. In this case, my !vote is mu: I think it should be allowed but should not be common and should normally be explained by some other reason than just "eh, I just wanted more people to comment". There is no place in your format for my response. WhatamIdoing (talk) 03:43, 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.
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 Albury20: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
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.
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)
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
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. 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. 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 NPOL is fine the way it is and I agree that most people covered under this guideline would be incredibly obscure. Lynch4413:58, 22 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.
'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:
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 ), and the website now contains significant content on topics that have arisen since his death. I raised this at Talk:Charlie Kirk, and there has been some rather inconclusive discussion at Wikipedia talk:External links, 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
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
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
I don't feel strongly about this, but my thoughts center on the article being a biography about a person. Once that person dies, that individual ceases to control the content on the website. The estate may control the site, but the article is not about the estate. New content on the site won't be controlled by the subject of the article, and may even run counter to the intentions of the subject. I'd recommend removing the link from the infobox. Davidwbaker (talk) 19:48, 2 August 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 think that's generally true once you get beyond the very-small-business level. However, being directly maintained by a notable individual is far more work than being controlled by that individual. If you hire the person who does the maintaining, then you're still in control, even if all you do is occasionally glance over a few proposals or send a text message saying "I want you to put something like ____ on the site during my big speech next Saturday". WhatamIdoing (talk) 02:59, 2 August 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.comgive 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
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
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
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
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
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
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 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.—SMarshallT/C09: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".—SMarshallT/C12: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
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 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
As Dionysodorus and I agreed at Talk:Charlie Kirk, the guideline does not require removal. It says editors "should" add links to an official website, but it does not say that only official links are permitted, nor does it say that formerly-official links should/must be removed. WhatamIdoing (talk) 03:05, 2 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
Nope. The guideline doesn't say that an infobox is only allowed to have official links. Some infoboxes' /doc pages say that, but the guideline itself doesn't. The guideline itself only says that links in infoboxes have to be "appropriate": "include appropriate external links in an External links section at the end of the article, and in the appropriate location within an infobox, if applicable". WhatamIdoing (talk) 00:31, 2 August 2026 (UTC)reply
Well the part of the guideline that has caused all this discussion says: The official website should be included in infoboxes such as {{Infobox company}}, and by convention are listed first in the External links section. If it's being over-interpreted then that is what needs to be clarified. It also does explicitly define criteria to be considered "official", which are relevant if it's an exception to links that should normally be avoided, whether it appears in the infobox or § External links or both. These criteria would seem to be critical to the determination of appropriate and within an infobox, if applicable in the section you quoted. And the widespread practice and apparent interpretation, which is the other thing that's under discussion here, appears to be that we only put "official" websites in infoboxes and not other links like IMDb that are fine for § External links, and so again, if it's been misinterpreted, it's good that we are clarifying. —Myceteae🍄🟫 (talk) 01:36, 2 August 2026 (UTC)reply
Yes, the guideline indicates that there are circumstances under which an official link should be included, but does not say anything about removing the link later. It would be silly, for example, to remove the name of a website from Category:Defunct online companies, and essentially impossible when the website and the company have the same name. We might make it non-clickable, or we might replace it with an archived copy (if there's a decent one available), but the guideline doesn't say that it needs to be removed.
I'm more interested in the widespread practice, which is to keep websites for individuals so long as they still work (e.g., not usurped by WP:JUDI). We can change the words of the guideline, if someone really needs to be explicitly told "If someone dies, or if an organization closes, then it's still okay to keep the same website in the infobox, if it points to something relevant." WhatamIdoing (talk) 07:57, 3 August 2026 (UTC)reply
I, too, am more interested in the widespread practice. I think we're on the same page there. Editors have an intuitive sense of what constitutes "official". Our guideline defines this in a way that probably works for the vast majority of living subjects but falls apart for deceased subjects and possibly other situations. The stated definition/criteria issue goes beyond the infobox. As a general matter, I don't think we should have guidelines that don't reflect widespread practice. But it's not clear what set of explicit criteria would be workable and actually helpful. —Myceteae🍄🟫 (talk) 16:29, 4 August 2026 (UTC)reply
The problem that I see here is that someone is asserting that a website that does not meet the ELOFFICIAL definition must be removed. Note the gap between the guideline indicating that it's not ELOFFICIAL any longer and the conclusion drawn (by at least one editor) that no-longer-official websites cannot be linked.
I think there are three ways that we could address this.
We could update the Template:Infobox person/doc to say that their "official" isn't limited to the definition in WP:ELOFFICIAL, and editors should use their best judgment to decide what constitutes the official website for a person (deceased or otherwise) for whom no ELOFFICIAL website exists.
Expand WP:ELOFFICIAL to say something like "Wikipedia does not have, and has never had, a rule saying that only official websites may be linked to in an article, including in infoboxes." Consider, e.g., {{Infobox company}}, which has an external link to a stock ticker, not to mention {{chembox}}, which is basically a mass of external links.
Expand WP:ELOFFICIAL significantly to say how to determine which website(s) are the ELOFFICIAL websites for deceased people, defunct companies, etc.
All your options imply that, if we adjust the guideline, we ought to be doing so in such a way as to make it clearer that infoboxes can or should include links to websites that belong to the subject but have been modified after the subject's death. But I think it's fairly clear from the discussion that quite a few editors here are not comfortable with this practice, and might prefer for the guideline to be adapted in the opposite direction, in such a way as to discourage the continued inclusion of such links in infoboxes, or at least in such a way as to encourage caution about doing so. Dionysodorus (talk) 21:41, 4 August 2026 (UTC)reply
Taking together every diverse opinion given in this discussion, I think our best option is to expand ELOFFICIAL, rather than to revise the infobox documentation, and I think that doing so, in some way, is going to be necessary. The question is what to put there, and how to frame it. I think the focus should be on websites of persons who are deceased or who in some other way no longer "control" the website, and I think we should allow for some case-by-case decision-making. I don't think we should be too rigid in what we lay out, because editors really do seem to disagree on a lot. Perhaps make clear how "control" becomes complicated in such situations, and give editors some leeway in deciding what is best on a given page. --Tryptofish (talk) 21:56, 4 August 2026 (UTC)reply
I agree. I think we should allow for some flexibility here. We should workshop some "Goldie Locks" general guidance that's not too rigid but also doesn't leave things so wide open as to generate more disputes than it resolves. Recognizing that not everyone agrees, we may need an RFC that proposes two or three alternatives: one that is more restrictive than the current practice, one or two "Goldie Locks" versions that allow for websites of the deceased with modest guardrails, and maybe some other approach. —Myceteae🍄🟫 (talk) 22:32, 4 August 2026 (UTC)reply
Avoiding an RFC is desirable. If we can get to an agreement about whether the deciding factor is degree of change since the person's death vs. a site that is continuously updated "in their interest", that would be great. —Myceteae🍄🟫 (talk) 23:00, 4 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.—SMarshallT/C21: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
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
If someone has been dead for a very long time but had a web presence during their lifetime, following this approach, then it is probably reasonable to go ahead and remove these links, too. I suppose an exception would be if it has clearly been left largely untouched, functioning almost like an archive even if not, strictly speaking, an archived page. For example, I don't know what Aaliyah.com looked like in 2001. I suspect she had an official website before her death. This has a fairly modern look and feel, so a reasonable default assumption is that it has substantially changed, though I'm not sure I could prove it another editor disputed removing the site from her infobox. —Myceteae🍄🟫 (talk) 23:44, 1 August 2026 (UTC)reply
Looks like the fansite was at AaliyahOnline.com, which is no longer live, not Aaliyah.com. Anyway, I don't mean to dwell on this specific example, just trying to think through how the current guidance and any potential change to it is supposed to apply to such cases. —Myceteae🍄🟫 (talk) 23:04, 4 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.—SMarshallT/C21: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
Under the rule as currently written, the link should generally go. The phrase "controlled by" is a link to WP:BLP. BLP has some rules for dead people but it cannot be stretched to indefinitely alive, like an estate or license holder may be. (There are probably some estates, or estate like orgs, that because of what they get up to may be independently notable but the article is not about the estate.). Alanscottwalker (talk) 20:03, 2 August 2026 (UTC)reply
(As an aside, the purpose of an estate is not to act in the interests of the dead person, it is to act in the interests of the beneficiaries, who are living.) Alanscottwalker (talk) 20:58, 2 August 2026 (UTC)reply
I think you mean the executor or trustee in certain situations with certain kinds of estates, depending on how they were setup. But more basically, a notable person might set one up to monetize, control, and protect their posthumous identity and intellectual property.
I guess the important question at the end of the day is if it has value to the readers, less so what a template or guideline say since neither really cover this situation directly.
I agree that the important question at the end of the day is if it has value to the readers. Both template documentation and guideline wording can be changed to recommend that editors follow the community's ordinary practice, which appears to be keeping the links so long as they're still working/relevant/not usurped by a spammer. WhatamIdoing (talk) 07:58, 3 August 2026 (UTC)reply
I meant estates or post death trusts. The estate or trust is legally alienated from the person who sets it up to benefit the interests of the beneficiaries. So, the control is placed with the trustee or estate manager or executor to benefit the interests of the beneficiaries. The trustee, etc. assesses fees and costs against the trust to fund their control and administration (they generally pay themselves and other professional services out of the trust which may be a fixed percent plus outside fees). The dead person is, well dead. The benefit of monetizing the dead's intellectual property, promoting what the image of the dead is, is in the main to fund the interests of their beneficiaries. (And especially with a dead person with fans, you see claims the trust/estate is ruining the legacy by their alleged greed).
As to your second and third point, I was conceding that under the rule as currently written which refers to BLP, the OP has a point. If anyone wants to rewrite the rule, they need to propose it, and deal with the inevitable discussion of whether the promotion should be sanctioned in rule, and how to identify the correct link and do the benefits outweigh the risks. (Given we don't even require an infobox, at all, it seems hard to make the argument its value is overwhelming, but whether it is enough will be up to the rule adopters/consensus makers.) Alanscottwalker (talk) 10:40, 3 August 2026 (UTC)reply
I agree that the policy should be rewritten to allow for official websites of people who are dead, and also people who don't control their own official website (mentioned by Myceteae above, I completely agree that this is relevant to the discussion). As pointed out, in practice editors do include official websites in these cases, and policy and guidance should reflect that. It's more difficult to define exactly what does and doesn't constitute an "official website" in these cases, so I think it's probably best to provide examples (e.g. run directly by the person's estate or a trust created by them or their family; existing official websites that continue to be run by the same entity, such as publishers, record labels, etc.), and allow discussions to determine this by consensus on a case-by-case basis. --YodinT19:15, 4 August 2026 (UTC)reply
I wonder what would be lost if this phrase were deleted from every lead sentence. I would bet a nickel that more movies / tv series / videogames display their titles in caps than otherwise; it don't mean nothin. —Antonissimo (talk) 18:41, 3 August 2026 (UTC)reply
Relevant guideline here is MOS:STYLIZED. I am quite sympathetic to your complaint here. I would try to see if the third paragraph of MOS:STYLIZED applies to the subjects of the articles you're seeing this on: When a stylization appears only in a logo rather than within text (in either primary or independent reliable sources), it generally does not need to be mentioned at the top of the article. That could be your grounds to remove the phrase. Mz7 (talk) 07:42, 4 August 2026 (UTC)reply
I think it's a reasonable thing to make note of, in cases where the all caps (or other styling) is reasonably common in prose. —Myceteae🍄🟫 (talk) 15:58, 4 August 2026 (UTC)reply
+1 Having a default way of handling this helps resolve disputes, one of the core purposes of having a documented guideline. —Myceteae🍄🟫 (talk) 16:51, 4 August 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
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 solidarity23: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
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 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
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-trafficwikimedia.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 asarabadaniwikimedia.org.
Yes, I would say an email to bot-traffic or a Phabricator ticket are most likely to be picked up. The ID on the error page helps us to track down why the limit is being exceeded, which can be for reasons like specific blocks put in place protect infrastructure, in addition to the rate limits. We're also currently working on changes that will allow us to have different rate limits for thumbnail and original images, which will hopefully allow us to relax the limits for thumbnail requests and make reader-visible problems less likely. JTweed-WMF (talk) 12:33, 3 August 2026 (UTC)reply
@JTweed-WMF and @Ladsgroup, Is there a community facingGrafana dashboard or any similar metrics dashboard to monitor spikes in 429s served? Also, similarly do we have any community facing mechanism to get a general understanding of anonymized aggregrates of how many such human-but-blocked-please-unban requests are coming in to bot-traffic, private Phabricator tickets or y'all's personal Gmail accounts? Sohom (talk) 13:55, 3 August 2026 (UTC)reply
@Sohom Datta The closes I can think of is this. Status of "int" basically means serving 429s (vs hit front, hit back, miss or pass). You can also split it based on cluster (upload being images, text being html requests). That's percentage, but you can turn it into actual number via looking up the total in the main dashboard. Ladsgroupoverleg23:04, 3 August 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
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.
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.
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.
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.
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.
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.
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.
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.
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. – 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
I've noticed a bug with the new feature though, it seems to break using the up and down arrows in the text box once the popup shows up (at least in Firefox 152), until a fresh mouse click "resets" it. So far I've been too lazy to put it into Phab though. Anomie⚔00:32, 2 August 2026 (UTC)reply
Blocked username is sometimes struck, sometimes not
Looks like the redlink uses <ahref="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 <ahref="/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
@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
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
Cool, thanks. I've been watching the parsoid project for a long time. It's good that it's gotten to this point. I'm sure there will continue to be pain as new problems emerge, but that's the price we have to pay for progress. RoySmith(talk)22:44, 3 August 2026 (UTC)reply
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(Cumulusnimbusfloats 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:). —Qwerfjkltalk11:34, 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:
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(Cumulusnimbusfloats by)14:07, 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(Cumulusnimbusfloats 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(Cumulusnimbusfloats 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
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), Huliva16:51, 31 July 2026 (UTC)reply
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
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
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.
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
@Redrose64 I see changing a div's class from "PlainNavboxes" to "Navboxes" makes it display normally. I guess I could set up a tampermonkey extension script that automatically makes that change each time tho I wonder if you might know a simpler way? BoardHum (talk) 00:10, 2 August 2026 (UTC)reply
Shortcuts with the string 'RFC' at the beginning generate corrupted anchors
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 R 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:
a dozen tests trying to narrow down what's going on here
12. {{sh|Help:RFCX}} neither does just one trailing char: <span id="Help:RFCX">
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
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
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.
Special:ExpandTemplates shows that {{sh|WP:RFCSIGN}} produces wikitext (not HTML but merely wikitext) with <span id="WP:&#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}}. 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
Using the workaround of an explicit {{anchor}} on the page and redirecting to that instead is one way to get rid of the ugly redirect. However, no other page other than the Rfc page requires a workaround, and it won't keep the next person from falling into the same trap. If the module is altering the uri fragment to remove an 'RFC' string based on some outdated or disabled magic link feature, shouldn't it stop doing that? Mathglot (talk) 00:18, 2 August 2026 (UTC)reply
I have documented the workaround. Ideally a workaround shouldn't be needed but workarounds are often good enough when a general fix is difficult, slow or uses limited resources. I guess Module:Anchor works here because it doesn't call mw.uri.anchorEncode like Module:Shortcut#L-85, but that probably means there are other cases where Anchor fails and Shortcut would have worked. The coding of anchorEncode cannot be changed at the English Wikipedia. Phabricator requests are often ignored for years, and use limited developer resources when they aren't ignored. Trying to make our own alternative version of anchorEncode would probably create more problems than it solves.PrimeHunter (talk) 15:06, 2 August 2026 (UTC)reply
We may not need a custom version of mw.uri.anchorEncode. The real problem seems to be that the function intends to return a string that's already HTML entity-encoded for use in a tag attribute, and then `mw.html:attr()` entity-encodes it a second time. Perhaps we could simply replace the anchorDiv:tag('span'):attr('id',anchor) with anchorDiv:wikitext('<span id="'..anchor..'"></span>') to avoid that double-encoding. Anomie⚔22:29, 2 August 2026 (UTC)reply
Broken link but syntax appears to be correct
In the Jihadi John article there's a broken link in the section about the two Japanese victims (see screenshot). But from everything I could find, the link syntax is correct. Does anyone know what the issue could possibly be? Kufern (talk) 04:33, 2 August 2026 (UTC)reply
That uses {{main}} which expects titles of articles, not links. {{ill}} outputs a link. The wikitext is like this:
I don't know what to do about it but you could presumably kludge it by not using ill—instead, put the jawiki link: {{main|Example|:ja:NotHere}}. Johnuniq (talk) 05:31, 2 August 2026 (UTC)reply
Or if having it on two lines is okay, then what about these two:
Hello guys. I would need to invent a new function called, for example, "xupright". This means that the logos in the infoboxes would have the same height. I have been using the "size=x250px" parameter in infoboxes for many years, as each ice hockey championship logo has a different width... Many users like this solution and include it in new articles. But, according to Wikipedia rules, pixels should not be used for image dimensions, so my idea is to use the parameter "xupright=1" or "upright=x1". That would be a great idea in my opinion. 😉 Thanks, Maiō T. (talk) 11:32, 2 August 2026 (UTC)reply
I thought about generating a user script with an LLM, though LLMs are now forbidden from being used to generate new articles or rewritten ones. Is that all right? For full context: discussion link. George Ho (talk) 20:11, 2 August 2026 (UTC)reply
As far as I can tell, it's all right, and I have used LLMs to sometimes assist with such things, but as with software development in general, you should at least 1) know what you're asking for; 2) try to understand what you're getting (you can have the LLM comment it to assist); 3) test the script to ensure it works as desired; 4) figure out how to fix any issues or ask the LLM to fix them (and retest); and 5) release the script as an alpha or beta at first to allow for time to wring out any issues before declaring it a "full release". Hope this helps. the Stefen 𝕋ower21:07, 2 August 2026 (UTC)reply
For the discussion, I will note I am a former professional software developer, just in case anyone is unduly alarmed by my position. The bottom line is if you have the ability and/or patience to understand what you're being given, it can and will work. the Stefen 𝕋ower22:32, 2 August 2026 (UTC)reply
Please exercise extreme caution. LLM-written code has been described as the asbestos of software: it seems to do the job but may cause major problems later when changes are needed and no human understands what it is doing or why. Certes (talk) 21:37, 2 August 2026 (UTC)reply
Please don't. An awful lot of trouble was caused on 31 December 2025 by somebody running an LLM-generated script. It went to WP:ANI and it took me and several other people some hours to clean up the mess. --Redrose64🌹 (talk) 21:48, 2 August 2026 (UTC)reply
I'm not sure if that policy applies or not, but I will echo what WhatamIdoing said at the linked discussion: Do you know enough about Javascript to know whether the LLM is doing a good job? As you answered no, I would avoid it. (I do have a basic understanding of JS and would avoid it myself regardless of policy.) I would also add the caveat that if someone stumbles across this and does write a script primarily using an LLM and publishes it, please disclose such. LittlePuppers (talk) 02:20, 3 August 2026 (UTC)reply
And if you answered yes, you're wasting your time by involving AI. Writing good code may be hard, but fixing bad code is harder. So that highlighted question is probably rhetorical in all contexts. ―cobaltcigs03:31, 3 August 2026 (UTC)reply
If you have a working piece of software, in most cases it's much easier (practically in terms of time involved) to fix a bug than to create the whole thing from scratch with nobody else's assistance (even if you're highly skilled). And LLMs can help find the bug and provide a solution in many cases. If you have a totally rotten code set, LLMs give you the opportunity to generate something totally anew. I would invite everyone to try using LLMs to generate some code even if you don't want to use LLMs or what they produce, just to see what is possible, today, in August 2026. It's pretty mind-blowing. the Stefen 𝕋ower04:41, 3 August 2026 (UTC)reply
Is there any bot that can be used to archive specific talk page discussions based on a filter rather than just date? Specifically, I'm hoping to automate archival of KiranBOT notifications regarding threads being archived, but it would be nice if I could add custom criteria for anything I want to sweep for routinely. ChompyTheGogoat (talk) 20:49, 2 August 2026 (UTC)reply
Do you know if it's possible to PREVENT it from archiving any threads that don't qualify under that parameter? I'm currently not wanting to archive anything else automatically, although I may change my mind on that later. ChompyTheGogoat (talk) 21:57, 2 August 2026 (UTC)reply
Only those (or other automated messages I add an |archivenow= parameter for). The ability to define any string there is a exactly what I was looking for, but without the bot's default time-based archival of everything else. ChompyTheGogoat (talk) 22:43, 2 August 2026 (UTC)reply
Perhaps, though the error messages could be seen as useful ways to find missing data. A cursory search doesn't reveal what colour I should have added. They seem to use a three-colour flag. Certes (talk) 22:40, 2 August 2026 (UTC)reply
I /think/ that if we changed line 81 to local return_value = party_info[out_type] or "" then that would have produced an error saying "Value not in template. Please request that it be added." which would be slightly better: we could also change that error message to mention the specific party it's trying to look up at that point. Morwen (talk) 22:52, 2 August 2026 (UTC)reply
That sounds much better, especially if it can mention the type of information that is missing (in this case, colo[u]r). Certes (talk) 08:55, 3 August 2026 (UTC)reply
This came up at Andrew Tate. The "Duplicate citations" script was deposited at the top of the main article (along with the listed citations which were hide/show). The instructions do state "You can add a {{Duplicate citations}} template to the page by clicking the link next to the References section header." Can any of you coders tell me if it's possible for the template to automatically be placed in articles' References sections? Do you think bolded instruction about placement at User:Polygnotus/DuplicateReferences would help? Thanks, Shearonink (talk) 18:45, 3 August 2026 (UTC)-reply
I'm not sure I understand the outcome you're looking for. DuplicateReferences is a user script written by @Polygnotus. It is unlike that they are the user that used it to place that section. Are you asking for a bot that goes around and runs this code on a large number of articles? audiodude (talk) 18:58, 3 August 2026 (UTC)reply
No, that is not what I am looking for. And yes, I know which editor placed the notice on the article, I did a search of the article history to find it. My issue is that having the template get placed at the very top of an article is not an optimum use of the template and if it's happened at the Tate article, it's also probably happening on other articles too. The instructions state that the template is supposed to be placed in the References section. Just asking WP-coders IF automatic placement in the References section is possible. - Shearonink (talk) 19:21, 3 August 2026 (UTC)reply
Other banners that apply only to a section, as opposed to the entire article, go in that section. These apply only to the categorization of the article, so it is logical that they go in that "section". Furthermore, these banners don't need to be widely seen to be effective, editors monitor the category and find/fix them that way. category:Uncategorized from March 2022 is the only month that exists, all prior months have been zeroed and the category deleted - evidence that there is no "notice" problem. MB 00:25, 11 March 2022 (UTC)
You'll see that I disagreed with the placement of {{Uncategorized}} six years ago for the same reasons. And as this and "Uncategorized" affect entire articles, not just sections, and not all editors (such as WikiDees like myself) monitor those cleanup categories. They should be displayed where they will attract the most notice—at the top of articles. —DocWatson42 (talk) 13:30, 4 August 2026 (UTC)reply
DocWatson42, They should be displayed where they will attract the most notice—at the top of articles. That is one position, yes. You are welcome to start an RfC on the matter, but I hope you admit that it is not a universal belief. —Qwerfjkltalk16:38, 4 August 2026 (UTC)reply
but I hope you admit that it is not a universal belief.
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
The Reader Experience team has developed a patch demo that wraps the page toolbar onto two lines when there is not enough horizontal space for all the buttons. This aims to reduce crowding in the Vector 2022 toolbar, which can occur on some language Wikipedias at certain screen widths.
The Reader Experience team is planning to launch Reading Lists, a Community Wishlist item, which is currently available to try in beta, as a full feature in September. Before then, volunteer translator help is needed for string translations into a number of languages. The feature supports reading and learning goals on Wikipedia.
Next week, the table of contents on Wikimedia Commons file pages will be improved by consolidating the file page table of contents with the page table of contents. This will make it easier to understand a file page’s structure, navigate to specific sections, and share links to individual sections.
View all 24 community-submitted tasks that were resolved last week. For example, an issue where some TIFF images failed to load after clicking their thumbnail, causing a broken image to be displayed instead of the full-size image, has now been fixed.
Updates for technical contributors
The variable and function selector in AbuseFilter has been updated to support search and autocomplete. It will allow filter maintainers to find the desired variable or function more quickly.
The MJPEG and VP8 formats are removed from the video player. The MP4 format (MPEG-4 Part 2) is added instead, which provides higher quality videos to older iPhone devices. It may take a few weeks to retroactively update all existing videos. The default format for modern devices stays the same (VP9/WebM).
Screenshot of article preview with color inverted image
Just noticed this in the suggested articles at the bottom of the page. If I click through to the main article the full image displays correctly, so this is a glitch only affecting thumbnails. I noticed something similar going on with userboxes the other day, but I think it was only affecting the text field so I didn't think much about it. ChompyTheGogoat (talk) 11:10, 4 August 2026 (UTC)reply
Good question. I've been trying out different skins and was having trouble with dark mode misbehaving, so I had to fiddle with settings to get it to cooperate. I'm on Timeless now. Where do I check the dark mode? ChompyTheGogoat (talk) 14:12, 4 August 2026 (UTC)reply
I have the dark mode toggle (which doesn't currently show) and core styling enabled. I don't know what else would be causing it - it doesn't carry over when it's already set in another skin?
Weirdly, dark mode is currently not working on the Preferences page, but does everywhere else. At one point it was swapping back and forth when I switched between this and mobile view, but I managed to fix that (somehow). ChompyTheGogoat (talk) 14:44, 4 August 2026 (UTC)reply
You have likely enabled the gadget for dark mode. It does its best, but it is not the currently supported way to have dark mode.
Both of those are under gadgets. What's the "supported" dark mode then? I thought that's the option the toggle enables? Please don't remove whatever this workaround is until/unless there's an officially supported option. I'm trying to find something that's reasonably functional on my phone, and so far this seems to be the best compromise as it's only a little borky (case in point). ChompyTheGogoat (talk) 14:53, 4 August 2026 (UTC)reply
No, the official dark mode is not a gadget and the selection of which can be found on every page in Vector 2022 (Minerva's dark mode access is a little bit more difficult).
Please don't remove whatever this workaround is until/unless there's an officially supported option. We are not required to support unsupported things. And the issue is that this unsupported thing keeps coming up as if it were supported, when it's not. If people want to use dark mode in a skin, I have no issue with that. But they need to interact with it as if it's unsupported, rather than coming to WP:VPT and demanding a fix, and then when told it's unsupported acting like it's in fact still supported and making demands like yours. It's tiring and time to move on. Izno (talk) 14:59, 4 August 2026 (UTC)reply
I'm not demanding anything; I'm trying to understand, because while those options are indeed listed under gadgets, there is nothing that says "These are unsupported workaround options to make dark mode work for when the supported one refuses to work for no particular reason". I had no idea why there's no less than FOUR different places I can change some setting related to dark mode. There's also nothing that explains why the core styling option is necessary to make it work in Timeless, while the basic toggle option does enable it in Minerva - which is why I have to click back and forth through multiple pages and skins trying to figure out what on earth anything actually does (on a regular basis) - and by the way, since the SUPPORTED option also has zero explanation and just a weird icon I likewise had zero clue what it was until I randomly clicked on it one day just to see what would happen. IIRC I already had the gadget enabled (because it's where you expect to find settings and actually says dark mode) so the supported option BROKE dark mode instead. And maybe if the officially supported parts of the site actually worked a little better we wouldn't need all these semi-functional workarounds to be able to use the site at all (point in case - I had to switch skins just to be able to leave this comment). So if it's too much work to just explain things when people ask (or maybe add explanations on the actual features that would prevent said questions?) I suppose you could just disable everything that's "unsupported" and run off all the mobile editors entirely. That includes all scripts too, right? ChompyTheGogoat (talk) 15:18, 4 August 2026 (UTC)reply
It says right at the top of that preferences section: "Below is a list of custom features ("gadgets") you may enable for your account. Most of them require JavaScript to be enabled in your browser. These tools are not part of the MediaWiki software, and are usually developed and maintained by editors on Wikipedia. Gadgets may malfunction or become inoperable due to software changes"
Apologies for the software being not totally clear. It is a side effect trying to cater to lots of different people, but that tends to make things rather confusing. Documentation for dark mode is here: Wikipedia:Dark mode —TheDJ (talk • contribs) 18:56, 4 August 2026 (UTC)reply
One gadget concerned is "Use a black background with green text", which nobody seems to have named yet. It's a CSS gadget - no Javascript is necessary. MediaWiki:Gadget-Blackskin.css has had two edits in the last three years. Its creator, Prodego(talk·contribs), left Wikipedia voluntarily more than three years ago. Another is "Dark mode toggle: Enable a toggle for using a light text on dark background color scheme", which is a Javascript gadget, located at MediaWiki:Gadget-dark-mode-toggle.js. This one is somewhat newer, and its creator, Xaosflux(talk·contribs), is definitely still around. But the main point from the above is that nothing at Preferences→ Gadgets is "officially supported". Some gadgets are fully maintained (but not by the WMF developers); others are totally unmaintained; and many drop somewhere in between. --Redrose64🌹 (talk) 22:37, 4 August 2026 (UTC)reply
Like I said, it just wasn't clear between the various different options that don't have explanations for exactly what they do. I thought maybe they had something to do with how the supported dark mode is applied or something, since it kept changing in weird ways. I understand now and it's fine - it's a minor glitch for something that's overall more functional than the supported version. No big deal. (What I object to is threatening to remove that feature because I dared to ask a question about it. Imagine if we acted that way at Teahouse?) ChompyTheGogoat (talk) 00:11, 5 August 2026 (UTC)reply
And as for the dark mode "toggle", if by that you mean the one provided in Vector 2022, that applies only in Vector 2022 (and potentially Minerva, IDK if that one carries over). No other skin supports it. That's why you can't see it in your preferences, which do vary based on the skin you use (and possibly other reasons, but at least the skin). Izno (talk) 14:48, 4 August 2026 (UTC)reply
And therefore can't ask for help over there either. Any idea what would cause this? I've made a few edits there before without issue; there's nothing in my logs, and everything is fine over here. I thought it was just an individual page acting up at first, but I can't save my edits on any of them. There's no error message - it just spins/loads forever when I try to submit. ChompyTheGogoat (talk) 17:40, 4 August 2026 (UTC)reply
I have been working on expanding an article through a separate userspace, I have noticed that I have had some errors in displaying some of the references I have cited. Citations 186, 192-194 do not display and I have no idea what is the cause or fix. I did notice a message when it is cited later on in the page that is odd and does not make any sense: {{cite web}}: Empty citation (help): CS1 maint: url-status (link)
@RoySmith: I haven't seen it. Does it still happen or was it a one-off glitch? Can you view the HTML source with a browser feature (often Ctrl+u) and see whether it says <title>SoHo Weekly News - Wikipedia</title> or <title>Editing SoHo Weekly News - Wikipedia</title> around the fifth line? PrimeHunter (talk) 12:27, 5 August 2026 (UTC)reply
I have not been able to reproduce it. I didn't record the exact text, but I did look at the HTML and, no, the title tag did not include "Editing". So, really weird. RoySmith(talk)12:35, 5 August 2026 (UTC)reply
I don't know if you have fixed the issue by now, but if the issue persists, try to see if other browsers make the same error. Purging the browser cache may help. Kurdanparez (talk) 12:46, 5 August 2026 (UTC)reply
Article button at the bottom of talk pages
Could we please get an Article button at the bottom of talk pages?
The following happens all the time: My watchlist shows an edit to a talk page. I open the talk page, scroll down to read the new comment. Hmmm... I need to check the article. I scroll up, click on the Article button, open it in a new tab and read what is written there. Aha... Back to the talk page, that now, again, shows the top of the page. Scroll down once more to find the comment.
If we would have an Article button at the bottom of the talk page, that would save me from scrolling up and then scrolling down again for each time I switch between a talk page and the article. I do that a lot, so I would be very grateful for such a button. Lova Falk (talk) 09:58, 5 August 2026 (UTC)reply
Do you have the floating bar at the top of your screen when you're scrolled down on a page? If so, when you're on a talk page, do you see this icon in the row of icons at the top right? Because that's the article button you're looking for. --rchard2scout (talk) 14:27, 5 August 2026 (UTC)reply
Yes, floating bar, but no row of icons, only a "Toggle reader view" icon. Maybe because I use the Timeless skin? Timeless works the best for me by far. Lova Falk (talk) 14:50, 5 August 2026 (UTC)reply
Ah, that might be it, I'm on Vector 2022, which does have the buttons. It's probably possible to add a button somewhere with some userscript, maybe ask the folks over at WP:US/R? --rchard2scout (talk) 07:49, 6 August 2026 (UTC)reply
So when I went to Wikipedia:Barnstars to copy a barnstar template and then paste it to someone's talk page, this is what pastes: subst:The Random Acts of Kindness Barnstar1=message ~~~~2=alt. What should paste is {{subst:The Random Acts of Kindness Barnstar|1=message ~~~~|2=alt}}. As you can see, '{' and '|' does not paste. This is very annoying. I pasted the text onto the google search bar, copied it from there, and then pasted it here to get the 2nd text, what should be pasted. Is there a reason why it doesn't paste when copying directly from a page? I have never had this issue before and have given out many barnstars; last time before today was July 5, 2026. Since then I have given my macbook to be factory reset so I am unsure whether it's a problem with just my laptop, or Wikipedia itself. Can anyone help? jolielover♥talk11:04, 5 August 2026 (UTC)reply
@Jolielover: Your edit is tagged "New topic", indicating "Enable quick topic adding" is enabled at Special:Preferences#mw-prefsection-editing. The Visual mode of that tool interacts with the browser in a way which works for me on a Windows PC but maybe it gives problems on your Macbook. If "Visual" is underlined above the top right of the edit box when you make a new section then try clicking "Source" before pasting template code. PrimeHunter (talk) 11:36, 5 August 2026 (UTC)reply
Thanks for letting me know, however, I've clicked 'add topic' before and it worked out fine, as you can see from the July 5 edit which is also tagged 'new topic'. Has this changed since then? It was easy and convenient before. And yes, I am in the 'source' section. jolielover♥talk11:46, 5 August 2026 (UTC)reply
@Jolielover: I don't have a Macbook for testing but you have to somehow get plain text instead of rich text (text with links when Wikipedia:Barnstars displays code). Pasting to a place with no rich text option and copying from there apparently works but is a little cumbersome. Does it work if you insert with Cmd+Shift+V as Nardog suggested, or Cmd+Option+Shift+V? Or is there an "Edit > Paste and Match Style" option? Or two options for how to paste if you right click and one of them works? Or maybe two options for how to copy if you right click before you originally copy the text? PrimeHunter (talk) 13:11, 5 August 2026 (UTC)reply
It is Parsoid-related, but it's to do with the page you're copying from rather than the page you're pasting into. https://en.wikipedia.org/wiki/Wikipedia:Barnstars?useparsoid=0 lets you grab a copy that works fine. DLynch (WMF) (talk) 14:50, 5 August 2026 (UTC)reply
Yep!!! This works, can copy and paste it fine. Is there a way to disable parsoid permanently, don't want to go ahead and put that bit of text all the time when I can't copy somegthing. (Sorry, not all too familiar with technical stuff) jolielover♥talk14:54, 5 August 2026 (UTC)reply
If you want to, you currently can at the bottom of the editing section of Special:Preferences, set "Use the new Parsoid wikitext parser" to "Never". That's going to go away as an option soon as the old parser is entirely removed, though.
Hm. It's something about how the HTML that you copied is being cleaned up for pasting -- when you copy from the read mode of an article your clipboard actually includes a full HTML version of what you selected, and we try to turn that into plain text for the source mode paste. For some reason the wikitext characters are being stripped out. I'll look into it. DLynch (WMF) (talk) 14:48, 5 August 2026 (UTC)reply
Okay, the patch fixing that has landed. It'll go out on the normal release schedule, so next week this will work without it mattering what your Parsoid setting is. DLynch (WMF) (talk) 20:23, 5 August 2026 (UTC)reply
List gap highlighter script stopped working
A while back I added a light gap highlighter script to my common.css (it's the last section there), however without my changing anything it has stopped working, I think in the past circa week. Can someone (advise me how to) fix it. Thanks. Thryduulf (talk) 11:23, 5 August 2026 (UTC)reply
The selectors div>ul+dl and div>dl+ul are no longer matching. It seems Parsoid is wrapping things in <section>...</section>, so the <ul> and <dl> are no longer direct children of a <div>. The things that still work are the ones with selectors ul:not(.portalbox)+ul and dl+dl, since those aren't restricting to a specific parent element. Anomie⚔13:42, 5 August 2026 (UTC)reply
What do the “wbentity” and other such hypertechnical page changes on the mobile app actually mean?
Sheer curiosity question here: on the Wikipedia app version of my page watchlist, I occasionally see changes to pages that look hyper technical, which usually say stuff like “wbentity” and “wbreferences,” followed by a bunch of numbers (I’m probably not even saying the right terms that are often used). Then, when I click on them, the app says that there is actually no change being made to the page. Furthermore, these changes do not appear on the desktop version of Wikipedia. Just curious, what are they? LincolnMagnus (talk) 23:01, 5 August 2026 (UTC)reply
They are changes to the Wikidata items associated with these pages. On the desktop version (or mobile website), you can view them by clicking into the "Active filters" menu on the watchlist and selecting "Wikidata edits" (or follow this link: ). I didn't know that the mobile app displays them incorrectly, someone should complain about it on Phabricator. (By the way, is that the iOS or Android app?) Matma Rextalk23:46, 5 August 2026 (UTC)reply
Back in March, a user named Saftgurka went around plopping boilerplate text of the {{Update after|2026|08|01|category|reason=Gunnar Aldén > Pernilla Josefsson-Lazo}} variety onto the names of the ambassadors in the infoboxes on Swedish embassies. This had absolutely no effect on anything at the time, but now that it's after 2026-08-01, the word "category" in that template is now causing it to transclude a redlinked nonsense Category:Category onto the pages, which they weren't in prior to 08-01 as that would have shown up at WantedCategories. I've had to edit at least 20 pages in the past few days alone to make the redlinked category go away by removing the word "category" from an update-after template on a Swedish embassy, and it's becoming tiresome.
So since that's a category that obviously won't and rightly shouldn't ever exist at all, could somebody who knows more about template coding than I do modify that template to make sure it can't autogenerate or transclude that silliness? Thanks. Bearcat (talk) 04:15, 6 August 2026 (UTC)reply
Bearcat, looking at the template documentation, the 4th parameter is for a custom category, so these usages are incorrect. Therefore the appropriate fix is probably just to edit them all. I don't know why this has only recently started to cause an error; it looks like it should always have caused an error. —Qwerfjkltalk10:49, 6 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.
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
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. — Knightoftheswords00: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)
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
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
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. — Knightoftheswords00:51, 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
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
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 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
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.
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
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
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 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
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.
@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
Pageviews By coincidence, 10 articles is the limit for the pageviews tool. To understand how these 10 topics are playing with our readership, please see their pageviews for this year. Only two of them have been getting the sort of massive views that indicate that there is a high level of general coverage and interest. They are 2026 Iran war and 2026 FIFA World Cup. These two routinely get daily pageviews of 100,000+ whereas all the rest rarely pass 10K. Those other topics don't stand out against the general background of ongoing issues which are often in the news such as climate change, artificial intelligence and other armed conflicts. Andrew🐉(talk) 11:38, 24 June 2026 (UTC)reply
It should be noted that your view that pageviews are relevant to what ITN should and should not feature has been rejected on every single one of the many occasions you have brought it up. Thryduulf (talk) 12:52, 24 June 2026 (UTC)reply
You're free to use page views as your personal metric, as long as you understand you're largely wasting your effort. 331dot (talk) 19:27, 24 June 2026 (UTC)reply
I didn't invent page views -- they have long been a standard, well-supported metric so DYK, for example, uses them to measure the effectiveness of its blurbs on the main page. The top read articles are headlined each day by the Wikipedia app which I browse every morning. They are given top billing and respect.
But, for ITN, the app only shows new blurbs when they appear and all of ITN's repetitive clutter like Ongoing are ignored altogether. The app has been designed by WMF professionals to have a clean, fresh, engaging style. They reject ITN's hidebound format and so it's that which is wasted effort.
I've never been one to use pageviews as a metric at ITN, but I always have and will continue to defend your use of them for as long as ITN remains a free-for-all where there are no criteria. At least the criteria you choose to use is something objective that aligns with WP:ITNPURPOSE. That's more than can be said about what most of the rest of us are doing (arbitrarily deciding what is important based on a random blend of past precedent & personal feelings). At this point, I think I might actually support replacing ITN with an automated list of the top 10 to 25 most viewed pages in the last 24 hours. I think that'd manage to do ITN's job better than ITN. Vanilla Wizard 💙00:14, 1 August 2026 (UTC)reply
For some reason, ITN simply cannot police itself. We suffer from some kind of analysis paralysis where every proposed change, however simple or obvious, immediately devolves into 10 tangential debates and everyone forgets to weigh in on the actual matter. BilledMammal is correct to think a proposal as ITN will go nowhere because they always do. GreatCaesarsGhost13:23, 24 June 2026 (UTC)reply
If anyone does, User:Levivich/ITN has mockups of potential replacements (what the main page could look like without ITN) from that old RFC. Anyone should feel free to take those pages (literally, move them) if they're helpful. Levivich (talk) 17:42, 27 June 2026 (UTC)reply
WP:ITN says "ITN originated in the aftermath of the September 11 attacks, when entries were created and put on the Main Page within minutes of the attacks." Ed[talk][OMT]15:06, 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.
If shown, what mockup should be used as the starting template? (rank from most to least preferred)
Mockup Versions
Mockup M.1
This week's article for improvement
An articulated bus, also referred to as a slinky bus, an artic, bendy bus, tandem bus, vestibule bus, stretch bus, or an accordion bus, is an articulated vehicle, typically a motor bus or trolleybus, used in public transportation. It is usually a single-decker, and comprises two or more rigid sections linked by a pivoting joint (articulation) enclosed by protective bellows inside and outside, and a cover plate on the floor. This allows a longer legal length than rigid-bodied buses, and hence a higher passenger capacity (94–120), while still allowing the bus to maneuver adequately.
Be bold and edit the article yourself! The box below lists examples of improvements you can make. If you have questions or want to give suggestions, go visit the article's talk page!
This week's article for improvement is Articulated bus, a type of vehicle found across the world! You can help make this article better by updating the history, adding information about different designs, finding sources about their use cases and limitations, and more!
Wikipedia is written by volunteers, and that can include you, so be bold and edit the article yourself! Alternatively, if you have questions or suggestions, go visit the article's talk page! For general questions about editing Wikipedia, feel free to ask at the Teahouse.
Mockup M.3
Want to contribute to Wikipedia? Help us improve this article!
You can be bold and edit the article yourself. Alternatively, if you have questions or want to give suggestions, go visit the article's talk page! For general questions about editing Wikipedia, feel free to ask at the Teahouse.
If shown, where should the section be placed on the main page? (rank from most to least preferred)
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
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. fifteenthousandtwohundredtwentyfour(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
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.
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
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, nilnz06: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
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
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, 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
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
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.
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.
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.
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.
This idea has been tried before and failed. I don't get the impression that this is any different.
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
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:
It turns out to be a list of Levantine cheeses and so the current page title is misleading.
The Levant is a highly controversial place as it includes places like Armenia, Israel, Palestine, Syria, Lebanon and other hot spots.
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.
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.
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.
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.
"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."
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.
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
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
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.
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
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. fifteenthousandtwohundredtwentyfour(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
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
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
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
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
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
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
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. TarnishedPathtalk01: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
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 /hj1brianm7 (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
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
Extended content
So instead of:
You can improve this article by:
Updating its information
Fixing its grammar
Finding reliable sources about its use cases and limitations
Do this:
You can improve this article by:
Updating its information
Fixing its grammar
Finding reliable sources about its use cases and limitations
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
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
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 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.
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:
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. 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 @asilveringpointed 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:
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, fifteenthousandtwohundredtwentyfour(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.
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. fifteenthousandtwohundredtwentyfour(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?
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. fifteenthousandtwohundredtwentyfour(talk) 16:22, 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
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: 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. JavaHurricane14: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
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 - talk01: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:
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
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 solidarity16: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
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
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 Geniustalk19: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.
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 Geniustalk10: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:
Lack of expertise
Satisfaction with the existing content
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. Stephen00: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
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
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
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.
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
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
A, with top preferences being M3 & P3, followed by M2 & P1, followed by M1 & P2. I still support adding AfI to the main page no matter what combination of M and P we end up going with. I've noticed over the years that AfI has been struggling, with a lot of articles for improvement ultimately getting few or even zero edits by the time their week is over. This is a great idea that addresses this problem by giving AfI some much-needed love, and better yet, encourages readers to become editors. Vanilla Wizard 💙21:44, 4 August 2026 (UTC)reply
There was a discussion on the topic of implementing this week's article for improvement on the front page. I participated in the initial thread but not in the RFCBEFORE, nice to see it got to this point. I'll have something to contribute in a while. -- Reconrabbit (talk) 11:04, 2 July 2026 (UTC)reply
@Reconrabbit, it might interest you to know that WP:RFCBEFORE gets its name from the idea that there are some things you could try 'before' starting an RFC in the hope that there would never be a need for that RFC. In the case of adding something to the Main Page or making a WP:PROPOSAL for a new policy or guideline, of course, there's no way to avoid an RFC, so RFCBEFORE's advice (e.g., "Asking over at the Teahouse") is irrelevant. WhatamIdoing (talk) 17:38, 2 July 2026 (UTC)reply
I don't involve myself too much in these processes so that's interesting to know. The section was quite literally "RFCBEFORE on adding a "This week's article for improvement" section to the Main Page"... but I get the feeling I am telling you things you already know now. -- Reconrabbit (talk) 18:30, 2 July 2026 (UTC)reply
Rationale for P1 prioritizing ITN and OTD over DYK? Why not put TAFI where DYK currently is, DYK where ITN currently is and OTD where ITN currently is? That has to be justified just as much as any other part of the change. Also, is there a way to make mobile users see TAFI under TFA while letting desktop users see TAFI to the right of TFA? If so, why should we not do that? –Maltazarianᚾparleyinvestigateᛅ10:07, 2 July 2026 (UTC)reply
I'm not sure about the mobile stuff, but TWAFI is better on the left-hand side where the green colours stand out, instead of on the right hand side with the more subdued colours.
Should we leave notifications about this thread on WT:DYK, WT:ITN, and WT:OTD respectively? We are talking about making a change that could potentially negatively impact these sections' viewership. –Epicgenius (talk) 13:25, 2 July 2026 (UTC)reply
I am well aware that this is a ridiculous idea with which I'm only barging in now instead of during the workshop. Regardless, a mockup is available at User:Aaron Liu/sandbox. The lack of color in the AFI space is intentional; it's simultaneously frontpaged and less attentionate than TFA. I'll shut up about this now. Toodle-doo. In solidarity, Aaron Liu (talk) 17:47, 2 July 2026 (UTC)reply
I don't like that (though trialing anything would be better than nothing) because the kind of people we want to attract would have to scroll very far to see it. In solidarity, Aaron Liu (talk) 20:13, 2 July 2026 (UTC)reply
I would support that (placing TWAFI under TFP), and agree that the TWAFI box should have a color. Since TFA and DYK are green; ITN and OTD are blue; TFL is red; TFP is purple; maybe TWAFI can be a shade of yellow. Some1 (talk) 22:46, 2 July 2026 (UTC)reply
Regarding the addition by Andrew Davidson to the Background section, after reading the links I'm not I agree that the project was "considered a failure." I agree with the users in those discussions (and the signpost article interviews) that said the main problems were a) bad template design and b) three articles were listed at once, both which are hopefully fixed in this proposal. Even with those issues, there were still improvements made to some articles featured. InfernoHues (talk) 03:40, 4 July 2026 (UTC)reply
@Bremps:@BlueEleephant:@7amithorn:@InfernoHues:(feel free to ping more if needed), So I noticed that Chess is currently the Guild of Copy Editors article "of the week", that got me thinking, are they "more successful" than TWAFI? And, since I'm relatively new, how does the Guild work? I'm honestly quite confused.
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.
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
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
While I am in full support of this proposal, one issue is that AFI itself receives little activity and the current process seems ineffecient. I don't completely disagree with those opposing this proposal on that. However, I think the solution is to fix AFI rather than not do this.
While TWAFI being added to the Main Page should help it be a more active project. a restructuring of how the project and nominations work and perhaps having a way of selecting which ones appear as TWAFI in the style of TFA (rather than just randomly selecting one) may need to be considered.
For example, should we start having subpages that transclude on the talk page like with DYK? Lots of questions. Not something to prevent this proposal from going forward in the meantime, but something to think about and potentially workshop. NewAccount7295 (talk) 00:21, 4 August 2026 (UTC)reply
This proposal would change how article selection works already, 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) ... Articles would be explicitly selected to be suitable for newcomers to edit. fifteenthousandtwohundredtwentyfour(talk) 20:09, 4 August 2026 (UTC)reply
Perhaps there could be a second one that can include more difficult topics, so that they don't get left behind. While many articles in contentious topics will have a lot of eyes on them, there will be some overlooked items among them that could still use some form of AFI. Perhaps even an article on a topic from non-english speaking countries, which are harder to source, could also have one of them per month as well. Mitchsavl (talk) 03:40, 5 August 2026 (UTC)reply
I'm happy if this doesn't become reality, but I think having two AFIs per week (possibly on a 5th week of the month), with the first one being ideal for new editors and the second one being a BLP, would be great for editors who've been around for at least two weeks and want to try editing/improving something different. This would allow AFI to be open for both new and old/experienced editors. I am NOT allowing contentious topics to become AFI articles, though. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪04:15, 5 August 2026 (UTC)reply
The article needs enough time on the Main Page to have an effect on improving the article. I think if this starts up that effect can be observed and then editors can get a better idea of if a full week is needed or if two per week (one every 3.5 days) can be done. NewAccount7295 (talk) 14:22, 5 August 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
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
(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
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?
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.
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'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 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
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
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
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
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
(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
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
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
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. SpartazHumbug!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 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
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.
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 6 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
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
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
Allow concurrent discussions. (Oppose proposal.) 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 before opening a separate RM/AFD discussion 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) Edited for clarity —Myceteae🍄🟫 (talk) 16:38, 4 August 2026 (UTC)reply
I had not been under the impression that this was in need of a formal closure, but a closure has been requested (Special:Permalink/1367273814). So I will say in addition to my earlier comment above, for the avoidance of doubt, that I oppose the establishment or codification of a rule on the basis of this discussion, per Alalch E. and Myceteae. Adumbrativus (talk) 23:36, 2 August 2026 (UTC)reply
To sum up my points above for the benefit of the closer, I beleive parallel discussions should be strongly discouraged but not outight disallowed. It should be allowed to procedurally close one discussion, but which discussion should be closed depends on the circumstace. I think that makes me opposed to the proposal as written. Thryduulf (talk) 00:09, 3 August 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
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
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.
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.
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."
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
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
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
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
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
"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
You can have an article that is WP:Based upon reliable independent sources without every single line in the article being cited to an independent source. It would, in fact, be quite "wild" to suggest that only reliable, independent, secondary sources are permitted by policy. WhatamIdoing (talk) 18:50, 5 August 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. —Rhododendritestalk \\ 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). —Rhododendritestalk \\ 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. —Rhododendritestalk \\ 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. —Rhododendritestalk \\ 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.
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
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
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.) This isn't really germane to this proposal since the current exclusion currently only affects organizational endorsements, not individuals. For what it's worth, I don't think be opposed to a very narrow exception for current (and former) officeholders who represent(/ed) part of the constituency being contested. If anything, the fact that a former elected's endorsement is excluded unless covered by independent media but an endorsement by an organization, however irrelevant, can be included cited to only their website highlights how odd the status quo is. Dcpoliticaljunkie (talk) 19:08, 2 August 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. —Rhododendritestalk \\ 23:18, 31 July 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. —Rhododendritestalk \\ 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
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
By this interpretation, most articles about news orgs would fail notability guidelines since almost other source would be considered a competitor and therefore not independent. This seems to be something to address within that guideline (stipulate that media outlets that are competitors of each other are independent) rather than this one. Dcpoliticaljunkie (talk) 16:13, 4 August 2026 (UTC)reply
Notable news organizations tend to get at least some coverage in journals, books, and other newspapers not operating in the same market; for an example, the Weekend Times, a Malawian tabloid that operated for only about 6 years, is primarily based upon such sources. GreenLipstickLesbian💌🧸18:10, 4 August 2026 (UTC)reply
In practice, though, I would also like to note that the community treats newspapers and academic journals very differently than commercial organizations in general. (You can argue that a newspaper as an actual isn't technically a corporation, but that's splitting hairs in most cases). WP:NJOURNAL and WP:NNEWS are essays, but they do emphasize impact/influence as a pathway to notability that we'd never allow under a typical application of NCORP. GreenLipstickLesbian💌🧸18:21, 4 August 2026 (UTC)reply
I agree that we treat articles about publishers differently from articles about other businesses, but I think it's practical of us. Sometimes we need that information as editors. WhatamIdoing (talk) 18:59, 5 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
Oppose - current system functions quite well, and WP:DUE doesn't appear to be violated because of it - I don't see a reason to prevent endorsements being sourced to verifiable primary sources. Jishara (talk) 00:53, 2 August 2026 (UTC)reply
Support I agree that generally primary sources may be used for a wide variety of information. But this provision is so poorly written, it should go. The first glaring mistake was its mention of largely discredited local consensus, when it could of just used "editors may", but even worse it then suggests that verifiability is all you need for content additions, and that is plainly untrue, see WP:VNOT. No editors at any article can vote to ignore the other content policies, and no guideline can either. -- Alanscottwalker (talk) 19:42, 2 August 2026 (UTC)reply
Oppose. This would create a more stringent sourcing requirement than that of most other content where the concern here isn't the veracity of the endorsements, but whether they are DUE. Jessintime (talk) 15:21, 5 August 2026 (UTC)reply
As was pointed out in the "BEFORE" at WP:RSN, the framing that the current guidance allows local consensus to overrule our general policy that facts be sourced to independent reliable sources is not quite accurate. A "dependent" primary source is often reliable for a statement made by the source itself, such as an explicit endorsement on an official website or social media account. WP:SELCRIT provides some general guidance but more or less allows for local consensus at the level of individual list articles. All that said, I can imagine these lists getting out of hand. WP:WEIGHT, WP:PROMO, WP:INDISCRIMINATE, and other general principles apply to endorsement list articles. —Myceteae🍄🟫 (talk) 21:45, 29 July 2026 (UTC)reply
Yup… while a selfpub source can reliably verify an endorsement, WP:VNOT and WP:DUE apply. We need independent reliable sources to demonstrate that the endorsement matters enough for us to mention it. Blueboar (talk) 21:57, 29 July 2026 (UTC)reply
What happens if an independent source claims Organization A endorsed Candidate B, but Organization A says it isn't an endorsement (and it's not a clear-cut case of either side being wrong)? Gnomingstuff (talk) 22:30, 30 July 2026 (UTC)reply
I would think that endorsement lists generally include uncontroversial, uncomplicated entries. Beyond that, this has to be a case by case determination and is not something a general guideline can address. —Myceteae🍄🟫 (talk) 16:51, 5 August 2026 (UTC)reply
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Should any of the following be added to WP:ITNBLURB:
If reliable independent sources generally describe an election as not free and fair, ITN should generally not report or indicate this characterization.
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.
If reliable independent sources generally describe an election as not free and fair, consensus at ITN can develop to report or indicate this characterization.
If reliable independent sources generally describe an election as not free and fair, ITN should generally report or indicate this characterization.
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
Thank you for pointing out the flaw in the RFC question (the first person after 24 days of workshopping...). I have reworked it to hopefully resolve the concern. 1brianm7 (talk) 21:06, 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 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, Rosguilltalk20: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
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
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
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 NewCaledonia referendum or the recent HongKong 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
we should be free to editorialise accordingly No! Absolutely not! The personal opinions of ITN editors should not determine how we describe election results. The last thing we need is editors only using the term "sham elections" for regimes they personally disagree with. Warudo (talk) 15:24, 3 August 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.
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 Smithis 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 and . 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
Proposing a 24-hour blackout in response to WMF actions
Closing as WP:SNOW given that this is clearly not going to win the overwhelming support necessary for such a measure, much less within the next seven days. It is clear from respondents that while there is substantial dissatisfaction in the community regarding the WMF's recent decisions and statements, even among those who have pledged support to the WWU, there is a general belief that a 24-hour blackout in the next week without having first heard from WWU is neither practical nor strategically sound. Alternate proposals being considered in other threads include:
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.
I am making a proposal that, in response to the WMF's recent actions (see also here), English Wikipedia enact a 24-hour blackout. This would be similar to the blackout enacted by Arabic Wikipedia in 2023, or to the 2012 blackout done in the Protests against SOPA and PIPA. I want it to be for 24 hours so that it can be a clear and attention-grabbing warning that does not cause any long-term disruption (for now). I propose that it take place on 11 August 2026, one week from today. Please respond to this RfC indicating whether you support or oppose this proposal. ArtemisiaGentileschiFan (talk) 01:37, 4 August 2026 (UTC)reply
Support– per WMF's recent actions in using donor funds for union busting and firing employees. It would definitely help raise awareness on the issue. Chris ☁️(talk - contribs)02:00, 4 August 2026 (UTC)reply
Wait– per other editors, we should wait until we get support from WWU to do this, or see if they decide to take another course of action, in order to remain in solidarity as one group. Chris ☁️(talk - contribs)02:36, 4 August 2026 (UTC)reply
Oppose A strike is more practical than a blackout because a strike gets the same, if not more, media attention without disrupting the readership. The reason the previous blackout worked was because the whole internet was striking around the same time, which we won't happen the second time around. What the WMF cares about is their image; if they aren't the "savior of the internet", they can't get as much in donations. If we do a blackout, we will get flash-in-the-pan coverage that will be gone in 72 hours. If we strike, we can get long-term media coverage, dragging the WMF through the mud if they don't meet our demands. Striking is less disruptive on the readers while being the most effective way to punch the WMF where it hurts: their donations. Mikeycdiamond (talk) 02:09, 4 August 2026 (UTC)reply
There are 250,730 active editors according to Special:Statistics; the vast majority of editors don't know about this WMF/WWU conflict and will continue editing as usual, so I doubt a strike is going to raise much awareness or directly impact donations. Some1 (talk) 02:30, 4 August 2026 (UTC)reply
The point isn't "how much disruption can we cause"; it is "how long can we get the media to cover this". I imagine with a blackout, we will get heavy coverage during the event and the immediate time after it. People will see the coverage, but they will easily forget it and move on to the next thing. With a strike, we can drag it out if we need to. People won't forget about our plea after the initial burst of coverage if it keeps being talked about. The longer the strike is covered, the more people will have their "perfect" image of Wikipedia shattered, thus making more people less likely to donate. I doubt the WMF doesn't already understand this, and they would be more responsive to us potentially dragging them through the mud than a quick protest that will be done in a day and forgotten in a week. The media loves a story, especially one they can talk about during periods where there is less news, and if we give them one, they will bring the people who donate to our movement. Mikeycdiamond (talk) 02:43, 4 August 2026 (UTC)reply
We only have so much social capital. If we spend it on a blackout, the strike will get less coverage. If our support drops early in the strike because it isn't "newsworthy" because the blackout happened, we lose a lot of negotiating power. Mikeycdiamond (talk) 11:16, 4 August 2026 (UTC)reply
I am mixed on your reply:
A strike can still be newsworthy beside a blackout if we write about it in our blackout message.
From my limited experience, more time means less interest no matter what, so the strike will turn un-newsworthy even without a blackout.
However, I agree with your sentiment on negotiating power. We are doing this for the WWU, and an editor-initiated blackout can risk their position. However, I also want to put out there the idea of a WWU-initiated blackout. (All this is partly why I have not yet !voted.)
Tentatively oppose and support a strike as per Mikeycdiamond. But I'll defer to the WWU, and am willing to change my position. Something should be done, I'm just unsure which is the best option. In solidarityIam-py-test (talk, she/her) 02:14, 4 August 2026 (UTC)reply
Oppose Much like how boycotts without a request from the involved union are discouraged because they risk undermining the union's strategy, we should not be doing a blackout, editing strike, or other collective action without a request from the WWU. Per Wikipedia:Wiki Workers United solidarity: We, the undersigned, stand in solidarity with Wiki Workers United and affirm our willingness to engage in collective action if called upon by WWU, up to and including staging an editorial strike. ... note that no collective action has yet been called for by Wiki Workers United, and thus none is actively being planned. In solidarity, GorillaWarfare(she/her•talk) 02:16, 4 August 2026 (UTC)reply
I think it's important not to do anything that might worsen their situation, but I also think community organized efforts can coexist with taking actions (or not taking any) that the WWU calls for. Clovermoss🍀(talk)02:47, 4 August 2026 (UTC)reply
I disagree. This is fundamentally about the unionizing WMF employees, and we should follow their lead. The community-organized effort was the solidarity petition letting the WWU group know there are more than a thousand of us who have their backs. To have the editing community suddenly go rogue with a blackout/strike without any request or even go-ahead from the WWU would be the opposite of solidarity. Directing our collective frustration (which I certainly share) in a haphazard and disorganized direction would only undermine the powerful message that the editing community is standing behind the WWU and ready to back them up. In solidarity, GorillaWarfare(she/her•talk) 03:18, 4 August 2026 (UTC)reply
If it'll leave them worse off, I'll totally strike my vote. I just don't like assuming that "we all have your back and will support you if you want us to do something like strike" and independently taking the stance that we should have a blackout inherently have to be contradictory positions. I could be naive, though. Clovermoss🍀(talk)03:21, 4 August 2026 (UTC)reply
(edit conflict× 2) Premature RFC. If the goal is to support WWU then the very first question to ask should be whether the WWU think this action will support their cause? The second question should be whether they think now is the best time for that action. Only if the answer to both questions is "yes" is it worth thinking about the practicalities (time (when will it have the greatest impact?), duration, technical prerequistes, etc.) and only once they are sorted should an RFC be held. Has anybody even asked WWU yet? I know there was comment at Wikimania that some actions editors could theoretically take could actually hurt the union's cause, I don't recall if a blackout was one of those actions but it's important to know the answer before organising anything. Thryduulf (talk) 02:23, 4 August 2026 (UTC)reply
Wait, grudgingly. - I'm open to a blackout if WWU requests it. Going off and cowboy blacking out the site ourselves weakens WWU's negotiating position. I will note that the situation is causing permanent damage and distrust to accumulate between the WMF and the editing community, and I hope WMF will speedily reconsider to avoid exacerbating the damage Tazerdadog (talk) 02:52, 4 August 2026 (UTC)reply
I worry this might be a catch-22? Like in the they can't have plausible deniability way and that the WMF might try to go after the WWU legally in some way if they endorse this since they clearly have no problems hiring a unionbusting firm. I think it makes sense as a community to do a sort of collective protest against hiring an anti-union law firm (if a consensus forms that this wasn't okay and we want the world to know about it). Clovermoss🍀(talk)02:58, 4 August 2026 (UTC)reply
Oppose. WWU will probably win the NLRB vote. I don't think it's smart to escalate when the desired outcome will likely be achieved without escalating. –Novem Linguae (talk) 03:31, 4 August 2026 (UTC)reply
Oppose I've seen enough back and forth on this issue to know that it will cause some bad blood between editors. People who don't know what is going on, don't care, or just forget out of habit are likely to get some heat for crossing the picket line, regardless of what organizers say. People barely need an excuse to find anonymous targets to pick on as it is. GeogSage (⚔Chat?⚔) 03:59, 4 August 2026 (UTC)reply
There isn't a picket line to cross if the site itself is down. I think you might have misread what is being proposed? Obviously a message would need to be written so people don't just think it's a technical issue. Clovermoss🍀(talk)04:03, 4 August 2026 (UTC)reply
Ah, thought blackout was the same as what happened during the Reddit API controversy where they made a bunch of sub-reddits private in an moderator strike. Not really sure how we could go about a blackout here without imposing some sort of a "strike." The Protests against SOPA and PIPA example made me think they wanted to "temporarily close or interrupt their content and redirect users to a message." Not sure how we could go about that without either high level admin involvement, or volunteers collectively playing along. GeogSage (⚔Chat?⚔) 09:21, 4 August 2026 (UTC)reply
Does anyone like the idea of taking a step that's less than a full 24hr blackout, like a banner and/or themed main page day? Levivich (talk) 05:03, 4 August 2026 (UTC)reply
That might be easier to get consensus for if we're worried it'll be too much of a bang and interfere with what the WWU might eventually want to do. I like the idea of a banner if we aren't doing a blackout and again, only if it won't worsen the WWU's position. I'd like to think raising awareness would be a good thing. I also think potential donors have a right to know where their money might be going. Clovermoss🍀(talk)05:22, 4 August 2026 (UTC)reply
We're organising a meta:Event:WikiProject Organized Labour Month Online Campaign, a cross-language effort to improve our coverage of unions, with a focus on the union matters relevant to WWU. The goal is to get it on Mainpages (GAs etc). The big question is how we advertise. Before, I wanted a watchlist notice, and was a bit hesitant to suggest a Central banner (to all logged-in users), and make that banner take a side (instead of just linking to discussions). Or we can simply directly do a site notice (to all readers) now, without mentioning the edit campagin, now that we've passed from implausible deniability to proof that execs have been misleading us. In solidarity, —Femke (talk) 🐦 07:18, 4 August 2026 (UTC)reply
Oppose unilateral anything; our actions, if any, must align with WWU's strategies. If they request a blackout, then I'm in favour, also because it would be an effective way to get more attention for the cause. -- DoubleGrazing (talk) 06:35, 4 August 2026 (UTC)reply
Oppose. I don't see how this is our fight. For SOPA there was a colorable argument that the law was a direct threat to the operation of the 'pedia, and I was happy that it appeared to work, but I've regretted it because now there's a temptation to engage in similar action whenever there's a political issue that enough editors are on one side of. This is dangerous for at least the perception of our neutrality. You can be as sympathetic to the union as you want and as vocal as you want about it, but don't try to draw the en.wiki community as such onto one side or another. --Trovatore (talk) 07:52, 4 August 2026 (UTC)reply
Support educating not disrupting readers... we should raise awareness about what is going on, for example inviting them to join the September edit-a-thon, but we should not immediately escalate. This is important, because the build-up potential for escalation needs growing consensus, and we get there by exhausting every other resort, including asking nicely. Till now, editors have asked nicely, but we have not involved readers, beyond what they might find in the press. So this build up gets us there. We can also think of donor centric language like "Donors can support Wikimedia's mission by contacting donate@wikimedia.org and ask that it not be used for hiring expensive union-busting law firms" ~ In solidarity 🦝 Shushugah(talk) 08:17, 4 August 2026 (UTC)reply
Oppose for the same reason I always oppose blackouts – it's an inherently non-neutral action, and we profess to be neutral. As TheDJ said above me, it's also internal drama and so should not be foisted upon passing readers. — Czello(music)09:01, 4 August 2026 (UTC)reply
Support some form of [in]action; neutral as to the exact form. The recent response to unions is one symptom of a wider malaise, and I would prefer a broader message: the WMF must return to its original purpose of supporting readers and editors rather than lining its own pockets. Certes (talk) 09:30, 4 August 2026 (UTC)reply
I think shutting down English Wikipedia for all readers and editors based on the support of a small percentage of the community contrasts poorly with the request to voluntarily recognize a union based on it having the support of a majority of eligible employees. It sends the message that a minority of the community can impose its will on the entire community, which may serve to confirm worries about the degree of union support. I think another approach may be more suitable. isaacl (talk) 10:36, 4 August 2026 (UTC)reply
Are the 251,000-minus-200 editors all against the blackout? Extremely unlikely (as a side note, there are currently 251,364 active editors so you don't need the -200). Is it that hard to connect the 200-vs-1 sample to the wider 250,000-editor population We have no knowledge how how representative the sample is. It is fair to presume that the significant majority of editors who have the strongest opinions about the matter have contributed to the petition and that there are editors who are aware of and do not support the petition that have chosen not to explicitly oppose it for various reasons (the vast majority of those who have not voted will be unaware it exists, many of them, perhaps most, will be completely unaware of the whole saga). Together this makes it almost certain that if all 251,364 editors were forced to explicitly support or oppose, the support ratio would be less than 200:1, however it is unknowable what the actual figure would be. Thryduulf (talk) 11:38, 4 August 2026 (UTC)reply
The point is that we don't know whether it is or is not beyond the point of recovery. If you ask 200 self-selected supporters of a political party whether that party's policies are good you will get very nearly 100% saying yes, however this tells you nothing about what the wider population thinks about that party's policies. Thryduulf (talk) 12:33, 4 August 2026 (UTC)reply
Oppose Absolutely not. Blackout is the last resort nuclear option against an existential threat. Shutting down the entire site about an internal matter is the quintessential definition of disruption to make a WP:POINT. The editors who want to support WWU would be wiser to actually listen to what would help them instead of getting carried away with obvious non-starters like this. If and when WWU invites editors supporting them to take action by for example striking, these editors are free to answer the call for action; in the mean time, a blackout is ridiculously out of proportion and accomplishes nothing. And that is even without mentioning how problematic the idea that an external actor should have any say into calling on the community for a blackout at all, but I suspect WWU themselves are wiser than that, at least. Choucas🐦⬛11:21, 4 August 2026 (UTC)reply
Oppose Do not hijack the main page to make a partisan political statement. If you want to fight this battle on meta or on project pages, fine, but keep it out of mainspace. RoySmith(talk)12:26, 4 August 2026 (UTC)reply
"WMF is spending donor money for a union-busting law firm" is enough reason why readers should be aware of this. Additionally, is it not partisan already to support freedom that you name yourself The Free Encyclopedia? That sounds as partisan as fighting for authoritarianism. LightNightLights (talk • contribs) 12:36, 4 August 2026 (UTC)reply
Oppose for the same reasons I did in 2012. We are not a collective or bargaining group and we should not seek to bind others. Individuals, of course, are free to do as they like.--Wehwalt (talk) 13:55, 4 August 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.
Don't run any donation banners until the union-busting is completely ended
I don't think it makes sense to allow the WMF to run donation banners, when they then spend a significant part of that money to employ a notorious (and expensive) union-busting law firm (see e.g. here and here and many other places if you don't know what I'm referring to). While discussion about other possible actions can of course continue, I think showing clear disapproval of spending donor money in this way is easy, warranted, doesn't disrupt the readers, and might affect the WMF leadership where it hurts the most. Fram (talk) 10:40, 4 August 2026 (UTC)reply
Support, and maybe the community could run its own banners to let readers know why the donation banners are being put on pause. Some1 (talk) 10:50, 4 August 2026 (UTC)reply
PS: I always thought the donation banners were a WMF thing? But if, as per this proposal, we have the power to not run them, then that implies that when they are run that's with our consent. So when users come to the Teahouse etc. to plead us to stop constantly begging for money, and we say "it's not us, guv, it's them WMF", that's not strictly true, then, is it? -- DoubleGrazing (talk) 11:00, 4 August 2026 (UTC)reply
I thought we had the technical ability to not show them if we wanted to (via an interface admin?), but if I'm mistaken, then this is not such a simple proposal as I thought. Fram (talk) 11:04, 4 August 2026 (UTC)reply
I think the community has the technical ability to not display the fundraising banners, however my understanding that the banners are a WP:CONEXEMPT matter - they don't require the consent of the en.wp community to run banners. They do engage at Wikipedia:Fundraising/Fundraising Hub about the design of banners, but that's a voluntary thing. So it's wrong to say that we "allow" them to run donation banners and we cannot disallow them or prevent them. The most we can do is express our disapproval. Thryduulf (talk) 11:28, 4 August 2026 (UTC)reply
We can perfectly disallow or prevent them. Banners don't seem to be included in CONEXEMPT, and even if they were, who cares? It's not as if the WMF leadership cares about Wikipedia either. Technically, they can still run them, we just don't display them. Fram (talk) 12:13, 4 August 2026 (UTC)reply
I would appreciate greater clarification about whether this is something we as a community could even do. Whether or not such banners are subject to community consensus seems like a pretty vital thing to understand before voting on it, and honestly probably should have been nailed down before proposing it. --Grnrchst (talk) 15:02, 4 August 2026 (UTC)reply
I'm pretty sure enwiki interface admins do have the technical ability to do everything proposed here - running arbitrary CSS and JavaScript on (almost) all pages on the website is much more powerful than you think it is. I don't think it's possible to answer the question of whether we have a social right to do this; I'm quite sure individual enwiki-ans could concoct an interpretation in which it is and WMF staff could concoct an interpretation in which it isn't pretty much regardless of what the rules actually say so the question can only be answered by seeing what happens if we do. * Pppery *(alt)in solidarity15:30, 4 August 2026 (UTC)reply
The way I would put it is that it would create a constitutional crisis. Like in many governmental constitutional crises, it's not that the community clearly can do this or clearly cannot, but that there been a stable state of affairs of both the community and the WMF quietly asserting supremacy in this regard, which has never been tested because both sides have avoided a full-on confrontation. Also like in governmental constitutional crises, the question of who has the better arguments becomes largely academic, secondary to the practical question of who can enforce their claim. In this case, in practical terms, the WMF has technical supremacy (including the ability to disestablish intadmin access entirely), but the community has a (near-)monopoly on the labor required to keep the site running, which would make it very hard for the WMF to enforce that technical supremacy more than briefly, lest they become dictators of a wiki no one wants to edit. If the WMF think they can politically get away with invoking CONEXEMPT in that context they probably will, and if they don't they probably won't, and that's true regardless of who has the better policy-based claim of sovereignty over banners. -- Tamzin[cetacean needed] (they|xe|🤷) 16:04, 4 August 2026 (UTC)reply
The WMF shutting us down on their end would definitely meet my high standard of when it's appropriate to start considering the collective shutting things down on our end. Thebiguglyalien (talk) 19:22, 4 August 2026 (UTC)reply
In the case of fundraising banner, WMF could WP:BLACKLOCKMediaWiki:Common.css which would prevent anyone from editing it. They probably have some way of stopping JS methods as well, like disabling JS across the site (not sure what else such a move would break). They could black-lock the main page. If we used a template to put a notice on every page, they could blacklock the template. If we had a bot edit every article page to place a notice manually, they could have a bot undo that. Arguably they could blacklock all of article space, but that would be causing an editor strike that would be more widespread than any volunteer strike (literally preventing all edits to article space).
I'm sure that, as with WP:FRAM, the wheel war would stop after a few steps and everyone would go to the negotiating table. However, despite the technical impediments to actually, technically, removing all fundraising banners, the threat of trying to do it in WP:FR2022RFC was enough to get the WMF to change their fundraising banners, although that probably had more to do with WP:Village pump (proposals)/Archive 196#Media coverage of this RfC than fear of a wheel war. Which is the whole point: the media will, once again, cover it, if it looks like the community is going to ban the fundraising banners, and the negative media attention matters to the WMF likely more than what rebellious volunteers could technically accomplish. Levivich (talk) 16:29, 4 August 2026 (UTC)reply
Technical anecdota presented without comment:
There are several ways iadmins can do this without editing MediaWiki:Common.js
As currently coded there is no way for anyone regardless of what rights they hold to stop local admins/iadmins from editing a page, other than by desysopping them -- superprotect was removed from the code in 2015.
Of course, this doesn't actually mean anything because they can change the codebase as is done routinely in the wikitech:Deployments process, and doing so would be technically trivial.
Several volunteers can do that (change the code) too.
Note "WP:BLACKLOCK" (i.e. "Office protection") is not a separate level of protection, it's just normal full-protection plus telling admins "don't touch this". If admins are willing to buck that, and other admins/'crats aren't willing to sanction those admins, then it's irrelevant.Rather than "black-lock", they'd have to bring back WP:SUPERPROTECT to actually enforce it. From a technical standpoint they could trivially do that; superprotect had no special code behind it, it was just configuration almost identical to templateeditor. Then it'd be a bit of an arms race between intadmins finding different ways to mess with the banners and WMF reverting and super-protecting. Anomie⚔00:56, 5 August 2026 (UTC)reply
Even if they could bring back superprotect, it would likely lead to a lot of negative press coverage, which could harm their donations. If the WMF is openly declaring that it cares about neither employees nor admins, who would give them money? Somepinkdude (talk|contribs), in solidarity20:39, 5 August 2026 (UTC)reply
Support. We should not run donation banners if donations are being used against the community. I also support Rosguill's idea if that proves to be the more popular option. ArtemisiaGentileschiFan (talk) 13:17, 4 August 2026 (UTC)reply
Drop Littler Mendelson and invest in community as a fundraising demand, where we do continue fundraising banners, but with a clear call to action to donors. Exact wording can be wordshopped but let's find a sweet spot of being critical without completely stopping everything, which will have harder time reaching consensus. ~ In solidarity 🦝 Shushugah(talk) 12:18, 4 August 2026 (UTC)reply
One possible route to implementing this would be to put up banners that go to a page that briefly explains the current crisis, then presents both a link to continue to making a donation and a link to a petition/email form/etc. supporting WWU and calling for an end to unionbusting practices. I don't really have an estimate of how successful this would be in terms of numbers and ultimate impact, but it seems like a viable route to setting up a stream of "As a donor..." messages to the WMF. signed, Rosguilltalk15:37, 4 August 2026 (UTC)reply
I think the full text gets a bit more in the weeds than what I expect the random curious would-be donor would be interested in; but it's definitely worth including as a linked summary, and reusing some of its most central points. signed, Rosguilltalk16:27, 4 August 2026 (UTC)reply
Support– if I had donated money to Wikipedia, I would feel betrayed. Previous campaigns mentioned that donations were down this month after the dissolution of CommTech and I'd hate for people to think we're "in need" when that need is paying an unethical organization. I know people are worried about the Wikimedia Foundation using this an excuse to lay off people, but if they decide to prioritize that, that's on them and I'll have much to say about that course of action. I know some people have been trying to encourage people who write about cancelling their donations on social media into maybe making it temporary or giving to an affiliate instead. Clovermoss🍀(talk)14:19, 4 August 2026 (UTC)reply
Noting that I have a slight preference for Rosguill's proposal, as otherwise people might not notice why we don't have banners and might simply think the WMF has decided to annoy them less often. Clovermoss🍀(talk)02:33, 6 August 2026 (UTC)reply
Oppose Ultimately it's the WMF consulting us on what ads to run on the playground they own and they don't have to so why go there?--Wehwalt (talk) 14:37, 4 August 2026 (UTC)reply
Support The community wants a union, and WMF seems to be out of touch with the community by hiring a union-busting law firm. Maybe by blocking the donation banners, WMF leadership will finally decide to listen to the community and its workers instead of dismissing the concerns of the community and only pretending to listen. Abzeronow (talk) 15:07, 4 August 2026 (UTC)reply
Question: Given the premise of this proposal is an indefinite implementation "until the union-busting is completely ended", what event, signal, metric, or message is being proposed to mark that end? The hiring of Littler Mendelson sends a pretty clear message about intent, but there are also folks here who believe disbanding Community Tech was definitely union-busting. So who decides what "completely ended" means? Is it just stopping the relationship with Littler Mendelson? Is it that plus a pledge not to do any union-busting? Does it require formal recognition? Whatever it is, say that. "I know it when I see it" doesn't make for good proposals IMO. —Rhododendritestalk \\ 16:02, 4 August 2026 (UTC)reply
I think parting ways with Littler-Mendelson, formally recognizing the WWU, and making a demonstrable effort to rehire the engineers whose firing precipitated the uproar (to my understanding, they've already half-done that last one) are reasonable demands to make. signed, Rosguilltalk16:24, 4 August 2026 (UTC)reply
(edit conflict) I would suggest the objective trigger criteria of the WMF committing to:
End any business relationship with Littler Mendelson
Not engage with Jones Day in any union-related matters
Not replace Littler with any other union-avoidance firm
There's a lot more I'd like to see happen here, including an independent investigation into which WMF personnel are responsible for the decision to mislead the community about union-busting, but having clear, narrowly-tailored goals is critical if we're going to provoke a constitutional crisis, so I would suggest focusing just on the "donation money going to union-busting firms" problem. -- Tamzin[cetacean needed] (they|xe|🤷) 16:26, 4 August 2026 (UTC)reply
Support Rosguill's idea. Directly denying donation streams is easier for the WMF to spin as rogue community malcontents disrupting things, provides less of a reason for them to change, and risks creating a justification for further union-targeting layoffs like the ones that started this crisis. Changing things so that we give potential donors the choice, letting them either agree or disagree with our concerns, donate or not donate, contact donate@wikimedia.org to complain or not contact donate@wikimedia.org to complain, sends a much clearer message, one that can't be dismissed as just a rogue element, and one that importantly will come not just from immediate lost revenue, but from many people writing in threatening to revoke donations if the WMF doesn't disavow its union-busting, which is a lot harder to not engage with. (If there is not consensus for Rosguill's proposal, this should be read as a neutral on Fram's original proposal.) -- Tamzin[cetacean needed] (they|xe|🤷) 16:12, 4 August 2026 (UTC)reply
This would also be my preferred approach. "We've taken down your donation banners" is one thing, but "we've given visitors a choice, and 4 out of 5 have chosen to pledge solidarity rather than donate" would be much more powerful. (That is, if we get majority going that way... 1 out of 5 could be a bit of an own goal.) -- DoubleGrazing (talk) 16:21, 4 August 2026 (UTC)reply
If you frame it as 1 out of 5 compared to a potential 4 out of 5, then sure. If you frame it as "20% of the visitors are pissed at you", then that's certainly an own goal... for the WMF. (I also like Rosguill's idea or something similar.) GreenLipstickLesbian💌🧸17:37, 4 August 2026 (UTC)reply
Support Rosguill's idea. Tamzin's rationale is spot-on. We may also run campaigns, such as a potential WP:MEETUP/In solidarity. My idea hinges on showing that those in solidarity against the union-busting can prove the most useful contributions and article improvements to Wikipedia. Already, detractors have spun a narrative that editor strikes would be bad, so what if we do the polar opposite of that? 🎆 Brynn Who Likes Editing|talk w/ me!16:44, 4 August 2026 (UTC)reply
Support perhaps a complete halt to donation requests for a couple of days and then Rosguill's idea, or the latter from the start if that's too harsh. I'm sort of out of the loop, does anyone know where the maintenance of the tools listed at m:Community Tech/Maintenance will be coming from, if at all? ~~ AirshipJungleman29 (talk) 17:16, 4 August 2026 (UTC)reply
My not particularly informed assumption would be that actually interfering with WMF donation banners would quickly lead to an office action that could prevent us from putting up our own banners later. But maybe there's reason to think that wouldn't be the case? --Maddy from Celeste (WAVEDASH)18:54, 4 August 2026 (UTC)reply
Support Rosguill's idea per above, first choice. Support pulling the banners (Fram's OP) as a second choice. I like Rosguill's idea because it lets us let readers know that the community doesn't support the WMF leadership's union busting, gives readers a choice, and reduces the chances of another wheel war with the office, which would be a distraction. Levivich (talk) 20:19, 4 August 2026 (UTC)reply
To clarify, I agree that whether or not to have a union is a choice for WMF employees to make, not volunteers or WMF leadership. But when WMF leadership acts contrary to Wikipedia values (like transparency and free knowledge) by trying to prevent unionization while repeatedly lying to the public and its own community about it, I don't think the volunteer community, as a unit, should look the other way and remain silent in order to stay "neutral." I don't think holding WMF leadership accountable to our values is "micromanaging." It is our obligation as a community to ensure the people we entrust with the money are following our values. Complaining loudly is the least we can do. Levivich (talk) 06:03, 5 August 2026 (UTC)reply
Support Rosguill's idea, and weak support the other idea. I don't think readers will make the connection between donation banners going away and the WWU stuff; either they just won't notice at all, or they'll think it's some kind of browser cookie thing or that the fundraiser is over or something. Shit, I don't even know what triggers when banners go away or reappear. I also think that should a wheel war event happen, readers would more easily notice a new banner suddenly going away than a familiar banner suddenly (maybe?) appearing again. Gnomingstuff (talk) 20:26, 4 August 2026 (UTC)reply
Support Rosguill's idea of posting our own banner. The dysfunctionality of the WMF that is revealing itself in this situation is a sufficiently strong threat to Wikipedia that alerting the community via is fully justified. I think that the banner should include a link to the September Labour editathon. Boud (talk) 21:03, 4 August 2026 (UTC)reply
Oppose. In many cases where we debate and come up with a consensus of a hundred or two hundred editors, the results only affect those who participate in Wikipedia's internal processes, as opposed to those who "just edit", as a commenter phrased it in a section above. We need a very high standard to do something like a blackout, a donation banner ban, or a political statement visible to all editors, or (even more so) to all readers. I can't see that standard being reached here -- as Thryduulf says in the earlier thread, there are hundreds of thousands of active editors who just don't care about this. Our real power is in our labour, which is appropriate, given that this is about unionization. If those who agree with the proponents of this section were to withhold their edits on a given day, would that lead to a significant dip in edits? If it did, that would be a much more powerful signal than a blackout or a watchlist notice. Those who hold particular political or ethical views are free to do with their labour what they will, but I oppose action that implies the silent mass of editors agree with a given political stance, regardless of whether I agree with the stance myself. (The SOPA blackout was different; that was an existential threat that had no significant political dimension.) Mike Christie (talk - contribs - library) 21:43, 4 August 2026 (UTC)reply
I disagree with the idea that managing fundraising banners inappropriately speaks for the "silent mass of editors" and that doing nothing doesn't. Currently, default WMF donation banners already co-opt all of us by leveraging our volunteer work to solicit money under the guise of "supporting Wikipedia." That usage of us is okay, if the money is all going to supporting Wikipedia and our work. But, these actions have revealed it is not. They showed that some of it is instead going towards supporting the WMF's political actions against unions, through paying for the high retainers for aggressive union-busting law firms.You said our true power lies in our labor. Doing nothing allows the WMF to exploit both our labor and the goodwill it generates in the community, for purposes which don't benefit us and damage the reputation of both editors and Wikipedia. If we don't do anything to pause or balance the banners, it means continuing to allow the WMF to abuse the labor and image of the silent editor for their fundraising towards contentious legal tactics unrelated to content creation. The silent editors you mentioned never consented to this. Thus, if we keep things the same, I think that's what will actually co-opt the silent majority. I also don't agree SOPA had "no significant political dimension." It was explicitly intended to oppose a particular law and encourage Americans to contact their representatives in congress, which is quite political. By contrast, setting parameters for fundraising banners is an issue of ethical stewardship and donor transparency, if managed appropriately.This is why I think Rosguill’s proposal is the ideal compromise. It completely resolves concerns about forcing a unilateral stance on the site. By keeping fundraising active while neutrally presenting both perspectives, we aren't imposing an opinion on readers or silent editors. We are simply upholding NPOV and providing donors with the full context required for informed consent. And we are preventing the WMF from continuing to co-opt the work of the silent editor to fundraise for their dubious legal crusades. Preventing the volunteer workforce from being co-opted in this manner should be a priority for all of us. - In solidarity,MolecularPilot(talk)23:48, 4 August 2026 (UTC)reply
I think it would be, banners are a big deal and that's a great way to get the attention of people who don't participate in projectspace discussions as much to see what they think. Clovermoss🍀(talk)16:53, 5 August 2026 (UTC)reply
Support Rosguill's proposal 1st choice, and also support Fram's proposal 2nd choice. I believe continuing to run the current one-sided donation banners, which use our work to direct support to the WMF's current political actions against unions, isn't right. The WMF's action to spend lots of donor money on such a law firm to pursue such political causes, is abusing both their existing donors and funds, and our website and work which as of today is used unreservedly to increase those funds through banners and power the WMF's political actions. Therefore, I support both stopping the banners (Fram) or adding both sides (Rosguill). The reason I support Rosguill's as first preference is because I believe it's more fair to the WMF and more neutral as it doesn't completely cut off funding banners for those who are still interested, but ensures that donors have the full context which is deserved and both sides are fairly and neutrally presented. - In solidarity,MolecularPilot(talk)23:41, 4 August 2026 (UTC)reply
SupportRosguill's proposal, which most effectively communicates the community's position to our readers, who deserve to be informed when their donations to support the community are instead being misappropriated for union busting (without disclosure). I recommend providing links in the banner to adjacent organizations readers can donate to instead of the WMF, such as Wikimedia movement affiliates and the Internet Archive. (As a second choice, I also support Fram's original proposal.) —Newslingertalk00:41, 5 August 2026 (UTC)reply
I'm not really convinced by this. The WMF holds significant cash reserves and assets, currently at $297 million (and that is excluding the WMF endowment). A temporary pause or additional information on fundraising banners is unlikely to cause any significant economic impact (and impact "our face") in any way. It is more about refusing to endorse their current political actions, and make sure donors are fully informed. In my opinion, money raised through misleading donors into "supporting Wikipedia", which one would infer goes to servers and workers, not massive retainers for law firms so anti-union political actions can be taken, isn't worth it or ethical. I would prefer those who really want to donate do so with informed consent. - In solidarity,MolecularPilot(talk)00:55, 5 August 2026 (UTC)reply
Strongest possible oppose to Rosguill's idea as a hotheaded and knee-jerk reaction with potentially massive long-term financial consequences. Things like that would have impact on Wikipedia's reputation with the general public that would take years to fix. Public goodwill is hard to build and should not be squandered. I am pro-union, but don't bite the hand that feeds you. I am neutral on not running banners at all. Renata•300:57, 5 August 2026 (UTC)reply
Public goodwill is hard to build and should not be squandered, yeah, and I personally blame the executives and board for not doing anything to prevent such squandering. Refusing to inform people would make a lot of the backlash worse, I think. A lot of donors finding out about this through other means have mentioned feeling betrayed. Clovermoss🍀(talk)02:46, 5 August 2026 (UTC)reply
"don't bite the hand that feeds you" – sorry, is WMF meant to be the one 'feeding' us in this scenario? We, the community, create the content, administer the site, and many of us also donate money on top of that. If anything, I would have said we're the hand that feeds here. -- DoubleGrazing (talk) 05:36, 5 August 2026 (UTC)reply
"Hotheaded" and "knee jerk" seems to be a more apt description of the rhetoric in your comment than it is of most of the discussion here. signed, Rosguilltalk19:18, 5 August 2026 (UTC)reply
Support Rosguill's idea first, Fram's original idea second. Rosguill's idea is more effective at informing readers/editors and, by extension, discouraging donations. Fram's idea only does the latter. LightNightLights (talk • contribs) 02:47, 5 August 2026 (UTC)reply
Oppose taking any official position whatsoever, as a community, on the WMF labor dispute. It's not our fight, and it compromises our neutrality. --Trovatore (talk) 03:49, 5 August 2026 (UTC)reply
Donation banners have never been neutral. Calls to action such as "please donate $2.75 right now—or consider a monthly gift to help all year long" only represent the WMF's point of view, and certainly do not follow WP:NPOV or many of our other policies (which obviously do not apply to donation banners, but I am only mentioning because you invoked neutrality in your comment). Rosguill's proposal would present the community's point of view alongside the WMF's point of view, which would make this year's fundraising messaging more neutral than any other donation banners in Wikipedia's history. —Newslingertalk04:17, 5 August 2026 (UTC)reply
My view is that the community should not have a point of view on this. Members of the community, of course, are free to. But the community per se should not. It's not within the scope of what the community does. --Trovatore (talk) 05:25, 5 August 2026 (UTC)reply
A comment that starts "My view is ..." doesn't seem to me to make unwarranted assumptions about whether the speaker's views are the same as the community's. It's a legitimate point of debate here as to whether the proposed action represents something that should be outside the community's usual actions. Mike Christie (talk - contribs - library) 15:36, 5 August 2026 (UTC)reply
I am not claiming to speak for the community. I am not making a claim as to what the community's view is, but about the things the community is entitled to have a view on. I do not think this is in the range of things that it is legitimate for the community to have a view on at all. Again, this is the community an sich; obviously it's legitimate for people in the community to hold a view on it. --Trovatore (talk) 16:48, 5 August 2026 (UTC)reply
The community is not entitled to have a view on the values of the community? On whether the WMF upholds those values? Why not? Levivich (talk) 16:54, 5 August 2026 (UTC)reply
Because it compromises our neutrality. If the community as such takes a position, for example, that unions are good or union-busting is bad, then who can trust, say, that our article on organized labor is neutral? --Trovatore (talk) 17:04, 5 August 2026 (UTC)reply
...but it's OK for the WMF to say that unions are bad? The people who take and spend donor money -- they don't have to be neutral, just the volunteer community? The volunteer community shouldn't break its values, but when the WMF breaks those same values, the community is not entitled to oppose it? That doesn't make sense. Especially considering one of our values is self-governance, which includes governing the WMF (we elect the Trustees who appoint everyone else). If we turn a blind eye when the WMF breaks our values, then we are breaking our values as well. If we stay quiet when the WMF lies, it's the same as the community lying. Levivich (talk) 19:06, 5 August 2026 (UTC)reply
The WMF is in a completely different position than we are. No, they don't have to be neutral. They aren't writing articles that users expect to be written from a neutral point of view. --Trovatore (talk) 19:13, 5 August 2026 (UTC)reply
I personally don't see how a banner like this would be any different from "Wiki Loves Pride" campaign banners (encouraging people to edit LGBT+ content). Just because something is "political" doesn't mean we can't respect NPOV. And a banner is inherently not article content. Clovermoss🍀(talk)19:23, 5 August 2026 (UTC)reply
I think there is a material difference between "edit content about this topic" and "read our opinion about a non-content matter". That's not to say that either type of banner should or should not be run, just that they are not the same and the reason why one is or isn't appropriate doesn't automatically apply to the other. A banner encouraging people to improve content about organised labour (that doesn't mention the dispute) would be the same as a Wiki Loves Pride or similar banner imo, one that mentions the dispute in a non-neutral manner would not. Thryduulf (talk) 21:00, 5 August 2026 (UTC)reply
I think you said it better than I could. That said, the verb "loves" does appear to take a side, which is why I do have something of an issue with it. But it is not quite as obvious a problem as the current proposal is. --Trovatore (talk) 21:15, 5 August 2026 (UTC)reply
Yes, that was the comparison I was trying to make. People have perceived the message as advocating for LGBT+ rights, a political stance. Almost anything can be "political" (a lot of my perspective on this was shaped growing up as a Jehovah's Witness, where the act of voting itself is "political"). User:Guy Macon/Yes. We are biased. is also an interesting perspective in that direction. In this case, one could say we're "biased" towards factual information regarding how the unionization process works in the US and against people who spend a lot of money to misrepresent it. Clovermoss🍀(talk)21:19, 5 August 2026 (UTC)reply
I feel like you're cutting the distinction pretty fine here. I would agree that it's OK for us to take a position in favor of factual information, even as a community. I do not think it's OK for us to take a position, as a community, in favor of (or against) organized labor. I'm afraid these proposed actions would be perceived, not entirely inaccurately, as more the second than the first. --Trovatore (talk) 21:56, 5 August 2026 (UTC)reply
Hmmm, well we're free to disagree. I do understand to some extent what you're concerned about, but I don't think a banner would quite literally say "go support the WWU". I'd hope it to be informational in nature (this is what the WMF is doing, this is how they've misrepresented the unionization process, this is who the money is going to, and we've come to a consensus that this isn't a responsible use of donor funds?). I think at this point we may just have genuine differences of opinion, though. If you want to debate more, my talk page is always open. Don't want you to feel like I'm pressuring you. I just find that talking through every aspect of things can sometimes lead to one changing their mind. Clovermoss🍀(talk)22:32, 5 August 2026 (UTC)reply
Oppose. This is not our fight, and joining it, given the political nature of unions, would compromise our neutrality. It would also likely be a violation of WP:P1 and WP:P2; joining a labour dispute would be using Wikipedia as a soapbox and engaging in advocacy.In addition, WP:CONEXEMPT applies here; running banner ads clearly falls under acts of the WMF Board and its duly appointed designees. For us to decide to overrule CONEXEMPT would require an overwhelmingly strong consensus. BilledMammal (talk) 05:02, 5 August 2026 (UTC)reply
Oppose. As editors, workplace issues of the WMF are none of our business, since we are not WMF employees, not unionized and unpaid. But as editors, we do have a vested interest in the WMF being funded so that they can in turn fund the operation of Wikipedia. Sandstein 07:30, 5 August 2026 (UTC)reply
For me personally, this is no longer about the union, but about the contradiction between the movement's values and the actions of the WMF executives. Involuntary union recognition would do nothing to alleviate my disgust at what has happened. —Kusma (talk) 08:02, 5 August 2026 (UTC)reply
oppose - I don’t think rushing through with such drastic measures would be a good idea right now. With such uncertain times regarding the future of wikipedia (with Ai leading to less readers and less new editors) we need to preserve the trust/goodwill/whatever we still have. This action will have unforeseen effects that outlast current WMF leadership and the union controversy. And as was said previously the WMF has so much money that if truly want to continue this path they just can and then this action will have as much effect as a declaration by the community will have without causing problems in the future when we won’t need them. Short-term this would unfortunately not make any impact. Squawk7700 (talk) 10:59, 5 August 2026 (UTC)reply
We could combine these approaches so that it's harder to unhide them by modifying skins' HTML or stylesheets. WMF could always enable sitewide safe mode, though, which disables all scripts and stylesheets which aren't included in skins. sapphaline (talk) 12:16, 5 August 2026 (UTC)reply
@Thryduulf: Fundraising campaigns have an overview of about five examples or so because sometimes we are testing hundreds of variants in a campaign, so it would be complicated to share every individual message, but this helps give an idea of the range of messages we are sharing at any given time across campaigns. So it doesn't seem like this information is kept on-wiki anywhere, either. It's too complicated to share every individual message, supposedly. Clovermoss🍀(talk)12:42, 5 August 2026 (UTC)reply
@Clovermoss I can certainly appreciate that we don't need inline images of every minor variation in wording, and maybe not images of them all either as long as we have a representative sample of each basic design and maybe a copy of the text too, but complexity is not a reason I'd use justify this view. Further discussion of this is probably offtopic for this discussion though. Thryduulf (talk) 17:06, 5 August 2026 (UTC)reply
Possibly, maybe we could move it to Talk:Fundraising. I think it makes sense to have both, personally. An overview and then a link where one can read a list of every minor variation for transparency's sake. Given long term conflicts about how fundraising is done, I think it would restore some trust in the process. I'm not entirely confident that my definition of "minor variation" matches the WMF's, although I'm sure there's some overlap between the two. Clovermoss🍀(talk)17:12, 5 August 2026 (UTC)reply
I don’t have a strong opinion on unionization at the WMF - However, if this proposal means I won’t receive endless solicitations for donations, then I support it. Of course, it also means that I would encourage the WMF to oppose unionization for as long as possible. Blueboar (talk) 12:29, 5 August 2026 (UTC)reply
Strongest possible oppose to Rosguill's plan we do not need to be airing out intrawiki drama to the public which has little understanding of the project and will be susceptible to narratives from the WMF or even from malicious actors on-wiki hijacking the narrative. Neutral, leaning oppose to Fram's proposal; while I'm weary of the possible precedent this may set, at least this confines the issue largely into the movement. Furthermore, I agree that any proposal here needs mass-community support from the greater editorbase, not amongst the most active in wiki-politics. — Knightoftheswords12:56, 5 August 2026 (UTC)reply
Wouldn't people be more susceptible to the WMF's narrative if we don't do anything to refute it? They already point people to an FAQ that contains blatant lies. I don't think we should assume this proposal wouldn't be supported by the rest of the community. From what I've seen online from people who edit little or mostly just read, they're furious. We can't choose what the WMF does with their donations, but we can decide to do the ethical thing and warn people about it. Clovermoss🍀(talk)13:16, 5 August 2026 (UTC)reply
The furious have a tendency to speak out more than the indifferent, though. No one walks down the street angrily demonstrating for the position, "WE DON'T CARE"! And the furious rarely need help to speak for themselves. Wehwalt (talk) 14:45, 5 August 2026 (UTC)reply
I'm just saying that we shouldn't assume that they wouldn't want us to speak up, since almost everyone I'm aware of who has learned about this and donated has been mad about it. Generally speaking, you'd see more "so what?" if this was some internal drama no one really cares about. But it's more than that. Clovermoss🍀(talk)15:11, 5 August 2026 (UTC)reply
This is entirely true, of course. The loudest noise tends to come from either ends of the spectrum, not from the middle.
Support Rosguill's idea — Banners are already speaking for the silent majority by asking for donations on behalf of their behalf. If we accept such banners being run, that endorses the claim that the money is being used on behalf of the community. If we accept such banners being run when the money is used to give fat paychecks to union-busting lawyers then we are endorsing that. I do not see how that could be construed as neutral. On the contrary, the neutral option here is to refuse to allow banners saying that money used for union-busting is being used on behalf of the community. –Maltazarianᚾparleyinvestigateᛅ19:42, 5 August 2026 (UTC)reply
Oppose. Not worth the disruption and political capital cost since WWU will probably win the NLRB vote. If WMF launches some kind of delaying litigation after WWU wins the NLRB vote, which can happen sometimes and would be clear union-busting, then revisit then. –Novem Linguae (talk) 19:57, 5 August 2026 (UTC)reply
Support Rosguill's idea – Rosguill's idea certainly has merits, and I am utterly unconvinced by the opposition. To address a few points in brief:
NPOV, and by extension 5P2, applies only to encyclopedic content, so does not matter here.
WMF actions are absolutely of interest to Wikipedians, especially when they have the potential for long-lasting reputational harm. This became our fight the second a team maintaining vital community tools was uncerimoniously laid off.
With regards to 5P1, the proposed banner doesn't have to be a hotheaded and knee-jerk reaction. We are meant to be good at writing neutrally, so let's let the reader decide after seeing the facts. All that matters is that this situation is known, which I would argue is not advocacy, just informing.
That said, I agree with Novem above that we should wait to see the outcome of the NLRB vote when taking more drastic action, i.e. the initial proposal. If delaying litigation is pursued afterwords, fire away. UpTheOctave!•8va?21:02, 5 August 2026 (UTC)reply
Considering that it could take awhile for that to happen and the WMF is going to keep spending a lot of money in the meantime, I don't like waiting. When I talked to someone who had experience in this area, they estimated that the WMF had already spent at least $100,000 in this direction, because that would've been what's normal for a case like this. See this email. I've also heard about "optional" captive audience meetings, one of which included 200+ employees, that sort of thing requires donor money to happen. Clovermoss🍀(talk)21:08, 5 August 2026 (UTC), edited 21:15, 5 August 2026 (UTC)reply
I still think that an action as drastic as this from us would be better placed as close to a last resort. It might take a while, but what happens if we do this, and then the NLRB vote comes back green and the WMF accept it? That makes us look like the unreasonable ones here, which is playing right into an anti-union narrative. UpTheOctave!•8va?21:14, 5 August 2026 (UTC)reply
I don't think it makes the WMF look reasonable, it would just show that all the money they spent trying to prevent that outcome didn't work. It wouldn't remove the moral harm of their actions or make them justifiable. Clovermoss🍀(talk)21:16, 5 August 2026 (UTC)reply
I didn't say it would make the WMF look reasonable, just that it would make us look unreasonable. I certainly don't think there's any sort of moral equivalence here. UpTheOctave!•8va?21:18, 5 August 2026 (UTC)reply
Hmm, well I disagree that it would make us look unreasonable, especially if we counter the misperceptions the WMF is encouraging about what all this means (m:Wiki Workers United/Claims and responses gives a very detailed overview for people who might be inclined to believe that it's just about a proper, democratic vote). Clovermoss🍀(talk)21:22, 5 August 2026 (UTC)reply
To be honest, I was mostly meaning that a complete removal might come across as a bit drastic. As above, I've thought a bit more and now think that Rosguill's idea would be fine as long as the banner is as neutrally worded as possible. Thanks, UpTheOctave!•8va?22:45, 5 August 2026 (UTC)reply
To be honest, UpTheOctave!, the WMF staff has repeatedly misled us regarding their approach to the dispute, so I don't think there's much of a need to posture. We don't really get many brownie points for sitting pretty. — ♠ Ixtal( T / C ) ⁂Non nobis solum ♠ 21:20, 5 August 2026 (UTC)reply
Can't speak for anyone else, but if the NLRB vote comes back green and the WMF accepts it, that won't make me any less angry about the WMF lying to the public, wasting donor money, and trying to stop unionization. Same outcome if the vote comes back red. I don't care if the employees do or do not want a union, I care that they get to make a free choice, and I care about WMF leadership upholding Wikipedia values like transparency and accountability. I care that my volunteer work doesn't help raise donations that are then spent on doing evil in the world, like union busting, and blatant lying. Levivich (talk) 21:24, 5 August 2026 (UTC)reply
Hmm, yeah, I agree with that. I've amended my comments a bit after some more thought: I think Rosguill's idea has merits in the here and now, but I still remain a "wait and see" on a complete removal. UpTheOctave!•8va?22:38, 5 August 2026 (UTC)reply
NPOV per se does not apply to this case, that's true. But it points to why we should not take political stances as a community. If we do, it undermines the readers' trust that we can actually be neutral in presenting encyclopedic content. --Trovatore (talk) 22:51, 5 August 2026 (UTC)reply
For me the core of the issue is that inaction is also non-neutral. We, the community, are on-notice that our work is being used to solicit donations that are in turn forwarded toward an effort that many donors would view as unethical and that we were reassured by the WMF was not happening. Not doing anything is taking the stance that we are okay with that, or at least not-not-okay with that. Which is a stance people are entitled to, if that is how they feel; but it's no more or less neutral a stance than Fram or Rosguill's ideas. -- Tamzin[cetacean needed] (they|xe|🤷) 22:56, 5 August 2026 (UTC)reply
When we submit any edit, we explicitly give up control over how it is used. On the larger point, my view is that acts are different in kind from omissions. --Trovatore (talk) 23:00, 5 August 2026 (UTC)reply
We give up control over who uses our content (provided they follow the CC BY-SA license terms), but that explicitly does not mean we must endorse the way it is used, and we all retain the right to criticize any entity that uses our work. As to misdeeds of omission versus misdeeds of commission, that's a matter of personal philosophy; personally I am a consequentialist and I do not see a difference between omission and commission in a case where a person is fully aware that inaction will lead to harm, and where the action that would mitigate that harm doesn't itself cause greater harm. -- Tamzin[cetacean needed] (they|xe|🤷) 23:26, 5 August 2026 (UTC)reply
Support Rosquill's idea (weak oppose on the original proposal). I think the WMF already deserves significant pressure and backlash for being ran by people who do nothing but lie to us about this topic. That is not just a matter of solidarity but also directly connected to editor interests, and regardless of what happens during and after the vote. As for neutrality, apart from what has been said policy-wise, I don't think it's bad to sometimes show how the sausage is made (not talking about article contents of course). Wikipedia isn't made by nobody nowhere at no point in time. I am a bit wary of the original proposal because of the high potential for a wheel war with the WMF – not because I oppose wheel warring with the WMF, but because I think it would be near the last step of escalation, not the first. As has been discussed, the WMF has plenty of opportunities to do more union-busting during and after the vote, so we need to keep our options open in terms of public impact and in terms of not losing technical abilities too early on. -- Maddy from Celeste (WAVEDASH)21:28, 5 August 2026 (UTC)reply
While I hope this can happen without any wheel war with the WMF, I don't think that would actually be a near-final escalation. There have been multiple such wheel wars in Wikipedia history, most recently during WP:FRAMGATE. All of them had serious impacts on community–WMF relations, but we survived them all. The real nearing-the-end-of-the-road escalations, in my view, would be actually preventing donations, a full-scale editorial strike, a lengthy blackout, or most radically a fork of the wiki—none of which would be appropriate at this time. A technical power struggle between admins and the WMF, while messy, would not do nearly as much damage as any of those. -- Tamzin[cetacean needed] (they|xe|🤷) 22:05, 5 August 2026 (UTC)reply
To be clear, with the wheel warring part I specifically meant Fram's original proposal to actually remove the fundraising banners, i. e. "actually preventing donations". Unless you by that mean something even more radical, like removing all donation links from enwiki? -- Maddy from Celeste (WAVEDASH)22:11, 5 August 2026 (UTC)reply
Either Fram's idea or Rosguill's could plausibly lead to the WMF invoking WP:CONEXEMPT and trying to override the community, which would presumably lead to what you're calling a wheel war and I described above as a constitutional crisis. Whether that actually would happen is harder to predict. -- Tamzin[cetacean needed] (they|xe|🤷) 22:16, 5 August 2026 (UTC)reply
To be honest, I don't see how we could accept a CONEXEMPT argument unless the donation banners are altered so as to not pretend like they are donations to the EnWiki cause. Invoking CONEXEMPT in order to lie to readers about what EnWiki thinks, for the purpose of making money that is going to union-busting law firms, is an intolerable state of affairs. A community that is okay with having their collective voice co-opted for a purpose like that is one that I personally could not in good conscience partake in. –Maltazarianᚾparleyinvestigateᛅ07:51, 6 August 2026 (UTC)reply
Support with a slight preference for Fram' s implementation over Rosguil's. I feel that either version of this is equally a constitutional crisis, and if we're going to do that (which we absolutely should, to be clear) we should go with the much simpler option that also doesn't provide a donation link at all. Loki (talk) 22:19, 5 August 2026 (UTC)reply
Oppose: Per RoySmith. Besides, if the union does come about (which is increasingly likely), the WMF will probably need additional funding anyways. ARandomName123 (talk)Ping me!22:58, 5 August 2026 (UTC)reply
Some navigational templates have links to redirects. The expected behavior is that the link to the current article is unlinked and bolded. Currently, the link is only bolded when it exactly matches the title of the article, breaking expectations for links that are redirects. TPI81AF (talk) 19:48, 3 August 2026 (UTC)reply
The target names can be very long relative to the redirected name. Where am I intended to submit feature requests? From your tone, I infer that it is not the WikiProject Templates talk page. TPI81AF (talk) 22:06, 3 August 2026 (UTC)reply
So is it preferable that the navigational template should include [ Professor Kageyama's Maths Training: The Hundred Cell Calculation Method ] or [ Professor Kageyama's Maths Training: The Hundred Cell Calculation Method|Personal Trainer: Math ] rather than [ Personal Trainer: Math ]? A much shorter link would seem to be ideal in navboxes where space is limited. If the article page is moved and it is linked to in several navigational templates, editors often forget to update all or any of the redirected links to piped links so this proposed change would also save some effort globally. TPI81AF (talk) 23:26, 3 August 2026 (UTC)reply
In navigational templates, that links to redirects to the current article should be rendered bold as direct links are. Currently, if the link is not a direct link it appears the same as all the others. (There is an edge case mentioned in WP:BRINT where redirects are intentionally left unbold that could be handled by checking for section links) TPI81AF (talk) 15:42, 4 August 2026 (UTC)reply
Now that you have actually named an article, instead of leaving us completely in the dark, I'm guessing that you refer to Template:Touch! Generations. For the specific article concerned, the template contains
the first link of which is an unpiped redirect, and the second is a direct link, not piped and not redirected. It would be acceptable (and indeed desirable for the first one, per WP:BRINT) to alter these to
|group4=2009
|list4=
*''[[Walk with me! Do you know your walking routine?|Personal Trainer: Walking]]''*''[[Professor Kageyama's Maths Training: The Hundred Cell Calculation Method|Personal Trainer: Math]]''
I don't see what the problem is about space - if the right margin is reached, navboxes will wrap the text just like any other part of the page. I also don't see what the problem is about pages being moved - if a page is moved, a redirect is left behind and the link still works, even if it doesn't get bolded. --Redrose64🌹 (talk) 10:14, 4 August 2026 (UTC)reply
The problem is that the link isn't bold until some editor notices that the page was moved and has manually intervened to get it to bold again. Ideally the system could automatically handle this case by bolding the appropriate redirected links. TPI81AF (talk) 15:35, 4 August 2026 (UTC)reply
I suppose that would be nice. Unfortunately that's not anything we can do anything about; that would be something that the WMF has to take care of on the backend. I recommend submitted a phabricator request to get this change made. Primefac (talk) 22:33, 4 August 2026 (UTC)reply
Interesting. Would you mind if I moved this entire discussion to WP:VPR? It's a better forum for this sort of discussion (as it's not related to this project) and it wouldn't require rehashing the entire discussion again. Primefac (talk) 22:42, 4 August 2026 (UTC)reply
Just to restart the threading and give a very quick summary of the above: TPI81AF is wondering if we can make all circular redirects bold on the page so that navboxes don't need to be updated as frequently following any page moves. Primefac (talk) 23:08, 4 August 2026 (UTC)reply
I think this would be a good change. We might provide some guidance on when redirects are more appropriate than piped links. In general, we encourage appropriate, contextual use of redirects that are WP:NOTBROKEN and navboxes are an exception to this practice due to technical limitations. For an {{R with possibilities}} or an {{R to section}}, for example, it makes sense to use the redirect. I often see redirects used in templates and navboxes when I'm reviewing 'What Links Here' for links to redirects from article space. Editors naturally want to use redirects in these templates the same way they do elsewhere in article space, or don't even realize the link is a redirect, and if we can facilitate that, we should. —Myceteae🍄🟫 (talk) 23:18, 4 August 2026 (UTC)reply
There seems to be some confusion over the actual issue. It also didn't help that at phab:T433904 the request was unclear, which brought about the early closure as "invalid". The comment by AKlapper(WMF)(talk·contribs) was This needs fixing on the local wiki by editing its local content. which suggests to me that they believed that the issue was simply one of incorrect wikimarkup in the template. Reading the opening paragraph here again, together with subsequent posts by TPI81AF, the desire is that redirects to pages be treated exactly the same as direct links (for instance, if I add a link to Wikipedia:Village pump (proposals) here, it's shown black and bold, whereas a link via a redirect such as WP:VPR is shown in blue). That is not something that can be altered on-wiki, but requires a MediaWiki software change, for which Phabricator is the proper venue. --Redrose64🌹 (talk) 17:59, 5 August 2026 (UTC)reply
Since we're here, and TPI81AF has been sent to several different venues and has been told that the request needs clarification, perhaps someone could suggest wording for a proper phab request. —Myceteae🍄🟫 (talk) 18:09, 5 August 2026 (UTC)reply
Thanks for raising this issue, and thanks to all the other editors who have helped clarify the question and direct it to the right place. —Myceteae🍄🟫 (talk) 18:20, 5 August 2026 (UTC)reply
This could probably be addressed via WP:AWB or even a bot: just find redirects and pipe them.
To be candid, I think this is a pretty unimportant problem because it appears only rarely, has an easy fix that any editor can do, and is only seen on the desktop site. It probably affects very few people in practice. Here's a quick back-of-the-envelope calculation in case anyone's curious:
Professor Kageyama's Maths Training: The Hundred Cell Calculation Method has 300 page views per month, so applying the usual numbers, that's 120 on the desktop site. There's about a 50% chance of a reader clicking on any link in the first article they read (which takes us down to 60), and there are about 60 links in the article (half in the navbox), so we're talking about slightly inconveniencing or confusing one reader a month – at most, because (a) click distribution is biased away from the end of the articles, which is where the navboxes are located and (b) since nearly half the people arriving at this page were already on a Wikipedia page, the chance of them clicking on any link at all is lower than the usual 50% (but I don't know exactly how much). At any rate, we're talking a handful of readers per year, out of more than a 100 billion page views per year. It's probably be more useful to put the WP:ELOFFICIAL website in the infobox than to worry about this, as that would likely interest a lot (>10x) more readers.
Your words are enlightening, to me and hopefully to editor TPI81AF, others above who seek a software solution, and the overworked devs, who have higher priorities to deal with. Here's another reason to smile knowingly: as a certified Wikignome one of my favorite WP duties is finding and bypassing redirects in navbars. It's one reason I became a page mover. When I close a move request, either moved or not moved, I check the article for navbars and bypass the redirects. And not just the one redirect left behind by the page I just renamed, I find and bypass any and all other redirects in the navbars that need bypassing. I've been doing this since I first registered and really do enjoy that part of the job! And I'm not the only one. There will always be low-priority things to do on WP for us gnomes to fix. They puts the "edit" in "editor"!>) P.I.Ellsworth,ed.–welcome!–23:48, 5 August 2026 (UTC)reply
The "suggested links" tool, which prompts newbies to add links in articles, is more trouble than it's worth. Every few weeks, at least, I see an article edited as suggested with the addition of links that are just plain wrong. One that sticks out in my memory was the linking of the phrase operation of law in a sentence about the day-to-day operation of law schools. Today it was on List of Blue Bloods characters, where, in reference to a character having worked in the Brooklyn South Division it suggested linking Brooklyn South, which sounds like it makes sense if you don't know that Brooklyn South is just the name of an unrelated TV series, and not relevant to the article where the link was added. On other occasions, I have seen a slow motion project-wide edit war between suggested links and editors dealing with WP:OVERLINKING (which suggested links often amount to). There are more than enough tasks needing work that a low priority busywork tool with a high enough error rate to make me go "not this again" should be eliminated. BD2412T15:58, 5 August 2026 (UTC)reply
MMiller (WMF) is the most likely person to be able to change this, at least among my limited "people I remember working at the foundation and work in this area" mental checklist. KStoller-WMF has also participated in some related discussions. I will say this isn't the first time I've seen this feature suggested as harmful to the new user experience. It definitely prompts a lot of new editors to try and use it, but I think it kind've defeats the point of more active participation if they'll get reverted for it. It's demoralizing to get told not to do something you were told to do by the software itself. Clovermoss🍀(talk)16:57, 5 August 2026 (UTC)reply
I think it kind've defeats the point of more active participation if they'll get reverted for it. We’ve found that being reverted is one of the most demotivating experiences a newcomer can have. This is actually part of what motivated us to create Add-a-Link, as we wanted to give newcomers an easier, more structured task where they would be less likely to get reverted and could build up their confidence.
Given their inexperience, newcomers are still going to make mistakes and get reverted sometimes. But compared to the baseline of newcomers making unstructured edits, we’ve found the tool to be a success. In the A/B experiment we ran, we found:
The group of newcomers for whom the feature was enabled was 33.7% more likely to successfully make an edit that was not reverted ("constructive activation"), 3.7% more likely to stay active ("constructive retention"), and 19.6% less likely to have their edits reverted ("revert rate"). This is similar to our prior findings for the feature in other languages.
I just worry that the percentages aren't accurate, given the manual and slow nature of a lot of the reverts. And I do think that the impact of being reverted is heightened when it's a consequence of the software literally telling you to do something vs an independent decision where you might feel like "oh, it probably makes sense that I messed up". Clovermoss🍀(talk)23:31, 5 August 2026 (UTC)reply
Any "manual and slow nature of" reverts ought to apply equally to other good-faith edits, though, so even if that's a problem, it's a problem equally distributed across the two groups. WhatamIdoing (talk) 02:02, 6 August 2026 (UTC)reply
I'm not sure that's nessecarily the case, although I think statistics shouldn't just be for a short time frame and should try to account for reverts that might not be as easily tagged, but I'm not sure how technically possible it is. I think this type of edit would be more likely to be "hidden" by filters, less likely to be immediately reverted because someone doesn't have that specific article on their watchlist, etc. I guess what I'm saying is it's the exact sort of small change that might have a skewed ratio on paper in a favourable looking direction. Clovermoss🍀(talk)02:21, 6 August 2026 (UTC)reply
From the notes: "These figures reflect the revert rates for all article edits made by users in each group on English Wikipedia rather than only edits made through the “Add-a-link” structured task. Edits made via “Add-a-link” specifically have a lower revert rate than the overall rates presented here."
The only difference between the two groups is that one randomly selected group had the feature enabled – not that they all used it, but that the software feature was there. It's about "Users assigned to the treatment group", not "Users who made this type of edit". This is the same kind of trial run when researchers want to know whether telling someone to floss their teeth improves dental health: you're comparing the ones in the treatment group, including the ones who didn't floss their teeth, against the ones in the control group, including the ones who decided to floss their teeth without being told. WhatamIdoing (talk) 02:39, 6 August 2026 (UTC)reply
And I'm saying that having the feature enabled by itself matters, because being prompted to do something affects people's behaviour and how they perceive what comes after. I'm not saying we need to get rid of the feature entirely, I'm just pointing out the flaws of "metrics are good" reasoning. Clovermoss🍀(talk)03:27, 6 August 2026 (UTC)reply
When users add multiple links, when one is bad the others can be good or neutral. Partially reverting the bad ones may not show up as a reversion. CMD (talk) 03:17, 6 August 2026 (UTC)reply
I agree that the tool leads to a lot of overlinking (and the wrong links as pointed out by BD2412 are really bad). There would need to be quite big advantages for the tool to counter these downsides. Does anyone or @WhatamIdoing know if we have any research about that? —Kusma (talk) 18:02, 5 August 2026 (UTC)reply
I'm sure there is some research. However, the research we need would answer a question like "Is the main problem this particular tool, or is the main problem that newbies make mistakes?"
There have been 558 such edits in the last 24 hours. 297 of them were from accounts that haven't even made 10 edits yet (and so not autoconfirmed). Only one (1) of those edits has been reverted so far. This does not look like evidence of a serious problem. WhatamIdoing (talk) 18:31, 5 August 2026 (UTC)reply
I've found a lot of errors, but I don't revert unless every link they add is incorrect. Instead, I manually remove the bad links. (For example, removing a wikilink to the wrong person or to the wrong target for that context.) The problem that I've seen is the tool suggesting bad links and new editors not having the experience to recognize them. When a new editor adds an inappropriate link, I fix it, but then also feel obligated to go through their other edits to correct similar problems on articles I'm not watching. Schazjmd(talk)18:40, 5 August 2026 (UTC)reply
Would it be easier for you if we only let the tool suggest one (or even two) links at a time? It's currently set to a maximum of three suggestions per edit. WhatamIdoing (talk) 18:44, 5 August 2026 (UTC)reply
If they could only make one link per edit, it would be a quick revert. I just wish the tool made smarter recommendations. Recent examples of bad ones: Schazjmd(talk)18:53, 5 August 2026 (UTC)reply
@Schazjmd: I see a very clear problematic pattern here of the tool wanting to link lowercase phrases (e.g. "fashionable friends", "a taxi driver", "why her") with capitalized names of works (Fashionable Friends, A Taxi Driver, Why Her). I can't imagine why on Earth anyone, machine or not, would think that such a title would reflect the generalizable lowercase phrase. Barring non-matching capitalization from the tool would prevent the bulk of these, though ironically not the two cases that mentioned, which do have matching capitalization. BD2412T19:38, 5 August 2026 (UTC)reply
In the category of "low priority busywork": If you see this tool exclusively as a method of adding desirable links, and you assume that its users would do something more significant if it didn't exist, then I can understand describing this as "low priority busywork".
However, I suggest that you consider:
that the tool's real value might be in teaching newcomers how to make links and that we want to Wikipedia:Build the web between articles,
that many newcomers probably can't do complex tasks, so the realistic choice is better "low priority busywork" and nothing, rather than between "low priority busywork" and "high-priority contributions", and
that if someone is consistently sloppy about making links, it might be better to find that out now, while they're doing "low priority busywork", and let them earn a block for incompetence instead of waiting until their sloppiness extends into areas that are more subtle or complicated to fix.
If we're getting too many poor suggestions, then I think that it might make sense to look at making a few changes to Special:CommunityConfiguration/GrowthSuggestedEdits#link recommendation. We're already limiting access to the tool (no more than 15 articles per day; never for anyone with more than 150 edits). Should we change the "Weight of underlinked articles" (currently set to 50%) to make it pick articles that are more severely underlinked? Should the "Minimum required link score" go up, to increase the required confidence in link suggestions? We've got some levers here that don't involve just a binary on/off. WhatamIdoing (talk) 18:24, 5 August 2026 (UTC)reply
Your last point is an interesting one. At the German Wikipedia, users are limited to one link per task (rather than three) and seven tasks per day (rather than 15); the task is turned off after the user has made five edits (rather than 150); and the "Minimum required link score" is 0.7 (rather than 0.6). Maybe some of those changes would be worth making here. Extraordinary Writ (talk) 18:35, 5 August 2026 (UTC)reply
I think that the approach taken by the German-language Wikipedia won't work for us, especially with cutting off the task before many people have had a chance to try it (especially if they start with Wikipedia:The Wikipedia Adventure, which can make more than 20 edits). But I think we should try making a small change in that direction. WhatamIdoing (talk) 18:42, 5 August 2026 (UTC)reply
I agree. I'll be honest, there's been a few times I've ignored edits with this tool that probably should have been reverted because it felt like too much effort and didn't seem like that big of a deal in the grand scheme of things. I figured that if someone else cared enough, they would revert later, and sometimes they do, even if it takes months. I don't think reversion rates are entirely accurate if people are manually fixing these as they come across them much later. Clovermoss🍀(talk)19:11, 5 August 2026 (UTC)reply
Yeah, one link per task seems sensible. Making it easier for patrollers will presumably result in more problematic links being reverted. That, in turn, should make the revert statistics more reliable—that is, more reflective of the true "bad link" rate. In theory, the current revert rate is artificially low because the effort required to review multiple links tends towards keeping more bad links and because manual correction (reversion) of just one out of three links may not be consistently logged as a revert. I don't know enough about these levers to have a strong opinion but a modest increase to the link score also seems reasonable. —Myceteae🍄🟫 (talk) 19:38, 5 August 2026 (UTC)reply
Thanks for raising this point about the difficulty of reverting Add-a-Link suggestions when there are multiple suggestions in an edit, @Extraordinary Writ/@WhatamIdoing/@Kusma/@Clovermoss/@Myceteae. Limiting to one link per task will resolve that, although it may also lead to a few more instances where only one item in a list gets linked.
One other approach to this issue we briefly considered (and could explore again if there is interest) is to make each added link a separate edit, just publishing them in rapid succession after clicking "publish" when a user adds multiple links in one article. This would make reverting easier, but it could also clog watchlists by producing more overall edits. I'm curious to hear from folks — would this be more desirable? Sdkb‑WMFtalk23:55, 5 August 2026 (UTC)reply
I believe that the tendency towards poor suggestions arises out of the nature of Wikipedia as a very large general purpose encyclopedia. As with the recent Blue Bloods example, there are just way too many titles that sound like some general topic but are in fact titles of specific works, which could be films or songs or albums or books. Similarly, the "operation of law" instance is misuse of a term of art within a specific profession. If links were limited to topics that were definitively the topic, like titles properly categorized as place names or names of people, presuming that we didn't get mistakes in the identity of ambiguously named places and people, that would be much better. At the same time however, place names tend to be some of the most overlinked in articles. BD2412T19:30, 5 August 2026 (UTC)reply
It looks like this problem was identified for Vietnamese at phab:T278864#6961431 but I don't see a more general Phab ticket. From the comments above, it sounds like our plan so far is:
to write a Phab ticket asking for lowercase text to not be matched to proper nouns, and
to edit the configuration to suggest just one link at a time.
@WhatamIdoing: I would say at the least to only link where there is already exactly matching capitalization, but I am wondering if we can just exclude all subjects categorized as titles of media from the tool altogether. There are plenty of other things to be linked without these in the list. That, and limiting to one link at a time and perhaps fewer instances per day, would address the immediate concerns. BD2412T21:56, 5 August 2026 (UTC)reply
Matching the capitalization should be a one-way street, because a link to the article Chocolate cake should be suggested when it's capitalized at the beginning of the sentence ("Chocolate cake is good") as well as when it's not capitalized in the middle of the sentence ("This chocolate cake is good"). What we don't want is a sentence like "Prison and Chocolate Cake was first published in 1954" to be linked to Chocolate cake, because Prison and Chocolate Cake is the title of a book. Our article on cakes made of chocolate should be suggested for any sentence-case string (chocolate cake, Chocolate cake) but not for the title-case string (Chocolate Cake); if our article is in title case, it should only be linked if the article text is also title case (e.g., the article Alice and Bob can be suggested for any mention of Alice and Bob, but not for Alice and bob. Unfortunately, we'll lose Alice And Bob matches). WhatamIdoing (talk) 22:44, 5 August 2026 (UTC)reply
I think we should try raising the "Minimum required link score" a bit, maybe to 0.7. Special:NewcomerTasksInfo indicates that there are over 1.1 million possible tasks in the pool right now, so I don't think there'd be any harm in being a little more selective (although finding the right threshold might take a little experimenting). Extraordinary Writ (talk) 22:20, 5 August 2026 (UTC)reply
@WhatamIdoing Thanks for chiming in and offering to support Community Configuration changes. I agree adjusting some config settings seems like a good place to start.
We are aware of two main issues with the model currently, both of which I see reflected in the concerns raised above:
The model looks at individual words, rather than phrases, which is resulting in many of the partial name links over proper nouns (sometimes improperly capitalized), including in the Brooklyn South diff. To address this, in T405185 we are introducing named entity recognition, which should resolve this. I discussed this task again just now with the product manager of the Machine Learning team (which works on the model), and they've committed to moving that work forward.
The model is trained on the first sentence of every article, which we believe may be leading to some of the overlinking tendencies because first sentences contain contextual links to more generic topics. In T415623 the Machine Learning team will explore retraining the model to instead use the first sentence after the lead section, which I’m hopeful will help address the overlinking issue. To help reduce overlinking suggestions, admins can also increase the "Weight of underlinked articles" score via the Suggested Edits Community Configuration form to prioritize articles that are more severely underlinked.
@KStoller-WMF: Does that mean that the requested fixes are not possible? One of the above examples is of an article with a sentence ending with saying that someone "was a taxi driver", which the tool advised to be linked to the media, A Taxi Driver. If these kinds of edits were not being pursuant to the suggestions of the tool, I would think a vandal was trolling us through intentionally bad links. I don't see how the partial name check would have prevented this one, as it is a complete phrase. What we should be doing is forcing sentence case capitalization matching, and excluding media titles from being linked at all. BD2412T23:54, 5 August 2026 (UTC)reply
@BD2412 The requested improvements are possible, although they’re not trivial, which is why they weren’t prioritized immediately.
The capitalization matching specifically is something we’ve been thinking about beyond just named entity recognition. The bottom half of the description of T405185 captures work on training the model to make use of the signals case sensitivity provides, which is essentially what you’re describing: in your “taxi driver” example, the mismatch between the lowercase phrase in the article and the capitalized title “A Taxi Driver” is exactly the kind of signal that work aims to have the model learn from. There’s also T409138, a related but separate task that looks at instances where the model suggests a link to the wrong proper noun (e.g. if there were two films both titled A Taxi Driver).
We’re prioritizing named entity recognition first because we believe it will have the greatest impact. However, we’re committed to continuing to improve the quality of Add a Link suggestions. Once that work is complete, we’ll evaluate the remaining issues and continue exploring additional improvements where they’re needed.
At the same time, no machine learning model will ever be perfect. That’s why we the onboarding instructions for newcomers make it clear that suggestions may be incorrect and encourage them to use their own judgment. Our expectation, however, is that these improvements will make the suggestions significantly more accurate than they are today.
And sorry that you've found these newcomer edits frustrating. I'm hopeful that, together with the Community Configuration changes discussed in this thread and continued improvements to the link suggestion model, we can strike a better balance by preserving approachable, less intimidating ways for new editors to get started while reducing the burden on experienced editors and patrollers. - KStoller-WMF (talk) 02:42, 6 August 2026 (UTC)reply
My inclination would be to suspend use of the model until the proposed improvements are implemented. I am not in principle against link suggestions as a learning tool. I am very much against link suggestions that have an excessive probability of being erroneous. While we do want to encourage more editors, ultimately our encyclopedia is for the readers, and readers should not face the confusion of following links to the wrong place. BD2412T02:55, 6 August 2026 (UTC)reply
Hi all (and thanks for pinging us, Clovermoss)! Add-a-Link is a feature we created as the Growth team, so Kirsten and I can speak to these concerns.Add-a-Link's onboarding instructions, telling editors to judge each suggestion as it may be wrongAdd-a-Link is a type of structured task. We’ve built these to break down the editing process into a series of steps that newcomers can accomplish easily, particularly on mobile, to help them get used to editing. We gave all newcomers access to Add-a-Link last September after this discussion. We’re trying to help improve underlinked articles by suggesting potential links, but editors are still instructed to use their own judgement to evaluate whether or not they are appropriate to add (see screenshot). As with other forms of assisted editing, editors are ultimately responsible for the edits they make, and like with other editing, some will edit less carefully than others; in this case they can be warned with {{Uw-addalink}}.I know it can seem like a lot of these edits are getting reverted, but unfortunately newcomers in general are reverted frequently. As I mentioned to Clovermoss above, our data shows that Add-a-Link improves on the baseline and results in fewer reverts than newcomers editing without structure.All that said, we do recognize that having the suggestions reflect the encyclopedia’s best practices for linking is important for teaching newcomers about them. I hope resolving the two issues with the model that Kirsten mentioned above will improve this significantly. In the meantime, the Community Configuration controls I hope will allow you all to mitigate them sufficiently that it won’t be necessary to disable Add-a-Link overall. Bringing in newcomers with easier structured tasks so that they can build up their confidence before diving into more complex tasks is vital for onboarding the next generation of editors, and we want to handle it in a way that results in as few reverts/as little extra work for other editors as possible.Cheers, Sdkb‑WMFtalk23:38, 5 August 2026 (UTC)reply
Advising newcomers to add incorrect/irrelevant links as part of a training exercise is not going to go well for anyone. BD2412T23:51, 5 August 2026 (UTC)reply
Support tweaking Special:CommunityConfiguration/GrowthSuggestedEdits to one link an edit. Perhaps in the same way as checking multiple links takes up reviewer time, it may contribute to new users not bothering to check the links. phab:T405185 which is about an issue which directly leads to bad links has been open since September, phab:T415623 and phab:T415622 which relate to less directly bad issue of overlinking have been open since January. All are still set to "Needs Triage", so we should take our own action as we can. Switching to one link an edit would give more relevant reversion statistics too. CMD (talk) 03:29, 6 August 2026 (UTC)reply
Settings changed: Given the comments above, I've changed the settings for this task so that it only suggests one link each time, and correspondingly bumped up the number of tasks that can be completed per day. In solidarity, asilvering (talk) 05:27, 6 August 2026 (UTC)reply
Just noticing this discussion, switching to just one link per article was one of the most important changes we made on German Wikipedia to increase acceptance of this newcomer task. I don't have any data but in our perception the tool is usually able to identify one useful suggestion while the second and third link suggestion are significantly worse. @Sdkb-WMF perhaps that's something the Growth team wants to investigate? Increasing the minimum required link score to 0.7 also seemed to have a positive effect (and still leads to more than enough article suggestions on dewiki).
Even after making these changes we decided to significantly limit the number of edits because we want newcomers to progress to more useful tasks more quickly (e.g. adding references), given that users are automatically promoted to dewiki's autoreviewed user group once they reach 50-150 article namespace edits. I've heard from other wikis also setting limits stricter than 150 edits, e.g. to avoid users getting eligible to vote in local admin elections entirely by completing "add link" tasks. Johannnes89 (talk) 06:31, 6 August 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 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
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 think that is a weird example. The entire purpose of rent control is to make housing affordable, not address the criticism that it reduces housing quantity and quality. The limited studies mentioned in Rent control#On low income renters have one against and two for the claim that rent control makes housing stably affordable. In solidarity, Aaron Liu (talk) 20:51, 5 July 2026 (UTC)reply
Housing quantity itself makes housing more affordable, so rent control reducing housing quantity ultimately makes housing less affordable for anyone who doesn't directly benefit from it. At least, under the mainstream economic reasoning we're talking about here. Loki (talk) 22:04, 5 July 2026 (UTC)reply
That's not quite right. It depends on circumstances.
The price ceiling meaning it's impossible to make it less affordable (unless said ceiling is higher than the price without said ceiling) aside, the law of supply and demand you're talking about only applies if supply exceeds demand. Meanwhile, the US has for a long time had a housing shortage for decades, New York's City has had a housing shortage since the end of White flight, and California since the '70s; there's 6 US states with localities enacting rent control and that's 2 of them. A lot of that quantity from lack of rent control you're talking about might come from the law of supply: it's the fact that the price is high that's drawing more to enter this market and supply more quantities. Since this is economics there's a ton of other factors that I omit and do not know but IIRC this is the picture in broad strokes. In solidarity, Aaron Liu (talk) 19:47, 6 July 2026 (UTC)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 fewphilosophicalviews 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
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 policyUser: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.
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
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
@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
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. -- LWGtalk(VOPOV)20:44, 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
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
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. -- LWGtalk(VOPOV)23:21, 29 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 Albury14: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
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
@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 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
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
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. ϢereSpielChequers23: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.
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. -- LWGtalk(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. -- LWGtalk(VOPOV)23:38, 29 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, Rosguilltalk14:10, 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 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
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
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
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
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. CaptainEekEdits 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. -- LWGtalk(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
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
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. -- LWGtalk(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
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 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
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.
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. -- LWGtalk(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
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
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
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:
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. -- LWGtalk(VOPOV)16:34, 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.
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.
+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.
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é Courianov^_^vObject Class:Drygioni03:17, 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 contribs12:35, 27 July 2026 (UTC)reply
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
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
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
? 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.
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 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 solidarity22:11, 19 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
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
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 solidarity20: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
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
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.
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 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 Albury16:38, 21 July 2026 (UTC)reply
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
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.
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
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
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
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
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, 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
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
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
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 solidarityWikipedian12512 (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
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
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:
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".
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.
Replace |type=user with |type=userbox in the renamed categories.
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
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.
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.
SupportCategory:Userboxes and its sub categories should only be for userboxes, and not for other templates. In the past I removed many that were not userboxes, but I was not able to remove the ones that were protected. I asked for them to be moved to another category and my request by an administrator was denied. Catfurball (talk) 17:12, 3 August 2026 (UTC)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). — Knightoftheswords05:16, 27 July 2026 (UTC)reply
This comment indicates that it's not feasible, so it may not be worth discussing.
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 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
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
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.
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.
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
@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
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.
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 agree that it is logistically challenging. May be you want to write an essay that helps people calm down. As for "changing Wiki culture" the word challenging would be too mild. But please do consider the essay route. Have a good day. Yesterday, all my dreams... (talk) 23:51, 1 August 2026 (UTC)reply
But please let us accept that a single essay will not help everyone. So you must use 3 or 4 questions upfront that allows them to click and get 3 or 4 essays. So you have a brief top level page that leads to different types of advice. Good luck. Yesterday, all my dreams... (talk) 04:21, 2 August 2026 (UTC)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. BD2412T03: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 with the Spanish Wikipedia version , 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
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
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
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.
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
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
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
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
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
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
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. SighChompyTheGogoat (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
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
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
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
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. 23." /> to {{sfn|Johnson|Smith|2005|p=23}}. The subref doesn't seem any easier to use, is less concise, may require finding the arbitrary label a previous editor decided to give your source, and doesn't handle the for you. My point isn't that sub-referencing is bad actually. My point is only that it's not a straight upgrade to {{sfn}}, which handles some things better and other things (like, eg, references that don't use {{cite}} templates) worse. If you like sub-referencing, great, but by itself it won't make {{sfn}} obsolete. – Scyrme (talk/solidarity) 17:15, 30 July 2026 (UTC)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
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
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
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: <refname="label"details="p. 42."/> vs. <refname="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 <refname="h2g2"extends="label">p. 42</ref> like normal references:<refname="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
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
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
The true "one universal standard that covers everyone's use cases" hasn't even been mentioned in this discussion yet: {{r}}. (Actually, it has been mentioned once.) Ah, blessed {{r}}, when they finally figured out how to do all the citations. Somehow it can even already do sub-references. Although, the current way to do that looks extremely confusing. Anyway, I just hope all the citation styles have fun. Dingolover6969 (talk) 19:44, 4 August 2026 (UTC)reply
R is the worst template. Trying to use that in visual editor is like pulling teeth. Also, the thing about R is that you can do like 6 different cite styles with R - it doesn't exactly solve the issue. PARAKANYAA (talk) 23:03, 4 August 2026 (UTC)reply
I find all of the citation templates cumbersome to use. Sometimes I just free text the citation side of <ref>...</ref> tags. I usually muddle through trying to do it the right way and I find the experience quite aggravating. —Myceteae🍄🟫 (talk) 23:11, 4 August 2026 (UTC)reply
Yeah, this is why I don't think adding sub-referencing will solve the problem, because each of us as individuals have our own preferences that may not work with another's. That is the principle of citevar. I really dislike plaintext citations and like CS1 but other editors like plaintext and hate CS1. Hell, we couldn't even come to consensus on suggesting templates rather than text alone.
Even though I mostly use sfn and will continue to use sfns, am still glad about sub referencing, as it may free me personally from {{rp}}, which I have always hated using but still had cause to use in certain situations, so hey. And I am sure on the other hand people will use sub referencing as they see it as better than sfns (while continuing to use rp). PARAKANYAA (talk) 23:15, 4 August 2026 (UTC)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?
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'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
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
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
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
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:
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.
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
"No original reporting" is basically just restating WP:NOR. Nothing new there. The second section provides most of the substance, including most newsworthy events do not qualify for inclusion and while including information on recent developments is sometimes appropriate, breaking news should not be emphasized or otherwise treated differently from other information. ChompyTheGogoat (talk) 09:56, 2 August 2026 (UTC)reply
It was new then, because NOR wasn't created until 2003.
I wonder how many editors have looked at the statement most newsworthy events do not qualify for inclusion with an actual paper copy of a newspaper in hand. I like to use Kansas as an example, because it's in the geographic middle of the US. The Wichita Eagle is the biggest daily newspaper in that state, and they very conveniently have a news reader that lets you see which things are on which pages. Here's the contents of the first few pages of last Friday's paper:
Page 1:
Red Cross blood supply crisis (USA Today Network)
A state agency will open an office in a small town
Latest strikes in the Iran war (NYT News Service)
Meet the candidates for county judge elections
Page 2:
Town irritated by county fire-prevention rules
(continuations of articles that started on the front page)
Page 3:
Regional update on the Cyclopspora outbreak
RFK Jr. said something about the outbreak (USA Today Network)
Groundbreaking ceremony for a local hotel
Page 4:
Rumor that a local restaurant might close (false; only the building will be sold)
Consumer spending up in Q2 (Reuters)
Trump using Todd Blanche's nomination as a way to force support for an unrelated tax cut (NYT News Service)
Routine "FYI" about open container laws
Page 5:
Iran objects to US using military bases near them (Reuters)
Local man arrested for crime
(continuation of article that started on the front page)
Page 6:
City gives developer a tax cut in return for building apartments
Local restaurant will reopen next week
Zoox robotaxis approved (Reuters)
Page 7:
Caller threatened mass shooting
Teenager with BB gun chased someone
Fatal motorcycle crash
Rape reported
Dulles Airport to be redesigned (NYT News Service)
I count 22 news articles. I count zero subjects that qualify for a Wikipedia:Separate, stand-alone article. American Red Cross doesn't even mention their recently declared crisis in the blood supply. We've got articles about the Iran war, but not a separate article about the individual events mentioned here. The election for the county judges probably doesn't merit a whole article; certainly "we interviewed the candidates" doesn't. The "explosive diarrhea" outbreak gets two articles in Friday's paper, but it only gets one section in Cyclosporiasis#2026 United States summer outbreak. There are eight articles (35%) about local businesses or local crimes, and none of them will even get half a sentence in Wikipedia.
In other words: Yes, I agree that most newsworthy events do not qualify for inclusion. But the thing you need to remember is that nobody's trying to put "most newsworthy events" in Wikipedia. WhatamIdoing (talk) 20:01, 2 August 2026 (UTC)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
Doing that while the event is fresh in people's minds has proven to be ineffective.
Besides, the work doesn't have to be done by one person. For example, your account is about seven months old, and you've made 89 non-deleted mainspace edits. So let's say 200 a year is possible for you. If you told me an interest area, I could probably generate a list of 100 or 200 articles about events that you could review. If you looked at just a few each week, it wouldn't take much more time than you're already doing. Just run down a basic mental checklist with each one and see what you think. For example, I'd ask this:
Subjectively speaking, is there any chance of this getting deleted at AFD? If the answer is "People will yell at me if I send this to AFD", then you're done, so move on.
Does a good WP:BEFORE check show sources not presently in the article? Be sure to check local media directly, if the event had a local or regional focus; this is especially important for events in non-English-speaking countries. If the answer is "yes", then add them.
If the available sources (not just the cited ones) seem weak, then consider whether WP:NEVENT or other guidelines might be met. If the answer is "yes", then you're done, so move on. If "maybe not", then tag with {{notability}}. If "definitely not", then send it to AFD.
Personally, I'd do some copyediting while I was there, but not everyone finds copyediting as quick and easy as I usually do, and it doesn't affect whether the subject is notable. WhatamIdoing (talk) 19:20, 2 August 2026 (UTC)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
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
Maybe that indicates that there's a range of interpretations of the GNG, with the result that stricter people perceive admins as not following the GNG, when the admins are following (a laxer interpretation of) the GNG.
Maybe that indicates that there's something wrong with the GNG. (The written rules are supposed to follow the community's practice; when practice diverges from the written rule, the written rule needs to change.)
Maybe that indicates that the GNG isn't what admins are supposed to be following. After all, we elect them at RFA on the basis of their ability to interpret consensus rather than on the basis of their views on the GNG.
In other words, there are lots of reasons why an admin might decide "X" when another editor might believe that a specific section of one guideline should result in "not-X". That doesn't mean the admins are wrong. WhatamIdoing (talk) 18:47, 2 August 2026 (UTC)reply
I think in general the preservationist attitude that we should keep an article if it might hypothetically be a better article in the future really needs to change.
We should be less shy about deletion; an article shouldn't exist if nobody's willing to make half an effort at writing a decent one. I've had multiple corporate articles that I nominated for AfD be voted as keep because there's some crumb of notability out there somewhere; even if the current article is a total mess riddled with routine coverage. At best somebody maybe pares it down to a stub, but otherwise we vote "keep" and move on and the article stays in bad condition.
Same goes for these event articles. If a year has passed and the article still looks like it was written 2 days after the event happened, get rid of it unless somebody's willing to actually commit to bring it to proper encyclopedic standard. Otherwise we end up with one big bystander effect; "we should keep this article because WP:SOMEONEELSE (not me though, of course, I'm busy editing things that actually interest me) might be able to make it into a decent article. Eventually." Athanelar (talk) 08:37, 2 August 2026 (UTC)reply
I'd like to see WP:TNT invoked more often. Notability alone does not an article make - I could find a reliable subject, add sources, and then fill the body with gibberish. We have WP:CSD for a reason, and similar logic should apply for creation and WP:XFD even when something doesn't meet those limited criteria. There needs to be a bare minimum standard for articles to have any encyclopedic value. A well formed stub is better than a bunch of WP:PROMOslop. If no one else cares to expand it correctly, is it really that notable? Along the same lines, if no one cares enough to go back and write a breaking news article after the event is over, it probably fails based on WP:RECENTISM. In most cases where it isn't immediately obvious that the subject will have persistent notability, there's no harm in a WP:DELAY to see how it plays out. I maintain that it's better to hold off than to create it based on a coin flip and rely on it getting deleted later if it flops. Lord knows we have enough cleanup to do as it is. Notability standards exist for a reason - while I don't believe in any hard limit on the scope of Wikipedia, we don't need to fill it with a bunch of low quality cruft either.
I wonder if it would be helpful to set up a project/noticeboard/something to try to establish a group of editors with a particular focus on this - not an introduction of new rules, but an attempt to apply existing standards consistently instead of relying on majority rule. Editors who are making those determinations on a regular basis on subjects they're uninvolved with can be more objective. ChompyTheGogoat (talk) 09:47, 2 August 2026 (UTC)reply
I think it'd be nice to have a kind of "article bounty" system looped into this via AfD. If you nominate an article for TNT deletion (with solid reasoning) then somebody has to claim the article and pledge to work on getting it in better condition. If nobody volunteers or if they don't improve it in a reasonable amount of time then it gets soft-deleted as if it were an uncontested deletion. Athanelar (talk) 15:34, 2 August 2026 (UTC)reply
Quoting myself above; an article shouldn't exist if nobody's willing to make half an effort at writing a decent one. If an article's in TNTable state I don't think we should keep it just because the topic is notable if there's nobody actually willing to write the article to an acceptable standard. Athanelar (talk) 16:45, 2 August 2026 (UTC)reply
83 refs – more than twenty times the median Wikipedia article (which has a total of four)
a "readable prose size" of 2,495 words – more than seven times the median Wikipedia article (which has about 350 words)
It appears that most editors consider that an article that is above the 90th percentile on both these scores to already be "acceptable". WhatamIdoing (talk) 19:01, 2 August 2026 (UTC)reply
I'm talking more about stuff like Academy 360, Sunderland which was closed as keep last year because the school apparently had significant coverage under its previous name. Did anybody go on to add any of that to the article? Of course not, so it's still a short blurb entirely sourced to the school's own website. Athanelar (talk) 19:20, 2 August 2026 (UTC)reply
Why didn't you add the sources to the article? You were given some sources in Wikipedia:Articles for deletion/Academy 360, Sunderland. Aren't you part of the "anybody" who didn't "go on to add any of that to the article"?
I wish you had found a different way to describe this problem, because my impression from this comment is that you think you're better than the rest of us. We peons might have to do boring work like putting sources in articles, but you are so important that you shouldn't have to do anything more than tap your foot impatiently while your servants scuttle around to meet your demands. I doubt that's the impression you wanted to make, but it's the one I formed. WhatamIdoing (talk) 20:21, 2 August 2026 (UTC)reply
Aren't you part of the "anybody" who didn't "go on to add any of that to the article"? Yes, I am, that's precisely the point I'm making. Nobody, myself included, wants to take the time to make an article about this random secondary school to an acceptable standard. So instead of just getting rid of it, it's going to languish in its current state for god knows how long. Nobody wants to delete it becsuse it's notable, but nobody wants to improve it either.
because my impression from this comment is that you think you're better than the rest of us. We peons might have to do boring work like putting sources in articles, but you are so important that you shouldn't have to do anything more than tap your foot... Ridiculous. My point is that, as I said explicitly, if nobody (which includes me; I am in fact 'body') wants to write the article, then maybe it's better that we have no article, and maybe we shouldn't maintain the culture of people being able to prevent deletion by gesturing toward the existence of sources without actually doing something to improve the article. If an article is in a demonstrably bad, unencyclopedic state (which that article is), then if somebody really wants to keep it they should hold the burden of doing the work to improve it, rather than stopping it from being deleted and leaving it in its poor state in perpetuity. I'm not arguing, and I never once said anything resembling, that somebody else should do this thing which I don't want to. I'm in fact arguing the opposite; people vote "keep" in these discussions in the belief that some other person at some other time will do the actual work to improve the article. Rather than hoping for that hypothetical person to come, again, to quote myself above, "an article shouldn't exist if nobody's willing to make half an effort at writing a decent one."Athanelar (talk) 20:47, 2 August 2026 (UTC)reply
You're confirming my impression: You don't want to do the work, and you're here on this page complaining that nobody else has done work that you refuse to do yourself. If neither the subject nor the article are important enough for you to do any work at all, then I suggest that it's probably also not worth you complaining about it.
Editors aren't voting "keep" at AFD "in the belief that some other person at some other time will do the actual work to improve the article". They're voting "keep" because our rules say that the decision about whether to have an article should be based on whether sources are available and not on the basis of whether anybody has put those sources into the article yet.
I don't know what kinds of articles you tend to read, but for a lot of school/organization/business articles, many of our readers are really only looking for a single basic fact. In the case of a school, I expect that there are only three questions that really need to be answered: What kind of school? (This one takes students of any age.) Where are they located? (That's going to be a long drive.) What's their official website? (Right there on the page. NB that the official link to the subject's website gets clicked on more often than any other link in any article, by a very large margin.) Most readers don't need the article that's up "to an acceptable standard", and especially not one that's up to your standards. They need an article that meets their immediate need, and this one likely does that for most readers. A red link won't meet their needs. I suspect that the only entity on Earth (present company excepted) that really wants a polished Wikipedia article is the school's marketing department. WhatamIdoing (talk) 22:27, 2 August 2026 (UTC)reply
I've previously thought that something like WP:WikiProject Current events should be repurposed/created where articles on recent events are listed as drafts for people to work on (basically an incubator), and they can be moved to mainspace when there's consensus they either meet WP:NEVENT or WP:GNG with secondary sourcing. But let's be honest, readers like the current events articles that are basically just a synthesis of primary sources, and readers first. Maybe someone could request a new project which'd be like Wikipedia but specifically for current events and breaking news, idk what we'd call it, Wikinews or something Kowal2701 (talk, contribs) 18:51, 2 August 2026 (UTC)reply
I think Wikinews failed because it tried to be an open source media outlet. Newsrooms need structure. Maybe if it had been basic news analysis, like most of our current events articles, it would've survied. voorts (talk/contributions) 18:53, 2 August 2026 (UTC)reply
I think there were a lot of reasons why Wikinews failed, including muddled purpose (supposed to be creating news articles, which means things like 'interviewing people' and 'writing things that can't be verified by reading a news article at a different website', or just rehashing other news stories?) and the wrong structure (too slow, too rigid, too little support, too little training, too failure-prone). But above all, I think what doomed them was too much competition, leading to no demand from readers.
I think that most readers and many editors (especially the kind of editor who doesn't spend all day on pages like this one) want the articles we write about current events. WhatamIdoing (talk) 19:07, 2 August 2026 (UTC)reply
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:
More than anything I just think it would help drive in new editors whose primarily (or only) way of accessing Wikipedia is via their mobile device and encourage them to create pages (or redirects). — ♠ Ixtal( T / C ) ⁂Non nobis solum ♠ 08:32, 2 August 2026 (UTC)reply
I'm not sure we really want to encourage brand new editors to dive in with entire articles. In fact, we specifically discourage it on Teahouse, although it's not a rule. More often than not they just don't know enough to make one that's passable, regardless of how well intentioned they are. A redirect wouldn't hurt in most cases, but I don't think many people are going to be inclined to start editing for the first time just for that.
I'm sure that the merits of encouraging page creation where discussed at length when that message was added to the desktop experience so I'm not really feeling it necessary to rehash that debate, my main concern is like you pointed out, ChompyTheGogoat: the experience should be consistent on mobile and desktop. — ♠ Ixtal( T / C ) ⁂Non nobis solum ♠ 00:25, 3 August 2026 (UTC)reply
CAT:EXLLM seems to be perennially backlogged because the category fails to auto-update when an nomination under {{llmprod}} expires. I'd suggest sending a bot to purge all pages with PROD tags every six hours or so, same as WP:PRODSUM. Any other ideas? –LaundryPizza03 (dc̄) 13:58, 3 August 2026 (UTC)reply
I think the problem is that the general PROD categories are dated, whereas there aren't any specific LLMPROD dated categories, and LLMPRODs expire earlier than normal PRODS. I think we do need seperate LLMPROD dated cateogries. I guess a bot is also fine since it won't even require an account, see this button that will purge all LLMPROD pages (only works if there are less than 500 such pages though): Purge LLMPROD pages (click 'Make Request' after this)Alpha Beta Delta Lambda (talk) 21:28, 4 August 2026 (UTC)reply
Let's ignore your comments about the WMF's Reserve (accounting), as it's both misleading and irrelevant. $300M as the economy teeters on the brink of a recession is how much actual experts recommend the WMF to have in their operating reserves.
Let's instead talk about getting more editors. I'm in favor of the goal. I've got some suggestions about the order in which we do things.
If we wanted to make a difference in this area, the research-backed approach might be an education campaign aimed at highly active editors. Specifically, we know that editor retention is improved when patrollers and other editors follow the rule to Wikipedia:Revert only when necessary, and whenever possible to build on an imperfect contribution (e.g., replacing their bad source with a good one, removing only part of an addition while keeping some visible fraction of it, adding a clearer explanation, etc.).
There's not much point in recruiting new editors if we're going to run them right back off again by reverting their attempts to contribute.
Therefore, I suggest that we first look at ways to improve retention of newcomers. After we think we can retain a decent fraction of the newbies, we can look into trying to get more newbies. WhatamIdoing (talk) 21:05, 3 August 2026 (UTC)reply
The active editor graph suggest that it's stable over 10 years, while the new editor graphs is going down. Of course I agree that we need to be more friendly, but I don't think most of Wikipedia are so bad that it scares newbies off. Most newbie contributions are not reverted. Anyways I might be overly thinking about a Signpost article that suggests that the number of new users is decreasing (admitedly not by a lot annually), although that might not be a huge deal. Alpha Beta Delta Lambda (talk) 21:27, 3 August 2026 (UTC)reply
This is of course a big problem, but I think we might be trying to find the perfect solution. It might not make a huge difference, but it'll still (hopefully) make a positive difference. Alpha Beta Delta Lambda (talk) 21:54, 3 August 2026 (UTC)reply
WhatamIdoing, as always graphs need context. Please also show a graph of the number of articles. Let me put it this way, if the number of doctors in a country remains stable, but the population goes up five fold, quality of care will go which way? That is the issue. Yesterday, all my dreams... (talk) 12:03, 4 August 2026 (UTC)reply
Our editors-per-article ratio has been declining at the same time that our article quality has been improving. Doctors-per-capita is at best an imperfect analogy. WhatamIdoing (talk) 20:24, 4 August 2026 (UTC)reply
This isn't a criticism of your suggestion, there's nothing wrong with it; that being said there's currently an elephant in the room that the WMF unionizing conflict is getting worse, and depending on how that goes it might affect what is done with donation banners. Gnomingstuff (talk) 06:50, 4 August 2026 (UTC)reply
(A bit off-topic, I'm sorry.) I think much more is needed than a banner. When I joined, nineteen years ago, so many editors were encouraging: "Be bold! Make an edit!" I rarely read this any more. Lova Falk (talk) 10:12, 4 August 2026 (UTC)reply
Of course, but I'm not sure we're breaking a promise. Wikipedia promises to be "the free encyclopedia that anyone can edit", and as far as I can tell we aren't lying about that. If you meant that we semi-constantly revert their edits, I'm not sure what could be done other than to remind experienced editors to revert only when necessary. Alpha Beta Delta Lambda (talk) 21:00, 4 August 2026 (UTC)reply
I've previously written about English Wikipedia's structural issues that make it unattractive to many co-operative editors. They essentially make content-dispute resolution ineffective and provide incentive for poor behaviour. Any edit one makes, no matter how small, has a sword of Damocles hanging over it: another editor can vociferoously object, and one has to decide if it's worth getting into a discussion about it or not. Either way the outcome is often poor: one can just move on, with a constant irritant that aggressive behaviour typically wins out, or one can end up spending an unbounded amount of time trying to find common ground with an editor not interested in co-operating. Even if most interactions aren't like this, just a few can suck all the joy out of editing. For better or worse, though, the portion of the community that likes to discuss these matters generally places a higher priority on the ability for everyone to weigh in, which is enabled by the current decision-making traditions. isaacl (talk) 22:29, 4 August 2026 (UTC)reply
By English Wikipedia's decision-making traditions, in the absence of clear disruption, whether or not one is being co-operative or just engaging in vigourous discussion is decided upon by a consensus-based discussion. So every disagreement requires a weighing of options: is the worth the effort to build a consensus for one's point of view? Since discussion participants are self-selected amongst those who happen upon the discussion, the outcomes are frequently uncertain. It's a constant drag on enthusiasm that can wear editors out. isaacl (talk) 16:54, 5 August 2026 (UTC)reply
There are two issues here. One is that we need more editors, and a banner may be a good way to help with that. The other is that aggressive fundraising is not universally popular with readers or editors. Those two points are almost orthogonal, the overlap being that they might compete for the same screen space. The current reaction to union developments may be relevant here. Although I don't think it's being proposed, one way to deliver a message to the WMF would be to interfere with fundraising banners, leaving a free slot which could be used to recruit editors. Certes (talk) 11:14, 4 August 2026 (UTC)reply
My unhelpful comment on the subject is that we generally need better editors, not more editors. Of course, since I don't know a way to get better editors that's hardly actionable. Except of course by getting more editors and hoping that the better ones remain. (Certainly, regular Wikipedia users are typically pretty good!) Dingolover6969 (talk) 19:57, 4 August 2026 (UTC)reply
Okay, admittedly I am not a great ideas person, nor am I the most familiar with Wikipedia as a whole or what I consider as a hardcore editor or anything, so everything here is admittedly based on vibes. Please correct me if I'm wrong on anything.
But I was curious, with the merging of WP:PAM into WP:AfD not too long ago now, that got me thinking. Has anyone ever proposed merging WP:PROPSPLIT into AfD? To me, while splitting isn't really deletion like merging is in a sense (especially with the RfC to rename AfD failing), in a sense, PROPSPLIT was essentially the inverse of PAM. From what I've seen, PROPSPLIT also seems to suffer from the same issues of inactivity and invisibility that PAM did (which was part of the motivation with merging it into AfD). In fact, I'd probably argue that PROPSPLIT probably has it worse off since AfD at least ostensibly acted as an occasional, inadvertent alternative, and it seems to me like a lot of actual split discussions aren't displayed on PROPSPLIT, leading to most of them being inactive. Splits honestly don't seem as common as merges are, so it probably won't really dominate AfD anyhow, even to the same extent as merges do. But yeah, I'm not sure if it's a good idea. I just wanted to get the ball rolling; maybe others have better ideas than I. Please, feel free to be brutally honest! OrdinaryScarlett (talk) 10:21, 6 August 2026 (UTC)reply
It's been suggested a few times. Most recently the general consensus was to wait and see how well folding mergers into AfD works in practice and I think it's still a bit early to get a feel for that tbh. Thryduulf (talk) 10:43, 6 August 2026 (UTC)reply
Abstract Wikipedia goes somewhat live and already hosts unattributed enwiki copies...
The extremely expensive, buggy and ill-thought out "Abstract Wikipedia" has gone live after many, many years, and already it hosts an "article" which not only go against the very purpose of it (putting a complete English article in html is not the way to get automated Wikidata-based translation to 300+ languages), but also creates an unattributed enwiki copy. Not that I am able to get it to load completely, it only returns a few sentences and then nothing happens (which is better than the many errors other pages generate, usually either "Reached max retries. Try again later." or "Wikifunctions returned a failed response: Error in evaluation" or simply "Page not found" when going from "history" to "read" or "page"...). Why this pre-alpha thing has been released to the world is not clear, why the WMF would think it conceptually is a good or feasible idea even less so. Fram (talk) 10:05, 25 March 2026 (UTC)reply
Also see , it looks like it’s just going to be another Anglo-project, how tf are non-English speakers supposed to develop the wiki's policies when everything is only done in English. It’s a project that’s specifically not meant to be Anglo and is irrelevant to en.wiki. It should be put on ice until people can discuss via the functions or there’s some kind of multilingual support Kowal2701 (talk, contribs) 11:12, 25 March 2026 (UTC)reply
Abstract + wikifunctions is 2 sides of the same coin. And if wikifunctions has this many issues still, then abstract shouldn't have been launched as a "beta". The most basic things don't work yet: e.g. take a random page, click on "edit source" or "view history", then click on "page" or "read"... error, every single time. This is not some obscure thing, this is basic functionality for the whole site, and it doesn't work. Type a page you know exists in the search bar (e.g. Cape Verde), the first result in the dropdown is the Abstract Wikipedia page (see the AW at the end), click it, and again you get the "page not found".
This is probably a simple switch somewhere, but the total lack of care displayed by whoever decided that this was ready to go public is staggering.
As for the multi-language aspect, the core business of Abstract... Q143, Esperanto.
"Esperanto is the languages of internationality. An Esperanto is a languages." (sic!)
In French, this gives "espéranto langue international" plus an error (the title doesn't get translated..., international(e) should be female, the verb has disappeared, ...)
In Dutch, it becomes "taal internationaal". No error, but missing most of the poor original.
Q21, "England is a country in United Kingdom." (sic). In Spanish, this gives "Unable to render this fragment due to an unknown error. ", in Swedish "The rendering service is temporarily unavailable. Please, try again later. " in Italian "Wikifunctions returned a failed response: Reached time limit in orchestrator", in Portuguese "Wikifunctions returned a failed response: Error in evaluation", and in Thai "England is a country in United Kingdom." I'm sure it will work wonders in the small languages for which it is intended though!
Most Western companies, and the WMF is no exception, would work better with half the people on twice the salary. But we would have to have a different attitude to work for that to succeed. Phil Bridger (talk) 20:07, 25 March 2026 (UTC)reply
Thanks for the link. The team bios seem somewhat telegraphic. Are any of them "hot shot" programmers? And they seem pretty happy. In the commercial world, best software is written by developers who are pushed to the limit. But not for me to dive into details of the team. Yesterday, all my dreams... (talk) 14:40, 26 March 2026 (UTC)reply
best software is written by developers who are pushed to the limit
Your word was "best", not most widespread. I heavily disagree that this is the Microsoft development process, and in any case, the market share of all Windows systems combined had been precipitously declining for years now because of how bad it is. The attempt by the WMF to do the development process you propose is Knowledge Engine (search engine) and the surrounding turnover. Aaron Liu (talk) 12:36, 30 March 2026 (UTC)reply
As a former programmer who's experienced severe, life-impeding burnout from overwork twice in her career, I can't disagree more strongly with the notion that "the best software is written by developers who are pushed to the limit". — Hex•talk11:37, 28 April 2026 (UTC)reply
best software is written by developers who are pushed to the limit. Assuming the limit here is a tight deadline, I would argue that software death marches do not result in great software. Tight deadlines result in insufficient time to write quality code. Quality is sacrificed to (try to) meet the deadline. Not to mention the impact on team morale and work-life balance caused by pressure and overtime. –Novem Linguae (talk) 22:51, 28 April 2026 (UTC)reply
I checked my browser console when viewing the OP's link and there were over 65 requests to the API! As of last week, the WMF (I'm presuming a different team which didn't talk to this one) has decided to limit unregistered users to 1000 requests per hour. Total, across all projects. That includes search suggestions, DiscussionTools previews, VisuaEditor, etc. So about 30 page views for you, and then every project breaks unless you have an account! Suffusion of Yellow (talk) 20:12, 25 March 2026 (UTC)reply
What I don't understand is how we are meant to make an "abstract Wikipedia" that is automatically translated to every language when the very design of the site is so centered around English. In abstract:Help:How to create an article I see a reference to a function called "Article-less instantiating fragment" which creates sentences like "Paris is a city". However, in some languages (e.g. Greek) such a sentence needs an article so the result will be ungrammatical unless a different function is used. Thankfully it seems like someone noticed this issue because the actual page for Paris, abstract:Q90, uses a different function called "defining role sentence" which doesn't have the same problem. But if basic stuff like this is wrong in the documentation, I don't have much faith in the project. In fact, pages like abstract:Q667 (south) still use this "article-less instantiating fragment" function. Warudo (talk) 11:36, 27 March 2026 (UTC)reply
Actually, I found abstract:Abstract Wikipedia:Useful functions for article composition which apparently says that "article-less instantiating fragment" is a good fit for sentences like "Nairobi is a city". It absolutely isn't. Again, it's article-less in English and several other languages but not all of them. While I'm not a linguist myself, it really feels like this system was designed without consulting experts. Warudo (talk) 11:40, 27 March 2026 (UTC)reply
It seems to me to be referring to the fact that it doesn't require an article in English. It may or may not require an article in any other language you care to mention, so this seems to be a very anglocentric point of view. Phil Bridger (talk) 17:32, 28 March 2026 (UTC)reply
No, that's definitely not it! Article-less and article-ful have different semantic meanings (the term article here seems to confuse a lot of people who do not understand the project, which I suppose means it needs a rename). All of these examples would use "article-less" (despite the fact that two of them have indefinite ones):
Golf is a sport
El golf es un deporte
The United States is a country
യുണൈറ്റഡ് സ്റ്റേറ്റ്സ് ഒരു രാജ്യമാണ്
And all of these examples would use "article-ful":
A bird is a dinosaur
Un ave es un dinosaurio
These are saying two fundamentally different things irrespective of language. Wikifunctions is already equiped to handle this distinction. Feeglgeef (talk) 18:28, 28 March 2026 (UTC)reply
I don't see any great difference between "Golf is a sport" and "A bird is a dinosaur" apart from the presence/absence of an article in English. Please explain. Phil Bridger (talk) 19:18, 28 March 2026 (UTC)reply
Then the name of the function should refer to proper and non-proper nouns, rather than articles. The point was that the name of the function is based on English language thinking. TietoTeekkari (talk) 07:58, 4 June 2026 (UTC)reply
"Article-less and article-ful have different semantic meanings". But then why are these semantic meanings not mentioned in the documentation of f:Z26039? Instead the function's documentation says Makes a sentence of the form "X is a Y" e.g "Nairobi is a city.", i.e. it takes an entity (X) and its class (Y) and states that it is an entity of that class. What are the semantic differences with f:Z26095? In case you think this is a small problem, it really isn't. Look at the Japanese translation of this documentation (a language that does not use articles). The translator had to use an English example to explain what the function does because in their language the concept does not really exist. Indeed, as far as the users are concerned, these functions are in fact defined in terms of whether the sentences they generate require an article in English. The semantic difference behind that is hidden to them. Warudo (talk) 22:33, 28 March 2026 (UTC)reply
Also, by the way Abstract:Q30 currently says "United States is a country. United States is a republic. Washington, D.C. is the capital of United States." So, I guess the article-less function was not the correct one to use in this case. Warudo (talk) 23:36, 28 March 2026 (UTC)reply
I've already said this above, but the "article" being referred to here is a indefinite one (a/an) at the front. definite articles (the) have no semantic meaning and therefore are to be added on a language-by-language basis. Feeglgeef (talk) 00:40, 29 March 2026 (UTC)reply
Definite article = "the", Indefinite article = "a/an". Also that's not true. The definite article has semantic meaning. It means that we are referring to a specific member of a group and not to the concept in general. In this case, "United States" means any states that are united, which would also include e.g. the Mexican United States. The United States on the other hand are a specific set of states that are united, in this case, the United States of America. Warudo (talk) 00:49, 29 March 2026 (UTC)reply
We already have the distinction between the concept of a federation and the example in North America seperated by Wikidata. Some languages (like Malayalam, as in the example) do not use an article in front of the United States. Eventually, the function will be able to handle automatically adding a definite article. Feeglgeef (talk) 14:09, 29 March 2026 (UTC)reply
Ok, to be fair, you're right. The generated sentence is wrong but that can be attributed to an incomplete implementation of f:Z26039 rather than a logic error in abstract:Q30 itself.
Still, there are several questions that remain. First, why are the semantics of the two functions defined in terms of English grammar? You said, Article-less is about one thing, article-ful is about a collection. but as I've said above, that's not how it's described in the documentation. But more importantly, if that's the difference between them then why are two different functions for "article-less" and "article-ful instantiating fragment" given to the user in the first place? Why don't you expose a single "instantiating fragment" function that checks if its input has a subclass of (P279) statement in Wikidata? If yes, use an indefinite article, if not, don't use one.
Just FYI, editing your own comments after someone has already answered without indicating the changes is considered bad practice in the English Wikipedia. Not a big deal in this case as you were just fixing a mistake but keep it in mind in the future. Warudo (talk) 14:47, 29 March 2026 (UTC)reply
@Feeglgeef no, your statement is plain wrong. This is how 6 sentences above will be translated to Russian (browser machine translation, but it's a correct translation): As you can see, all 6 cases uses exactly the same grammar construction, because Slavic languages has no articles and they don't provide meanings, that is provided by articles in Germanic languages. We, native Russians, believe that this semantic meaning simply does not need to be conveyed. MBH (talk) 18:24, 21 May 2026 (UTC)reply
You have to accommodate the languages that don't, though. The names of the function have been thankfully changed now to "subject is instance of" vs "class is subclass of". These are different things, even if they look the same in Russian. Feeglgeef (talk) 18:30, 21 May 2026 (UTC)reply
All of other points other people mentioned aside, many languages have exceptions for articles. For example, in German proper nouns don't get articles (noone says "Der Deutschland") but Turkey for example is "die Türkei" (a similar example "The Netherlands" which also takes article in English too). I tried it and abstract:Q3640 produces "Ankara ist die Hauptstadt von Türkei." while the article in German Wikipedia (de:Ankara says "...die Hauptstadt der Türkei.". Ignoring the wrong "von" in the produced text, it is missing the article for Turkey as well (I copied the functions for Q3640 from abstract:Q61, so my apologies if I copied the wrong functions). I don't know how AW works in depth so my apologies if I'm misunderstanding anything. Ladsgroupoverleg16:44, 16 July 2026 (UTC)reply
The copy of enwiki is attributed now, and the project is not doomed because one user fails to abide by copyright law or to make a quality article.
As for the beta release, it's impossible to debug or improve without community content, so I'm not sure what you'd have the WMF do. Feeglgeef (talk) 17:03, 28 March 2026 (UTC)reply
"one user fails to abide by copyright law or to make a quality article." Not a single user has made a "quality article", which is hardly possible with the current setup. And the actual intention of the project, automatic translation to small languages, is just not happening.
Random "article" translation to French: "Wikifunctions returned a failed response: No matching lexeme for item in language"
Random "article", translation to Italian: "Wikifunctions returned a failed response: Number of arguments mismatch"
Random "article" translation to Spanish: "(en) Bahrain is a country in Middle East." Hey, I can understand Spanish!
Random "article" translation to Dutch: "Brussel is the hoofdstad of België." THE hoofdstad? Yep, clearly not a problem with the use of articles...
Random "article" translation to French: "Paris est une ville. Wikifunctions returned a failed response: Error in evaluation" Translating two sentences was a challenge of course.
Random "article", no translation: "Wikifunctions returned a failed response: Could not acquire WASI runner within time limit" and "Wikifunctions returned a failed response: No matching lexeme for item in language" and "Unable to render this fragment due to an unknown error."
You state "As for the beta release, it's impossible to debug or improve without community content, so I'm not sure what you'd have the WMF do." which is absolute nonsense. You don't do a public release of such extreleky buggy software, and you don't call it a beta either. The errors found so far are not edge cases where mass testing is necessary, but things a developers + QA team should easily have found. WMF should, for a $6 million + project, have some people on board who understand what this project is intended for and can test it before it is released as a beta. The release of a severely immature project where even the most basic fundamentals are being questioned is irresponsible. Then again, the decade-long development seems to have been irresponsible as well. Fram (talk) 10:19, 29 March 2026 (UTC)reply
Fram, you have more than enough examples now. Item 17 is disastrous and tells me that the entire system needs a rewrite following a redesign of the architecture. But that would be throwing good money after bad. I predict that there will be no remedy for this project anytime soon. Once the underlying software architecture has problems 1 million bandaids placed on it will be no cure. Yesterday, all my dreams... (talk) 12:32, 29 March 2026 (UTC)reply
None of these problems are architectural. All of these are the result of the work of a few (like less people than that participated in this topic) community contributors. Feeglgeef (talk) 14:17, 29 March 2026 (UTC)reply
So there is no Wikidata item for "is a" in French, but this thing will be able to handle translations to languages with very few editors somehow? And "it knows how to say the words in Dutch", er, no: "the" (or "is the") is English, not Dutch. Again, it can't even translate that most basic building block to a language with a large editing base. As for 19, I have no idea how "unknown error" and a failed time limit are the responsibility of Wikidata contributors, nor how a translation tool was ever tested by the developers if the most basic aspects are missing in French, Spanish, Dutch, ...
Someone at the WMF was aware that translation (and specifically translation to languages with very small user bases) was the intention of this tool, right? Because it sure doesn't look that way. I don't see how they can have tested this at an alpha-level to give it the green light to go to beta, if if can't even handle these basic things. Blaming it on Wikidata contributors is rather rude, the developers/testers should have added things like "is a" or "the" or ... in major languages (both the ones I just tested, but also completely different ones with other scripts and grammar) to Wikidata. I assume these people have some fluency in Wikifunctions and Wikidata editing, and in languages and translation? Seems a prerequisite for such a project... Fram (talk) 15:30, 29 March 2026 (UTC)reply
Question: How many people who work on Google Translate are linguists? Please answer to yourself before you read further. Answer: zero. We have all learned long ago that fiddling with linguistic constructs will end in one place: the shelf that holds the Aspirin bottle. So please do not assume that as a requirement. Their problems are much deeper and architectural in nature. They should have never used Wikifunctions, given that they are crowd sourced. Alas the key issue is that we can all huff and puff for ever but we have no control on what WMF does. So maybe we should all take an Aspirin and move on. Yesterday, all my dreams... (talk) 16:22, 29 March 2026 (UTC)reply
Google Translate is not entirely human-made though, but is based on computer-learning (statistics, deep learning and brute force basically). Abstract is based on "humans will build it all", which, while admirable, then requires humans with very specific skills. And "we can all huff and puff for ever but we have no control on what WMF does" is false, we have forced them to shelve things like Flow and Gather. Fram (talk) 16:49, 29 March 2026 (UTC)reply
I know exactly how G-translate works. Thanks. My point was/is that the crowd sourced paradigm works for text input but not for software. The world is moving towards automatic software generation now, so crowd sourcing will be inherently inefficient and error prone. But I think I have said enough now. No more comments from me here. You are right in objecting to the project but time will tell how much power you have over WFM. Cheers Yesterday, all my dreams... (talk) 22:57, 29 March 2026 (UTC)reply
How many people who work on Google Translate are linguists? Why are you using Google Translate as an example? Do you know how many mistakes Google translate makes when translating to and from languages other than English? For some reason English homographs throw it off completely. I've seen it do stuff like this where I asked it to translate a verb that means "to bear" and it came up with a word for the mammal. Even ignoring the fact that English is clearly used as an intermediate language here even though it isn't suited for this purpose (probably not by design but because of the way Google translate was trained), why on Earth is Google translate translating a verb as a noun in the first place? I think stuff like this shows how Frederick Jelinek's quote is outdated and is leading us astray at this point. Warudo (talk) 16:53, 29 March 2026 (UTC)reply
There is no implementation of the function in Dutch. The Abstract Wikipedia team has not added an implementation in Dutch because the community is responsible for creating the function in Dutch, and nobody has created the function in Dutch.
Essentially, how the current English implementation is to string together the first concept with "is the" with the second concept with "of" with the third concept. The function can get the Dutch terms for the concept, but it does not know how to string the words together because nobody who speaks Dutch has told it how. This is not something that the WMF can magically fix. Eventually, when the project is older than a week, somebody will implement it in that language, and in Malayalam, and Dagbani, and Massa, and Southern Altai, and Dusun. Feeglgeef (talk) 21:49, 29 March 2026 (UTC)reply
Please see my last response to Fram. Anyway, time to cool off and move on before someone busts an artery here. You will be glad to know that I shall make no further comments here. Now, in what language shall I say goodbye? Yesterday, all my dreams... (talk) 23:02, 29 March 2026 (UTC)reply
"when the project is older than a week"? It's a decade old or thereabouts, Wikifunctions specifically was created in 2020 and launched in 2023. But sure, some Southern Altai Wikipedian will go to Wikidata to translate everything that is needed, then go to Wikifunctions to translate all necessary functions into the grammatically correct version of their language (assuming naively that the used function can be one-on-one transformed to one in their language for every use of it), just so they can then autocreate stilted article stubs instead of either writing them directly, which would require a lot less effort and give a lot more satisfaction, or using an online translation tool to translate an existing Wikipedia article to give them much easier results. Totally realistic. Fram (talk) 07:32, 30 March 2026 (UTC)reply
When I go to this totally not-alpha project, to the page we are discussing, and click on "defining role sentence in English as string" (which should apparently go to abstract.wikipedia.org/view/en/Z28109), I am taken to the Abstract Wikipedia Main page. Please explain to me again how this has been sufficiently tested and was ready to be opened to the wider public? Fram (talk) 08:39, 30 March 2026 (UTC)reply
"by putting several sentences into a single paragraph, the paragraph as a whole is being run, may cause time-outs, and will be cached. Instead, if, for now, you put one sentence into each fragment, caching and evaluation can be more spread out and should allow for more content. Eventually we want to fix that" Gee, why would you fix the bug where putting more than one sentence into a paragraph makes it even more likely you will get a timeout error? Fram (talk) 15:55, 30 March 2026 (UTC)reply
Probably a few years of pointing out both the immediate and the fundamental issues. The work of developers, testers and product managers. Once the grant and endowment money stops flowing, and some quarterly or yearly goals can be checked on some paperwork, the drive to continue this will stop. At best/worst to keep whatever exists at the time running and let some volunteers play with it for a few more years before completely stopping it (see the soon to be closed down Wikinews). At least with Gather, Flow, ... we could point out that it was actively, directly negatively impacting enwiki (and other wikis): here it is only money and developer time disappearing down the drain. Fram (talk) 14:16, 31 March 2026 (UTC)reply
For what it's worth I would like to see them continue as the issues pointed out do not seem to be systematic (with the platform design) but an incredibly horrible implementation of it. I do agree that the state of the project seems at best alpha. Aaron Liu (talk) 14:37, 31 March 2026 (UTC)reply
The systemic issue is the belief that English grammar rules can be copied one-on-one to all other languages. We have e.g. functions for "use this the" and " use with a/an" and "use without either", which even within English is problematic (e.g. sometimes you need X is the capital of Y, and sometimes X is the capital of the Y, like with United Kingdom): but in other languages half the cases of a certain English function may use one construction, and the other half uses another construction, and this needs somehow to be built into the simply English function. I'm simplifying things here, but I hope yo get my drift.
Purely on a word level this whole construction works somewhat theoretically, but requires a massive amount of work which is exactly the problem for the small languages where this is supposedly built for. On a sentence/paragraph level though, I don't believe this will ever work (for simple cases for related languages, yes, but not in general). If this is pushed through regardless, we will probably end with new Scots and Greenlandic version catastrophes, but then on a larger scale. The setup and performace issues are just the icing on the cake. Fram (talk) 15:05, 31 March 2026 (UTC)reply
The ideal would be to store everything in context-free language, and then generate sentences in the target language by applying a set of rules. When I was a grad student in Linguistics lo these many years ago I wrote my dissertation on one aspect of Deep structure and surface structure. From my experience trying to figure out what some of the rules are in (my idiolect of) English for a limited subset of syntactical structure, it will take a very large and hard to maintain set of rules with extensive exceptions just for English. My mind boggles at the concept of doing that for all the currently spoken languages of the world. Donald Albury16:35, 31 March 2026 (UTC)reply
Indeed. At the moment, they produce the article "New Jersey is an U.S. state." I presume the "an" comes from an "an before a-e-i-o-u" rule, which doesn't deal with the many exceptions to that rule. And this is a very simple example, in the main development language. Fram (talk) 16:45, 31 March 2026 (UTC)reply
The systemic issue is the belief that English grammar rules can be copied one-on-one to all other languages. You'd think that people would have learned from the failure of this approach when it was applied to Wikidata. Some editors wanted a property to express the relation "X is the mayor of Y". So they just made a property called "of". They then found out that the property was not only difficult to translate to certain languages but it also evolved into a monster that modeled many different, sometimes contradictory relations (which is kind of bad when the whole point of a database is to be machine readable) and it ultimately required a huge effort from the community to get rid of it.
Yet now, the abstract Wikipedia editors are doing the same things, defining their functions in terms of English grammar constructs and not the underlying logical relations those constructs represent. Warudo (talk) 17:21, 31 March 2026 (UTC)reply
All of these rules assume that an English grammar rule is also 1 rule in another language. "Article-less instantiating fragment" will sometimes need to be translated with, and sometimes without an article (even if the remainder of the grammar is the same). If this can be done with one function, then there was hardly any need to have different functions with or without article in English surely? And this is a very simple and basic example. So how is this solved? Fram (talk) 20:28, 1 April 2026 (UTC)reply
Article-less does not mean what you think it means here. The name is confusing and should probably be changed, but, for example "Golf is a sport" and "El golfo es un deporte" (both use article-less, despite the fact that the latter has an article) have the same meaning, but "A bird is a dinosaur" and "(The) bird is a dinosaur" have two very different meanings, even if, say, Bulgarian does not make the distinction. The distinction between article-less and article-ful is not actually articles. Feeglgeef (talk) 20:37, 1 April 2026 (UTC)reply
So if you start from an article which doesn't make a distinction, and go to a language that does make a distinction, you're screwed? If in your example the base language would have been Bulgarian, and you went to English, sometimes the Bulgarian function should give "the" in English, and sometimes "a", which depends on context. And all of this is still between very comparable languages basically. If the base article is for some sentence / meaning "article-less" and the target language "article-full" (or vice versa), you have a problem, no matter how you call these functions. Fram (talk) 20:48, 1 April 2026 (UTC)reply
I get the feeling that Feeglgeef is a little out of their depth here, but there's nobody with any decision-making authority at the WMF willing to rescue them. Phil Bridger (talk) 21:52, 1 April 2026 (UTC)reply
Based on your replies in this thread, it seems you are unwilling to assume good faith of either your conversational partners or the functionaries (pun intended) of the wiki in question. Why not just ignore it, if you feel it is consigned to failure? Arlo James Barnes19:09, 11 April 2026 (UTC)reply
You actually don't "start from an article which doesn't make a distinction", because all Abstract Wikipedia articles are supposed to be abstract. All articles are required to make the same distinction and all distinctions necessary for every single language (even if some languages ignore them) because they are all written in abstract language. There is no English or Bulgarian base, nor translating here. Feeglgeef (talk) 22:07, 1 April 2026 (UTC)reply
That, again, makes no sense. Because in English, "a bird" and "the bird" have two different meanings (but refer to the same Wikidata item), you need a different function than for "golf" (the sport), which has in English one meaning for that Wikidata item. But still you claim that the functions, the whole approach, are language-independent, as if these issues in English are the same across all languages for the same words. If Abstract Wikipeda were truly language-independent, you wouldn't need the article-less and article-full functions. And that's still only at the word level, and doesn't go into sentence- and paragraph structures and countless other quirks, irregularities, ... Anyway, it looks so dumb that after all this time, apparently there isn't a function yet to start sentences/articles with an article; we get things like "Bible is a religious text." for an article specifically about the Judeo-Christian Bible (not about the general word). And finding out how things actually work for Abstract articles is very opaque as well, I have no idea where the "suns" instead of "stars" comes from in "Stars are sources of light. Stars contain metals. Suns shine."
Oh well, the WMF team doesn't respond here, but they seem to read it, as some of the most stupid errors get fixed after they are reported here at least. Fram (talk) 07:44, 2 April 2026 (UTC)reply
Wikipedia has articles about more than 20 million topics in more than 300 languages. But none of these languages alone allow access to the knowledge about these 20 million topics (...) Abstract Wikipedia does that without relying on AI. Each step of the way remains under human control, and is accessible and editable by the volunteers. I doubt volunteers will create articles about 20 million topics in "this thing" (and with 108 active editors, as there are now, it seems completely impossible to arrive at any place).
Looking at this article, it seems that a software-generated summary (yes, there is software other than AI) automatically combining some data from all language editions of Wikipedia, plus Wikidata and Commons, and using machine translation when needed (for machine translation, AI usage is usually not bad, and free and open source AI software also exists), would do a far better job.
In addition, if the point is to avoid AI, I don't understand why it says "Generated text" (who generated it?). Sorry if I am too critical (of course, I appretiate the efforts of the people who are working on the project), but I don't believe this adds anything new to the Wikimedia ecosystem: it looks as made for consumption by a machine, not by humans, so maybe it would be better if it was also mostly machine-generated.
The idea of joining the knowledge from all Wikipedia language editions (plus Wikidata and Commons, and, for some articles, also Wikisource, Wikivoyage, etc) is a very good one (and one I had thought about many times), but I think that a "global search" feature with integrated machine translation, and some way to access the combined data from multiple sources, would be the only way to achieve that. MGeog2022 (talk) 19:46, 8 June 2026 (UTC)reply
I doubt volunteers will create articles about 20 million topics. Yes, exactly. There's no chance we ever surpass enwiki or other major language Wikipedias, as abstract articles take much more time to write than normal articles, and there's much less chance for onboarding new contributors.
In addition, if the point is to avoid AI, I don't understand why it says "Generated text" (who generated it?). Sorry if I am too critical (of course, I appretiate the efforts of the people who are working on the project), but I don't believe this adds anything new to the Wikimedia ecosystem: it looks as made for consumption by a machine, not by humans, so maybe it would be better if it was also mostly machine-generated. It was made for the consumption of humans who speak only small-to-mid sized languages.
Machine translation might be worth consideration for a future project, it's been used, for example, on Caesar DePaço to circumvent a court order, but writing content in an abstract (instead of concrete) language means we don't have to deal with information loss (see the whole "Google translate 100 times" thing).
If you click through the endless errors and finally try to see a translated article, you get monstrosities like "Ein Äpfel ist eine Frucht." or even worse " Bisexuelles lieben Fraus. Bisexuelles lieben Manns."
People from the WMF, could you please clarify: before releasing this as a supposedly beta product, which tests did you run? Which articles have you created, with which functions, and tested for which languages? Fram (talk) 13:16, 8 April 2026 (UTC)reply
@Sannita (WMF): as someone who seems to be closely involved, but of course feel free to put this through to whoever is better placed to answer this. I also notice that most activity on Abstract seems to come from an editor who was indef blocked on enwiki for CIR / timewasting, and is now running some AI-generated tool to create non-working pages (like this 193K monstrosity-) and to change working pages (no matter how bad they were) into non-working ones (e.g changing this into this ("Wikifunctions returned a failed response: Error in evaluation"), across a lot of pages. While I think the project should be abandoned as a waste of time and money, it shouldn't be done by mass-vandalizing the work of the editors there. Fram (talk) 16:30, 10 April 2026 (UTC)reply
@Fram We did some limited tests in a controlled environment, but doing so can only help you so much in identifying potential problems. We are learning a lot by releasing the beta project (because this is still a beta), and we'll improve from there. Sannita (WMF) (talk) 10:28, 11 April 2026 (UTC)reply
Thanks, but no, this is not a beta, this is barely an alpha, the thing is unworkable for all but the simplest sentences, terribly slow, had the most basic errors when released. Using volunteers as cheap/sheep testers on a $6 million+ project which hasn't been thought through, hasn't been tested, and has in its utopic, unrealistic ideals been overtaken by reality anyway, is old school WMF which I hoped had been left behind after previous such failures.
After the omnipresent "Reached max retries. Try again later.", you get a plethora of errors. A 2-sentence "article" gives "Wikifunctions returned a failed response: Reached time limit in orchestrator", basic English words give "Wikifunctions returned a failed response: No matching lexeme for item in language" (but this will work for languages with barely any editors somehow), other articles give "Wikifunctions returned a failed response: Error in evaluation", "Wikifunctions returned a failed response: Could not acquire WASI runner within time limit", "Wikifunctions returned a failed response: Reached rate limit in orchestrator"
And the things that do "work" give results like "Australian continent is a continent in the Earth. Australian continent contains Australia." (German translation of that last line: "Australien contains Australien.") Or the extremely basic issue that when you translate an article, you would expect the title of the article to be the first thing that gets translated, even in alpha-stage. No such luck. This thing is supposed to be used to create articles and translate them into manu languages, but not a single decent example has been produced so far. A "beta" product which simply can not produce an acceptable end product just isn't tested to even the most basic standards and should never have been released. And a project where the actual requirements don't seem to have been thought through, and where the results (if the wanted end result was ever reached) would probably make the Greenlandic and Scots disasters look like minor blips, should have been stopped much, much earlier, before so much money and time was wasted. Fram (talk) 17:44, 11 April 2026 (UTC)reply
"両性愛者s 愛し 女性s.両性愛者s 愛し 男性s." If this is what it's producing for a language with over 100 million speakers, what's it doing for small languages? Sesquilinear (talk) 23:26, 9 July 2026 (UTC)reply
That is hardly surprising. The function used here is English simple present collective sentence. Of course it does that. This, again shows how over their head some editors over on the Abstract Wikipedia are. When the whole point is to make a cross-language encyclopedia, you cannot directly call functions that only work for one language. Those should only be called internally. What makes this worse is that the language neutral function simple present collective sentence (creation date: 24 March) already existed when the bisexuality article (creation date: 4 April) was created. This means that the editor who made that article had a choice between "simple present collective sentence" and "English simple present collective sentence" and chose to use the latter in a multilingual project! For what it's worth, I fixed it. It now says "両性愛者は女性を愛する。両性愛者は男性を愛する。" which is at least grammatical. It took about 2 minutes. It would have taken 30 seconds if the abstract Wikipedia editor didn't overwrite the arguments of a function call when you change the function. Warudo (talk) 23:55, 9 July 2026 (UTC) (edited at 00:15, 10 July 2026 (UTC))reply
If someone had to come up with a clever way to disrupt Wikipedia by wasting editors' time, I cannot think of a better way than creating Abstract Wikipedia. It feels like a clever sabotage operation Ita140188 (talk) 12:27, 10 July 2026 (UTC)reply
According to f:Z32530, no, there isn't one. That is a separate problem to the one I'm trying to solve at the moment. When I tested on Wikifunctions I got this:
I can't really fix that because I don't speak German and can't write the gloss for the Sense entity. While I have come across Senses that don't have a gloss in the Lexeme's language like d:L:L1082283#S2, I don't think it's a good idea to make those, so I'll leave this one as is. Warudo (talk) 16:29, 10 July 2026 (UTC)reply
The wrong way
I just don't get how they are going along and spending money on something so ill-thought out and poorly executed. Let's ignore for now the basic questions of "is this feasible, which competencies or expertises do we need to think this through, what is the best approach", the slight issue that reality (LLMs) has somewhat changed the whole environment this needs to be thought about, and the basic recurring problem that a completely untested, very buggy environment has been released as a beta for everyone to play with without any guidance. But why are they (WMF and editors) now going further with this in the most inefficient way possible? Everyone creates whatever they like, 99% of what is being made is absolute rubbish that serves no purpose at all. People are creating one- or two-sentence stubs for all countries which all have the same issues.
A logical, productive way of dealing with this project (apart from the most logical one of pulling the plug) would be to start with one article, take e.g. the lead from enwiki (or dewiki or whatever), and build the necessary structure (Abstract + Functions + Wikidata) to create this and translate this in 5 wildly different languages. Step by step, sentence by sentence, until you have a basic set of functions for this kind of article, and have an idea if it will work.
Second steps might then be either testing the same for a related article (say, test 1 was a country, take another country and see if the functions are all transferable or if there are things you missed), or doing the same "build from scratch" for a different topic (say, a biography).
That way, you build a structure, a set of reusable and needed blocks you can refine later on, and at the same time learn a lot of "don't do this" pitfalls and issues. And after you have done this for the 5 or 10 most common types of articles, you actually have a tested, usable, beta environment (or you have realised it won't work at all, or it will work in theory but the work to get things right for a more obscure language isn't worth the hassle).
Instead, we get articles directly using the function "English plural", really useful for an abstract, language-independent project. Or more commonly "articles" consisting of random repetitive sentences like "Reproduction is a biological process. Reproduction is a type of process. A reproduction is a biological process. A reproduction is a creation. Animal reproduction is the part of of reproduction. Plant reproduction is the part of of reproduction. Human reproduction is the part of of reproduction."
Oh well, at least I learned that "An information is a knowledge." or "biseksualiteit ∈ {seksuele oriëntatie}" in Dutch or still "Bisexuelles lieben Fraus. Bisexuelles lieben Manns." in German . Note how here and on all other pages, the actual title doesn't get translated? This is not something the article creators can help, this is something which should have been included by the WMF as a basic element (assuming they realised what Abstract Wikipedia was intended for) but is missing.
Anyone minimally familiar with the history of Linguistics or Computer Science as disciplines should be aware that the core premise of the project was investigated and discarded decades ago (and anyone who has studied at least one language that isn't super closely related to their native language should be able to quickly come to similar conclusions). There is no universal deep structure across languages. Why was this ever greenlit? This is about as useful as funding new studies in Lysenkoismsigned, Rosguilltalk05:51, 3 June 2026 (UTC)reply
When I first looked at the project, I just thought...oh, here's another attempt to make an interlingua. They've all failed before because it fundamentally misunderstands how meaning works, but ok, sure, do whatever you want, maybe you'll succeed this time... Erynamrod (talk) 12:42, 9 July 2026 (UTC)reply
New dashboard
The WMF has launched a dashboard to follow the progress of Abstract Wikipedia . It has e.g. a list of articles which work in any language! Well, most of them have no actual text translated through functions, just Wikidata items without any sentence-building, so yes, these work, they just aren't articles... The ones that do try to have actual sentences and supposedly work are e.g. Brussels, full text "Brussels is the capital of Belgium." This gets translated as "Brussel is the hoofdstad of België." in Dutch, which isn't correct Dutch. "Bruxelles is the capitale of Belgique." in French is equally wrong, as is the German "Brüssel is the Hauptstadt of Belgien." It doesn't work at all in e.g. Romanian, Moldavian. Anyway, I guess the function "defining role sentence in English as string" should perhaps not be used in Abstract Wikipedia, and items which use it should not be said to be working in any language, as the naturally don't. Something like "list of cities in Belgium" gives a result in English, and keeps running endlessly when I try it in Dutch or French. So not really "working". It looks as if not a single actual article can be said to be working in all or even most languages, making the dashboard rather meaningless. Fram (talk) 11:49, 8 May 2026 (UTC)reply
From reading the Abstract Wiki, it also seems like there is no way to utilize the past tense, which um… seems a bit critical in an encyclopedia. ExtantRotations (talk) 18:34, 8 May 2026 (UTC)reply
On the plus side, they have introduced endless repetition, which makes for much better reading. At the moment, the article for New Year's Day reads in full: "New Year's Day is a public holiday. New Year's Day is part of the public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, and public holidays in Australia." Fram (talk) 12:10, 22 May 2026 (UTC)reply
Somehow, they have made this dashboard worse. It now has a section for "Articles ready to publish in English". What this means is "Wikidata Qnumbers we have created in Abstract but don't exist in enwiki", not that these pages are in any way either wanted in enwiki, nor that they are actually "articles" which are "ready". This includes things like "Evaluating the biological validity of European river typology systems with least disturbed benthic macroinvertebrate communities", ne of the thousands (millions) of scholarly articles with a Wikidata entry, but also Blake Lemoine, apparently a software engineer, where the complete "article" exists of three identical links to research.google, but the link gives a "page not found". Ih yes, this is so ready to be published to enwiki. Other "articles" we are apparently missing is "interaction", full text "An interaction is an effect.An interaction is an effect.An interaction is an effect." Oh look, a Picasso painting we are missing. Actually, no, we have it at Three Musicians (Picasso)
I don't even want to try to guess what the next section on the dashboard, "Quick wins in English", is supposed to be about. "Add a label to California"? "Pending fixes in English", explanation "All items where English is the blocker", e.g. "photon" needs a label.
Mind you, that's not even the most bizarre or optimistic thing on that dashboard. At the very bottom, there is a section for "Almost there — English is the only thing missing
Already usable in the most other languages. One English edit gives each near-universal coverage." Well, perhaps not. Giza is not one English edit away from anything, Giza (or any Abstract "article") shouldn't use the function "defining role sentence in English as string" because "in English" is not really what Abstract is about.
While for English these things won't be published here and we see the problems from miles away, for small languages (the intended target) this is another dramatic Scots Wikipedia scenario waiting to happen, but this time pushed directly by the WMF.
According to the latest newsletter about Abstract, all that is left is improving Abstract and integrating it into language Wikipedias (the horror), but as of now, "Abstract Wikipedia can compose articles from functions on Wikifunctions". Bizarrely, despite this claim, not one actual article has been composed, only a few collections of loose, short, often ungrammatical sentences, which in a few cases can even be translated in even worse sentences in very few languages. But oh well, what can one expect from a newsletter which claims "Abstract article pages now show the label of the Wikidata item alongside the QID in the page title. " when in reality, for a week or so now, what is actually shown next to the Wikidata label is the letters "ltr" in grey. When you click on them, you get the text "copied!", and you have literally copied the text "ltr". Brilliant! Even things that barely worked before have since become worse, the page "Paul Cézanne" now shows "<a href='https://abstract.wikipedia.org/wiki/Q17277950'>The Card Players</a>" instead of the links to Wikidata it had. Also errors like "Reached max retries. Try again later. Retry" have reappeared.
Let's be clear: "Franz Schubert is a composer in Austria. Franz Schubert is a pianist. Franz Schubert is a teacher." is not an article. "Wikifunctions returned a failed response: Invalid key" is not an article. "Organism is a part of of population. Organism is a part of of group of living things." is not an article. "Roman Empire is an empire." is not an article. "2 is a small number." is not an article. "List of French artists is a Wikimedia list article." is not an article (why would anyone think that this is the kind of text wanted in any language wikipedia?) "August is a calendar month. August is part of the Swedish calendar, Swedish calendar, and Swedish calendar." is more than an article, it's a mantra. "A Citrus × limon is a useful plant." is the full article about the Lemon.
And the translations... "Organisme is an onderdeel van of populatie." is not a Dutch sentence. "2 is een ." is not a Dutch sentence. "Franz Schubert est un enseignant ou enseignante." is what you get when you start from English as the norm for all languages. "August is a calendar month. August is part of the schwedischer Kalender, schwedischer Kalender, and schwedischer Kalender." is supposedly a German article. "{citroen} ⊆ {nuttige plant}" is supposedly a Dutch article.
I clicked on random article, the first one I saw was Homer:
Homer is a poet. Homer is an author. Homer is a writer. Homer is a human whose existence is disputed. Homer is a conceptual character. Homer is the part of of Greek mythology.
What I don't get is, they don't have support for past tense yet. Whatever, they'll add it eventually, I hope. So, why are they making abstract articles that need it? Warudo (talk) 20:35, 1 June 2026 (UTC)reply
Partially reminds me of caveman speak: If horse go walk, cart also go walk. You see, force from horse leg on ground push on rock, then normal force push horse leg in opposite direction, cause horse to move small amount, for each time horse leg push on rock. Rope tied to horse neck move with horse, and is connected to cart with wheels. Cart wheel spins if moved in same direction as wheel is facing, which glide across rock, but still exert normal force due to gravity. Therefore, if horse go walk, cart also go walk.
For what it's worth, the Homer abstract article was created by the editor who did this. As harsh as it may be to say, this is the level of quality we are used to seeing from this editor, both here and in the abstract Wikipedia. Warudo (talk) 19:04, 2 June 2026 (UTC)reply
They were blocked for CIR/wasting community time and (how do I put this politely) I couldn't agree more with that description. Anyhow, most of the slop problems Fram is pointing to were caused by them, so I don't see how that justifies shutting down the whole project. Feeglgeef (talk) 03:51, 3 June 2026 (UTC)reply
Not true though. Going over the issues in my above posts, the "ltr" instead of the Qnumber is obviously a WMF technical mistake (and a failure of whoever wrote the newsletter). The "articles" I randomly picked: Paul Cézanne "2", August, the Picasso painting, New Year's Day, Giza, ... all not edited by that blocked editor. And there are plenty of articles I could have picked, I don't think "Australian continent is a continent in the Earth.Australian continent is a component of Earth's surface.Australian continent contains Australia." or its Spanish translation "(en) Australian continent is a continent in the Earth.Australia is a componente of superficie terrestre." (note that the middle sentence simply disappeared, perhaps a blessing) is an indication that the issues are due to one bad editor and not to a terrible project. Bisexuality, in German, is first an error and then "Bisexuelles lieben Fraus. Bisexuelles lieben Manns." Not touched by the blocked editor. this is not created by the blocked editor. The "Italian" article "Holy Week is a liturgical season. Settimana Santa is part of the anno liturgico." is not edited by them. Obviously it would be best if you mass deleted the embarrassing creations by that editor (full article: "A current is a current.A current is an electricity."), but it wouldn't solve any of the fundamental issues. Fram (talk) 07:37, 3 June 2026 (UTC)reply
And it's not like this is the only editor who writes articles about dead people. "William Shakespeare is a playwright from Kingdom of England." Has not been touched by that this editor either. Warudo (talk) 11:22, 3 June 2026 (UTC)reply
@Fram Thank you for the continued updates, which are rather amusing, if in a morbid way... Would you be interested in starting an RfC on Meta on putting an end to this madness? If anyone has any better ideas, I'd be happy to hear them. Toadspike[Talk]11:49, 2 June 2026 (UTC)reply
I normally don't edit Meta, and I fear that many people who hang out around there are more inclined to let such projects continue no matter what. Fram (talk) 12:17, 2 June 2026 (UTC)reply
For what it's worth I agree with Toadspike and would like to see an RfC on meta. It might be true that this bias exists there, but Abstract is such a one-of-a-kind, unmitigated disaster that I believe it would not apply in this case. Choucas🐦⬛12:29, 2 June 2026 (UTC)reply
Not the right process; you're thinking of m:Proposals for closing projects.For what it's worth I think there's something worthwhile to come out of this; to resolve the fundamental problem the articles look to be moving towards using functions that express specific meanings rather than grammar. I definitely agree that the WMF is hopelessly overstating its progress, as Fram has meticulously documented.I would support some kind of discussion to make WMF be accurate when assessing the level of progress on the project. An RfC might be able to do that but I'm not sure if purely WMF communication matters can be subject to an RfC. In solidarity, Aaron Liu (talk) 12:40, 2 June 2026 (UTC)reply
I have some strong opinions about the content created by a couple contributors. This one was the original unattributed enwiki cop[y] Fram had originally mentioned. In addition to Csisc, there's also User:Immanuelle, who was blocked here for WP:CIR. Generally I think they share a need to do something now, though at this stage these contributions are unhelpful and frankly actively disruptive. Feeglgeef (talk) 23:45, 8 June 2026 (UTC)reply
What a poor thing if integrated into small language Wikipedias without any correction, especially for those Wikipedias without active sysops or rollbackers.--Jason2016426 (talk) 14:17, 12 July 2026 (UTC)reply
Something new
People keep commenting about stub articles filled with grammatical errors. This seems to have changed. This is - or would be - a large article, but little text actually shows. The rest is just errors. ~2026-40174-24 (talk) 11:56, 17 July 2026 (UTC)reply
Coming from huwiki, I've been trying to understand the scope and progress of Abstract Wikipedia, and I want to say first that Frem's updates in this thread have been more informative than the project's own pages on Meta. Thank you for that.
That itself points to my concern. This is an enormous and complex undertaking with many moving parts. A project of this size depends on community buy-in, so it needs to communicate its scope, progress, and decision-making clearly and regularly. Right now I don't think it does. If you read meta:Abstract Wikipedia and its subpages, much of it appears out of date, and the current scope and state are not stated anywhere in a way an ordinary editor can quickly grasp. You could say they're rather abstract. Additionally the original project proposal did not lay out the alternative solutions considered for the individual problem statements, nor any cost-benefit analyses. From what I've been able to piece together there were more readily available approaches, that could have delivered usable results by now (not including the recent advancements of LLMs). Checking the pages and the Wikimedia Board minutes it is also unclear what changes of direction have been discussed or approved since the initial 2020 resolution, or under what criteria the project would be judged unfeasible to continue. This is important, cause this is a highly ambitious project that, without clear guardrails, could go on indefinitely.
In this thread serious concerns were raised, and it's shocking that so far no one from the project has responded to these. I can only add to those, I agree that the project cannot really be described as an "early beta": after reading through pages of Abstract Wikipedia documentation, I still have no idea how I, as an editor, could begin supporting the project and test Hungarian implementations.
Without a clear understanding of what is happening and why, community discussion is effectively blocked. So that this does not sink without a reply, I'd like to ask the project leads to respond:
Current state and scope: What is the precise, current scope and phase of the project? What is the progress on the tasks, which of these are done from the initial 30 months plan? What is still prototype or research?
Supporting a language: Is there a documented, step-by-step path for a language community to add or improve support for its language? Concretely, what could a non-English editor do today to help with testing?
Documentation: Given that the Meta pages appear outdated, is there another current, plain-language page stating scope, status, and roadmap? Could Meta be updated?
Regular review: Since the Board's approval (the resolution of 22 May 2020), what changes of direction have been discussed or approved, and by whom? Are there defined milestones or off-ramps, and what criteria would lead the Foundation to conclude the project is not feasible to continue? How does the Board assure itself that the project remains on track and worth its cost, and what would have to be true for it to decide otherwise?
Resources and partial wins: Approximately what has been spent on the project to date, and how is the continued resource commitment justified against other Foundation and community priorities? What concrete, independently useful results has the project delivered so far (with examples)?
And @NGunasena (WMF): if you could comment on, or connect us with someone who can say more about the Board's thinking and its insight into the project's actual progress (questions 4–5), I'd be grateful.
To be clear, I'm raising this in good faith, I want the project to succeed, and clear communication from the stakeholders is a precondition for the community to participate. Boro (talk) 11:32, 7 June 2026 (UTC)reply
Not WMF, but for #2, you could look at which functions are commonly used on abstractwiki (e.g. f:Z28016) and learn to contribute to them. I am aware this is a tall ask and if you want to, I could help you. In solidarity, Aaron Liu (talk) 14:17, 7 June 2026 (UTC)reply
Thank you for the offer, but it's a taller ask than it looks. Hungarian is an agglutinative language that uses vowel harmony. The simple "defining" structure you linked (X is the Y) does exist in Hungarian, but the neutral, encyclopedic version doesn't use a definite article at all, while the variant that does carries extra contextual meaning. So it's unclear which needs to be used here: match the intention or the definition? The correct rendering needs helper functions to get the morphemes right, and research groups in MT and linguistics are still working on tools to do this reliably for all possible cases. I'm not an expert in this field, so I don't feel comfortable writing semi-correct functions to make this work. I've already seen students pick up incorrect uses from AI output, so getting this wrong at scale could affect the language itself.
From the Meta page this seems to fall under "Task P2.9: Renderer for a language from another family". But I can't find any notes on whether that was evaluated, and with what results and to what extent, before moving forward with the project. As I understand it, the majority of its benefit is supposed to come precisely from supporting non-Indo-European languages, so checking more than one language family seems essential. Boro (talk) 20:10, 7 June 2026 (UTC)reply
My understanding of Hungarian isn't the best, but from what I remember, isn't just a rearranging of the words? So it'd be literally "Budapest Hungary's capital" (Budapest Magyarország fővárosa). Feeglgeef (talk) 21:09, 7 June 2026 (UTC)reply
Not quite, főváros is the base word, +a/+e is a suffix, that can change form based on the word: capital of → fővárosa (főváros), sibling of → testvére (testvér), older brother of → bátyja (báty), younger brother of → öccse (öcs), mother of → anyja (anya). Also all these sentences are valid, but subtly different in their meaning: (1) Budapest Magyarország fővárosa, (2) Magyarország fővárosa Budapest (3) Budapest Magyarországnak a fővárosa (with definitive article). Boro (talk) 22:03, 7 June 2026 (UTC)reply
If it doesn't use a definite article, then the output should not have a definite article. I think how this is supposed to work is that each function outputs the construct with the intended meaning no matter what the grammar is. In solidarity, Aaron Liu (talk) 18:15, 8 June 2026 (UTC)reply
I'm not WMF staff, but as a volunteer I'm one of the most active users on abstractwiki and a functioneer on Wikifunctions.
Currently, on the Abstract Wikipedia wiki, which is in beta, users are able to create basic stub articles that render in English and often other languages. Wikifunctions is no longer in beta and is generally usable, P1.1 through P1.13 and P1.18 though P1.19 are things I'm able to do on the wiki right now. The plan listed for Abstract Wikipedia is very different from what it seems is actually being implemented, so I can't comment on progress there.
Somewhat. I do believe we need much better documentation, but f:Help:Contents has a few pages that are good starting points. I have helped and am willing to help others with the process of creating localized versions of functions.
I don't believe so, unfortunately.
I'm not sure, as again I'm not WMF staff.
On results, we've seen some use by smaller-language Wikipedias and small-and-mid-sized Wiktionaries of using Wikifunctions like templates. As mentioned before, Wikifunctions is also useful on its own and has a large catalogue of functions.
"users are able to create basic stub articles" for extremely low bars of "basic" and "stub" (and "create" for that matter, many editors don't seem capable of this, the learning curve is quite steep).
" that render in English and often other languages. " Very rarely, actually. But feel free to give us a few examples of what you consider basic Abstract stubs and which languages they render in. Take for example Australia, which probably comes the closest to an actual article. When I try to translate it to German (and after a very long wait), I get 5 errors, and a mixture of German sentences, English ones, and mixed ones like "The Einwohnerzahl of Australien was 27614411 in 2025." Same when I try it in French, 6 errors (4 different ones), mixed languages. But at least in English you get an article that reads as if some dumb robot compiled it, with the first five (obviously very short) sentences starting "Australia is", and ending with varied but hradly correct ones like "Melbourne is the most population urban area in Australia." Or let's look at the most recent one you created, Labrador Retriever. Full text: "A Labrador retriever is a dog." Capitalization is hard apparently. Dutch translation: "{labrador retriever} ⊆ {hond}". Another one you created, 6-7, doesn't even work in English ("Wikifunctions returned a failed response: Reached recursion limit in orchestrator") Mount Everest: "Mount Everest is a mountain of China–Nepal border.". Frenglish: "Everest is a montagne of frontière entre la Chine et le Népal." Swedish: "Mount Everest is a berg of ." Spanish: "Everest is a montaña of Frontera entre China y Nepal."
So no, both creating decent stubs and rendering them in other languages doesn't really work, even when one of the most experienced Abstract editors creates them. Fram (talk) 09:32, 8 June 2026 (UTC)reply
It's crazy that the resources of the WMF are going into this hopeless and pointless black hole instead of fixing actual problems that the community have been highlighting for years. It would be fun if it wasn't tragic Ita140188 (talk) 09:42, 8 June 2026 (UTC)reply
Yes. It's time to pause development on Abstract (to avoid the embarrassment of cancellation) and redeploy the engineers to process community tech requests. That's not as good a result as retaining the staff with relevant experience, but it's a start. Certes (talk) 13:01, 8 June 2026 (UTC)reply
You're a one trick pony, Fram. We get it. Some of the articles on Abstract Wikipedia are not great. But if one billion useless articles were added to the English Wikipedia, I wouldn't call for it to be shut down. The fact that you can find articles that look bad doesn't mean the project needs to be shut down. As for your examples, they do not disprove (in fact, they prove) my intentionally conservative statement, users are able to create basic stub articles that render in English and often other languages (emphasis mine). Feeglgeef (talk) 15:07, 8 June 2026 (UTC)reply
If you would look at article after article on enwiki that looked like this, you would be right to call for it to be shut down though. And it's not a case of "I can find articles", I picked recent ones created (or in the case of Australia edited) by you specifically, as last time you complained that some examples came from an editor who is blocked on enwiki (but not on Abstract).
But I see that you consider these rather dreadful examples as "basic stubs" and the abysmal translations as evidence that they "often render in other languages" and provide no better examples, so I presume that this "one trick pony" (WP:NPA) somehow found representative examples and you won't point to some better Abstract articles instead. Fram (talk) 15:42, 8 June 2026 (UTC)reply
Firstly, I'm sorry for the "one trick pony" comment. I had meant it as a comment on the lack of variation in your evidence, and should have framed it as such.
Here's a decent article, abstract:Q1186. It's a basic stub (the information would be useful) and renders correctly in both English and Bangla, thus meeting all of the criteria I gave. Feeglgeef (talk) 16:25, 8 June 2026 (UTC)reply
Thanks. Why does it give the population in 1961? It's less than half of the current population, so hardly good information to include here. Fram (talk) 16:31, 8 June 2026 (UTC)reply
That's especially weird considering that not only does Wikidata have a figure from 2017 but it is also marked with preferred rank. Warudo (talk) 16:33, 8 June 2026 (UTC)reply
I've fixed it such that it will use preferred statements first. Unfortunately, despite the fact that I've requested it multiple times, there's no way to fully clear the cache, meaning the Kerala article is stuck with the old value. But it will work for new instances, like Illinois, which I just created. Feeglgeef (talk) 16:48, 8 June 2026 (UTC)reply
Seeing the working examples led me to think that, at the reader level, this is something that ArticlePlaceholder was already capable of: surfacing Wikidata facts about a topic with no local article. For topics that do have an article, inline Wikidata item calls can keep those facts current on its own (though the editing experience could be smoother). All in all, I don't see why sentence generation is worth all this effort, when easier paths were open to achieve essentially the same benefit. Boro (talk) 22:37, 8 June 2026 (UTC)reply
There're certain things only articles can do, like document the history of how something happened. I don't really see any advantages of ArticlePlaceholder over just referencing Wikidata when you do need to switch wikis. In solidarity, Aaron Liu (talk) 01:51, 9 June 2026 (UTC)reply
You described yourself as one of the most active users on abstractwiki and a functioneer on Wikifunctions, so I do not find it unreasonable for Fram to look at your articles and point at the glaring and massive issues there. Maybe being able to find articles that look bad means little, but are we even able to find articles that look good though? Or is the bar so low that "good" by Abstract Wiki standards just means "not broken in a thousand obvious ways"? You have to admit that from an exterior point of view, things really look dire, and the fact that there is not even more than one outdated meta page in terms of documentation does not bode well in terms of perspective. And that is even without getting into the immense issue that the basic premise of the project is based on disproved linguistics, as has been pointed out elsewhere. Choucas🐦⬛16:04, 8 June 2026 (UTC)reply
I do agree that things might look dire from an external point of view, but, as I've been trying to show, Abstract Wikipedia is a viable project. It just needs more time, and, ideally, better technical support. I do agree with those above that Dr. Vrandečić is overstating our progress. Feeglgeef (talk) 16:56, 8 June 2026 (UTC)reply
Personally I think it's worthwhile to explore this avenue with the aim of making imperfect 'universal stubs' that serve as placeholders while small wikis are developing, but the design of abstract wiki is frankly amateurish, the team appear to be incredibly out of their depth. Why has wikifunctions been primarily based on English/Indo-European languages when there'll be practically no new wikis in languages closely related to English? Do we know if any professional linguists were consulted (the mastermind behind it sure as hell isn't one)? Why was this not done by experts? How on earth has $6 million been spent? On what? How has this gotten through so many checks and meetings? Kowal2701 (talk, contribs) 21:08, 8 June 2026 (UTC)reply
I'm open to the possibility that there could be a way to write articles using a lingua franca that is amenable to translation to many different languages. But I have strong doubts about Abstract Wikipedia being viable as a crowdsourced project using Wikifunctions as the lingua franca. isaacl (talk) 00:17, 9 June 2026 (UTC)reply
The lack of documentation means people have to (re)invent the wheel when they want to write things and, at least some of them are not good at it. Consider abstract:Q246463 where the editor who made it wanted to use a pronoun instead of repeating the name of the article subject, so they passed it (Q6091500) to the function that generates the second sentence. There are two problems with this. One, it leads to the awkward phrase "of it" instead of "its". But more importantly, it doesn't work for languages other that English because grammatical gender is different between languages. What is the equivalent of "it" in French, which doesn't have neuter? Or worse, what would happen in a language where neuter exists, but the word for "shrine" is not neuter? Warudo (talk) 17:08, 8 June 2026 (UTC)reply
This is a problem as well. Wikifunctions (and, by extention, Abstract Wikipedia) has a very steep learning curve, so we have a few users who understand it deeply and everyone else, who barely understand it at all, which makes it very hard to find contributors, whereas the English Wikipedia has a remarkably flat learning curve and a very high ability to specialize. Feeglgeef (talk) 17:19, 8 June 2026 (UTC)reply
This is the part that makes me ambivalent about the WMF's involvement. I think it's worthwhile doing research in understanding ways to capture information based on commonalities in language. It's not clear to me, though, that crowdsourcing is an effective way to generate an encyclopedia of articles written in a lingua franca with a programming-like syntax. Without the crowdsourcing aspect, I don't think the project is a good fit for the strengths of the Wikimedia Foundation. isaacl (talk) 17:42, 8 June 2026 (UTC)reply
I'm reading through this again and that "Dutch translation" in particular scares me because of how wrong it is on multiple levels. First of all, is returning math notation really helpful? Wouldn't an error be better here so there's no illusion of support? But more importantly, no matter how smart the person who came up with this workaround felt, it is still wrong! "{labrador retriever} ⊆ {hond}" means that the singleton set {labrador retriever} is a subset of the singleton set {hond} which is obviously false. It should be "labrador retriever ⊆ hond" or, more explicitly, "{x|x ∈ labrador retriever} ⊆ {x|x ∈ hond}". If after all this time, people who work on this stuff cannot handle what are essentially instance of (P31) (∈) and subclass of (P279) (⊆) correctly how can we expect this project to ever succeed? Warudo (talk) 10:35, 13 June 2026 (UTC)reply
Hello @Boro, and thank you for your good faith inquiry.
I agree with you that the project pages for Abstract Wikipedia could use an update. We will spend some time in the near future to do so, thank you for pointing that out. We have mostly focused our progress report through our weekly newsletter. We have been keeping the newsletter up for more than 250 editions now, and I am sure you would be able to find most of the answers to your questions in the updates. But I admit that sorting through so many newsletters to find the one answer you are looking for is not the best solution.
Here is the current status of the project, in a very short overview:
Wikifunctions launched almost three years ago (July 28, 2023). The project has a growing community, and there are now more than 4000 functions created. The speed of function creation is increasing.
Wikifunctions function calls can be embedded in almost all Wiktionaries, as well as Dagbani, Bengali, Igbo, Hausa and Malayalam Wikipedia. This allows editors to call a centralized store of functions to produce outputs, instead of having to create and maintain them locally in each wiki. An example is here, where the German declension table comes from Wikifunctions. If more Wikipedia language editions would like to have this functionality, please let us know. We are currently prioritizing article integrations and are planning to revisit embedded Wikifunctions at a later date, but let us know your feedback.
From Wikifunctions, we are able to access data from Wikidata. This includes most statements about items, and most lexicographic data. This allows the community to create functions using the rich lexicographic data in Wikidata, or using population numbers from Wikidata directly, etc.
Abstract Wikipedia is in early beta, and we made it available live to enable learning, testing, and iteration. We want to co-create this project with our communities, including on how NLG functions evolve. Here’s an example that was just working as I write this, a short article about the year 1234 in English and in German. We also want to see how the system performs with real traffic to make it more stable and responsive. We are listening to feedback and releasing improvements every week.
Now you might object that the Hungarian article about 1234 is better than our abstract article (for example, it doesn’t call 1234 a Gregorian year even though it’s a Julian one), and you’d be right. Our scope, however, isn't to replace existing articles, but to fill in gaps where they currently exist, particularly in language editions with a smaller community.
In a few months, this will be possible when language communities will be able to integrate Abstract Wikipedia articles into their Wikipedias. We hope by then such errors will be fixed, and more content will be possible. This will be the last major piece of the puzzle, and once in place, we will work closely with communities to discover missing capabilities, bottlenecks, and potential for improving the contributor interfaces. We will create feedback loops to ensure the product evolves to support community needs. We will assess how effective Abstract Wikipedia is at addressing multilingual content parity, and make further decisions on next steps from there.
We are fully aware that this is only addressing a small part of the questions here. Our suggestion is that we will summarize the constructive criticism and concerns to kick off a discussion page on Meta, and answer the questions there. This discussion here has surfaced great suggestions and criticisms which we want to address. We want to take this input seriously, but it will take some time, and we can then continue this conversation on Meta, where it is visible for all communities.
"making it much easier to start a local version of the article, instead of writing it from scratch or translating from another language. " That I doubt. It's not as if for these smaller languages, things will magically work if you have the right Abstract article and the right functions. Even completely ignoring the language structure issues (a pretty big issue in itself), people will need to navigate Abstract and Wikidata, add labels and lexemes, and who knows what else. Even a simple "article" like the rather useless 1234 linked here, gives 6 errors when translating to smaller languages like Nahuatl (and 2 errors for French), with the errors not really helping to knw what needs to be done.
Why you believe this can be integrated in any Wikipedia in a few months time is beyond me, sounds more like a KPI that needs to be met than an actual good plan. Publishing one or two symbolic "articles" from Abstract to some language and then celebrate this as a major milestone and a proof that it works, when in reality next to nothing has been achieved and questions about the fundamentals are completely ignored, does not give any confidence.
As for the Wikifunction, it looks to be wrong or at the very least oversimplified. A rather different table is given e.g. here or here or here.
Having basic information wrong - as in the 1234 example or several other examples listed here - is not filling in a gap on smaller projects it's spreading misinformation. I would not expect information from abstract to be 100% correct. Or even as correct as the average enwiki article or the average article on some other large project. But I would expect it to have basic information correct. And I would expect it to be reasonably intuitive for someone who spots an error to be able to correct it, which if I understand things correctly, would mean some kind of easy connection back to Wikidata. Best, Barkeep49 (talk) 15:59, 9 June 2026 (UTC)reply
How is that a easier way to populate articles for smaller languages compared to automatic translation from a bigger language and basic copyediting? It seems to me this would require a lot more work for a much worse result compared to the basic way that worked until now Ita140188 (talk) 07:59, 10 June 2026 (UTC)reply
They seem to have the wrong idea that when you have an abstract article and working functions, all you have to do is change the language and you have an article. Without even going into the grammar issues with many languages, it ignores the work needed in Wikidata to get everything you need for a certain language. Hence, in the 1234 example given, the 2 errors for France and the 6 for Nahuatl. It also ignores the complete instability of Abstract: if I go to 1234 (in English) now, instead of the text I saw yesterday I get "Wikifunctions returned a failed response: Invalid orchestrator result". Finally, it ignores that probably you will find more people interested in actually writing articles in their language, than people navigating 3 or 4 environments (Abstract, Functions, Wikidata, and Wikipedia) to copy someone else's creations, certainly when they can (for many, not all languages) much more easily copy creations to their language through online translation tools.
The only use case where I see this making sense is from a push-concept, where people from Abstract "push" translations (in languages they don't understand) to all Wikipedia languages where a certain topic doesn't exist yet. This obviously is a disaster waiting to happen, and should be opposed by all possible means. Fram (talk) 08:16, 10 June 2026 (UTC)reply
Even for the example at wikt:hr:Wort this is painfully useless at scale, since the construction and further editing of {{#function:Z29055|L2206|}} requires knowing that there is a Wikifunctions page called f:Z29055 and a Wikidata page called d:Lexeme:L2206. It is abhorrent that instead of doing something along the lines of mw:Multilingual Templates and Modules, millions of dollars from the Endowment (source here) are being spent on this website that’s extremely hard and annoying to use, and is impossible to edit without JavaScript. stjn15:05, 10 June 2026 (UTC)reply
@Sannita (WMF): can you give us clarity if there are future funds being planned to be sunk/invested into this project? Like many people above, I'm sceptical this can ever work at scale, and feel that small communities deserve better. In solidarity, —Femke (talk) 🐦 16:08, 10 June 2026 (UTC)reply
To be fair, there's no good reason to call {{#function:Z29055|L2206|}} directly from mainspace. Functions that editors will use often should be wrapped in templates precisely so editors don't have to memorize the ZID. As for the LID, you can open Wikidata on another tab and look up the lexeme to get its ID. It doesn't sound that bad. Warudo (talk) 16:14, 10 June 2026 (UTC)reply
I think if someone provides that as an example of the potential usefulness of Wikifunctions, I am going to judge it on its merits. And the merits here are entirely unconvincing (what you are describing in itself is extremely tedious), especially compared to investing in the less pie in the sky ideas that you can use the regular editing interface for (Wikifunctions and Abstract Wikipedia in themselves are a good example of how badly the website would be run if WMF developers ever forgot that to truly serve knowledge to everyone, we need to be HTML-first). stjn18:11, 10 June 2026 (UTC)reply
How can it be an easier way to create articles for smaller languages compared to automatic translation? And the automatic translation is already given in the Special:ConstentTranslation.--Jason2016426 (talk) 14:32, 12 July 2026 (UTC)reply
@Jason2016426: There are three issues with the automatic translation approach:
For many languages, automatic translation is still not good enough or even simply unavailable. Point in case is the English Wikipedia's reluctance to accept automatically translated articles -- so, even for English, the quality is not deemed good enough.
Automatic translation basically forks the content of an article. Updates are not propagated but manually.
Automatic translations are by design a one-way street. No knowledge added to a translated article propagates back to the source article.
There are also advantages to automatic translation. The good thing is that the Abstract Wikipedia project does not require exclusivity. Readers and contributors both can still use the benefits of automatic translation wherever it fits their needs. --DVrandecic (WMF) (talk) 09:02, 16 July 2026 (UTC)reply
Point 1 is kind of a flawed argument. Articles created with machine translation are not great, but they are infinitely better than articles from Abstract Wikipedia. I don't see how this is going to change ever, given the continuous improvement of machine translation and the incredibly slow progress of Abstract Wiki. Ita140188 (talk) 10:44, 16 July 2026 (UTC)reply
The Abstract Wikipedia team has drafted a response, which was reviewed and improved by the community. We want to express our gratitude to the community members who have shown their care and spent their valuable time contributing to the answer. All remaining shortcomings are strictly ours. The answer can be found here: meta:Abstract Wikipedia/Response to English Wikipedia criticism. You are welcome to comment and to pose further questions and criticism on the talk page. -- DVrandecic (WMF) (talk) 08:55, 16 July 2026 (UTC)reply
Clearly not. I can't believe that there is nobody that can say anything useful here, so can only conclude that the non-reply is because they have been ordered not to communicate with us plebs. What do we know anyway? Phil Bridger (talk) 16:42, 18 June 2026 (UTC)reply
@Phil Bridger, as of this message in this thread you have made nine comments. With them, you have managed to: - Imply every WMF employee answering about Abstract Wikipedia would be engaging in bad faith because their salary depends upon not fixing issues; - Suggest that the WMF workforce is so lazy that the place would run better after firing half of them; - Belittle (twice) an editor who made the error of trying to address your concerns in good faith; - Dare any of the hundreds of WMF employees to come spar with you; - Suggest their limited answers are actually due to a marching order because they despise the community. I want Abstract Wikipedia, a flawed project based on an erroneous assumption and no community to carry it, to be abandoned shortly as much as anyone here, including you presumably. I also think communicating with the community should be a bigger part of the responsibilities of WMF employees. Nevertheless, I do not believe dealing with your constant, pointless, and toxic abuse is part of that. Either engage in good faith to find solutions, or control yourself. If what you need is a place to vent, find another one, because aside from lashing out and poisoning this already heated conversation further, you have accomplishing nothing. Choucas🐦⬛19:24, 18 June 2026 (UTC)reply
Thank you. I'm operating in good faith here. Everyone here wants what's best, and, even without AGF, we wouldn't have spent countless hours contributing to Wikimedia projects if we didn't. Feeglgeef (talk) 21:24, 18 June 2026 (UTC)reply
Thank you. However, I get the feeling that Feeglgeef is a little out of their depth here, but there's nobody with any decision-making authority at the WMF willing to rescue them wasn't particularly kind, nor did it have anything to do with the merit of my argument. I understand that this community has a poor relationship with the WMF (I don't particularly like them either!), but that doesn't mean that Abstract Wikipedia has zero potential in any form, and just because I believe in that potential doesn't make me a mindless WMF droid. Feeglgeef (talk) 21:59, 18 June 2026 (UTC)reply
@Feeglgeef, @Phil Bridger Can both of y'all take it down a notch. Calling folks mindless WMF droids or insinuating that they are lazy or bad faith assumption because they have been ordered not to communicate with us plebs is definitely not okay. Sohom (talk) 07:21, 19 June 2026 (UTC)reply
True, but the people in charge of the project posting halftruths at best and then ignoring all follow-up questions isn't really okay either, and causes the irritation that shines through in some ill-tempered remarks here. Fram (talk) 07:36, 19 June 2026 (UTC)reply
I have my own misgivings that roughly align with yours (I've tried contributing to Abstract Wikipedia and found it extremely hard to do so -- much harder than the cost of machine translation or even writing something from scratch in my native language). However, I don't think Sannita is talking in half-truths, I think WMF (as an org) does believe that they can create a system that can: "make it much easier to start a local version of the article, instead of writing it from scratch or translating from another language." and the approach they are taking is to first build out the whole pipeline first and only then measure whether operating Abstract Wikipedia causes production outages, whether or not editors find it easier to write articles in Abstract Wiki-lang (for the lack of a better term) and whether the effort of learning to write Abstract Wiki-lang is worth the trade-off of being able to write a few dozen linguistic rules (or whether that is even possible at scale). cc @Femke's call out of whether future funds will be invested, my understanding is that the team is still on grant runway and my understanding is that they do plan on measuring whether or not Abstract Wikipedia is viable this year (actually maybe @DVrandecic (WMF) or @ATsay-WMF would be better placed to answer that specific question?) Sohom (talk) 08:20, 19 June 2026 (UTC)reply
Comments like "We did some limited tests in a controlled environment, but doing so can only help you so much in identifying potential problems. We are learning a lot by releasing the beta project (because this is still a beta), and we'll improve from there. " are half-truths at best, with words like "limited" or "beta" doing an awful lot of heavy work here.
"Abstract Wikipedia is in early beta, and we made it available live to enable learning, testing, and iteration. " is also a dubious statement. Like has been said, it was an untested alpha, where the WMF really dropped the ball quite dramatically, with the most logical conclusion that some KPI or deadline had to be met. Even the examples given for the use of Functions and Abstract were and are very dubious. At the moment, 1234 gives me "Wikifunctions returned a failed response: Error in the function call API". In other major languages, for the same article, I get errors like "Wikifunctions returned a failed response: Invalid executor response", "Wikifunctions returned a failed response: No matching lexeme for item in language", and "Wikifunctions returned a failed response: Argument value error". Fram (talk) 09:00, 19 June 2026 (UTC)reply
When AL2 was saying that we should not build publicly open tools that show the impact of WMF’s grant funding because of potential scrutiny and criticism of WMF by Wikimedia movement community members, she singled out and named a specific critical Wikimedia movement community member as an example. To me, the way AL2 portrayed the critical community member came across as very negative. It created the impression that the critical community member was a bad, hostile person with negative intentions towards WMF. My manager did not object to or question AL2 doing this to a community member. She appeared to be in agreement with how AL2 treated that person.Gnomingstuff (talk) 20:01, 27 July 2026 (UTC)reply
Are you seriously responding to a comment from more than a month ago to just throw gasoline on the fire with something that is completely off-topic? I am aware people do not seem to think WP:FORUM applies the same way to WP:VPW, but this is simply ridiculous. What are you trying to accomplish here? Choucas🐦⬛20:37, 27 July 2026 (UTC)reply
Sorry, I thought this was part of the below thread, given that there is a lot going on right now on this large page and a lot of scolding of people to assume good faith toward the WMF (to which this is very much on topic) Gnomingstuff (talk) 21:23, 27 July 2026 (UTC)reply
Two wrongs don't make a right? For what it's worth, while I cannot control (and have no desire to control) who says what in non-public spaces (both editors and Foundation staff), within public/onwiki/phabricator spaces you can be rest assured that if a foundation employee insinuated similar, I would escalate it and strongly demand a apology (and to my understanding Foundation staff are strongly cautioned against publicly castigating volunteers). Sohom (talk) 22:22, 27 July 2026 (UTC)reply
No, they just ignore them completely, twist the facts, make incorrect or extremely dubious claims, and repeat this for years and years. But publicly castigating, no, not since WP:FRAM I think. We see the exact same pattern at the Image Carousel discussion, where they reply to the questions they think they can spin positively, and ignore the ones where this isn't possible. Fram (talk) 09:05, 30 July 2026 (UTC)reply
But nobody called anyone a "mindless WMF droid". The only use of anything like that term was by Feeglgeef saying that they were not a "mindless WMF droid". But I see that my words here will be twisted beyond recognition. Phil Bridger (talk) 07:40, 19 June 2026 (UTC)reply
How is this better than AI?
I know it's popular in wiki-land to hate on anything related to AI, and in particular LLMs, but I look at what Abstract does and I look at what the LLM-driven translation tools do, and I just don't see the point of what we're doing. Our goal is to be able to take an article written in one language and allow somebody who does not read that language to read the article in a language they do know. The LLM tools do that today. They're not perfect, but they're good enough for most purposes, and they'll only get better over time.
I don't mind investing WMF money in research projects. There is value in adding to our understanding of how information is stored and processed, and exploring better ways we can deliver that information to our readers. Abstract and Functions is about that, so I'm happy that we've explored what's possible. But given the progress LLMs have made over the past few years, and the current state of what Abstract appears to be able to deliver, I'm just not seeing how this has a chance of becoming a viable product. That's not to say the experiment was a failure. A failure would be "we haven't learned anything". But we have learned something, which is that "this approach to automatic translations doesn't appear to be the way to go". RoySmith(talk)13:00, 19 June 2026 (UTC)reply
AI translation has a tendency to be confidently incorrect, but AI is certainly more accurate than using buggy functions and blaming it on the community. ~2026-34629-56 (talk) 15:52, 19 June 2026 (UTC)reply
It's a record of data and not AI. If WMF steers this in the right direction and invests the resources and work in the right places (which they are surprisingly failing to do for a project that they so champion) then the articles have the capacity to be much better than AI. In solidarity, Aaron Liu (talk) 17:31, 19 June 2026 (UTC)reply
How? Why would WMF be able to translate into obscure languages without the help of one or two linguists of those languages? Someone will have to translate all lexemes for these languages, add all labels for these languages, check the output of Abstract, and then give the green light. We need to be certain that they are native speakers or very fluent in the language, to avoid a Scots scenario. And all that to translate an Abstract article which will probably be worse (language, completeness, ...) than enwiki, dewiki, jawiki... and not adapted to the target language (see e.g. the example of 1234, which doesn't take into account any other year system). LLMs won't do all of these things either, but for a fair number of languages it will already produce a result which is as good as can be expected from Abstract, but without all the additional effort described. How will Abstract ever be better at those things? Fram (talk) 18:15, 19 June 2026 (UTC)reply
Exactly, that's what they would need to do (the advantage is deterministic outputs). It's worrying that the infrastructure for what they need to do is in such an alpha-at-most state. In solidarity, Aaron Liu (talk) 18:59, 19 June 2026 (UTC)reply
"LLMs won't do all of these things either" is such an understatement by the way. They have no understanding of the things they translate at all, which is pretty bad for an encyclopedia because we use technical terms whose translation is not always straightforward. For example, in some languages a field is called a "body" (presumably the ones that borrowed the term from French). My native language, Greek, is one of them. Guess what Google translate does when I ask it to translate Field (mathematics) (). It switches between the correct term (σώμα) and the literal translation of "field" (πεδίο) between paragraphs. To no one's surprise, it sticks to the wrong word most of the time and it also uses the wrong word in the title. "Field" is far from unique in this. While checking this and other articles, I saw words like function, matrix, ideal, differentiation, infinitesimal, domain etc. get mistranslated too. That is in addition to all the other things it butchers along the way ("general quintic equations" -> "general quantum equations"?? in the field article) as well as grammatical mistakes even a complete novice wouldn't make ("Εάν η συνάρτηση είναι διαφορίσιμο(??) στο a" in derivative). It's not a google exclusive problem either. In my testing with DeepL it didn't do much better. Also, since I mentioned French earlier, here is a French example where Lie ring turns into "ring of lies" (I don't speak French so I verified this with Wiktonary): . Warudo (talk) 20:04, 19 June 2026 (UTC)reply
To be clear the point of my comment is that the only translation that is worth considering is one done by humans. I understand why people want to compare abstract Wikipedia to LLMs but I think that comparison misses the point. Even if abstract Wikipedia reaches a point where it is able to produce LLM level output, which I feel would be nothing short of a miracle, it would not be anywhere near good enough to consider using. Warudo (talk) 20:10, 19 June 2026 (UTC)reply
Incorrect word choice is hardly limited to computers. People do it too. I used to work with a guy from Cuba who, while fluent in English, never quite mastered the difference between "in" and "on" (they're both "en" in Spanish). The phone would ring, he would answer it, and hand it to me: "Bob is in the phone for you". Oddly enough, "in the phone" actually makes more sense, but that's not the correct English idiom.
I read a lot of text related to checkuser actions in various languages. It didn't take long for me to figure out that "doll" was just Google Translate's way of saying "sockpuppet" in Spanish, and so on for other languages and other bits of wiki-jargon. In the end, it really isn't a big deal. It was obvious from the get-go that "doll" wasn't the right word but I quickly figured out what it meant and ultimately there was no real hit to my cross-wiki reading comprehension.
I expect the same is true of "field" for you. You recognized that πεδίο didn't make sense, but you figured it out and now that you know what it means, so what if it's not the correct word? Languages evolve. Hardly a day goes by on the internet without me being reminded that I'm no longer one of the cool kids because they're using words I've never heard of before and I have to resort to Urban Dictionary to figure out what they're talking about. Is it really fair that we hold the LLMs to a higher standard that we hold ourselves? RoySmith(talk)20:52, 19 June 2026 (UTC)reply
Let's assume I didn't speak English and elwiki didn't have an article on fields. I'd read the translated enwiki article, see that the term is called "πεδίο" (this is the term that appears most, the other terms are probably translation errors) and move on. Except what if I then wanted to go look for more information outside Wikipedia? I'd then pick up my mathematics textbook, check the index and only find results about scalar fields and vector fields (which are called πεδία in Greek) but nothing about the algebraic structure. What I'm missing is that I'm looking in the wrong place. If only I knew what it was actually called. Then I want to learn what an ideal is. Google translate said it's called "ιδανικό" . Huh, there's nothing here? If only I'd known the word is "ιδεώδες". And on and on it goes. So, ultimately, you can't look things up on your own because you don't know what they are called so you're stuck asking the AI about them. You also can't really discuss these concepts with others because your idiolect is completely different from theirs. And before you call this hyperbole, I'll let you know that google translate also mistranslates "associative" in the field article. So even if you try to tell your interlocutor the definition of the thing you're talking about, you're still out of luck unless they speak English and guess what happened.
You also underestimate just how confusing things can get. In the translation of ideal (ring theory), the term "right ideal" (which is supposed to be δεξιό ιδεώδες) turns into something that basically means "correct ideal" (σωστό ιδανικό) and "proper ideal" (which is supposed to be γνήσιο ιδεώδες) into something that means "suitable ideal" (κατάλληλο ιδανικό). So someone who doesn't speak English and does not know why these error happened will try to figure out why a right ideal is correct and a left one isn't and what a proper ideal is suitable for. Warudo (talk) 22:38, 19 June 2026 (UTC)reply
I feel your pain. My particular peeve is symbols. If I read in an article: and don't know what that symbol is, how do I even begin to look it up? Claude actually does a good job if I copy-paste the markup, I get back "The notation: F \ {0} means "the set F, with the element 0 removed." which at least gets me pointed in the right direction. But to get back to my original point, "they're good enough for most purposes". Failing to correctly translate some terms in advanced math articles doesn't negate that. RoySmith(talk)23:01, 19 June 2026 (UTC)reply
My favorite analogue phrase for "sockpuppet" is the one used in French, which is "faux-nez", e.g. "false nose". jp×g🗯️23:30, 18 July 2026 (UTC)reply
If by "better" you mean produce better translations in theory, in essence this is pitting a rules-based translation system where the rules are explicitly programmed by humans versus a black box where a program adjusted its tuning parameters by itself that control how translation is done from input to output. One example is the world's strongest chess program, Stockfish, which originally had a human-crafted evaluation function, then introduced a trained neural network, and now has dropped the human-crafted evaluation function. However games have a very specific ultimate evaluation method – did the program win – which I suspect makes it easier for the network to evolve to a state where it wins more often. I think human language translation has more training challenges, and it's not as clear to me that a program self-training could in a theoretical perfect world do a well as an explicit set of rules.
From a practical standpoint, though, codifying rules to capture all nuances is very difficult. And even to the extent it's possible, it's not clear that there are enough people interested in working on it in a crowdsourced project. So while the black box may produce OK translations only some percent of the time, that might still offer a better cost-benefit ratio than getting Wikifunctions to meet the same level of quality. isaacl (talk) 02:51, 20 June 2026 (UTC)reply
If I understand it correctly, Abstract Wikipedia is fundamentally different to LLM-generated translations. (1) Abstract runs on fully transparent source texts and algorithms instead of LLM sources and algorithms that are to a great degree opaque (despite the label "open") and whose results are not reproducible. (2) The carbon footprint accelerating the climate emergency is, in principle, auditable in the case of Abstract (within the overall Wikimedia carbon footprint) but is mostly hidden by corporate secrecy in the case of the big LLMs for which 23% of Ireland's 2025 electricity is used by data centres. There are similar problems for excess water usage. Boud (talk) 16:20, 16 July 2026 (UTC)reply
Funding sources
Given what I’ve wrote here above, I feel like the community is owed a more detailed explanation on the funding of Wikifunctions and Abstract Wikipedia as of right now and overall. How much funds come from Wikimedia Endowment and/or Wikimedia Foundation? How much donor money was spent on making a JS-laden interface that’s incomprehensible to an average programmer, never mind a newcomer? Was that really deemed the best use of the funds by Wikimedia Endowment board, and if so, how (i.e., why was this project deemed more important compared to less frivolous ideas that would actually improve our software)? stjn20:30, 29 June 2026 (UTC)reply
Since the draft response is linked at the very beginning of the RfC, I think it is fair to say it has been taken into consideration. Choucas🐦⬛11:58, 14 July 2026 (UTC)reply
@Sannita (WMF) and @DVrandecic (WMF): In addition to what Choucas mentioned, sweeping, handwaving statements like: Generated article quality: This is a concern that we share, but we have evidence that the results will get better with time, and with the expansion of the community. (with zero links to any kind of evidence) is well below the level of transparency and assurance I would expect in response to such detailed feedback and criticism about the problems of scaling this model. Please do better. Sohom (talk) 12:18, 14 July 2026 (UTC)reply
WMF Banner ads
The WMF is currently running banners with the text:
17 June: Wikipedia still can't be sold We're sorry we've made several attempts to reach you, but it's Wednesday, 17 June, and we still need some help. If Wikipedia is useful to you, please take a minute to protect its future with a $2.75 donation today. Most readers don't donate; only 2% do. Wikipedia is run by a nonprofit, not by a billionaire. So if Wikipedia has given you $2.75 worth of knowledge, please give. Any contribution helps, whether it's $2.75 or $25.
In the past, we produced a consensus that banners that state or imply any of the following are not considered appropriate on the English Wikipedia:
Wikipedia's existence or independence is under threat or dependent on donations
Donated funds are used primarily to support Wikipedia and/or its volunteer editors
Readers should feel obliged to donate regardless of their means ("guilt tripping")
I don't believe that these current banners comply with this consensus. I'm hopeful the WMF can resolve this quickly; I will post to the talk pages of a few relevant employees, asking them to comment. BilledMammal (talk) 07:25, 17 June 2026 (UTC)reply
Could you expand on why you believe this is against community consensus? Compared to the ads of old, I think this passes muster but maybe I'm missing something. In solidarity, —Femke (talk) 🐦 07:56, 17 June 2026 (UTC)reply
The most problematic text seems to be "protect its future", where "it" clearly means "Wikipedia". That could be read as suggesting firstly that a substantial part of any donation would go to Wikipedia, and secondly that Wikipedia is $2.75 short of being able to survive without it. However, the implication is indirect and less deceptive than previous banners. Certes (talk) 10:16, 17 June 2026 (UTC)reply
@Certes: A substantial part does go towards Wikipedia, cc the Annual Plan breakup. Regarding the original question, I personally align with Femke and RoySmith in that I don't think the banner breaks consensus given the context of the guidelines (which were primarily made for a different category of much more egregious banners) Sohom (talk) 16:42, 17 June 2026 (UTC)reply
Complaining about a banner is a different bar from "banner violates past consensus, needs to be resolved quickly" (which is the tone of this discussion). One is "lets have a dialog" another implies "do this now, or else". Sohom (talk) 19:41, 17 June 2026 (UTC)reply
@Black Kite Could you explain what part of this is deceptive? (When you answer, one thing to keep explicitly keep in mind that the funding situation has significantly changed since 2022 when this consensus was obtained, WMF does spend 77% of it's budget on volunteers, a majority of which goes to English Wikipedia, and unlike in 2022, donations are actually on a downward trend and WMF is actually now increasingly turning to long-term donors to continue funding itself -- while it still has a fair bit of money around, it is not infinite and the lack of any donations will indeed lead to insecure future at some point, especially in a climate where we are competing with billionare led ventures like Grokipedia). Sohom (talk) 20:15, 17 June 2026 (UTC)reply
"...take a minute to protect its future with a $2.75 donation today". Nothing is going to happen if you don't donate $2.75, and neither is it if no-one else does either. That was the reason the first clause was agreed the last time we had this discussion. Black Kite (talk)20:26, 17 June 2026 (UTC)reply
Collectively if no-one else does either is a problem. I remember doing some back of the napkin math, at our current spend rate, I think we have roughly 1.5 to 2 years assuming everyone immediately stops donating. This is obviously not a dooms-day, we pack up tomorrow scenario, but it's not "if nobody donates we will be around for 10 more years" scenario either and the "nobody really has to worry about donating" scenario that you are laying out. Sohom (talk) 20:49, 17 June 2026 (UTC)reply
Nothing is going to happen if you don't donate $2.75, and neither is it if no-one else does either. How exactly do you think WMF pays its employees and its bills for running its data centres? – SD0001 (talk) 16:47, 18 June 2026 (UTC)reply
I'm sorry, SD, you're just plain misinformed about where the money comes from. The way it works is the good wiki fairy comes along and waves her magic wand. That keeps the disks spinning and the bits flowing and enlightens repressive regimes around the world about freedom of information so we don't have to waste any effort defending our editors in court. It also makes hotel rooms and airline tickets drop from the sky so volunteers can get scholarships to wikimania. And as the wiki fairy walks along the beach, gold coins grow out of her footprints in the sand; these go to funding local affiliates to keep their education and outreach programs afloat.
All we need to do is join hands and think happy thoughts in a big group hug so the wiki fairy will come and save us. Until then, I'm willing to put up with a few banners. RoySmith(talk)17:26, 18 June 2026 (UTC)reply
Do we have any detail on this 77% figure? It's one I've not seen before, and I am really struggling to see where $150 million is being spent on volunteers this year. It feels much, much less. Certes (talk) 20:41, 17 June 2026 (UTC)reply
Thank you. That's interesting. I'm particularly heartened to see that the Annual Plan actually mentions Wikipedia – an improvement on the last one I read. It's always difficult to categorise spending. "Investment in Technology" (48%) includes issues such as management of scraper bots, which is a very welcome function but not one directly aimed at volunteers. Presumably it also covers developments such as Abstract Wikipedia which fewer volunteers might prioritise. We certainly appreciate the work of the community tech team which this item has funded in previous years. Certes (talk) 21:05, 17 June 2026 (UTC)reply
Presumably it also covers developments such as Abstract Wikipedia which fewer volunteers might prioritise., it does, I had written up a guide about the current annual plan to contextualize what is planned for next year. It's a bit out of date, but it should be relatively accurate and Abstract Wikipedia is a fairly small portion of the pie. A lot of WMF's current spending is on making it easier for intermediate editors learn to become competent editors, make readers stay around for longer and a chunk to help admins fight vandalism effectively (outside fighting scrapers itself and making sure we have high availability) Alongside that you have work being done to make Toolforge more user friendly and making existing APIs better so that folks can reuse content without taking down Wikipedia itself. Sohom (talk) 04:18, 18 June 2026 (UTC)reply
Most readers don't donate; only 2% do was previously rejected as "guilt tripping"
I also consider Wikipedia still can't be sold to be suggesting that Wikipedia's independence is under threat, although it isn't as blatant as previous examples.
I think people would also be frustrated by the fact they're seeing something several times in the first place. I can't guarantee how other people would perceive it, but more than three times feels like a lot, especially if the answer has been "sorry, no, don't have the money to spare" the first time. If I recall correctly (please tell me if I'm incorrect!) the banners also have a "maybe" option if you want to be reminded, so I don't think it's simply a matter of people that might actually want to be reminded. When I worked at McDonald's, we had lots of people who would donate to the Ronald McDonald house the first day or two of fundraising and then got quickly annoyed later on as we kept going throughout the week ("I already donated"; "no, I just want my coffee"). Clovermoss🍀(talk)01:08, 24 June 2026 (UTC)reply
No one is going to donate when prompted the first time, regardless of how much they have in the bank. The fundraising team gets it. Once someone has donated, I believe cookies are used to track it and they stop seeing the banners. – SD0001 (talk) 07:53, 24 June 2026 (UTC)reply
As I recall, it's been previously said that no association is made between donors and on-wiki user names or any session information for a given browser (linked via cookies or I suppose local browser storage). From a privacy perspective, personally I think this is sensible. isaacl (talk) 17:26, 24 June 2026 (UTC)reply
I support the banner ad program and the current language. It is a reasonable, unobtrusive, and voluntary option for meeting the organization's financial needs... ensuring that Wikipedia can persist long into the future as an independent source of information about the world. They tried letting the community run the ship on the fundraising a few years back and it imploded. Clearly this is not something that the "consensus" is equipped to handle. Ice Vest (talk) 22:57, 17 June 2026 (UTC)reply
Is no one else irked by We're sorry we've made several attempts to reach you? That's the kind of nagging tone that turns me off any appeal from a charity or non-profit if I get it in a phone call/voicemail or in the post. It sure feels like "guilt-tripping" to me. —In solidarity with Wiki Workers United · ClaudineChionh (she/her · talk · email) 23:00, 17 June 2026 (UTC)reply
But are they truly sorry? Wouldn't someone who was genuinely apologetic about having contacted me refrain from doing so again? Certes (talk) 11:11, 18 June 2026 (UTC)reply
I want to give some context about the phrase "protect Wikipedia's future;" the intent is not to suggest that Wikipedia's existence is in immediate danger or that any individual donation determines whether Wikipedia survives. In an era of falloffs in referral traffic and readership decline, protecting Wikipedia's future means ensuring that Wikipedia remains accessible, visible, and sustainable in a changing world.
I also recognize that people may interpret fundraising language differently – which this conversation shows. We value your input and will think of other ways to convey this point, and we'll share them back with you. Feedback on different interpretations is something we look at closely and frequently incorporate into banner language. Every year we workshop fundraising language with communities. You can see Fundraising/2025 banners for community-WMF banner discussions about last year's campaign. Next week, we will be publishing our regular collaboration on fundraising banner content at the Fundraising Hub. We welcome feedback on particular messages there, where we can get more in depth around wording and the considerations behind it.
@TurboSuperA+ Please clarify what you mean here. If you mean our executives, I don't think it is a unknown fact that some of our C-level executives might be millionaires through non-Wikipedia ventures/their former jobs, what matters is that they don't "run" the website. The community "runs" the website and makes content decisions. This is in contrast with Grokipedia where it's trillionare founder makes content decisions and "runs" the website. If you are talking about WMF the corporate entity, XAI, the corporate overlords of Grokipedia have assets that dwarf Wikimedia Foundation's corporate income by multiple billions. In fact, I'd say that the WMF is much much smaller than almost every org that serves "big-tech" numbers of users daily such that the WMF corporate budget in it's entirety would be considered a drop in the bucket for most big tech companies operating at our scale. I don't think it is out of touch to point either of these out and pitch this as a strength. Sohom (talk) 19:45, 18 July 2026 (UTC)reply
To be fair, the sentence says "run by a nonprofit", so it's clear what definition of "run" they're using. I agree with the rest, and in fact I'm skeptical whether any executive is a millionaire since the amount saved after you deduct everything from the $400k salaries is probably $100k and I'm on the "optimistic" side about their accumulation. (Jimbo probably does but even if we count him, he's the exception, and IIRC doesn't give that much input on WMF's operations. I could be wrong on this.) A lot would probably have a million by retirement but I don't think that counts because you need a million to retire. In solidarity, Aaron Liu (talk) 23:28, 18 July 2026 (UTC)reply
The CEO of the WMF, Bernadette Meehan, is a millionaire.
I don't think it is a unknown fact that some of our C-level executives might be millionaires through non-Wikipedia ventures/their former jobs
Well, there you go.
The community "runs" the website
Did I imagine all the threads where editors complain about WMF decisions? Aren't we in one such thread now? WMF can make decisions that affect the website without consulting editors.
and makes content decisions
The content is not the website, the technical infrastructue, or the organisation. Is the community ever consulted on what kind of servers Wikipedia should run, where it should be hosted, who to hire to do it...? TurboSuperA+[talk]04:52, 21 July 2026 (UTC)reply
I would imagine most people in the US who have held down a well-paying job for 10+ years are millionaires.And yes, lots of work is done by volunteers on the technical infrastructure. Phabricator and Gerrit are open forums where you can propose feature requests and implement them. – SD0001 (talk) 06:14, 21 July 2026 (UTC)reply
These banners that are asking for donations and making false claims about the website going bankrupt is "misleading and unacceptable" and is being used as a scare tactic to force editors to donate. These banners represent nothing but corporate greed and lies.
The platform's fundraising strategy faces considerable public and internal critique:
Substantial Reserves: Financial statements reveal the Wikimedia Foundation holds hundreds of millions of dollars in cash and investments, meaning it is not in danger of shutting down.
Aggressive Language: Critics, and even some veteran Wikipedia editors, argue that the banners misleadingly imply the site is on the verge of going offline if readers do not donate immediately.
Organizational Growth: A large portion of the budget goes toward expanding the Foundation’s bureaucratic footprint and funding adjacent non-profit grants rather than just maintaining the core website.
Hello @~2026-35699-89: could you share what you see in those banners? They should not imply bankruptcy is near.
Just so you know, the Foundation has stopped its grant programme for knowledge equity. Having reserves is a good thing given how tumultuous the world is now I'd say. In solidarity, —Femke (talk) 🐦 18:26, 18 June 2026 (UTC)reply
This is exactly what i saw: 18 June: Wikipedia still can't be sold
We're sorry we've made several attempts to reach you, but it's Thursday, 18 June, and we still need some help. If Wikipedia is useful to you, please take a minute to protect its future with a $2.75 donation today. Most readers don't donate; only 2% do. Wikipedia is run by a nonprofit, not by a billionaire. So if Wikipedia has given you $2.75 worth of knowledge, please give. Any contribution helps, whether it's $2.75 or $25. ~2026-35699-89 (talk) 05:43, 19 June 2026 (UTC)reply
Anyone who knows me will be well aware I won't hesitate to criticize the WMF when warranted, but I don't see anything there that states or implies imminent bankruptcy. SeraphimbladeTalk to me14:02, 25 June 2026 (UTC)reply
2nd Warning to the Wikimedia Foundation
These banners that are asking for donations and making false claims about the website going bankrupt is "misleading and unacceptable" and is being used as a scare tactic to force editors to donate. These banners represent nothing but corporate greed and lies.
The platform's fundraising strategy faces considerable public and internal critique:
Substantial Reserves: Financial statements reveal the Wikimedia Foundation holds hundreds of millions of dollars in cash and investments, meaning it is not in danger of shutting down.
Aggressive Language: Critics, and even some veteran Wikipedia editors, argue that the banners misleadingly imply the site is on the verge of going offline if readers do not donate immediately.
Organizational Growth: A large portion of the budget goes toward expanding the Foundation’s bureaucratic footprint and funding adjacent non-profit grants rather than just maintaining the core website.
another example: 1 July: Wikipedia still can't be sold
You deserve an explanation, so please don't skip this 1-minute read. It's Wednesday, July 1st and you only had a small chance of seeing my message. This year, Wikipedia has had fewer visitors and fewer new supporters, so your visit today means a lot. I hope that Wikipedia's given you at least $2.75 of knowledge recently. If everyone who found Wikipedia useful gave $2.75, we'd hit our goal in a few hours.
After nearly 25 years, Wikipedia is still the internet we were promised-created by people, not by machines. It's not perfect, but it's not here to push a point of view. It's run by a nonprofit, not a giant technology company or a billionare. (Lies)
Less than 2% of our readers donate. The rare few who give do so because Wikipedia provides them with useful knowledge. If that sounds like you, please donate $2.75. Any contribution you make today helps.
This is unacceptable. These banners are highly misleading, financially manipulative, and damaging to Wikipedia's reputation among the community. Thank you. ~2026-37878-87 (talk) 22:46, 1 July 2026 (UTC)reply
The truth: Substantial Reserves: Financial statements reveal the Wikimedia Foundation holds hundreds of millions of dollars in cash and investments, meaning it is not in danger of shutting down. Aggressive Language: Critics, and even some veteran Wikipedia editors, argue that the banners misleadingly imply the site is on the verge of going offline if readers do not donate immediately.
The Lie: 1 July: Wikipedia still can't be sold You deserve an explanation, so please don't skip this 1-minute read. It's Wednesday, July 1st and you only had a small chance of seeing my message. This year, Wikipedia has had fewer visitors and fewer new supporters, so your visit today means a lot. I hope that Wikipedia's given you at least $2.75 of knowledge recently. If everyone who found Wikipedia useful gave $2.75, we'd hit our goal in a few hours.
After nearly 25 years, Wikipedia is still the internet we were promised-created by people, not by machines. It's not perfect, but it's not here to push a point of view. It's run by a nonprofit, not a giant technology company or a billionare.
Less than 2% of our readers donate. The rare few who give do so because Wikipedia provides them with useful knowledge. If that sounds like you, please donate $2.75. Any contribution you make today helps. <(Corporate greed and lies) ~2026-37878-87 (talk) 22:59, 1 July 2026 (UTC)reply
I'm still not seeing where the lie is – can you be more specific instead of pasting in a LLM summation? If we break down every claim in what you call "The Lie":
Wikipedia still can't be sold – Y true
It's Wednesday, July 1st – Y true
This year, Wikipedia has had fewer visitors and fewer new supporters – I know readership is down, and wouldn't be surprised if the correlates to supporters, so gonna say Y true
After nearly 25 years, Wikipedia is still the internet we were promised-created by people, not by machines. – Y true
It's not perfect, – Y true – but it's not here to push a point of view. – Y true, though some people may subjectively disagree with that last point
It's run by a nonprofit, not a giant technology company or a billionare. – Y all true, WMF is a non-profit.
Less than 2% of our readers donate. – Y true
Any contribution you make today helps – Y I'm sure it does.
Again, where is the lie? Read the banner. And then read it again. Don't use an LLM to draft your response. You keep seeing something in the banner that is quite simple not there. In solidarity, nilnz04:04, 5 July 2026 (UTC)reply
Yesterday, I was planning to boldly close this thread as the OP had been indeffed, but then I found that there was a new recent comment, so I left this sub-section to be. In the case these TAs are just trolling us, shouldn't this thread be closed/hatted? - BlueEleephant (talk · contribs) 18:43, 5 July 2026 (UTC)reply
Just a passing comment. I do not object to the banners, for I think they will generate revenue. But they did make me laugh and shake my head because of some item I saw on the news, decades ago, before I threw away my TV. They were interviewing the wife of televangelist Jim Bakker, who at the time was a guest of the US government and could not be interviewed. They asked her why they kept saying that unless people donated to them their program would fail soon. She said: because that would generate more donations than anything else. So I laughed today, and will have no further comments here. Yesterday, all my dreams... (talk) 02:56, 19 July 2026 (UTC)reply
I also believe "to protect its future" violates the consensus against "banners that state or imply [...] Wikipedia's existence or independence is under threat or dependent on donations", largely because the latter verbiage is not qualified with "imminently" or "directly" or suchlike. Skimming through the previous RfC I think this lack of qualification is deliberate, as similar language was also objected to last time.
Despite coming down against them, I wish to express that I appreciate that it must be difficult on the WMF's part to craft fundraising language that explains why one might give without expressing the idea that it will allow Wikipedia to continue existing. Dingolover6969 (talk) 19:16, 4 August 2026 (UTC)reply
WMF CEO Bernadette Meehan shares her thoughts after meeting more than 1,100 Wikimedians
Bernadette Meehan joined the Wikimedia Foundation on January 20, 2026. As part of a community meet and greet (Around the Puzzle Globe), she asked volunteers these three questions:
A few things stood out to me. My overall impression is a little underwhelming: there are some interesting signals but nothing particularly concrete. She has clearly heard some of the community's most common complaints and concerns but there are no actionable solutions other than vague unmeasured platitudes.
Moving fast (and breaking things?)
Meehan writes that standing still is not an option, later saying nostalgia is not a strategy, and calls for bold thinking, faster experimentation and iteration, and difficult decisions. This seems to establish that the WMF is going to start moving quicker and pushing for change, while maintaining the underlying principles of the movement. There is, of course, often quite a gap between what the community thinks should change and what the WMF wants to change.
Declining readership
Meehan highlights an 8% year-on-year decline in pageviews across Wikimedia projects with declining referral traffic from search engines. She argues that Wikipedia must meet people where they are – on other platforms, in new formats, and through new partnerships. I'll be interested to see how Wikipedia adapts to this and how editors can be part of that adaptation. I do have concerns about how far the push towards apps, personalised feeds, video, and off-platform distribution might go and if the heart and soul of Wikipedia might be lost in a race to the bottom.
Community relations and changes
Meehan says that many volunteers asked for greater transparency and stronger communication, and that the Foundation needs to improve how it listens, communicates, collaborates. I don't reckon anyone will disagree with that.
The changes to the Community Wishlist are mentioned specifically:
Recent changes to the Foundation’s approach to the community wishlist prompted strong reactions and generated significant discussion. I take those conversations seriously. While the intent of the changes is to better meet volunteer needs by ensuring that multiple Foundation teams – not just one – share responsibility for addressing wishes, community feedback shows clearly that the Foundation must build a shared understanding of internal structural changes when they directly affect our communities.
The last sentence struck me as particularly unhelpful corporate speak. I think it means something like "when we reorganise something that affects volunteers, we need to explain what we have changed and why". The problem identified here seems to be that the Foundation did not establish a sufficient shared understanding of its internal changes, rather than that we had substantial objections to the changes themselves. I read this as "we need to communicate organisational changes better", which is not necessarily the same as "we need to reconsider changes when the community objects to them".
There is a similar point a bit later. Meehan says that disagreement is inevitable and the goal is not unanimous agreement, before asking how we can harness divergent ideas to move forward. I think that's reasonable as a general principle, but in the context of Foundation/community relations it raises the governance question of what happens when the Foundation believes a change is necessary and the community disagrees.
Artificial intelligence
Meehan says that 65% of the most resource-consuming traffic Wikimedia receives is coming from bots, with automated traffic placing increasing strain on Wikimedia's infrastructure and sometimes degrading the experience of human users.
There is also the problem of the contributor pipeline. People who no longer come to Wikipedia because they get our content through "zero-click" experiences are also less likely to stumble into editing and become contributors themselves. The Foundation appears to regard preserving this reader-to-contributor loop as a strategic issue. qcne(talk)11:23, 20 July 2026 (UTC)reply
Ever-increasing readership or even stable readership cannot be the goal. The goal should be to build the best possible encyclopedia. Anything else is a distraction to the project. What does standing still is not an option mean? Where exactly are we moving? Ita140188 (talk) 12:27, 20 July 2026 (UTC)reply
What does standing still is not an option mean? Where exactly are we moving? It means that standing still and fading into irrelevance is not an option. People contribute to Wikipedia because it is widely read. If it stops being widely read, the incentives to contribute fade away. Why would anyone want to build a knowledge base that isn't actively serving anyone? – SD0001 (talk) 09:22, 21 July 2026 (UTC)reply
I don't think that's true, or at least not fully true. Open culture generally works because contributors are scratching their own itch, and the contribution system makes it easy for that work to benefit other people. I'm biased because I tend to work on more esoteric topics, but when I write an article about something, I benefit by doing the work and clarifying my own thinking and understanding on the subject, and by having my work in a permanent repository, nicely hyperlinked, where I can look it up again with ease when my knowledge has faded a bit. That's not to say declining readership is harmless, but I don't think most of our editors are working with one eye on the page views meter. Choess (talk) 04:55, 25 July 2026 (UTC)reply
It seems no matter who occupies that job, they always sound the same, right down to the "if you disagree with a decision, it must mean we didn't explain it well enough." Levivich (talk) 14:48, 20 July 2026 (UTC)reply
Re: "Meehan says that many volunteers asked for greater transparency and stronger communication", picking one Wikimania and publishing exactly how much it cost and what was bought with that money would go a long way toward convincing me that she is serious about transparency.
(Please, people, don't reply with a link to a document that lists total expenditures for "Wikimanias, air conditioning upgrades, office supplies, consulting services and private jets")
For the many people who are not subscribed to the mailing list, important information was shared about board election "reform". From my perspective, it's incredibly concerning.
Seems like WMF is trying to strengthen the empirical evidence in favour of the Iron law of oligarchy conjecture: According to Michels, all organizations eventually come to be run by a leadership class who often function as paid administrators, executives, spokespersons, or political strategists for the organization. Far from being servants of the masses, Michels argues, this leadership class, rather than the organization's membership, will inevitably grow to dominate the organization's power structures. The conjecture has the word "law" in it, but that does not make it a sociological certainty.Or to put it more bluntly: the proposed set of criteria sounds like an oligarchical self-coup.There are already several excellent comments at m:Talk:Wikimedia Foundation elections/2027/Proposed eligibility criteria objecting to the self-coup. Boud (talk) 15:22, 21 July 2026 (UTC)reply
AFAIK this is mainly from one/two board members, it doesn't seem to have been socialised much, and they seemed receptive/good-faith in the Meta channel on WP:DISCORD. Anxiety about it is understandable though given how often community concerns get relegated/ignored re this type of thing Kowal2701 (talk, contribs) 20:12, 21 July 2026 (UTC)reply
I get the impression I also get chalked off and ignored as a 'WMF hater', which is frustrating and I'll probably leave the server. But this seemed to be a mistake based on one person's perspective (they mostly just edit plwiki), but at the very least they should have realised this'd poke the hornet's nest, "community-selected" members are meant to be in touch with the communities fgs, not up in ivory towers Kowal2701 (talk, contribs) 21:09, 21 July 2026 (UTC)reply
I have to be honest, at this point, I've given up on caring too much about the Board of Trustees, since I don't believe there's any real path to the community having a real voice anymore. The only two times the WMF appears to really care about what the community thinks about things is, in my view, when the community's view happens to correspond exactly with what the WMF board wants anyway and secondly, when the community is so mad that there's a real danger to day-to-day Wikipedia that might affect fundraising. Fretting about the WMF co-opting the movement are 2010 actions; it's already happened. CoffeeCrumbs (talk) 14:31, 22 July 2026 (UTC)reply
Sadly you're right. I've lost count of how many WMF-owned committees now claim control of our encyclopedia. However, there may be hope. Although the BoT was laid as yet more astroturf, it has somehow acquired a majority of community members. Although they were all WMF-approved, with candidates likely to effect actual change being carefully weeded out, this worm may still be able to turn. Certes (talk) 08:48, 23 July 2026 (UTC)reply
We've never tried developing a consensus platform (a list of board resolutions) and voting for candidates that pledge to vote for the platform. Levivich (talk) 14:58, 23 July 2026 (UTC)reply
Sohom Datta'smessage on the mailing list summarises the entire crux of the issue. One dosen't need to be an experienced 20-year veteran to see where the WMF is headed with its criteria for Board membership. It's therefore not surprising they've kept their token 'open' discussion very much inside baseball. IMO someone should at least ping all the signatories of the petition begun byuser:Clovermoss and the participants of all the other discussions about it. Kudpung กุดผึ้ง (talk) 08:03, 29 July 2026 (UTC)reply
Wikimedia Foundation Bulletin 2026 Issue 13
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on July 3. Please help translate. The work follows annual plan goals for this fiscal year (July 2026–June 2027).
Wikimania 2026: Wikimania is happening this week! After the event, all streamed sessions will be linked in the program on Eventyay and later uploaded to Commons.
Grantmaking: The Global Resource Distribution Committee has published a Grantmaking Strategy draft that sets out a renewed approach to how the Wikimedia Foundation's Community Fund is distributed across the Wikimedia Movement. The GRDC is requesting feedback from volunteers and affiliates, regardless of whether they are grantees or not.
Movement Ecosystem: A proposal that would update movement affiliate recognition and establish new, connected criteria for eligibility to receive Community Fund grants is now available for community review. You are invited to read the proposal and participate in the discussion until August 7.
Women+ contributions in Wikimedia Tech: A guide based on lived experience on how to address some of the invisible barriers for women+ in more technical Wikimedia spaces and recommendations to become more inclusive. Help further by filling out this survey to better understand technical contributions by women+ across Wikimedia projects until July 20.
Structured Experimentation: A reflection on the first year of structured experimentation highlights successful experiments such as Paste Check, Reference Check, and Tone Check, which improved editing outcomes and have been rolled out to more users, as well as experiments that did not lead to product changes.
Revise Tone test ended: The A/B test of Revise Tone ended on July 9. It showed that newcomer task completion rates increased by 38.7% compared to the default Copyedit task, with no decrease in edit quality. The feature is now available for everyone on the Arabic, English, French, and Portuguese Wikipedias. The plan is to release Revise Tone to more wikis.
Wikidata: The latest Wikidata Platform newsletter (July edition) shares how to identify and rewrite queries that rely on Blazegraph-specific extensions and affected by the migration off Blazegraph.
Discussion Tools: On English Wikipedia, DiscussionTools' Usability Improvements has now become default for talk pages. You can opt-out of these changes at any time in user preferences. With this, Discussion Tools are now fully available at all wikis.
Tech News: The latest highlights from Tech News week 28 and 29 include the new Parsoid parser continues to be deployed to additional wikis, making it easier to introduce new reading and editing features. See also the 72 community submitted tasks that were resolved over the last two weeks. Overall, from April – June 2026 about 337 community tasks were resolved by the Wikimedia Foundation.
Language inclusivity at Wikimania 2026: New approaches to translation and interpretation will be tested at Wikimania this year.
Call for submissions open for Wikimedia Latin America Conference 2026: The Wikimedia community in Latin America has opened the call for session proposals for the Wikimedia Latin America Conference 2026. Community members are invited to submit proposals for the conference program by August 10.
UK Online Safety Act: Ofcom, the United Kingdom's Office of Communications, announced that Wikipedia is not designated as a Category 1 service under the Online Safety Act (OSA). This is an important and welcomed outcome as a Category 1 designation could have included privacy and safety risks to our global community of volunteers.
UN Open Source Week edit-a-thon: Volunteers created 60 new Wikipedia articles and made nearly 700 updates to improve Wikipedia's coverage of UN and open source topics at the second UN Open Source Week edit-a-thon co-hosted by Wikimedia Foundation.
"Don’t Blink": The latest developments from around the world about protecting the Wikimedia model, its people and its values.
"A Wiki Minute" videos: New videos are added to the series answering some of the most common questions such as "Do you still need Wikipedia when AI can answer anything?" and "Does Wikipedia push a political agenda?".
Wikipedia 25 brand collaboration in Indonesia: On 4 July, the Jakarta-based street wear company Ageless Galaxy launched a Wikipedia 25 collection, the first ever Wikipedia Brand Collaboration in Asia. The apparel collection featured hats, t-shirts, and a jigsaw puzzle cardigan. Wikimedians in Indonesia joined Ageless Galaxy for a launch party.
Board Elections Eligibility: There are new proposed eligibility criteria for standing as a candidate in Wikimedia Foundation Board of Trustees election now available for feedback. The requirements are more specific and detailed than in years past, to both inform the community of what the Board needs and to create multiple pathways to the Board for Wikimedians.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. If you have feedback or suggestions about the bulletin, let us know at foundationbulletin@wikimedia.org. For questions about the Wikimedia Foundation's work, contact us!
Undermining WMF's relationship with the Wikimedia movement community
Abuse of power
Undermining the workplace culture at WMF
Avoiding accountability
Incompetence
Potential financial waste
Moreover, Wikifired states that s/he reached out to many of my colleagues at WMF and learned of many other instances of potentially problematic conduct by WMF management and HR. It was very disappointing to learn how widespread this is, and how there's apparently no accountability for it. ... And also stories that started with something like 'you think that's bad, here's what happened when I dissented or tried raising concerns about WMF management'. Stories where, in response to employees raising concerns in good faith, what they often heard back was 'if you don't like it, then leave' or 'you need to practice curiosity'.
To put it bluntly, Wikifired is asserting that something is rotten in the state of WMF leadership. Corporate waffling and "we can't talk about this for legal/privacy reasons" are unlikely to be accepted by the community as an adequate response. We don't need to know the identity(ies) of AL2 or any other WMF managers who have violated Wikimedia norms; we need their unethical behaviour to cease. Boud (talk) 17:14, 24 July 2026 (UTC)reply
They're not anonymous, the about me section makes it clear that this was an actual verified former employee of the foundation. This story is new to me, but unfortunately the underlying subject matter isn't. I've heard multiple horror stories with similar substance. The internal leadership at the WMF needs to change and be much healthier than it is. Clovermoss🍀(talk)19:48, 24 July 2026 (UTC)reply
Side point on anonymity: I agree that Wikifired seems to intend to be not too difficult to identify, but the LinkedIn link is closed access, and it's up to Wikifired or someone else to state his/her name explicitly if desired. I'm assuming that "Wikifired" is an acceptable pseudonym until then. Boud (talk) 20:28, 24 July 2026 (UTC)reply
I have a regular LinkedIn account and I could see it. I'm not saying go rake them over the coals, I just wanted to preemptively stop people from questioning whether they were actually a former employee. I'd hope the details are specific enough that people wouldn't but yeah. I'm fine with the pseudonym. Clovermoss🍀(talk)20:56, 24 July 2026 (UTC)reply
I think it is important to not identify Wikifired, even if they say it is OK. Knowing Wikifired's identity, it would be trivial to figure out the identity of "AL2", which would not only violate Wikipedia policy but would be morally and ethically wrong. --Guy Macon (talk) 21:30, 24 July 2026 (UTC)reply
I've heard severance in exchange for these non-dispargement clauses are quite common, and it's partly why I made such a big deal out of it in the sprawling discussion about the dissolution of CommTech weeks ago. Who knows how much money has been spent keeping people quiet. And when part of the WWU's stated aims is preventing inconsistent firing, one also wonders how many former employees truly believed the WMF lived up to its values and wouldn't suddenly find themselves without a job and in a financially precarious situation for trying to do something about this working environment. Clovermoss🍀(talk)21:43, 24 July 2026 (UTC)reply
I note there's no mention in that about the non-disparagement attached to the severance. Also, I've heard they recently silently changed it from "one month per year" to "up to one month per year", just before things like the Community Tech firing and the slashing of the states and countries they'll hire from. Anomie⚔18:20, 25 July 2026 (UTC)reply
"The Wikimedia Foundation is a remote-first organization with staff members including contractors based in 40+ countries.
Please note that we are currently able to hire in the following:
US States: Arizona, California, Colorado, Connecticut, District of Columbia*, Florida, Georgia, Idaho, Illinois, Indiana, Iowa, Maryland, Massachusetts, Michigan, Minnesota, Missouri, New Jersey, New Mexico, New York, North Carolina, Ohio, Oklahoma, Oregon, Pennsylvania, Puerto Rico*, Rhode Island, Tennessee, Texas, Utah, Vermont, Virginia, Washington, West Virginia, Wisconsin and Wyoming (*US Territory or Federal District)
Countries: Brazil, Canada, Colombia, France, Germany, Ghana, India, Indonesia, Italy, Kenya*, Mexico, Morocco, Netherlands, Poland, Singapore*, South Africa, Spain, Switzerland and the United Kingdom.
Thanks, Guy! Anybody got any guesses what these states have in common that the omitted states do not have? I can't discern a pattern. Montana doesn't have at-will employment but that's the only thing sticking out for me. The states listed include some of the states with the strictest employment laws, so it doesn't seem like that's the difference. Why would they hire in NC but not SC, for example? In Utah but not Mississippi? How odd. Levivich (talk) 22:12, 25 July 2026 (UTC)reply
the fact that only some EU countries are listed seems strange to me. Surely the rules are pretty similar between eu members. Bawolff (talk) 22:28, 25 July 2026 (UTC)reply
Also strange: The WMF will hire you if you simply live in Ghana, but in Kenya you have to be a citizen or permanent resident. Why? And why no country in Central America, Eastern Europe, or the Middle East? --Guy Macon (talk) 23:38, 25 July 2026 (UTC)reply
If I'm not misremembering, I recall hearing that Singapore had a law change recently cracking down on non-permanent-residents working remotely. Kenya may have similar restrictions. Anomie⚔00:59, 26 July 2026 (UTC)reply
Yes, there was indeed a recent change of that sort in Singapore. I can't speak to how that has affected Wikimedia staffing as I'm uncertain what is and isn't covered by my NDA. brooke (talk) 05:56, 26 July 2026 (UTC)reply
It may be as simple as "WMF currently has things set up to withhold state taxes in these states, and they're refusing to add any more to that list". Anomie⚔00:54, 26 July 2026 (UTC)reply
When this was discussed before, it was explained with the fact that WMF needs to provide healthcare benefits across the state lines and that's not easy or cheap if the company has to do it separately in all 50 states. Don't know how valid this explanation is, just what I've heard from WMF-related people. stjn05:17, 26 July 2026 (UTC)reply
Note that while I was working in Oregon, I received my WMF health insurance as a Blue Shield of California "out-of-state" plan. I don't know the details of how this works on the internal/HR end and whether there's anything particularly difficult to adding more states. brooke (talk) 05:59, 26 July 2026 (UTC)reply
I have a problem with like 98% of things the WMF does, but this isn't really one of them. This is bog standard in situation where there's no requirement for severance (outside of a labor agreement, a contract, or a company policy). Now, there are exceptions when it comes to enforcement, in both federal and California law, (for example, abuse and harassment under federal law and illegal company actions in California). But non-disparagement clauses themselves are not unusual when the a company pays in severance agreements. CoffeeCrumbs (talk) 11:42, 25 July 2026 (UTC)reply
Just because it's normal for American companies doesn't make it right. Where I live, you cannot make severance conditional upon signing an NDA. If you qualify for it, you get it, and that's that. I think there's some serious human rights issues to this norm. Clovermoss🍀(talk)12:07, 25 July 2026 (UTC)reply
When NDA stifles criticism of the WMF afterwards, as I know is the case, it is not normal or acceptable, even if it is a standard practice elsewhere. We should be better than for-profit companies on this. It should be imperative for the WMF to disavow the parts of the NDA that currently prohibit employees to tell their stories like the one above or criticise various wasteful initiatives. stjn12:54, 25 July 2026 (UTC)reply
Coffee is right in that non-disparagement clauses are "bog standard" for severance agreements, in the US but not only, also in other countries (but not everywhere), and not just in the for-profit sector, but also in the non-profit sector.
At the same time, I'm quite persuaded by Clover and stjn's point that just because something is standard doesn't mean it's right, or moral, or that the WMF should follow the crowd.
It is very possible for the WMF to not require non-disparagement clauses in severance agreements (while still receiving consideration that makes the severance agreement legally enforceable).
It is also very possible for us, the community, to force the WMF to stop using non-disparagement clauses. It's the thing I keep harping about that very few of us seem to care about: we control a majority of the Board! That means we can set WMF policy!
All it takes is one Board resolution to get rid of non-disparagement clauses in severance agreements:
Board Resolution No. 1: RESOLVED, that the Wikimedia Foundation shall not include non-disparagement clauses in severance agreements.
That's it, that's all it takes. If the Board passed that, the WMF would be required to comply.
There are currently 6 elected Trustees and 4 appointed Trustees (the max under the bylaws is 8-7). The elected Trustees, by design, are a majority of the Board.
If the Trustees we elected won't support that Resolution, then we should elect Trustees who will, and keep electing them until that Resolution is passed. It might take two three-year cycles to get the right Trustees on the Board.
We could repeat this process for everything we want to change.
The current Trustees and Officers know this, and that's why they're "vetting" candidates and now trying to limit candidate "qualifications."
If they take away the community's control of the Board before the community uses that control to push through reforms, well, then we will have lost control, forever.
I was reminded today that while WMF caps everyone else at 9 months of severance -- 1 month per year worked, so only a 9-year+ vet gets 9 months -- Katherine Maher got 18 months severance ($600k). 18 months isn't unusual for a CEO in the U.S., but it's just another example of how WMF acts the same as any other large international corporation, with executives treating themselves way better than everyone else. Levivich (talk) 15:51, 1 August 2026 (UTC)reply
Given this public record by several different people of misbehaviour and attempts to hide that misbehaviour by WMF management, this raises the credible hypothesis that the real reason for the removal, just two days before the Oct 2025 WMF Board election, of Bluerasberry as a candidate in the election was that WMF leadership refused to accept having a Board member who is opposed to misconduct: excerpt from Bluerasberry's June 2021 statement: "There is an unacceptably high rate of Wikimedia Foundation staff and consultant misconduct in the Wikimedia Movement. Where money is involved, there are paid Wikimedia Foundation representatives who violate the meta:Universal Code of Conduct and stifle free discussion about the regularity of this problem."Boud (talk) 08:54, 25 July 2026 (UTC)reply
To me, the way AL2 portrayed the critical community member came across as very negative. It created the impression that the critical community member was a bad, hostile person with negative intentions towards WMF.
Likely what happened is that WMF was offering compensation for the amendment of the NDA to include such a clause and it's just being described strangely. Jerod Lycett (talk) 01:06, 26 July 2026 (UTC)reply
Wikimedia has a boilerplate separation agreement, into which they drop the specific amount of severance offered for individual cases. The agreement includes both a non-disparagement clause and a non-disclosure clause.
I can't speak about the actual details of the agreement, however, due to the agreement.
Note that Wikimedia considers severance to be "optional" in exchange for agreeing to the conditions of the separation agreement; in some countries severance is in fact a legal right and may have a minimum amount, which has lead to occasionally spicy times when someone is let go outside the US. brooke (talk) 06:07, 26 July 2026 (UTC)reply
I'll note that I also brought this up at Jimmy's talk page if anyone wishes to read that discussion. He hasn't said anything yet, but he's probably the most reachable board member when it comes to likelihood of responding to queries on-wiki. Clovermoss🍀(talk)08:15, 26 July 2026 (UTC)reply
If there are similar stories from former (or even current) WMF employees, hopefully some news outlets will pick up on this. Some1 (talk) 15:59, 26 July 2026 (UTC)reply
Noteworthy quote from the article: And don’t even get me started on WMF leadership’s hilariously frequent use of “practice curiosity” in response to employees questioning the ethics of WMF leadership’s conduct.Some1 (talk) 16:36, 26 July 2026 (UTC)reply
Recent questions about the Foundation and US unionization request
Hi All, I am posting this on behalf of The Wikimedia Foundation as the Chief People Officer. During Wikimania last week, we received several questions about Wikimedia Foundation staff unionization. Most questions focused on the recent request from the Communication Workers of America (CWA), affiliated with the American Federation of Labor and Congress of Industrial Organizations (AFL-CIO), to voluntarily recognize it as the exclusive collective bargaining representative for eligible US-based staff. We sent a message to staff and posted a statement on the Foundation website to openly answer questions we have been receiving. You can read more in our statement and the FAQ that was posted here.
What a shameful decision to tie the process to the willingness of Trump-controlled NLRB. Everyone involved in denying the voluntary recognition should resign in disgrace or be driven out. I have absolutely zero faith that @BMeehan-WMF didn't just tell a bald-faced lie when she refused to address the question at Wikimania by saying that they're just too focused on the conference. We are ruled by lying politicians, and not even the ones that are particularly good at lying. A sad day for the Wikimedia movement. stjn16:19, 27 July 2026 (UTC)reply
CBasssherizen-WMF, be assured that the community of editors -- even those of us who have deep disagreements with some of the things that the WMF does -- will not tolerate abuse of individual WMF staff. I am so sorry that you had to read that. My personal view is that there are no individuals that we can point to and blame but rather that we are looking at an institutional priorities that have persisted through multiple changes of WMF leadership. --Guy Macon (talk) 16:59, 27 July 2026 (UTC)reply
People are referring to what executives said at wikimania during the fireside chat, that they wouldn't say anything until Monday because they were busy. I think it's perfectly reasonable to suggest that they made this decision to avoid backlash at the conference itself. Clovermoss🍀(talk)17:08, 27 July 2026 (UTC)reply
Wow, calm down. To write such a big comment (and post a warning on my talk page) you should be aware of the context, but I see you're not, go read my comment again. Nemoralis (talk) 17:16, 27 July 2026 (UTC)reply
They were explicitly asked about voluntary recognition and said they didn't have anything to say until Monday because of Wikimania. I refuse to believe that this post was agreed upon in less than a day. I think Bernadette should've bravely said they won't agree to it and got some well-deserved boos. Instead, she didn't tell the truth. The exchange happens here.stjn17:21, 27 July 2026 (UTC)reply
If there's gonna be sanctions over stjn's -- or Nemoralis -- words, then you better be ready to sanction me too. I agree with every word they both said. ⇒SWATJesterShoot Blues, Tell VileRat!17:31, 27 July 2026 (UTC)reply
I don't owe you, or anyone else, "evidence" that I agree with an opinion *someone else* expressed. If you want to pick a fight with someone, Guy, I'm not the one -- WP:AGF is not optional, and that's *twice* in this thread that you've gone off half-cocked at something while being wrong about who wrote it. Do it a third time, and you're not gonna like the consequences. ⇒SWATJesterShoot Blues, Tell VileRat! —Preceding undated comment added 17:55, 27 July 2026 (UTC)reply
[Redacted to avoid further drama] I repeat; WMF employees are not your personal punching bag. Argue with what is said. Don't insult the one who said it. --Guy Macon (talk) 14:41, 28 July 2026 (UTC)reply
I think there's a difference between treating employees as a punching bag (clearly wrong) and suggesting that the chief executive might have mislead her audience (or [told] a bald-faced lie) when she was talking on a contentious issue.
I completely understand your position about defending WMF staff from unwarranted attacks — and I broadly agree. But criticising the chief exec of an organisation for public comments she made that, in hindsight, could appear not to have been in good faith is perfectly legitimate commentary and describing that as a lie is not unusual. I would suggest that you might want to back away from dying on this hill. — OwenBlacker (he/him; Talk). I support Wiki Workers United15:15, 28 July 2026 (UTC)reply
But it's OK for community members to be their own personal punching bags? I look forward to you keeping the same energy for this: When AL2 was saying that we should not build publicly open tools that show the impact of WMF’s grant funding because of potential scrutiny and criticism of WMF by Wikimedia movement community members, she singled out and named a specific critical Wikimedia movement community member as an example. To me, the way AL2 portrayed the critical community member came across as very negative. It created the impression that the critical community member was a bad, hostile person with negative intentions towards WMF. My manager did not object to or question AL2 doing this to a community member. She appeared to be in agreement with how AL2 treated that person.Gnomingstuff (talk) 18:46, 28 July 2026 (UTC)reply
I'm not sure whether you're talking to me or not, but I'm quoting a blog post from a former Wikimedia employee. I don't know what I could possibly be accusing you of. Gnomingstuff (talk) 05:40, 30 July 2026 (UTC)reply
(Off-topic) Thank you for clarifying to Gnomingstuff what happened. (I will say that the confusion ended up being helpful to me as I didn't notice Guy Macon's changes until now.) --Super Goku V (talk) 09:28, 31 July 2026 (UTC)reply
This is an extremely disappointing statement. It says that Foundation leadership respects the right of staff to unionize, if they choose to do so. That decision rests with them. But that decision has been made - by a supermajority of US-based staff. The only thing standing between the US WWU and recognition is WMF executive leadership, who could recognize the union today if they cared to.
Editors less familiar with union organizing may be wondering what is wrong with holding a secret ballot on the question. After all, that certainly sounds perfectly fair and right, and, if a supermajority has signed union cards, surely a supermajority will vote yes to the union? Certainly, I would expect them to, if that ballot was held today. But the ballot is not today. It will be later - months later - even if the NLRB does not itself add more roadblocks to the process. And the WMF can spend the intervening months pressuring and propagandizing employees. You can already spot some examples of the standard anti-union playbook in their FAQ. I particularly like Our goal is to ensure that everyone can make their own decision in an informed and civil environment. This is an old standard ("informed" is code for "'educated' on the 'dangers' and 'risks' of joining a union", and I expect you can figure out what that in turn is code for), and it rings even more hollow than usual, given that a significant driver of WMF staff dissatisfaction is related to information issues: employees feel that a) they are insufficiently informed, b) they are instructed not to inform us of things they believe we should be informed of, and c) when they inform upper management of issues, they face retaliation.
You can see another example of how this rhetoric works in the section, "How has leadership historically responded to concerns raised directly to leaders by staff?" I'll quote it in full:
We have a record of listening carefully to the concerns raised by staff and have implemented several changes based on staff feedback to strengthen their experience. We have taken steps to improve communication and transparency, including more opportunities for staff to engage directly with leadership and more regular updates about the organization’s direction. We are committed to improving and are continuing to strengthen how we gather feedback and how we act on it. That said, we recognize that if the CWA becomes staffs’ exclusive representative for purposes of collective bargaining, we will have a legal responsibility to avoid dealing directly with staff on their pay, benefits, and other terms and conditions of employment.
I have not added "citation needed" templates to various points in the first two sentences, but that hurt my Wikipedian soul a bit. For the rest: if they're committed to improving, what's wrong with doing so alongside the unionization efforts? And notice how the final sentence - which expresses a core purpose of a union - has been framed to suggest this is a bad thing? Dealing with staff directly on their conditions of employment means the employer can take a divide-and-conquer stance and keep employees in the dark about what other employees are receiving. It means a state of "every employee for themselves". It means employment can be terminated, as we saw with commtech, with little forewarning and and seriously poor planning. This is not good for the employees, it is not good for the volunteer communities they serve, and, frankly, it's not good for the WMF either. But now they have plenty of time to try to let this kind of misdirection marinate.
I don't have anything to add that asilvering hasn't already said. This is an incredibly disappointing statement and that FAQ at the bottom might as well have been pulled directly from a Union-Busting 101 handbook, it's all the same rhetoric I've seen 100 times before. --Grnrchst (talk) 17:21, 27 July 2026 (UTC)reply
As I said way back when the CommTech dissolution happened, they sound exactly like Amazon does here. I'm tremendously disappointed that Wikimedia Foundation executives are not acting within the spirit of the movement itself. Clovermoss🍀(talk)17:24, 27 July 2026 (UTC)reply
+1 to this, as I stated to Bernadette Meehan at the fireside chat, their actions are not matching their words, and actions are important. I'd have respected Bernadette more if she directly said she opposed unionization. I'd have been very disappointed in WMF, but I'd have given her credit for not using corporate doublespeak to obscure their anti-union views. Abzeronow (talk) 00:38, 28 July 2026 (UTC)reply
Major own goal here by WMF management. Shameful indeed!
As a U.S. trained labor lawyer and past organizer with WWU, this statement, alongside the WMF’s public facing community post reek of union-busting disinformation. What’s critical for the community to know is that a supermajority of the workers already did vote by signing a card. This “extra step” is just a delay tactic that employers are advised to do when they don’t want a union. They are doing the same thing in the UK as well.
These WMF workers have already been extremely brave by expressly affirming their commitment to a union. Years of efforts to get this accomplished. This is not some rash decision by them. Moreover, the community supports their union too! It literally makes no sense as to why WMF thought this was the right decision here in this critical moment.
Finally, as a general reminder of the lack of good faith that was demonstrated by WMF here, there was a legal process for WMF, offered by the union, that intentionally avoided delay and going through the Trump administration. It is a very well-trodden path which includes a third-party arbitration process to verify the integrity of the signed members. Again, I believe this demonstrates a willful attempt to ignore the supermajority of their workers’ desires and, worse, causes a further erosion of trust and goodwill between WMF management and their staff going forward. Jbernick98 (talk) 17:55, 27 July 2026 (UTC)reply
As stated, the decision to unionize belongs to staff.– Correct, and a supermajority of staff have already made the decision to unionize. It's simple, any unnecessary delays in recognizing this fact are nakedly anti-union. fifteenthousandtwohundredtwentyfour(talk) 21:08, 27 July 2026 (UTC)reply
I agree with the essentially unanimous criticism here. I look forward to hearing next steps from the WWU and to doing whatever in my power I can to help oust the WMF’s existing leadership. signed, Rosguilltalk21:15, 27 July 2026 (UTC)reply
The WMF and its CEO, BMeehan-WMF, (who served under Biden and Trump administrations), are well aware that Trump cut funding for the National Labor Relations Board, which causes several months of undue bureaucratic delay pending a supervised vote.
At best, the WMF believes that a majority of its US staff are lying when they sign union cards and wants additional verification. At worst, the WMF knows that a majority of its staff have signed union cards and hopes that, over the upcoming months, pro-union staff will vote against in a desperate bid to make this stressful situation go away. Communication Workers of America, the union representing US WWU staff, has a union-election success rate of 80%, above average for private-sector unions. They are serious about winning and have dealt with employers far worse than Wikimedia, so even with NLRB elections, there is good reason to be optimistic, but it is clear we cannot be complacent. Source
This is a common tactic in union-busting campaigns. According to labour sociologist Joshua Mayor, unionization efforts sometimes fail not because workers are against unions, but because they do not believe they can win. Source.
Between now and the yet-to-be-scheduled NLRB-supervised election, there is time for WMF to do the right thing and recognize the will of the majority of its staff voluntarily. WMF is supposed to be better than the average tech company, and largely is, but right now it is behaving worse than Microsoft when it comes to labour rights.
As a long time donor and editor, this an outrage. The work that these folks do is vital to the world. They deserve the opportunity to collectively bargain for a fairer workplace.
This is incredibly disappointing to see, especially when conditions that may seem "generous" in the US are below legal minimums in most of the Global North.
Good employers who value their employees have nothing to fear from unionisation. The way the Foundation is responding to a good-faith unionisation that is supported by a supermajority of US staff is not how a good employer behaves — and when the Foundation publishes this statement the day after Wikimania, it is hard to see how @BMeehan-WMF's comments at Wikimania could be anything other than misleading delaying tactics. (And the sophistry around UK unionisation efforts is not much better, given that the WMF is the "effective employer", even if it is handled through a "company of record".) Assuming good faith is all good and well, but it does come to a point where repeated assumption of good faith is merely naïveté.
This is profoundly disappointing and yet another example of the Foundation leadership being out of touch with the Movement. We should be able to expect better from the Wikimedia Foundation and its leadership. Frankly, it is not good enough. — OwenBlacker (he/him; Talk). I support Wiki Workers United14:04, 28 July 2026 (UTC)reply
I fully agree with Asilvering. I hope that nobody mistakes my objection to personally attacking the WMF staffer who wrote the message with in any way agreeing with the message itself. In my opinion, this is the same old story that has been going on for decades: The WMF long ago gathered enough money to keep Wikipedia running on the interest without any further fundraising banners or accepting large donations from corporations as if there were no strings attached. They continue moneygrubbing for the purposes of -- well, we don't really know, do we? It's a huge secret where, exactly, the money is being spent other than the minimum disclosure required by law. --Guy Macon (talk) 17:56, 27 July 2026 (UTC)reply
Today was a day to show trust in staff. Because trust is what we will need in the years ahead, which are likely going to be as chaotic as the last couple of years if not more so. The framing in this letter does not convince me the Foundation leadership is neutral in this matter. A small example: rather than acknowledging the WWU effort to build a global union (or network of bargaining units), the text focuses on the CWA, which cannot represent global staff, seemingly to diminish international support: It is important to note that the CWA is only seeking to represent a portion of US-based staff, and there is no global union option due to different labor laws across countries and jurisdictions. Also note how the text emphasises the 'portion of', which is technically correct as US labour law exclude managers, but downplays the role of the union in representing most workers. The FAQ emphases what leadership calls 'good working conditions'. The listing of benefits tries to convince staff that all is well and that unions might not be necessary. What the text fails to mention is that these are not contractual and can be changed unilaterally. In tumultuous times, we need staff that has the security of actual 'secondary labour conditions' as we call them in the Netherlands. The 'benefits' are especially questionable when the "generous" 15-day holiday allowance would be illegal in every single EU country. Today was a day to show trust in staff. Instead, we've started a rough road of persuasion and spin. Fortunately, as a movement, we are exceptionally well trained to recognise this. I'm confident staff will prevail. In solidarity, —Femke (talk) 🐦 21:02, 27 July 2026 (UTC)reply
So where's the petition to have the Board pass a resolution requiring the WMF to voluntarily recognize unions that receive supermajority employee support? Levivich (talk) 23:12, 27 July 2026 (UTC)reply
How likely is it that this third (!) petition will accomplish anything? Hard to imagine that the Board of Trustees will (publicly or not) disagree with their CEO and "instruct the CEO to voluntarily recognize the union"... but who knows, I guess. Some1 (talk) 01:47, 28 July 2026 (UTC)reply
Petition fatigue is a real concern. This 3rd petition is newly directed at the BoT who till now did not feel obligated to "interfere" or state anything till now. Prior petitions were directed at editor community and the Foundation. ~ In solidarity 🦝 Shushugah(talk) 10:47, 28 July 2026 (UTC)reply
The Wikimedia Foundation’s statement and its frequently asked questions section is full of very carefully-worded language that is common among companies and organizations that have fought against unionization. For example, the FAQ includes a long section about the benefits that Wikimedia Foundation already offers its staff, and the statement suggests that there is a “wide range of views on unionization” among employees.
This statement is very disappointing. You try to portray the union as some outside force separate from the foundation workers, when the union is made up of WMF workers, and already has the support of a supermajority of eligible workers. You are not a corporation. Your responsibility is to the community, not to shareholders. 1something (talk) 01:41, 28 July 2026 (UTC)reply
Of course the foundation is a corporation. They are a 501(c)(3). Note that our article on the subject starts with A 501(c)(3) organization is a United States corporation. Their corporate structure and goals may be different from a for-profit publicly traded company, but they're still a corporation. As for "Your responsibility is to the community", that's not true either. The community and the foundation are both responsible to the project. Neither is subservient to the other. Both are equal partners working to advance a common cause. We really need to get away from the us-vs-them mentality. RoySmith(talk)12:02, 28 July 2026 (UTC)reply
I think the us vs them mentality is a reaction to an already adversial relationship. Consistently taking actions that anger the community is not a neutral stance and that's not the way to treat people you consider to be partners in your shared endeavour. Clovermoss🍀(talk)12:08, 28 July 2026 (UTC)reply
WP:AGF applies. Lots of decisions get made every day. You're not going to agree with every one of them (I certainly don't). But I can say the same about Arbcom. People like me and you have the advantage that we're not legally obligated to uphold our fiduciary responsibility to manage a lot of money, or to comply with labor laws in multiple countries, or sign our names to corporate filings, so it's easy to take pot-shots at the people who do. If we screw up, the worst that can happen is we get trouted or banned. If WMF folks (at least at a high-enough level) screw up badly enough, they can go to jail. RoySmith(talk)13:50, 28 July 2026 (UTC)reply
Fidicuary responsibility does not require people to take these actions. I'm not taking potshots at people, I'm telling them to do the bare minimum. Clovermoss🍀(talk)14:04, 28 July 2026 (UTC)reply
WMF has twice decided to take up the slowest option to delay having to deal with a union, they could have voluntarily recognized in the UK and in the US, and chose not to. WMF cannot claim to support labor rights and take actions that we'd expect Amazon to do. WMF is choosing this path, their relationship with a union does not have to be antagonistic but yet again as we've seen in the past few years, WMF acts like it's their way or the highway. Abzeronow (talk) 14:27, 28 July 2026 (UTC)reply
There is nothing about voluntary recognition option that could make anyone go to jail. See Labor unions in the United States#Labor unions in the 21st century. Presenting it as such is exactly why the disingenuous comments are being made by the executives. They refused to agree to a union because fundamentally they are anti-Union. Even if the CEO says that she was a union member for 13 years. stjn17:31, 28 July 2026 (UTC)reply
That's a rather ... unique ... interpretation of the (true) statement "If we screw up, the worst that can happen is we get trouted or banned. If WMF folks (at least at a high-enough level) screw up badly enough, they can go to jail." --Guy Macon (talk) 17:48, 28 July 2026 (UTC)reply
As best I can tell, nobody at the WMF is claiming that there are legal impediments to, or risks from, voluntary recognition (as distinct from an NLRB vote, which they've said they would honor), so that's really a non sequitur. In any event, editors actually do face legal and extralegal risks that are quite real. —Emufarmers(T/C)19:33, 1 August 2026 (UTC)reply
Wikipedians can go to jail for Wikipedia editing aswell. We have colleagues in the Middle East currently in this situation. I have also had legal proceeding launched against me for editing here... Doc James (talk · contribs · email) 00:45, 3 August 2026 (UTC)reply
In addition to all the good arguments given above, I’m concerned and a bit disappointed by the way this has been communicated: just few days after Wikimania, where the world convened into Paris to discuss and share about the Wikimedia project*s* (and not only the English-speaking ones), and where some talks were had about WWU and its recognition, with a lot of attendees showing WWU badges and pins, showing that the international communities do care about this matter… and yet it seems that the only official notice has been given here… Let’s say that I’ll try to continue to assume good faith also about the messaging, but I also hope that the next developments would be shared with a large part of the Wikimedia communities! Sukkoria (talk) 21:40, 29 July 2026 (UTC)reply
+1. En-wp is not the only Wikimedia project; WMF should communicate this information on other projects where WWU has been discussed as well. — Jules*talk08:56, 30 July 2026 (UTC)reply
Opting for a lengthy NLRB process is a choice to enable time for an in-house campaign against unionization. Employers can respect majority opinion of staff by opting for card-check unionization instead. In many international organizations with existing unions in more labor-friendly places than the US, this is exactly the behavior demanded by unions that represent other workers. And that is exactly what we should insist WMF do in this case.--Carwil (talk) 12:48, 3 August 2026 (UTC)reply
WMF should recognize, but this is a calculated gamble for Wikipedia
Pardon the new section; I wasn't sure where to put this, and it's been weighing on me.
I'm going to make an argument because I haven't seen anyone make it.
Let me first say that, given a supermajority of eligible US workers have supported unionization, I hope they're successful and agree it should be recognized. I've had union jobs myself and have heard enough stories from then-current or former staff over the years to buy that there are issues with management that a union would help to resolve. But we should be angry, or sad, that it got to this point, because what I'm not persuaded of is that a WMF union is definitely good for Wikipedia.
There's no great data about the relationship between unionization and the quality of outputs. Some studies with decidedly mixed results and a ton of anecdata. My sense is that most of the time, stable unions don't have much of an effect on outputs and in some cases may help. Strikes, however, are obviously very bad for outputs, as are pronounced episodes of labor unrest/conflict (another argument for voluntary recognition IMO). Elsewhere, that might mean more defective tires or mislabeled cans that harm consumers and eventually harm profits, which harms the executives. Here, executives might lose a labor conflict in the end, too, but Wikipedia is the product in the balance and the stakeholders are readers and editors. It's for these reasons that I'm ambivalent about a union in an organization like this one, because the source of the union's power is less its ability to hurt executives or shareholders and more its ability to hurt a public good.
A union often means more rules for who can do what, with unclear implications for boundaries between staff and community as concerns our technical infrastructure. What work protections might a hypothetical future bargaining unit put in place that restricts what volunteers can have access to? Is it hard to imagine some future grievance about volunteers working on gadgets that were the focus of laid-off staff members? Is it hard to imagine a worker strike that renders a range of volunteer maintenance tasks effectively struck, too?
Having a union means adding yet another stakeholder to decision-making processes. The union's ambition is to have a say not just in wages, hours, and working conditions, but also in strategy/annual planning, and indeed I've heard supporters mark that as a major reason for their support. Putting aside that formal say in strategy feels like an unrealistic ask, why would we assume that a union run by some future unknown staff would be acting in the way we want (sufficient for a large portion of this community to pledge its own labor to an organization that has no reciprocal obligation)? For those of us whose Wikipedia priorities are independent of the WMF, is there nobody else who finds this scary?
To read these threads about the union (to the exclusion of many, many other past threads on this board) one might get the impression the community believes every WMF staff member is a Brooke Vibber or a Community Tech team member, with long connections to the community and in tune with our needs/interests. I broadly have a favorable view of WMF staff, who are mostly good, mission-driven people, and agree with a likely response to this: that there have been several times when staff members have spoken up when a bad idea was being implemented (Superprotect, Knowledge Engine, etc.). I also would concede that my work protections hypothetical above is unrealistic among current staff because they get the mission. But who's to say who future staff will be? "In tune with the editing community" is already not descriptive of most staff, well-intentioned though they may be. We have also heard from many staff that the enwiki community in particular is rather more like a thorn in their side (again, see most past threads in the archives of this board for examples). Why would we assume that, in a decision-making conflict, the community-minded staff would win the day over those who aren't, or that the union would always take the community's side? Why would we assume that the currently most vocal proponents among staff, who indeed are aligned with us, are representative of who will be running the union 10-20 years down the line? And what can be done to codify these obligations, if they're so baked into broad community support? (I don't know if that would be a smart thing, to be clear, as it feels like a desire to govern indirectly through on-wiki !votes, but if that's the promise people are banking on, how will it be enforced?)
If others have these worries, I haven't heard them expressed. It would make me feel better (and possibly others) to see that others are thinking about this, too, and that the outpouring of support for a big, blunt instrument isn't just a cascade in response to a recent instance of injustice. I feel like it would be helpful to articulate that it's fundamentally a calculated gamble -- that a union might in fact be a bad thing for Wikipedia in the long run, but that the median prediction for a WMF future with a union looks better than a median prediction for a WMF future in which management continues as-is. And that for those who aren't scared at all, it's less a belief that unions are always good for everybody and more that WMF management has, over the years, convinced so many people of its disconnect from this community that hundreds are desperate enough to cling onto any prospective entity that holds more power with the WMF than we've ever had. That feels more sad than exciting to me, regardless of the outcome, and if it's accurate it's worth sitting with that sadness and acknowledging the gamble. But here we are. —Rhododendritestalk \\ 17:46, 28 July 2026 (UTC)reply
Thanks for the thoughtful post. To my way of thinking, the main difference is this: If the employees at Goodyear stop working no tires get made. If the employees at America Red Cross stop working a lot of people won't get the help they need. If the employees at the Wikimedia foundation stop working, the effect on Wikipedia will be pretty much zero. There are a few exceptions -- core tasks that must be done. Examples include running backups on the servers, paying bills, having lawyers respond if someone sues, and even checking that the fire extinguishers at HQ follow the legally mandated service schedule. I would be very surprised if any strike didn't have exceptions for those few vital functions, and even if they didn't, the WMF would be perfectly justified to hire temporary replacement workers.
(@Guy) the effect on Wikipedia will be pretty much zero Two responses to this: first, if they matter so little to Wikipedia, what difference does it make to Wikipedia if they unionize? Solely operating in the domain of "nice to haves" rather than "need to haves" doesn't seem like it would foment such parallel collective action on-wiki. But second (and much more importantly), I'd just strongly disagree with that premise. To be clear, yes, they need us more than we need them -- not disagreeing with that. The product that brings in donations is primarily the product of volunteer labor. But staff maintain toolforge and cloud services, they review community-requested config changes and patches, they respond to outages and mitigate DDoSes, they respond to trust & safety threats of harm and child safety, they handle non-emergency T&S business like harassment, they handle DMCA takedowns and subpoenas on fixed deadlines, they have to follow a litigation calendar, they disburse grant funds to affiliates and event organizers who have their own non-unionized staff not to mention bills to pay, the stream of data dumps and database updates and analytics get outdated, we fall behind in security patches, there's all the boring hardware maintenance... and all that is putting aside addressing any issues with the fundraising pipeline, which I suspect would not be persuasive.:) —Rhododendritestalk \\ 18:33, 28 July 2026 (UTC)reply
This question pivots between the disruptiveness of a potential strike or not. Even in the cases of schools or hospitals, where a strike would be incredibly disruptive AND harmful to communities, they still happen, with responsible caution. For example, nurses will still show up for life-saving emergency shifts. In the case of schools, it is less dramatic, but still detrimental for youth education. A framework to bridge this gap is the bargaining for the common-good, which is alluded to in Wiki Worker's United listed priorities. ~ In solidarity 🦝 Shushugah(talk) 18:23, 28 July 2026 (UTC)reply
Thanks for the link. And yes, that's relevant to what I'm talking about. I'll be curious to see what kind of ~"emergency provisions" WWU would codify that ensure Wikipedia and its non-executive stakeholders aren't harmed during labor conflicts. —Rhododendritestalk \\ 18:33, 28 July 2026 (UTC)reply
I don't think that difference gets to the heart of the concern. Unions are responsible to their members, so they may strike over issues that aren't supported by the community. Ensuring the servers are running safely (if they remain operational) is an essential task for safety, but making Wikimedia sites accessible to the public is not. I agree that employees have the right to unionize and a union ensures employees get a seat at the table. But I also agree that it doesn't necessarily have a beneficial effect on an organization's suppliers – in the case of Wikimedia, for example, those who supply content. isaacl (talk) 18:29, 28 July 2026 (UTC)reply
Sorry, but I'm not particularly impressed by the argument of 'if we give people the right to negotiate as a group, they might side against us and that's bad'. Don't get me wrong - I've seen unions not work. I've probably seen them work a lot worse than 99% of people in the discussion. I can't talk about my experience with a particular union without getting horrible anxiety. Still think people should have the right not to get dicked around by their bosses. Even if it personally benefits me or makes my life more convinient. GreenLipstickLesbian💌🧸18:23, 28 July 2026 (UTC)reply
Good point. This relate to the question above "if they matter so little to Wikipedia, what difference does it make to Wikipedia if they unionize?" I don't support unionization because it will be good for Wikipedia. I support it because supporting it is the right thing to do. --Guy Macon (talk) 18:41, 28 July 2026 (UTC)reply
Thanks. It feels useful (or at least clarifying) to have articulated that there are several motivating factors here. It has felt like the biggest factor was "it's in our interest" and I'm just not at all convinced. It's heartening to see "it's just the right thing to do, even if it's against our interests". Good vibes there. —Rhododendritestalk \\ 18:47, 28 July 2026 (UTC)reply
@Rhododendrites, I do strongly believe that it is in our interests that WMF employees are unionized, but I'm confused by how you've conflated the idea of "this is generally in our best interests" with "the union will agree with the community and act in line with what the community wants". I can believe that it's in my kid's best interest that their teachers are unionized without concluding something like "because my kid's teachers are unionized, they will give my kid an A+". In solidarity, asilvering (talk) 02:32, 29 July 2026 (UTC)reply
The conflation isn't mine? "Generally in our best interests" is the gamble that may well pan out, but that (IMO) is worth acknowledging as a gamble. The union advocating for and/or acting in the interests of the community is a more specific claim that's part of the union's own pitch (e.g. "empowering our union to advocate for you") and something echoed by many supporters as part of the reason for their support. To me, the conflation appears in a lot of the discourse around the union, and in a way I'm trying to challenge the taken-for-grantedness of the latter to better consider the former. As for the analogy, I'll put aside the A+ bit at the end, which is an illegitimate favor that isn't in anyone's interest and doesn't correspond to anything here, and can't really be adapted into something that fits because there's no additional class of volunteer stakeholders who do most of the educating of kids. I wrote out a list of differences (the scope of people affected by labor action, the agency of affected people, the kinds of accountability, the driving motivations for unionization, the difference in the role of the members in the final output, the absence of any major volunteer group of stakeholders, etc.), but replaced them with this vague parenthetical because I don't really want to go on a tangent. At the end of my message above, I was trying to say that what I'm looking for is from the folks who aren't in the "unions are just good" camp -- those who find the prospect of a union a gamble that could turn out badly but is better than the alternative. If we're getting into analogies with very different kinds of unions, I'm guessing we're talking in the realm of broad support for unions in general? I respect that position -- I'm just trying to see how much of the support isn't that, I guess. —Rhododendritestalk \\ 03:52, 29 July 2026 (UTC)reply
I mean, I am in the "unions are just good" camp, as opposed to the camp of "unions are good when they benefit me personally." I don't care about the community wishlist in the slightest, and focusing on it feels like a bit of a trap because it presents an easy way out of just prioritizing the wishlist and keeping work conditions otherwise exactly the same. Gnomingstuff (talk) 13:06, 29 July 2026 (UTC)reply
I think it's odd (to say the least) to use someone who joined the WWU in part because of management disparaging the community to claim that WWU members will probably have that contempt. (The latter is not unreasonable as a reading of that plank, though I'll note that interact directly with movement communities almost certainly means, in large part, dealing with the stuff that gets put under Oversight) Sesquilinear (talk) 20:20, 28 July 2026 (UTC)reply
I think mental health support being available for roles that deal with incredibly large online communities is actually a pretty reasonable ask, and doesn't necessarily say anything bad about us on the whole. Interacting with people on that scale can be exhausting and distressing, especially on online forums where dogpiling can happen. --Grnrchst (talk) 21:35, 28 July 2026 (UTC)reply
I'm one of the people who had these worries but hadn't really expressed them. Truth is, I don't have a ton of sympathy for WMF workers wanting to unionize, particularly given my impression that most if not all of these workers are being paid over $100k per year. (I chuckled when I read that wikifired's two months' severance was $25k, meaning they were paid $150k/yr.)
Anyone making $100k+/year is in the top 10-20% in the US, top 5-10% in Europe, top 2% globally. WMF employees are, objectively, among the richest people in the world. Plus they get benefits -- fully paid health care, life insurance, retirement plan, etc. Plus they work from home. So a bunch of the richest people with full benefits working from home want to unionize so they can get a little bit richer? Not exactly what I think of as "oppressed workers."
And what are their gripes? Are their paychecks bouncing? Are they forced to work double shifts? Is there rampant sexual harassment? No, AFAIK, none of these things. Their gripes are that a department was restructured and some of them were offered reassignment to other high-paying, comfortable jobs. The other gripe is that their bosses are jerks. Ohh nooooes, how will they ever manage?
So I have little patience for any comparisons between the richest people in the world with comfortable work at home jobs, and actual oppressed workers, like people who work in mines or are forced to live in company towns. That's why I think the criticism of "cosplaying a labor movement" is, while uncharitable, not far off the mark.
Still, what's the alternative? Say no to unionization? Idk about anyone else, but I wouldn't be willing to tell other people I'm against their unionization, even if the unionized workers are among the richest, most comfortable workers in the world. Let anyone who wants to join a union, join a union. I certainly don't think the WMF should take any kind of anti-union stance, it'd be against the values of the mission and the project. And anyway, it's really their business: the business of the employees. Not for me to say "no," and I don't support the WMF saying "no" either.
So while I might roll my eyes at people claiming "solidarity" with some of the richest, most comfortable people in the world who are complaining about crappy bosses, I still support the WMF voluntarily recognizing a union that a supermajority of WMF employees want to join. Levivich (talk) 18:42, 28 July 2026 (UTC)reply
Gonna be the bitch here and point out that acting like The other gripe is that their bosses are jerks. and sexual harassment are completely unconnected is... well, it shows a naivety I am jealous of. The WWU listed one of their goals as better mental health support, which, despite years of sitcom -esuq Ohh nooooes, how will they ever manage? jokes to the contrary, is important I'm also not sure that 'well, they make a lot of money, so who cares about Occupational stress or workplace bullying, at least they aren't slaves or not being paid' is a winning argument, but, well, I'll let an editor who you respect have that conversation with you. GreenLipstickLesbian💌🧸19:04, 28 July 2026 (UTC)reply
@Levivich, they are not unionizing so they can get a little bit richer. Certainly, for many unionized workers, increasing pay or benefits is a significant priority. But the immediate issues the WWU is more concerned with are things like "I want to be able to voice concerns at work without being afraid I will be fired for doing so" and "I do not want my benefits to be changed without notice". These are pretty basic things that any worker should be able to expect, and it is shameful that WMF employees cannot presently do so. In solidarity, asilvering (talk) 02:22, 29 July 2026 (UTC)reply
"the rich" == people who are in the top 2% globally, top 5-20% in their country depending on country. "Comfortable" == working from home with benefits. And pay and benefits equity that makes sense to the staff is a plank on the WWU platform, and that's corpo-speak (just like the WMF) for "more money and better benefits for some if not all". So, yeah, the rich and comfortable are organizing so they can be a little bit richer and little bit more comfortable. Put more charitably, so that their slightly-less-rich and slightly-less-comfortable colleagues can also be equally rich and comfortable. That framing of course doesn't sound quite as noble as "labor rights," but that's what "pay and benefits equity that makes sense to the staff" means: more pay and benefits.
The way you phrased the first example is not really on point, but I'm not going to waste your time arguing semantics, I think we'd both agree that whistleblower protection is important, and the WMF should be not only complying with the minimums required by law but serving as a leading example in the world of how large organizations should work. But whistleblowing is more than just "voicing concerns at work," it's more than just griping about a bad boss. I haven't seen the union anywhere talk about a lack of whistleblower protection, or even an example of a WMF whistleblower who wasn't protected. (Not a disgruntled employee, but a whistleblower.)
The second example, I'm not familiar with... I didn't see that on the union's website or in the blog post, maybe I missed it... and there are laws against that sort of thing, at least with respect to important benefits like health insurance (fringe benefits, maybe not, but who cares about those). Can you point me to where WMF workers are complaining about benefits being changed without notice? Levivich (talk) 02:49, 29 July 2026 (UTC)reply
Labour rights are human rights. We should support WMF workers' unionisation rights as a human right.Respecting others' human rights does not always bring personal benefit. There's no guarantee that in a decade or so (or even sooner), WWU will not have flaws as serious as (but complementary to) those of the WMF leadership. Institutional safeguards and structures that tend to reduce those flaws are needed in both WMF and WWU. Anyone talking constructively with WWU organisers right now might have a chance of convincing them to make the right institutional choices now that reduce the chance of WWU becoming evil by 2036. Boud (talk) 20:35, 28 July 2026 (UTC)reply
Are WMF employees laid off when projects are shuttered? For example, Knowledge Engine or potentially Abstract Wikipedia. If so, it could be possible that if the community attempts to get a project closed, the WWU would be opposed in an effort to keep people's jobs (which is understandable, but could also be a waste resources). ARandomName123 (talk)Ping me!03:49, 30 July 2026 (UTC)reply
I assume that part of the idea of having a union is to bring about a workplace that offers more than the two options of "do this questionable project and keep our jobs" vs. "shutter this questionable project and lose our jobs." Gnomingstuff (talk) 05:37, 30 July 2026 (UTC)reply
Wikimedia Foundation banner fundraising campaign in Malaysia
Dear all,
I would like to take the opportunity to inform you all about the upcoming Wikimedia Foundation banner fundraising campaign in Malaysia.
We will run banners for non-logged in users in Malaysia on English Wikipedia itself. The banners will run from the 2nd to the 30th of September 2026.
A brief note on the timing. We are moving the fundraising campaign in our planning from June to September which means that logged out readers will see fundraising banners twice this year. Going forward the campaign will again only run once each year.
Prior to this, we are planning to run some tests, so you might see banners for 3-5 hours a couple of times before the campaign starts. This activity will ensure that our technical infrastructure works.
Generally, before and during the campaign, you can contact us:
@JBrungs (WMF): Isn't that rather risky of a backlash in the current context? Malaysiahas manybigtrade unions. In fact, per the current lead, National Union of Plantation Workers is one of the largest [trade unions] in Asia. A month from now, if WMF has not yet voluntarily recognised WWU UK and WWU US, then readers in Malaysia risk getting angry that they're being asked to donate to a foundation that doesunion busting. The damage to WMF's reputation risks extending to the wider Wikimedia community itself, since much of the public doesn't see the difference between "Wikipedia" (the Wikimedia community) and "Wikipedia" (WMF that runs the infrastructure). You're playing with a tinderbox. WMF's union-busting will not remain secret. Ordinary Wikimedians do not want to discourage donations: we know that WMF needs to pay salaries and server costs. But we will not hide the evidence. Boud (talk) 08:31, 29 July 2026 (UTC)reply
As a sign of good faith by WMF, I would recommendyou might want to considerdelaying the banner campaign until WMF has recognised both WWU UK and WWU US. "We hate trade unions, please give us some money" is not a great way of convincing people to donate. (@JBrungs (WMF): It would also be a good sign of respect for the community to answer the questions at the discussion pointed to below by Chipmunkdavis.) Boud (talk) 12:03, 29 July 2026 (UTC) (edited Boud (talk) 13:55, 29 July 2026 (UTC))reply
In the spirit of WWU's social media post stating that it is not calling for donations to be delayed, I've weakened my recommendation to a "maybe consider". Even if WWU is not calling for a delay, the risk of backlash remains. I've seen plenty of social media (both decentralised and centralised) posts by people declaring that they would stop donating because of the union-busting. WWU cannot force those people to keep donating, nor convince English speakers in Malaysia that they should donate despite the union-busting (unless the banner includes a reference to WWU's social media statement that it is not calling for donations to stop, which would risk being interpreted like an out-of-the-blue statement "I am not a thief", which makes people wonder why it was stated at all). Boud (talk) 13:55, 29 July 2026 (UTC)reply
Regardless of what my views on the WMF union situation is, I do think they should still run the fundraiser and get funds. Not getting funds is a ecological risk for our movement. Sohom (talk) 14:45, 29 July 2026 (UTC)reply
Note that server costs are not a major expense item for the WMF. Internet hosting costs are less than $3.5 million p.a., while the Foundation has close to $500 million in assets (if you include the Endowment).
On the plus side, the banners look so much better these days than they used to. The emails however I still find borderline wrong, because they arguably include subtle suggestions that free access to Wikipedia might be under threat.
"My hope is that you'll think about how useful Wikipedia has been to you this past year, and how valuable it is to have access to a source of knowledge that doesn't charge you anything, doesn't sell you anything, and doesn't interrupt you with ads." (E-Mail 1)
"We owe it to them, in a world that is always changing, to keep Wikipedia free for everyone. Like it always was and always should be." (E-Mail 2)
"This might be my last chance to ask, so I want to make sure this email reaches everyone who might give. Right now, we're at a critical stage of our fundraiser in Brazil." (E-Mail 3)
"We need our community of donors to help us reach our goal, and time will soon run out in this fundraiser. ... We want to make sure we all have equal access to high-quality information – something that is really hard to find online these days. We still have a lot of work to do to make knowledge free for everyone, and you can help us achieve it. With your donations, The Wikimedia Foundation keeps Wikipedia operational ..." (E-Mail 4)
@Jayen466We need our community of donors to help us reach our goal, and time will soon run out in this fundraiser. (what is actually being said) and need our community of donors to help us reach our goal, and time will soon run out (what you tried to highlight in your framing) are two very different sentences espousing very different meanings. For what it's worth, we spend approx >200 million a year, most of which is spent on the movement, 500 million buys us a year and a few in change (unless you want to only keep the lights on, in which case 3.5 million is still woefully insufficient since it actually discounts the salary of the people maintaining the hardware/software). Sohom (talk) 14:30, 29 July 2026 (UTC)reply
Of the $190 million in 2024/2025 operating expenses, $114 million were spent on salaries and benefits for just under 700 employees (averaging about $165,000 per head), and another $16 million on professional services. This may be money spent "on the movement", but indirectly so. Regardless, keeping Wikipedia operational can be done for far less. It's not what the money is needed for, or primarily spent on. To my mind the emails highlight that aspect a little too much. AndreasJN46614:55, 29 July 2026 (UTC)reply
To be fair, not answering is standard procedure. Try asking them to tell us how much just one Wikimania cost and what was bought with that money. Try to get any answer including "we have decided not to tell you that". You will get various responses from other volunteers who don't have the information and don't speak for the WMF, but the WMF itself will stonewall you. --Guy Macon (talk) 13:21, 29 July 2026 (UTC)reply
Petition to the WMF board of trustees to voluntarily recognise the US staff union
Hi all
As some of you may have seen WMF announced the day after Wikimania they have chosen not to recognise the WMF staff unionisation efforts in the US and UK voluntarily. I'm sharing this as someone who has never worked for the Foundation, but if I did I would not like to be treated like this.
I hope you will consider signing this petition to ask the board to instruct the CEO to voluntarily recognise the US union and begin bargaining in good faith.
Where was it "discredited" that the WMF has the right to ask for a secret ballot vote? Please quote the exact part of applicable labor law that says that WMF management is required to submit to third-party arbitration. --Guy Macon (talk) 00:42, 31 July 2026 (UTC)reply
That's an unnecessarily combative way to say "the WMF has the right to secret ballot and is not required to arbitrate." Anyway, who cares about rights and requirements? The WMF could, and should, choose to voluntarily recognize or arbitrate. (That's why the thing everyone is calling for is called "voluntary" recognition.) Levivich (talk) 01:15, 31 July 2026 (UTC)reply
I don't believe that's what Stjn is saying. I believe they mean that they used discredited anti-union talking points in their response. For example, calling the vote a commitment to ensuring that every eligible staff member can make their own decision freely, privately, and democratically flies in the face of how staff did make a decision, freely, privately, and democratically, when ~70% of eligible staff signed a union card. Best, HouseBlaster (talk • he/they)01:26, 31 July 2026 (UTC)reply
OK, I can see that. I also asked the WMF to voluntarily recognize the union, but I expect WMF management to do what management does, which is to make anyone trying to start a union follow every step that they are legally required to do.
I predict that, once there is a union in place, a time will come when the union and management disagree on something. Will I see the same reaction when the union fails to voluntarily give management everything they want without a fight? When some manager who really doesn't like unions accuses the pro-union side of "using discredited anti-management talking points"? I suspect that the reaction would be quite different. --Guy Macon (talk) 01:52, 31 July 2026 (UTC)reply
They are not legally required to do a secret ballot election under Trump-controlled NLRB. They would only have to do it because the WMF rejected a good faith settlement with the union for reasons ranging from flimsy to downright improbable. stjn09:09, 31 July 2026 (UTC)reply
"It is completely legal for the WMF to insist on a paper election conducted by the underfunded Trump-appointed NLRB. I find it ironic that half of the BoT trustees are unelected in the first place. For the remaining trustees, online voting was considered secure enough to oversee the foundation's $200 million annual budget, yet it is deemed too risky for the 200 US staff."
So when everyone is talking about "signing a union card" are they talking about doing that online?
If so, I would be very much interested in the security of the method the WMF uses to manage the budget over the internet and the security of the method the union uses to gather signatures over the internet. --Guy Macon (talk) 02:17, 31 July 2026 (UTC)reply
So who, outside of the union or WMF management, has confirmed the claim that a supermajority of eligible workes have "signed a union card" (falsely so called)? If, as I suspect, management is doing what management does and trying to stop some union from reducing their power, it seems reasonable to have a secret vote that neither side can cheat on. --Guy Macon (talk) 03:34, 31 July 2026 (UTC)reply
The WWU page that links to the form says By law, your answers on it are confidential between you, the Wiki Workers United union, the CWA and the National Labor Relations Board (NLRB). Your answers are not allowed to be shared with WMF management.ARandomName123 (talk)Ping me!04:05, 31 July 2026 (UTC)reply
No one has confirmed it yet, because no one has had the chance to. Were the WMF to do the right thing here and go for voluntary recognition, the next step would be a process in which a neutral third-party arbitrator reviews the cards that have been signed and responds to any concerns the WMF may have about potentially invalid cards; in the very unlikely event that the arbitrator strikes enough cards to shrink the share to below 50%, voluntary recognition would not happen. Voluntary recognition does not mean the WMF forfeiting its right and responsibility to do due diligence before taking a legally binding action. It means agreeing to recognize the will of the majority assuming it actually is the will of the majority—the same thing the WMF is claiming it needs a drawn-out, government-run secret-ballot election to accomplish. -- Tamzin[cetacean needed] (they|xe|🤷) 10:37, 31 July 2026 (UTC)reply
Again, I agree that management should go the voluntary recognition route. I have signed the petition asking them to do that. But they clearly don't have to. And, given their past performance in other areas, I fully expected them to do everything they can to maximize their own power and wealth. Nor do I have any expectation that any petition or discussion at the Village Pump will change the situation.
So here we have an actual, genuine, bona fide example of assuming bad faith. There's absolutely no reason to believe that WWU is "cheating" on the ballot. Gnomingstuff (talk) 15:04, 31 July 2026 (UTC)reply
Show me a diff where I or anyone else implied that anyone is cheating. Assuming good faith does not require letting the WMF count the ballots. Assuming good faith does not require letting the union count the ballots. Is meta:SecurePoll an AGF violation? --Guy Macon (talk) 17:11, 31 July 2026 (UTC)reply
Here: So who, outside of the union or WMF management, has confirmed the claim that a supermajority of eligible workes have "signed a union card" [...] it seems reasonable to have a secret vote that neither side can cheat on.
Unless there is actual evidence suggesting that the union is falsely claiming that a supermajority of eligible workers signed the card, there is no reason to suggest it might be false, as you have above. Gnomingstuff (talk) 18:18, 31 July 2026 (UTC)reply
"It might be false" is an objective fact. It is also an objective fact that you are trusting the union and that they have a COI. It is fine to trust someone, but criticizing someone for simply stating the true fact that you are trusting them seems to me to be going way too far. Plenty of people who have COIs can be trusted to not let their COI affect their actions, but that doesn't imply that stating that they have a COI is assuming bad faith.
Please stop for a moment, do a bit of self-examination, and tell me honestly that you would be casting the same aspersions if it was the WMF that promised to do an honest count and to keep the names of those who signed the cards secret, and if I had simply pointed out that you are trusting the WMF. --Guy Macon (talk) 16:07, 1 August 2026 (UTC)reply
Guy, I'm not sure why you're taking this tone with people in this discussion? It's coming off as very combative and I'm not sure that's your intent. Regarding your implied question about the union cards, yes, it's theoretically possible that WWU has cooked the books, but if they have, they're extraordinarily cooked: only 50% of employees need to vote yes in the secret ballot election for the union to be recognized, and only 30% of workers need to sign union cards to trigger that election in the first place. WWU claims that 70% of US employees have signed union cards - so about a third of them would have to be faked, coerced, or whatever else, for this to be an insufficient number to make it through the secret ballot process. I think the chances of that being the case are effectively zero. It's also possible to do some form of card check to verify the cards. The WMF hasn't gone for that option either. In solidarity, asilvering (talk) 16:31, 1 August 2026 (UTC)reply
Union cards aren't secret from everyone. In cases of voluntary recognition normally a mutually agreeable neutral third party counts and verifies the cards. MrOllie (talk) 16:31, 1 August 2026 (UTC)reply
I am only "taking this tone" with the ... individual ... who keeps writing untrue things about me like "So here we have an actual, genuine, bona fide example of assuming bad faith". I have no problem with anyone who disagrees with me without making false accusations and insulting me.
Yes, the WMF could do several things to address any actual objection they might have with the union counting the votes. But they won't. They could even do both; recognize the union, start negotiations, and also start the process of having a normal secret ballot union election. We all know that is not going to happen either. The WMF wants to retain power and control and thus will make the union jump through every hoop instead of voluntarily giving the union what they want. I really doubt that everyone who is outraged by this will be similarly outraged when the day comes that the WMF asks the union to voluntarily give the WMF what they want and the union refuses. --Guy Macon (talk) 20:22, 1 August 2026 (UTC)reply
"One of the problems with the process so far is that it was not secret and we have heard from some staff members that they felt pressured because the organizers would know how they decided. That isn't a great process and it goes against our movement's values quite badly to have people in a situation where they are pressured into something one way or the other.
It's pretty easy to see the problem if we imagine it in the other direction - imagine some company asking staff to sign pledge cards not to join a union, and keeping track of who did or didn't in order to put pressure on those who didn't. Gross. It doesn't make it better for it to be the other way around in my own personal view.
I want a process where staff are safe to deliberate in the privacy of their own minds and make the decision based on all the available evidence that makes the most sense to them. So I don't think insisting on a proper vote is process for the sake of process and I say that with my own estimate that the staff will vote to support unionization. I think we'll be in a better place if it's really clear - a clean and clear choice with no chance of pressure.
In terms of time, energy, and money - I don't think it should take very long and again speaking only for myself I hope we get it done as quickly and efficiently as we can and I hope that everyone - staff, management, board, and community can come together to celebrate the outcome. I know I will."
From what I've heard from pro-union people, there were two members of the union managing/verifying the union cards, they were the only 2 people with access to the information and did not share who signed with anyone else. So the process absolutely was secret. Staff could not have effectively pressured other staff since they did not know who did and didn't sign. Obviously me saying I heard something second hand doesn't mean much, but I strongly suspect Jimmy is simply misinformed on how the process worked. Bawolff (talk) 07:05, 5 August 2026 (UTC)reply
Petitions to show solidarity with WMF workers trying to unionise
Hi all
I haven't seen these petitions posted on this page, I hope people will consider signing them
Wikipedia:Wiki Workers United solidarity an English Wikipedia page to show support for the workers and discuss potential collective actions. If 150 more people sign it it will become the most supported proposal or petition ever on English Wikipedia.
The good news is that the WMF money scale is not growing with the speed of the early 2000s.
The bad news is that it looks fairly consistent with stable exponential growth. I just did this for the expenses, but the script can trivially be redone for the other two parameters.
Per a business-as-usual scenario, the expenses should hit 10 billion USD around 2050.
The model exponential is . That's a factor of e increase each 7 years.
For context, the model of the The Limits to Growth appears to be still considered more or less accurate, so either unavoidable economic collapse or democratically chosen degrowth should start by around 2040 to 2050 or so (and if I understand it correctly, this model only partly takes into account the climate emergency).
Where does the Wikimedia movement want to be in 2050?
It will be obsolete long before that. Certainly the current software, or anything resembling the current software, will be. It's already pretty creaky and the idea that it will survive another quarter century is absurd. The handwriting is on the wall that LLMs (and the technology behind them) are going to eat our lunch. The core mission of the movement is to make all the knowledge of mankind available to everybody, for free. If something comes along that can advance that mission better than we can, we should embrace it and work on finding ways to improve it, not put up roadblocks to its adoption. RoySmith(talk)13:32, 1 August 2026 (UTC)reply
I won't try to predict the future of technology, and I won't be around in 2050 to see how such predictions work out, but I do expect that pursuers of enclosure or monetization of the commons will be a threat to the continued existance of Wikipedia as a free (libre and gratis) entity. I think that will be a greater threat to Wikipedia than any changes in technology. Donald Albury15:02, 1 August 2026 (UTC)reply
I have been thinking of completely rewriting WP:CANCER, which is itself getting a bit creaky, but on think that will absolutely stay is my prediction of the future:
"Nothing can grow forever. Sooner or later, something is going to happen that causes the donations to decline instead of increase. It could be a scandal (real or perceived). It could be the WMF taking a political position that offends many donors. Or it could be a recession, leaving people with less money to give. It might even be a lawsuit that forces the WMF to pay out a judgement that is larger than the reserve. Whatever the reason is, it will happen. It would be naïve to think that the WMF, which up to this point has never seriously considered any sort of spending limits, will suddenly discover fiscal prudence when the revenues start to decline. It is far more likely that the WMF will not react to a drop in donations by decreasing spending, but instead will ramp up fund-raising efforts while burning through our reserves and our endowment."
This was posted earlier this year, after the FY25/26 English fundraising campaign:
I want to be honest with you all, this campaign presented some challenges as the December banner campaign started off well below our projections. While we anticipated lower traffic year–over-year and had accounted for this in our planning, the drop we saw surpassed our expectations. While we did manage to raise our set goal, this was partly because those that did give, on average gave more. We saw 14% decline in the number of donors who gave, 20% decline in the number of new donors and 7% less revenue year-over-year.
I whitelist Wikipedia in my ad blockers because I still naively believe it to be special. However, that would be easy to change for me and everyone else if banners became year-round. Certes (talk) 18:21, 1 August 2026 (UTC)reply
I think your premise is certain (and indeed already happening, or close to it), but your conclusion is not, and we can already see that at work. There is a lot of effort being put into reader retention, the apps, etc, so that an AI-driven collapse in readership doesn't take the whole donation model down. The funding model for affiliates and grants is being re-evaluated. And so on. In solidarity, asilvering (talk) 16:41, 1 August 2026 (UTC)reply
Wikipedia has survived 25 years. I wouldn't be surprised to see it survive another 25. It is true that our revenue model is in danger, but this can be responded to with a combination of the endowment and cutting expenses. The knowledge itself and our model for updating it (rapid crowdsourcing) is still the best way to organize knowledge in human history -- AI is not nearly as accurate and depends on us for its training data. –Novem Linguae (talk) 20:43, 1 August 2026 (UTC)reply
Predictions of the end of Wikipedia remind me of 1950s sci-fi set in a late 20th century where we take our daily food tablets, zip around in flying cars and holiday on the moon. I think the world in 2050 will be very much like today's, and so will Wikipedia. Here, as in football, those who want to commercialise a global institution to line their own pockets can be stopped if enough people resist. Certes (talk) 23:03, 1 August 2026 (UTC)reply
I remember the 1990s, when many people thought that WordPerfect, Lotus 123, Compuserve, and America Online would dominate computing forever. I doubt that we are any better at predicting the future than they were. --Guy Macon (talk) 00:58, 2 August 2026 (UTC)reply
WMF annual support+revenue + naive extrapolationWMF annual net assets + naive extrapolation Keeping in mind the warnings, I've kept using the word "naive" in the support+revenue and net assets figures. For simplicity, the exponential fit is from 2011-2012 to 2024-2025 in all three cases. Despite the naivety of the fits, it looks to me like both the revenue and expenses growth are reasonably (by eye) fit by an exponential in a stable way for these 13 years; that suggests a system with sufficient negative feedbacks to keep it stable, with no macro-financial signs of disruption. The two e-folding times differ: revenue: ; expenses: , i.e. expenses were lower than revenue in 2011, but are growing about 1.4% faster, so the naive extrapolation puts annual revenue something like 10% or so below annual expenses in 2050; equality would be around 2032. The net assets look poorly fit by an exponential based on the 2011 and 2024 values. Boud (talk) 08:50, 2 August 2026 (UTC)reply
Neither of these graphs looks linear to me. Not sure why a linear estimation is being used. They both look like they're leveling off to me. Perhaps using a non-logarithmic scale would make this easier to see.
I assume that "support and revenue" means donations ("support") plus money from selling goods (t-shirts, ...) and services (API services to Google, ...). The exponential models (straight lines in the diagrams) are not for the whole 22-year history. They are naive fits (i.e. they're only fits by eye; numerically they use the two values at 2011-2012 and 2024-2025, which allow only one exponential that gives both values). In the case of the support+revenue (here) and the expenses (top of this section), these look, at least to me by eye, like reasonable models for those 14 (inclusive) years. A straight line in the diagram is an exponential, , where I've left off the normalisation. You're welcome to do linear plots, but if these continue to 2050, almost nothing would be visible except for a big jump near 2050. The net assets curve slowed during 2020-2024, which makes sense when expenses increase faster than revenue. Subtracting two exponentials does not (generally) give another exponential. Boud (talk) 14:08, 2 August 2026 (UTC)reply
Thanks for the explanation of support. Yeah, that's probably donations, makes sense. For the graphs, they look like curves/hooks to me, so I would expect the trendline to look like ╭ instead of /. –Novem Linguae (talk) 14:35, 2 August 2026 (UTC)reply
Curves that show spending increasing exponentially while contributions look like the are heading toward leveling off would support my prediction, which is why I don't trust myself to eyeball them. I might just be seeing what I want to see. --Guy Macon (talk) 18:35, 2 August 2026 (UTC)reply
Lawyers, Not Persuaders: Even what little we know about Littler is enough to describe what appears to be its philosophy: prevent any worker anywhere from collectively bargaining for anything.
ibid.: Funk explained to me that organizers and pro-labor leaders only tend to discover Littler Mendelson’s involvement once a petition is filed to the NLRB. “[Littler] doesn’t show up in any other disclosures,” he said. “We know that companies are spending a lot of money on it. But unfortunately, they’re hiding that from workers and the public.”
Anti-Union Law Firm Tells Clients to Go Ahead With Illegal Union-Busting Tactic: Not much is even known about what Littler attorneys earn. In an engagement agreement with the City of Peekskill, New York, the firm says its attorneys make as much as $1,760 an hour, though it discounted rates for the city down to $550 an hour for partners, known as “shareholders.”
If the WMF is so pro-union, hiring an anti-union law firm to pay their lawyers astronomical amounts of donor money to not squash the union is just absurd. However, I think at this point everyone can agree that what's happening is far simpler. It's the union busting, stupid. stjn14:12, 2 August 2026 (UTC)reply
While I've had my issues with how the WMF has allocated funds before, I don't think I've ever seen a use of donor money that I felt was actively detrimental to the project before now. I've never been one of those people to discourage donations to the foundation, but if this is what donor money is being used for, then I think donors have a right to know about it. This is downright disgraceful. --Grnrchst (talk) 17:46, 2 August 2026 (UTC)reply
Just going to post here what I posted on Jimbo's talk page, which is that a few days before this news broke, he told the community that There are no "union-avoidance law firms" involved here […] The hostility you are expressing here is not fact based at all.
For me the worst part is that when he wrote that, when he called the WMF's leadership courageous for rejecting recognition, and also when the CEO said at Wikimania that no decision had been made, when the Chair of the Board said the Board supports what the WMF leadership is doing... when all those statements were made, all those people making those statements already knew that the WMF had hired Littler, which the rest of us didn't find out until the NLRB docket was published. (Because no way they hired the law firm and decided to reject recognition all in a matter of like 48hrs, and no way the Board and CEO weren't informed of, or didn't actually make or agree to, those decisions.) The Chair (on behalf of what is probably a unanimous but at least a majority Board), the CEO, and the co-founder all publicly lied when they said they supported workers' rights to unionize, they were simultaneously engaging in anti-union actions like hiring Littler and following their playbook. Infuriating. I can't think of another example of the WMF leadership stray so far from, even act directly against, the mission and our values. Infuriating and disheartening. Levivich (talk) 15:50, 3 August 2026 (UTC)reply
For all that some contributors were previously (and understandably) getting exercised about "WMF employees [being anyone's] personal punching bag", it seems to have become clear that @BMeehan-WMF, @Slaporte (WMF) and @Jimbo Wales were actively misleading the Movement when they (variously) claimed that the Foundation would negotiate in good faith, that the Foundation would offer a fair, lawful and transparent process, that there would be good-faith bargaining or that there are no "union-avoidance law firms" involved here […] The hostility you are expressing here is not fact based at all.
Whether those people were actively lying to us or merely uninformed is not really relevant here — in wither case it is unacceptable.
As I just updated to my signature on Meta, I am beyond disappointed and well into the territory of disgusted. I have lots of faith in some parts of the Foundation. I am very disappointed to say that it would appear the C-suite and the Board chair emeritus are no longer among them. — OwenBlacker (he/him; Talk). I support Wiki Workers United16:30, 3 August 2026 (UTC)reply
"New union organizing rules, including the standard for responding to union demands for recognition" and "confidentiality and nondisparagement agreements" conveniently at the same webinar but I'm sure those two things are totally not connected. And an extensive library for anyone still looking for some summer reading. Levivich (talk) 05:47, 4 August 2026 (UTC)reply
From what I can see, the only possible interpretation of the facts is that the WMF CEO and Jimbo Wales were lying the whole time. We cannot and should not assume good faith against all evidence. Ita140188 (talk) 11:41, 4 August 2026 (UTC)reply
Regarding the personal punching bag, there is a huge difference between WMF top management, board members, etc. and WMF employees who may very well have been directly ordered to say the things that resulted in nasty personal attacks by volunteer editors on this page. That being said, there is no "it's OK to engage in personal attacks and assume bad faith if the victim is part of WMF management" exception in WP:NPA, WP:AGF, or WP:CIV. --Guy Macon (talk) 13:08, 4 August 2026 (UTC)reply
Except when you actually catch them lying, especially repeatedly or in an organized way. Then it's not a personal attack anymore, it just becomes a fact. If someone actually lies, it's ok to say that they lied. Our policies don't prohibit that or require us to lie ourselves by pretending otherwise. We do this to editors and WMF management alike. Like every day someone or other is busted for lying about using AI. Same thing if someone says they haven't hired any union busting law firm, at a time when they hired Littler for months, then it's ok to call that lying because that's what it is. If someone says we aren't union busting, when they had already hired Littler for months and held captive audience meetings where they made the staff listen to anti-union talking points, that's lying too, it's ok to call that what it is. If someone says we have not made a decision yet because we're so focused on Wikimania, at a time when they'd already hired Littler, held captive audience meetings where they made the staff listen to anti-union talking points, and decided not to go the voluntary recognition or arbitration route and instead forced a NLRB vote, that's a lie, a fat bald faced public lie, and there's nothing wrong with calling it out, especially if it's a person in a leadership position who is being paid hundreds of thousands of dollars of donor money to run the WMF, or is like a cofounder of Wikipedia, or Chair of its Board of so-called "Trustees," a label that, itself, is increasingly becoming a lie. Levivich (talk) 13:26, 4 August 2026 (UTC)reply
I am not engaging in personal attacks, I am just stating the facts. Jimbo Wales and Bernadette Meehan explicitly denied trying to obstruct unionization, while it is evident (anti-union meetings, hiring anti-union law firm, etc.) that was their intention from the beginning. As for on-wiki matters, we assume good faith until proven otherwise. Quoting WP:AGF: This guideline does not require that editors continue to assume good faith in the presence of obvious evidence to the contraryIta140188 (talk) 13:43, 4 August 2026 (UTC)reply
Can you quote similar "allowed if you are just stating the facts" language in WP:NPA, and WP:CIV?
"Jimbo Wales and Bernadette Meehan explicitly denied trying to obstruct unionization, while it is evident (anti-union meetings, hiring anti-union law firm, etc.) that was their intention from the beginning." is allowed. So is "the WMF CEO and Jimbo Wales were lying the whole time." Those were your words, and I never criticized or even commented on them.
"I have absolutely zero faith that BMeehan-WMF didn't just tell a bald-faced lie when she refused to address the question at Wikimania by saying that they're just too focused on the conference. We are ruled by lying politicians, and not even the ones that are particularly good at lying. A sad day for the Wikimedia movement." is not allowed per WP:NPA. Those were not your words, but they were the words that I referred to when I wrote "WMF employees are not your personal punching bag. Argue with what is said. Don't insult the one who said it." --Guy Macon (talk) 14:39, 4 August 2026 (UTC)reply
@Guy Macon: I agree, and I deliberately didn't tag you in my comment because it already felt more pointy than I wanted it to, for which I apologise. I think you and I might disagree on where the line is between "we still need to offer good faith towards this C-suite staffer / Board trustee" and "it feels very clear they are deliberately misleading us and we should call that out", but I don't disagree with you in principle: being a senior exec or a trustee does not give a free pass to cast WP:ASPERSIONS or make WP:NASTY attacks.
I'm sorry if my reference to your "punching bag" comment felt like it was attacking your position; that was very much not my intention.
I do think, however, that initial assumptions of good faith have been traduced at this point and that neither WP:CIVILITY nor ASPERSIONS continues to require us to avoid calling out the betrayal of good faith that has been exhibited by the 3 people I mentioned above. To quote from CIVILITY: Accusations about personal behavior that lack evidence. Serious accusations require serious evidence; the evidence for the claims does appear to be clear now. — OwenBlacker (he/him; Talk). I support Wiki Workers United14:21, 4 August 2026 (UTC)reply
Thanks! I have no problem with your phrase "calling out the betrayal of good faith that has been exhibited by the 3 people I mentioned above" or anything similar. My punching bag comment was in response to another editor saying that "we are too focused on the conference to answer at this time" was "bald-faced lie" and following it with "We are ruled by lying politicians, and not even the ones that are particularly good at lying. A sad day for the Wikimedia movement." Those are personal attacks. I am puzzled as to why multiple editors are assuming that I was responding to something they said instead of the comment I replied to. --Guy Macon (talk) 14:39, 4 August 2026 (UTC)reply
Knowing what we know now about the counsel WMF hired and the kinds of anti-union emails and meetings that were held in almost certain coordination with Littler Mendelson by CBasssherizen-WMF herself, that editor was clearly right:-) And the editor that was so strangely hurt by it they accused the wrong person of incivility might need to reassess continuing to defend the executives that practice such deception. stjn14:53, 4 August 2026 (UTC)reply
I decline to play your continued game of "gotcha" over a mistake that was corrected and apologized for. Please drop the WP:STICK.
Your comments clearly violated WP:NPA. Don't do it again.
You latest WP:ASPERSION (that I "defend the executives that practice such deception") has zero basis in reality. You might want to read WP:CANCER before accusing me of defending the WMF. I am just asking you to argue with what is said without insulting the one who said it. --Guy Macon (talk) 15:17, 4 August 2026 (UTC)reply
Please explain the circumstances in which this statement, and similar statements such as "There are no 'union-avoidance law firms" involved here,' are not lies. They are certainly false. Gnomingstuff (talk) 15:02, 4 August 2026 (UTC)reply
Evidence please. Please post the diff where I said that "There are no 'union-avoidance law firms' involved here" wasn't a lie. I am getting very annoyed with being asked to defend made up words that I never wrote.
I would also very much like to see evidence that a claim to be too busy to answer a question that deserves a well-thought out answer while in the middle of running a Wikimania is "certainly false" or a "bald faced lie" Because that's what I actually commented on. --Guy Macon (talk) 15:32, 4 August 2026 (UTC)reply
or anything similar - well, lie and lying are similar to betrayal of good faith. WP:LYING is itself a violation of the civility policy, and the civility policy is not violating itself by using that word. Serious accusations require serious evidence, but we have met that bar here. Levivich (talk) 15:10, 4 August 2026 (UTC)reply
And you see no difference between saying that someone is lying and saying "We are ruled by lying politicians, and not even the ones that are particularly good at lying. A sad day for the Wikimedia movement"? Please explain how the latter is not a violation of "Do not make personal attacks anywhere on Wikipedia. Comment on content, not on the contributor" in WP:NPA. --Guy Macon (talk) 15:42, 4 August 2026 (UTC)reply
Ok so if we agree that lying isn't a PA or uncivil in this case, are you saying it's politicians that's a PA/uncivil, or the accusation that they're not good at it, that's a PA/uncivil?
And, c'mon Guy, you're better than to take a single sentence out of context and wave it around like that. We obviously comment on contributor, and not on content, in project space, such as at noticeboards, and this is a noticeboard. Don't go about suggesting that every single comment on a contributor is a violation of NPA, you know better than that. You know it wouldn't be hard for me to find you commenting on contributors and not on content, so let's just drop that particular line. Levivich (talk) 16:04, 4 August 2026 (UTC)reply
Did some brief looking into this. Bernadette Meehan stated that The Foundation received recommendations to work with these specific lawyers from other values-based organizations (non profit/public benefit companies) and because of their familiarity with unionized staff who work in technology. These lawyers have in fact supported work with organizations that now have unions, and they are familiar with the process. As some have pointed out, it's unclear which specific organizations recommended them. It's also unclear whether "these specific lawyers" refers to Littler Mendelson as a whole, or the, uh, specific lawyers involved. (Also unclear to me -- others with more experience in this area can correct me if necessary -- whether WMF chose the specific lawyer or were assigned one. If they were assigned one then that may recontextualize the below paragraph somewhat.)
At any rate, the specific lawyer involved here is Kevin Burke. He does not seem to specialize in the technology sector; his specialty appears to be health care, based on his bio and the publicly accessible cases he is named in. The most noteworthy of these cases is St. Vincent Hospital, as its nurses went on strike in 2021 in an event notable enough to have its own Wikipedia article. Burke wasn't involved in the nurse cases, but he did represent the hospital when its security officers voted to unionize in summer 2019, a few months before the nurses' union started attempting to negotiate a new contract. The takeaway, then, is that the hospital worked with this guy at a point in time when they were antagonistic enough toward its unions to eventually make national news over it. I suppose you could call that "supported work with organizations that now have unions" (what does that even mean). Gnomingstuff (talk) 19:57, 4 August 2026 (UTC)reply
"Other values-based organizations (non profit/public benefit companies)". Hmm. So just how many non-profit organizations out there that are unionized or labor union friendly? I'll admit that I did a quick Google search & found a list of unionized non-profits, but I don't recognize the names of any of those. I'll admit at this point that I suspect that most non-profits are hostile to unionization, for the usual reasons. -- llywrch (talk) 22:13, 4 August 2026 (UTC)reply
"supported work with organizations that now have unions" could cover a wide range of things, including being euphemistic for "fought unionization and lost". Anomie⚔22:33, 4 August 2026 (UTC)reply
Full text of M:WWUEMAIL sent to US Foundation staff with anti-union talking points on 27 February. The below paragraph in particular is not neutral in any sense of the word.
Unions are not structured to represent non-union members or formally negotiate issues on behalf of non-union groups. This is important because of concerns raised about the Foundation’s relationship with the Wikimedia movement around how decisions are made. We care deeply about this and are working to address it through different avenues.
Does the Wikimedia Foundation seriously expect people to believe that it is somehow unique in having US- and non-US-based employees? Or that it's the first multinational company where workers have unionized? It's profoundly disappointing to see such plainly anti-union arguments privately expressed to employees at least as far back as February, with the CPO and other executives signing an email to all employees directly stating that we don’t believe that a union would effectively address the concerns being raised or meet the Foundation’s needs at this moment, as those same people make repeated assurances that they are not taking any anti-union actions and Jimmy claims "The Foundation is taking a totally neutral stance." And it's hard to take seriously the WMF's stated concern that staff are feeling pressured by other employees to support a union when executives — who have direct control over a person's continued employment — are sending out anti-union emails like this one. But hey, who needs a union when you have "Making Space sessions"... GorillaWarfare(she/her•talk) 20:17, 3 August 2026 (UTC)reply
So... do we know when the union busting actually began? It is blowing my mind to quite literally read this page out of Littler's playbook dated February. That tells me they'd already hired Littler before February. Meehan only became CEO at the end of January, so was this decision to union-bust made by the previous CEO Iskandar?
(Is this why we hired a CEO with no prior CEO experience? Because every candidate with prior CEO experience had the good sense to not step into this mess?)
I'd guessed that hiring Littler was a response to WWU going to the CWU, because Littler has like the most experience fighting CWU--not saying that's a good thing, just that it makes sense in an arms-race way: WWU got the big guns, so then WMF got the big guns. But now I'm wondering: who got involved first, CWU or Littler? Do we know? Levivich (talk) 21:09, 3 August 2026 (UTC)reply
Wiki Workers United remained independent (no professional union staff) until late June 2026. I believe we announced our existence to management in January 2026 (this current iteration... we had attempted twice before this attempt over the last ten years.) We formally affiliated with CWA after taking a vote on several other options including remaining independent.
We have a timeline of events that we may share with the public down the road.
I wasn't going to bring this up until you have a contract (and I advise that nobody associated with WWU reply to this comment until there is a contract -- some very clever union-busting lawyers are reading every word written here) but you might want to start thinking about this: What if the WWU decided to be financially transparent and publish exactly where any money comes from and exactly how it is spent? Not just the minimum required by law like the WMF provides, but real numbers so that those who pay dues know exactly what their money is buying? Like I said, don't answer now. Just start thinking about it and maybe retaining records so that info on what was spent in the early stages doesn't get lost. --Guy Macon (talk) 23:03, 3 August 2026 (UTC)reply
Just stating the obvious here: The no 'union-avoidance law firms' involved here" comment was made somewhat late in the workday on July 28 -- around 2:30 PM San Francisco time. The filing confirming Littler's involvement was also dated July 28. So in order for that comment to have been true, the turnaround from involving the firm to filing would have had to be 3 hours or less. (and that's assuming the NLRB is on Pacific time) Gnomingstuff (talk) 01:35, 4 August 2026 (UTC)reply
When I see here so much interesting content about what's going on in English, I regret two things: the lack of interlanguage links between wikis and espacially community spaces... and my poor level of English . DarkVador79-UA (talk) 02:20, 5 August 2026 (UTC)reply
French Wikipedia Signpost-equivalent article on the WWU debacle
Article here, in French obviously. Interviews w/ Sadads, some employees, what seems to be new information not mentioned here, will bullet-point some. Apologies for Google Translating, I feel dirty about it too, anyway:
Demands for better employee representation have been reportedly going on since 2015 at least, according to one employee (who requested anonymity as did all employees mentioned here) the recent unionization efforts were catalyzed by "a cascade of departures and dismissals of colleagues with significant seniority whose voices were respected within the Foundation's staff"
According to one employee, an anti-union videoconference meeting was held March 3; after the invitation to said meeting went out, it was amended to add a "Your participation in this meeting is entirely optional" statement, to which the employee remarked: (again, Google Translated) "I really got the impression that someone from the legal department became aware of what could very easily have been considered an unfair labor practice."
The list of countries the WMF is and is not hiring from has changed recently and has created some de facto job loss: (Google Translation) "Employees who wanted to relocate to [excluded] countries were unable to do so, and some had to leave WMF. Even more incomprehensibly, according to [interviewed employee], one employee had her relocation to France refused, even though the country was not among those excluded; she left WMF. The job description created to replace her, however, included France in the list of recruiting countries."
The reassignment/re-hiring of the community tech team was the product of "external and internal pressure", unclear whether "external" means the community, the media, both, something else
regarding that last bullet point, the article got updated with the following clarification:
(google translate disclaimer again) Several employees we spoke to specifically named Selena Deckelmann as the one truly responsible for these decisions and the setbacks of recent months, which have significantly increased tensions, including within the communities. They also emphasized how much they appreciate the support of the online community. For Marcel, this is one of the first times the community has 'explicitly distinguished between employees and senior management,' he added, noting that the former sometimes bear the brunt of volunteers' frustration over decisions made by the latter.Gnomingstuff (talk) 20:04, 4 August 2026 (UTC)reply
Hi, I would clarify that what was shared was an unfinished draft. It will be published in about two hours, in the RAW issue (right now a red link) in which it belongs. The part you highlighted, @Gnomingstuff, is, I believe, an important addition (but not the only one). Best, — Jules*talk20:23, 4 August 2026 (UTC)reply
Thanks for the note -- I was confused about the date in the title, that explains it. Feel free to highlight anything else you feel is important, I focused mainly on things that I didn't remember being mentioned on enwiki throughout this. Gnomingstuff (talk) 20:28, 4 August 2026 (UTC)reply
Now it is published; your remarks are welcome. (Another interesting point, at least for me, is that several WWU members I talked to do not believe Community Tech being disbanded or Brooke Vibber being fired was intended by WMF leadership as union-busting actions. This does not mean that they think those actions were OK.) — Jules*talk22:13, 4 August 2026 (UTC)reply
To the best of my knowledge, the dissolution of Commtech was in the works for some time and the team was not specifically targeted due to the unionization effort or the union affiliations of some of its staff.
It was, however, exactly the sort of management action that gets folks already thinking about unionization to organize more effectively together. brooke (talk) 22:48, 4 August 2026 (UTC)reply
Wikimedia Foundation Bulletin 2026 Issue 14
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on July 18. Please help translate.
Meet the Wikimedians of the Year 2026: The beloved Wikimedian of The Year awards shine the light on exceptional individuals, and through them, on the whole Wikimedia community. Learn about all of this year's winners.
Public policy advocacy: Overview of Wikimania 2026 sessions about public policy advocacy. While not all sessions are recorded, you can watch some by clicking the session.
Users with extended rightspre-conference: 190 users with extended rights from all around the world gathered at a Wikimania pre-conference, to exchange experiences, learn from each other and connect.
Media coverage: The event was mentioned in many media outlets as part of wider coverage about the Wikimedia projects including in Le Monde, El Nacional and Radio France.
Improvement to Reading Lists: Community feedback around the placement of watchstar and watchlist buttons for the Reading Lists beta feature has been incorporated. 93% of participating users reported that it was useful. This feature allows saving articles for later reading – a wishlist item to bring the functionality to web.
Creating custom edit suggestions: With the TextMatch feature, volunteers can now create custom local suggestions within the VisualEditor for improving Wikipedia articles. You can find examples from other communities for inspiration. Share your feedback.
Dark mode for Content Translation: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.
Mobile page preview: Based on the conclusion of the experiment, mobile page previews feature will not be rolled out. 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.
Scaling of Explore Feed to iOS: 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, Home Feed redesign will be scaled to iOS by applying the learnings from the Android release.
Improving Account Creation process: 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. Read more.
Tech News: The latest highlights from Tech News week 30 and 31 include that now wikis can restrict editing in the “User” namespace to only the page owner and certain user groups. See also the 50 community submitted tasks that were resolved over the last two weeks.
New bot detection system for all wikis: After a successful trial, which showed evidence of both deterring bots and being easier to use, hCaptcha (our new bot detection system) has been rolled out to all wikis, for account creation, and for most newcomer edits.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. If you have feedback or suggestions about the bulletin, let us know at foundationbulletin@wikimedia.org. For questions about the Wikimedia Foundation's work, contact us!
It's neither. Articles written on Abstract Wikipedia are written by humans, using wikifunctions that are also written by humans. isaacl (talk) 02:53, 2 August 2026 (UTC)reply
Humans write many things. That doesn't change that Abstract Wikipedia articles are written by users directly and no artificial intelligence program is executed by the server software. isaacl (talk) 02:55, 3 August 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 Albury18:16, 26 July 2026 (UTC)reply
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 solidarity15:56, 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
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.
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
I went to look at WP:SPI not long ago, and saw a picture of a cat in a drawer, saying Sock drawer empty. I didn't know if this was good or bad. (I also don't know if the cat thinks that this is good or bad. She may have been in the habit of resting on the socks rather than on the wooden drawer. Then again, she might have thrown the socks out of the drawer because cats like to play with things.) It could have meant that the SPI clerks had a backlog drive and dispositioned all of the SPI's, or that a template had been broken by a reckless edit. Then I saw two SPI cases listed, very different from the usual 30 or 40. So my question is: Should we thank the hard-working SPI clerks for eliminating the backlog, and also for what appear to be some improvements in the structure and handling of sockpuppet reports, or did something improperly close all of the sockpuppet reports?
Robert McClenon (talk) 01:00, 3 August 2026 (UTC)reply
We legitimately have zero SPI cases currently! Thanks are definitely in order to all the SPI clerks, admins, and checkusers who have been working hard not only on the backlog but also on training new clerks and getting new contributors involved. As far as my memory goes, there have been only two other moments when we have reached "SPI 0": last time was in November 2022 and before that in January 2022. Well done, everyone! Mz7 (talk) 05:43, 3 August 2026 (UTC)reply
Moved from Wikipedia:Administrators' noticeboard § Current status of translation tools considered harmful.
— Rhododendrites talk \\ 22:49, 3 July 2026 (UTC)
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)
wikimedia.org so that we can investigate further.
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. 
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. 
Fixed — hike395 (talk) 01:25, 1 August 2026 (UTC)
peanut gallery comment) 
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)
and 
respectively? I uploaded these two years ago but never proposed actually adding them. splains (💬/📝) 23:30, 27 July 2026 (UTC)
Confirmed sockpuppet of Blackbombchu. 
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)
.png)
15:15, 28 July 2026 (UTC)
Let’s say that I’ll try to continue to assume good faith also about the messaging, but I also hope that the next developments would be shared with a large part of the Wikimedia communities! Sukkoria (talk) 21:40, 29 July 2026 (UTC)
. DarkVador79-UA (talk) 02:20, 5 August 2026 (UTC)
.png){kind=link}
