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.
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 "gender" be removed from the WP:EGRS guideline on "Categorizing by ethnicity, gender, religion, sexuality, or disability"? Fram (talk) 09:46, 10 August 2026 (UTC)
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)
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/C 11:12, 10 August 2026 (UTC)
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)
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)
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)
:: 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)
Disagree, as a reader they help you find many topics ~2026-43917-50 (talk) 20:55, 15 August 2026 (UTC)
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)
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)
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)
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)?
I don't know the answer to most of these questions, and this discussion is likely the wrong place to answer them. Thryduulf (talk) 17:17, 10 August 2026 (UTC)
Per MOS:GENDERID, people should be referred to as their most recent self-identified gender label. I'd assume that would apply to categories as well. So trans male chemists wouldn't be categorized under Category:Women chemists because they are not women. Shocksingularity (talk) 02:46, 29 August 2026 (UTC)
Given the asserted impact on women and transgender people, has WP:WOMEN and WP:LGBTQ+ been involved in discussing this? Davidwbaker (talk) 20:03, 10 August 2026 (UTC)
It's been 20 years since Wikipedia:Category intersection was proposed which would have solved this. I fully expect to die of old age before it will be implemented. — Hex•talk 21:20, 15 August 2026 (UTC)
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)
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)
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)
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Should editors be allowed to nominate miscellaneous pages for merging at MfD? 09:37, 12 August 2026 (UTC)
Yes. There needs to be some sort of venue when talk page discussions don't attract enough editors or more eyes are needed. voorts (talk/contributions) 14:18, 13 August 2026 (UTC)
Publicising uninteresting merge proposals to the small number of MfD regulars is a poor substitute. SmokeyJoe (talk) 22:51, 16 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)
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)
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)
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)
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)
What's to stop people from doing what was done before: starting a talk page discussion? Katzrockso (talk) 02:35, 14 August 2026 (UTC)
Nothing. This is for situations that require more than a talk page discussion for some reason. Thryduulf (talk) 03:40, 14 August 2026 (UTC)
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)
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)
A MfD discussion is also a talk page discussion. Katzrockso (talk) 23:15, 15 August 2026 (UTC)
Huh? —Myceteae🍄🟫 (talk) 23:29, 15 August 2026 (UTC)
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)
The fact that the venue for nominating pages in that namespace prohibits merge proposals; that's what stops them. FaviFake (talk) 09:33, 16 August 2026 (UTC)
This does not stop them from using RFCs or Village Pump or WP:3O or WP:DRN or seeking input from a relevant noticeboard or WikiProject. —Myceteae🍄🟫 (talk) 15:40, 16 August 2026 (UTC)
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)
I took a stab at fixing the table. If you think project space merges should be handled by rfcs, you might want to bring that up at WT:RFC. Chessenjoyer (talk) 16:01, 16 August 2026 (UTC)
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)
(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)
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)
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)
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)
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)
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)
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)
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)
Yes for consistent with AFD. Crouch, Swale (talk) 22:15, 13 August 2026 (UTC)
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)
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)
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)
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)
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)
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)
Editors with no experience or knowledge of the articles in question opining isn't necessarily a good thing. Katzrockso (talk) 13:20, 14 August 2026 (UTC)
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)
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)
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)
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)
Yes. Harmless. Aligns MFD with other XFD processes. Useful. –Novem Linguae (talk) 03:52, 14 August 2026 (UTC)
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). Sdkbtalk 04:52, 14 August 2026 (UTC)
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)
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)
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)
This proposal wouldn't stop editors from discussing merges on the talk page. Chessenjoyer (talk) 22:17, 14 August 2026 (UTC)
If this is approved, I hope any guidance is clear in not only allowing but encouraging talk page discussions. —Myceteae🍄🟫 (talk) 22:28, 14 August 2026 (UTC)
That's what they said about the PM-AfD merger and yet the merge police go around moving all the discussions to AfD. Katzrockso (talk) 22:32, 14 August 2026 (UTC)
I thought those are because the ones that started the discussion were trying to use PAM by using merge tags. Chessenjoyer (talk) 22:48, 14 August 2026 (UTC)
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)
No it shouldn't. It should be reserved for cases where the nominator believes the merge is controversial, just like at AfD. FaviFake (talk) 10:30, 15 August 2026 (UTC)
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)
I agree with FaviFake, the guidance should be the same for all merges regardless of what type of page it is. Thryduulf (talk) 12:17, 15 August 2026 (UTC)
Why is that? Katzrockso (talk) 02:56, 16 August 2026 (UTC)
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)
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.
Your question here really highlights the point @Alalch E. has made several times in recent discussions - the urge for symmetry and order just for its own sake. Katzrockso (talk) 15:58, 16 August 2026 (UTC)
+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)
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)
What I see in that thread is editors who disagree about what constitutes a formal PAM discussion¯\_(ツ)_/¯ —Myceteae🍄🟫 (talk) 17:36, 15 August 2026 (UTC)
What do you think constitutes a formal PAM discussion? FaviFake (talk) 22:43, 15 August 2026 (UTC)
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)
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)
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)
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)
The PAM process is the Wikipedia:PAM page which has already been marked historical. There's nothing more to do there. Katzrockso (talk) 15:59, 16 August 2026 (UTC)
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)
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)
As WhatamIdoing noted, a lack of shared understanding means the RfC failed. Katzrockso (talk) 18:49, 16 August 2026 (UTC)
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)
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)
Sure! But to initiate a review of the closure of an RfC, you need to go to WP:AN, not here. FaviFake (talk) 18:51, 16 August 2026 (UTC)
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)
Then if consensus was derived correctly what's your point? FaviFake (talk) 19:09, 16 August 2026 (UTC)
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.
Unintended consequences, collateral damage, and implementation challenges might also be considered a type of RFC failure. —Myceteae🍄🟫 (talk) 15:59, 17 August 2026 (UTC)
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)
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)
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))
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)
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)
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)
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)
No because this sounds more like a solution to a problem that does not exist, with a solution that could cause additional problems. Skarmory(talk •contribs) 17:27, 24 August 2026 (UTC)
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. Sdkbtalk 02:23, 25 August 2026 (UTC)
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. Sdkbtalk 02:32, 25 August 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
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. Sdkbtalk 19:28, 25 August 2026 (UTC)
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)
@Sdkb, would you say it's important to you that the decision for/against a merge be made quickly? WhatamIdoing (talk) 21:56, 4 September 2026 (UTC)
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. Sdkbtalk 22:19, 4 September 2026 (UTC)
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)
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)
What is unpredictable about the status quo? Katzrockso (talk) 04:10, 4 September 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
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"
Both of these statements can be true at the same time, if there are only five pages being considered for merging. WhatamIdoing (talk) 21:55, 4 September 2026 (UTC)
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)
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)
Should we remove, or modify, WP:CREATIVE#3, which currently reads:
The person has created or played a major role in co-creating a significant or well-known work or collective body of work. In addition, such work must have been the primary subject of multiple independent periodical articles or reviews, or of an independent and notable work (for example, a book, film, or television series, but usually not a single episode of a television series)
There is consensus against removing this criteria. Those opposing this removal expressed multiple ideas which can be summed up with: this SNG leads to the creation of notable entries which satisify our (other) content policies and guidelines. Given the clarity of this consensus over the past 2 weeks (exceeding RFEND's 7 day minimum), there is no need to wait for 30 days to close. Best, Barkeep49 (talk) 22:13, 3 September 2026 (UTC)
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.
Should this criteria be removed? 04:33, 21 August 2026 (UTC)
Yes, as first choice. SNG's should be predictive of whether someone has received sufficient coverage to write an article on them. Since very few reviews include coverage of the creator of the work, WP:CREATIVE#3 is not predictive of this, and so is inappropriate as an SNG. It also violates the principle of WP:INHERITED; a creator shouldn't be notable just because their work is, any more than a work should be notable just because its creator is. BilledMammal (talk) 04:33, 21 August 2026 (UTC)
INHERITED says: That is not to say that this is always the case (four of the notability guidelines, for creative professions, books, films and music, do allow for inherited notability in certain circumstances). I don't think that an exception that is explicitly named by that page can be considered a violation of it. WhatamIdoing (talk) 06:08, 24 August 2026 (UTC)
No, and premature RfC. SNGs are not supposed to be predictive of anything, they are an alternative to the GNG, per WP:N. WP:INHERITED is not a principle or a guideline, it is an explanatory essay, and one that explicitly excludes creators of works. Having multiple notable works is an indicator of significance that someone deserves an article. The result of such a thing would be utterly ludicrous; we could, and would, have people who have dozens of notable works but cannot have any article about them to link their works together or to connect the reader to further information about the author, or their other works. It is grossly unencyclopedic and contrary to established scholarly practice for literary works. Further, information about the work is inherently useful for constructing articles on the authors, separating coverage of what someone does from them is nonsensical; there is no 1 fact we are mandated to have for an article, and per WP:PAGEDECIDE, it is often in fact better to merge less notable works to their creators rather than keep them isolated. PARAKANYAA (talk) 04:39, 21 August 2026 (UTC)
Removing CREATIVE#3 wouldn't prevent us from having a list article on their works, it would just prevent us from producing a biography from pieced together primary sources. I'm also not convinced that there are creatives with dozens of notable works who would not meet WP:GNG. BilledMammal (talk) 04:41, 21 August 2026 (UTC)
Yes, it would, such a list would not be notable if the person would not be. And why would having a list with no detail be better than having a biography with detail? Notability aside, this is proposing that instead of having [x author article] we have only [List of x author's works] with no background detail. Who does this help? Why would we do this? PARAKANYAA (talk) 04:48, 21 August 2026 (UTC)
The list will be notable if the body of work is notable. It also helps because it stops us trying to force a biography out of trivial mentions in reviews and primary sources, and because creatives don't need many notable works to be eligible for an article under WP:CREATIVE#3 - they only need one. BilledMammal (talk) 04:52, 21 August 2026 (UTC)
No, it wouldn't be, because where would the sources be to pass WP:NLIST? if we're going to appeal to WP:NOTINHERITED, then that especially.
"It also helps because it stops us trying to force a biography out of trivial mentions in reviews and primary sources" if the reviews are trivial, that is a problem for work notability, and there is no problem with appropriate use of primary sources. There would also be nothing prohibiting adding the content you object to to a list article; even split off list of works for notable authors include biographical information. This would amount to just forcing us to make all articles on obscure authors be incorrectly named.
They do need multiple, a "body of work" is not 1 thing. PARAKANYAA (talk) 04:56, 21 August 2026 (UTC)
The sources would be the ones discussing the body of work? We also generally keep lists whose purpose is navigational.
There is a problem with building a biography almost entirely out of primary sources, which is what is required if the reviews don't contain more than passing mentions of the person, as it violates WP:PRIMARY, which says Do not base an entire article on primary sources, and be cautious about basing large passages on them.
A single work is enough to meet WP:CREATIVE#3; The person has created or played a major role in co-creating a significant or well-known work or collective body of work. BilledMammal (talk) 05:20, 21 August 2026 (UTC)
Who says we have those sources? And why would we?
We wouldn't be basing "the entire article" off of it, we would be basing it off of critical analysis of their works and then augmenting basic facts as allowed by WP:ABOUTSELF.
A single notable work would be WP:BIO1E except in cases where it is, as WP:CREATIVE says, so "significant or well-known" as to overcome that. PARAKANYAA (talk) 05:26, 21 August 2026 (UTC)
If we base it off of analysis of the work, then the article is on their works and not the author. So either the article isn't on the subject is claims to be on, or it violates WP:PRIMARY - either way, its a problem.
"significant or well-known" is typically interpreted as "notable". However, I'm going to stop responding here; this discussion chain is deep enough already. BilledMammal (talk) 05:38, 21 August 2026 (UTC)
The difference here is that you don't seem to think an author's career is information on the author. Katzrockso (talk) 13:26, 21 August 2026 (UTC)
Biographical articles that focus on the author's work do something that lists and bibliographies do not. As I stated over at Clarifying NAUTHOR, these articles are merely lists of works. Creative biographies often include in-depth information about their works, as well as things like awards and honors, which are not found in lists and bibliographies. Author's biographies can also tie in information from primary sources to provide additional context for their work. Significa liberdade (she/her) (talk) 14:51, 21 August 2026 (UTC)
with the exception of NPROF and NCORP, all SNGs are predictive of whether meeting some criteria will likely lead to a non stub quality article that meets the core content policies. Its why the are set up as rebuttal presumption to favor early article creation in the wiki mainspace, but if it turns out that a thorough source search and review doesnt allow for much more to be said, then the SNG's presumption waa wrong and deletion or merging makes sense. Which is why the SNG criteria should be cases we can be assured sources likely exist or will come about because of some clear point of achievement or merit. Masem (t) 17:52, 26 August 2026 (UTC)
No, after reading the background discussion. I fail to see how reviews discussing somebody's life and career aren't actually discussing the person, just because those reviews focus on, say, a book or a play they have written. GreenLipstickLesbian💌🧸 04:42, 21 August 2026 (UTC)
Trying to define a list of somebody's works (presumably, alongside their name and a few explanatory details )as anything other than a rudimentary biography is also splitting hairs, to me -- read any biographical dictionary, and you will find entries that are little more than a few basic facts, followed by a list of somebody's work. GreenLipstickLesbian💌🧸 04:45, 21 August 2026 (UTC)
Because these reviews aren't discussing somebody's life or career, they're discussing a work which that person happened to create. To take an example from the previous discussion, Harry is a hugely likeable child, kind but not wet, competitive but always compassionate tells us nothing about the author, but is usable for an article on their work. BilledMammal (talk) 04:50, 21 August 2026 (UTC)
1. Yes of course what the person writes about is a statement about them. If a source summarizes someone's theories, for example, that is about them. If we have a book that discusses a scientist's various theories for 2 dozen pages we wouldn't decide to have an article on [x's theories] and not [x].
2. Plot only descriptions of works are prohibited by MOS:PLOT so honestly that would help with the work article even less than it would help the author's. PARAKANYAA (talk) 04:53, 21 August 2026 (UTC)
Yes, this, pretty much. We don't have plot only descriptions of works, we look for reviews that discuss reception, meaning, provide analysis. You know, review the work. And those are inextricably linked to the creator of the work -- because, unlike the use of the passive voice here suggests, it is widely accepted that most works are created deliberately by individuals, not just something they happened to create.
And if the reviews of Harry Potter series were confined only to the single quoted line, I would likely agree that there's little to prove notability -- but as was pointed out in the discussion, this is a very selective quote as the review was longer than that, and did include biographical detail on Rowling. (Though, admittedly, I fault o see how "Rowling wrote a book about a child character, who XXX reviewer described as "competitive but always compassionate" is unusable and unrelated to the author so as to obviously fail to merit a mention in a biography.)GreenLipstickLesbian💌🧸 04:59, 21 August 2026 (UTC)
1. We're not discussing scientists, we're discussing creatives.
2. In my opinion, that sentence goes beyond plot summary and into analysis. However, whether it contributes to GNG for the work isn't relevant; the point is that it tells us nothing about the author. (And in reply to GLL, in the previous discussion I agreed that the review as a whole contributed to GNG, but that sentence does not - the point indeed is that many reviews do contribute to GNG, and that we shouldn't rely on the ones that don't) BilledMammal (talk) 05:23, 21 August 2026 (UTC)
1. Why would we treat those differently given the objections you described would apply equally to them? Plenty of nonfiction authors and scientists who write books are covered by this guideline.
2. I don't agree on that containing analysis, but "the author wrote about a character named Harry Potter who is characterized as xyz" or "the author writes about wizards" or "the author created a fantasy world with wizards", which you could use the review in question to say, is a statement about the author. Taken in isolation, I'd say that actually (theoretically, not like a sentence counts for anything) contributes more to the author's notability than the books, because you can recontextualize that to be more than MOS:PLOT summary, which alone doesn't even count for work notability. PARAKANYAA (talk) 05:30, 21 August 2026 (UTC)
We are discussing scientists, though; WP:NCREATIVE is a nice shortcut, but the section itself applies to authors, editors, journalists, filmmakers, photographers, artists, architects, bolding own. GreenLipstickLesbian💌🧸 05:31, 21 August 2026 (UTC)
Because authors, editors, journalists, filmmakers, photographers, artists, architects aren't scientists, who are instead covered by WP:PROF.
the author wrote about a character named Harry Potter who is characterized as xyz is talking about the work, not the author; it's the character who is characterized, not the author. BilledMammal (talk) 05:33, 21 August 2026 (UTC)
Scientists are frequently authors and editors and any scientist who writes books is covered by this guideline.
Saying that the author wrote about something is a statement about them. Is a statement that "[x physicist] researched [black holes/quantum gravity/physics idk] and discovered [xyz]" not a statement about the physicist? PARAKANYAA (talk) 05:36, 21 August 2026 (UTC)
All I'm going to say is that I see WP:PROF, not WP:NCREATIVE, as applying to academics, and that as this discussion is already too deep I'm going to stop responding here. BilledMammal (talk) 05:38, 21 August 2026 (UTC)
I think that, though it would be nice if we could divide the world into such clean, black and white divisions, in terms of what's practical, those divisions fall apart rather rapidly. An anthropologist or linguist, for example, may easily be notable as an author, first and formost. (Art history is actually somewhere the divisions fall apart very rapidly, if you're looking for an example -- historically, in Western academia, people who studied and wrote on Native American art could be considered a scientist before they were considered an art historian by their peers. Yet they're dealt with under NCREATIVE on Wikipedia, in most cases) GreenLipstickLesbian💌🧸 05:49, 21 August 2026 (UTC)
@BilledMammal, most academics in the humanities are judged by NAUTHOR. In solidarity, asilvering (talk) 07:00, 21 August 2026 (UTC)
As a general comment, some editors seem to struggle with the idea that a single source can contribute to notability for more than one subject. If the source is mainly about a book and partly about the author (for example), some editors feel like that source cannot contribute to notability of the author at all (and vice versa). Maybe we need to address this in WP:N directly. WhatamIdoing (talk) 06:11, 24 August 2026 (UTC)
That seems like a good thing to get clarified. I've always operated that way (a source can contribute to notability of multiple entities). ++Lar: t/c 22:20, 25 August 2026 (UTC)
No per Parakanyaa and GLL above, and per pburka's comment in the previous discussion along with its subsequent replies from LEvalyn, Significa Liberdade and asilvering. In solidarity, nilnz 05:22, 21 August 2026 (UTC)
No - this does not solve any of the issues from the other thread —Preceding unsigned comment added by Czarking0 (talk • contribs) 06:36, 21 August 2026 (UTC)
No, per my comment on the earlier thread. This is not some SNG that is an end-run around the GNG - the works in question have to be notable works. This is, effectively, a rule of thumb that allows us to short-cut having to have a whole pile of repetitive WP:PAGEDECIDE discussions. It is much more useful to readers to have a single article on a mildly obscure author that discusses their four notable books than it is to have to go to four individual book articles to find that information. It's also easier for us to maintain. In solidarity, asilvering (talk) 06:57, 21 August 2026 (UTC)
I've created a sub-question that should allow #3 to continue meeting the purpose you support it for, while preventing the worst of its excesses. BilledMammal (talk) 07:20, 21 August 2026 (UTC)
No, and I don’t understand what problem this is even theoretically supposed to address. Moreover, I reject the premise that the SNG is not predictive of a writable article. I’ve never seen an author with multiple notable books for whom a useful bio article could not be written. ~ le 🌸 valyn (talk) 08:10, 21 August 2026 (UTC)
I’ll give Deborah D. Rogers as an example of an article that can only exist with this SNG but, I contend, should exist. ~ le 🌸 valyn (talk) 15:33, 21 August 2026 (UTC)
Yes - The issue is the reliance on reviews of works to establish that this is met. If an author, for instance, has truly created a large and notable body of work, it will usually be the case that the author has been discussed in biographies, but unlike LEvalyn above, I have seen quite a few authors who have reviews and bout whom very little is known. The case in point I raised in another discussion is the self published author Morgan Rice, who has written a lot, probably makes a good wage, but is not covered in secondary sources (although an author interview exists). But authors use pen names. Do we even know this person is really called Morgan rice? I just googled and found I'm not the first person to ask that question. There are plenty of known uses of pseudonyms (Anne Fine is Anne Pilling too and has other pseudonyms). If we go just off reviews and the fact someone published a lot of books, we find ourselves writing pages that are not based on independent reliable secondary sources. If we used GNG/ANYBIO, we would not have this problem. So as per BilledMammal above, the criterion as written is not predictive, and inasmuch as LEvalyn is right that in most cases there are bound to good sources from which a BIO can be written, we can just rely on the sources per GNG/ANYBIO. We don't need this shortcut, that allows us to retain biographies of people who may not even exist. Sirfurboy🏄 (talk) 10:09, 21 August 2026 (UTC)
Without rehashing the conversation with BilledMammal above, where it would just amount to me repeating myself, addressing this one point: Do we even know this person is really called Morgan rice? Why would that make a difference? Plenty of people notable by GNG go by stage names or pseudonyms. Really, if we had RS that talked about it, while they tried to hide it, we shouldn't even include it, per WP:BLPPRIVACY. PARAKANYAA (talk) 12:15, 21 August 2026 (UTC)
What does this biography of a living person tell us about this person who may or may not be called Morgan Rice? WP:BLPs have to be written from independent secondary sources. If such don't exist, we should not be pretending that an encyclopaedic biography of the person is possible. The guideline is making us breach our own policies. Sirfurboy🏄 (talk) 12:19, 21 August 2026 (UTC)
That they produce self-published books, are apparently one of the more prolific self-published authors, the critical and commercial response to their body of work? I'm not sure what else I'd want; what other facts are we required to have for an article, besides what the person does? Sure, and reviews are independent secondary sources. PARAKANYAA (talk) 13:02, 21 August 2026 (UTC)
in a biography of the person I'd want much more. The article is, surely, about the person. If the person even exists. Sirfurboy🏄 (talk) 13:20, 21 August 2026 (UTC)
Your personal requirements don't dictate Wikipedia's and why should they? Katzrockso (talk) 13:27, 21 August 2026 (UTC)
It is not about personal requirement, but about the type of article we are writing. If you want a biography of a living person, the clue is in the name. It should be a biography. Of a person. The guideline allows us to keep BLP articles that break our rules. If you want an article that talks about the critical response to the body of self published work that is attributed to Morgan Rice, then write that. Don't pretend it's a biography of Morgan Rice. It is not. Sirfurboy🏄 (talk) 13:35, 21 August 2026 (UTC)
Notability is a guideline. BLP is a policy. If an article violates the BLP policy, make that argument in a deletion nomination, and hopefully a closer would weight that argument per WP:ROUGHCONSENSUS.
Obviously not everyone agrees that the articles are breaking the BLP policy. Katzrockso (talk) 15:12, 21 August 2026 (UTC)
If Wikipedia has existed in her lifetime, George Eliot could have had an article even when her personal identity (and biological sex) was unknown. I don't see the problem here. Carwil (talk) 12:25, 21 August 2026 (UTC)
What would it have told us about her? Sirfurboy🏄 (talk) 12:34, 21 August 2026 (UTC)
That she was a leading and influential writer, her style of writing, her influence, etc. Katzrockso (talk) 13:22, 21 August 2026 (UTC)
See my reply to you above. Sirfurboy🏄 (talk) 13:36, 21 August 2026 (UTC)
As I stated in the previous conversation, ANYBIO #1 states, The person has received a well-known and significant award or honor, or has been nominated for such an award several times. A person can receive significant awards without having biographical information published in reliable, independent sources. Significa liberdade (she/her) (talk) 15:05, 21 August 2026 (UTC)
With LEvalyn is right that in most cases there are bound to good sources from which a BIO can be written, we can just rely on the sources per GNG/ANYBIO you have misunderstood my argument. In most cases there are non-independent sources from which a bio can be written, which do not pass GNG or ANYBIO, but can be used anyway to write a helpful article per WP:ABOUTSELF if their works instead entitle them to an article through the SNG. That is why the SNG is useful and necessary for such articles to exist. ~ le 🌸 valyn (talk) 15:26, 21 August 2026 (UTC)
Then our disagreement is broader. I don't believe anyone is entitled to a biographical article if the sources from which a tertiary bibliographic article must be written do not exist. What we end up with is secondary biographies. Sirfurboy🏄 (talk) 15:45, 21 August 2026 (UTC)
No, per asilvering and GreenLipstickLesbian. It's usually possible to produce a useful and encyclopedic article about someone who produced multiple notable works using in-depth secondary sources analysing their body of work, even if the biographical information within that article might be more limited. It's also much better from the reader's perspective to have that information about someone's life and works in a single place rather than being forced to split it across articles about their notable individual works. MCE89 (talk) 13:20, 21 August 2026 (UTC)
No unless someone can come up with better edge cases than Morgan Rice. I don't find the "but they might use a pseudonym" argument convincing at all. Either they continue using the pseudonym, in which case that is effectively their identity, or their "real" name is revealed, in which case we move the page or merge it. Gnomingstuff (talk) 13:50, 21 August 2026 (UTC)
They may not be one person at all. As per the link I put for Morgan Rice. We may be hosting biographies for content farms. In the case of people like Anne Fine, we might have multiple biographies for the same person (not there, since we do have biographical details - but in the cases we don't know about). But, in fact, unless we know some biographical details about the people, none of these are biographies at all. We need a guideline that helps us recognise that a policy compliant biography is due. Sirfurboy🏄 (talk) 14:11, 21 August 2026 (UTC)
I think it’s appropriate that we have articles on, say, Carolyn Keene and Franklin W. Dixon, who are not real individuals but collections of ghostwriters. ~ le 🌸 valyn (talk) 15:17, 21 August 2026 (UTC)
No per the discussion at Wikipedia talk:Notability (people)#Clarifying NAUTHOR. The example I've worked with most recently is Kathleen Jennings (illustrator). The biography is created almost entirely with primary sources accepted by WP:ABOUTSELF. However, Jennings has a large catalog of work and has won multiple notable awards for her collection of work, meeting ANYBIO#1. It would be dishonest of Jennings's career to only include her notable publications on Wikipedia, given that she is notable as an individual. Significa liberdade (she/her) (talk) 15:10, 21 August 2026 (UTC)
Oo, adding here that Elena Ferrante is actually a good example. Despite wide-spread fame, Ferrante has kept her identity and biographical information hidden--to the point that part of her article is about how she has kept her identity hidden for over 30 years! Significa liberdade (she/her) (talk) 16:21, 21 August 2026 (UTC)
No I am sympathetic to the argument that this criteria could be tightened (not in the way in proposal 2), but as GreenLipstickLesbian explains above, there is not necessarily a clean or clear division between a review of a work and a discription of the creator. And in general, I do believe that readers want to see biographies of creators of notable works. --Enos733 (talk) 15:35, 21 August 2026 (UTC)
If anything I might tighten (in practice) or consider removing the singular in a significant or well-known work - because our general practice of three reviews to make a work significant or well-known may not be predictive that any or enough biographical information is present in the reviews to warrant an article. Enos733 (talk) 15:46, 21 August 2026 (UTC)
The author that comes to mind here is Harper Lee. In 2012, her article was primarily based on her sole notable work, To Kill a Mockingbird. In this case, we had independent coverage to discuss her as an author. However, she had a single, extremely notable work. In other cases, the question may become, "Do we have an article for the work with an 'About the author' section (if relevant), or do we have an author's biography with their single notable work?" Honestly, either would be fine by me. Significa liberdade (she/her) (talk) 16:02, 21 August 2026 (UTC)
I'd support tightening it to say "collective body of work" only because the cases where a single work would be enough are so exceptional that an abundance of sigcov would cover it IMO. PARAKANYAA (talk) 16:24, 21 August 2026 (UTC)
Fair, I think there are far fewer cases where someone only has one notable work and yet a separate author bio is warranted; when it happens, like with Harper Lee, the sourcing is probably GNG/NBIO material and doesn't need to be covered by the SNG. In most cases I think an 'Author' section on the book article is the better approach, like at Unexpected Destinations. I would be willing to remove the words work or so the requirement is just a significant or well-known collective body of work. Possibly with a footnote stating that those with exactly one notable work, should be covered on that work's article. ~ le 🌸 valyn (talk) 16:26, 21 August 2026 (UTC)
I'd vote against that - there are a lot of people where that would cause controversy/confusion as a clash between two notability guidelines if recommending that one work should be covered on the work's article - just in writers see Harper Lee (To Kill a Mockingbird), Margaret Mitchell (Gone With The Wind), Emily Bronte (Wuthering Heights), Anna Sewell (Black Beauty), and so on Jishara (please ping upon response) (talk) 06:04, 26 August 2026 (UTC)
People who meet WP:GNG or WP:BASIC do not need to also meet every SNG that might apply to them (People who meet the basic criteria may be considered notable without meeting the additional criteria below). —Myceteae🍄🟫 (talk) 16:17, 26 August 2026 (UTC)
I know they're exclusive, but it'll cause confusion if the guideline recommends that those with exactly one notable work should be covered on that work's article - so I oppose the footnote Jishara (please ping upon response) (talk) 17:42, 26 August 2026 (UTC)
Is this a problem now? There must be thousands of subjects that meet GNG but would fail one or more SNGs that could be applied to them given their profession or background. —Myceteae🍄🟫 (talk) 05:19, 27 August 2026 (UTC)
For clarity, the confusion IMO at AFD would come with the footnote saying people with one notable work should be covered on that work's article - because it's a SNG not just not being met but explicitly saying you shouldn't do a separate article. Jishara (please ping upon response) (talk) 13:47, 27 August 2026 (UTC)
Trimming this to ≥2 notable works is sensible. Some biographical information about the creator can reasonably be covered in the article about the single work. —Myceteae🍄🟫 (talk) 05:18, 26 August 2026 (UTC)
No per Gnomingstuff and per the unconvincing case made by the yes votes. The arguments above seem to be conflating notability and verifiability/BLP. If an article has unverifiable information, remove it. If it has poorly-sourced claims about living people that might be defamatory or privacy-violating, remove them. If there's enough left for a stub, great. If not, delete it. IMO this change would result in losing some desirable articles without a corresponding benefit to outweigh that cost. -- LWGtalk(VOPOV) 16:16, 21 August 2026 (UTC)
Yes. Notability is not inherited, up or down. It is entirely possible for works to be notable but their creator not to be, or vice versa. If the works are notable but the creator is not, create articles about the works, mention the creator in those articles, but do not create a pseudo-"biography" just based upon "They created X and Y and Z and...". To write a biography, we need actual biographical material. If the available source material is about the works, not the creator, then that means the works, but not the creator, are notable. SeraphimbladeTalk to me 16:32, 21 August 2026 (UTC)
What is "biographical material" if not material about what the person does? What additional information do we need? PARAKANYAA (talk) 19:05, 21 August 2026 (UTC)
The WP:NOTINHERITED part of the WP:Arguments to avoid in deletion discussions essay explicitly states that four of the notability guidelines, for creative professions, books, films and music, do allow for inherited notability in certain circumstances. Katzrockso (talk) 21:36, 21 August 2026 (UTC)
Recommending practicality here is far more useful than black letter law approaches. It might well be that there is an author with numberous notable texts, but little biographical information, and so what? The "biography" is a list which satisfies NLIST. Case by case approaches guided by, for example, NOPAGE, NLIST and BIO can all serve to determine the best outcome. Goldsztajn (talk) 05:58, 22 August 2026 (UTC)
If we have an author's biography that simply says, "[Name] is an author", followed by a list of their works, then yes, a bibliography or list would make sense. However, even when talking primarily about the works, an author's biography creates a narrative about that person's career and their writing. Significa liberdade (she/her) (talk) 14:21, 22 August 2026 (UTC)
No. The actual harm here hasn't been shown in any way. I'd be much more convinced if we had a group of articles that would clearly be deleted after this and that were clearly unencyclopedic and harmful to the living person covered, but right now we're discussing a theoretical case, and there have already been a few examples mentioned of cases of encyclopedic good articles that would be removed under this policy. Gbear605 (talk) 17:48, 21 August 2026 (UTC)
No per PARAKANYAA. Whether or not biographical content sourced to primary and/or non-independent sources is appropriate for the articles for whom there isn't much biographical content in secondary independent sources is a different question as to whether these articles serve an encyclopedic purpose and should exist. Even if we excise all such content, we could retitle them all to "Works published by X author" and they would be encyclopedic articles that should exist based on the reviews of these notable works.Katzrockso (talk) 21:41, 21 August 2026 (UTC)
Yes (although it seems like a lost cause at this point). As it stands, this flies in the face of WP:NOTINHERITED. Take Team Cherry as an example, the game studio behind the wildly successful Hollow Knight and Silksong. Even they're not considered notable enough to have a dedicated article (that may change, but it was at least the case for an extended amount of time). Why should this really be any different? And what the hell even counts as "a significant or well known work"? This is just too vague as it stands, and it's too easy for people to point to this and go "look look! a couple of their books got some reviews! neener neener, notable!". –Deacon Vorbis(carbon•videos) 22:34, 21 August 2026 (UTC)
maybe not the greatest example; haven't looked but I wouldn't be surprised if there were significant coverage of Team Cherry now, it's been a long time since 2017 when the article was in bare bones form and subsequently converted to a redirect Gnomingstuff (talk) 19:44, 22 August 2026 (UTC)
Yes, the 2017 article seems very similar to an author with exactly one notable book, ie, an author who would not typically pass NCREATIVE and who would be covered on their book's article instead. Now that there are multiple games and a longer history for the company, I'm sure an article could be written; I see several sources on Google Scholar that look like WP:NCORP for Team Cherry. ~ le 🌸 valyn (talk) 21:38, 22 August 2026 (UTC)
We shouldn't derail this discussion too much on one example, but I'll say that surprises me, though when I look closer it seems they are famous for never telling press/researchers anything so although there are some sources like this, this and this which analyze their role in the Australian indie games industry, they do seem to get a lot less detailed coverage than similar studios like House House. ~ le 🌸 valyn (talk) 20:51, 23 August 2026 (UTC)
Why should this really be any different? The reason WP:NCORP sets a higher bar is to address specific problems with sources in this area, as explained at WP:ORGCRIT. —Myceteae🍄🟫 (talk) 06:34, 26 August 2026 (UTC)
No. NOTINHERITED isn't a policy or a guideline, and I don't think there's any merit to the idea that careers and lives can somehow be teased apart, and that a notable career doesn't contribute to a life's notabality. Even if basic biographical details are missing, articles about notable bodies of work are encyclopedic. pburka (talk) 22:48, 21 August 2026 (UTC)
No "Il n'y a pas de hors-texte"? Non, merci. Regards, --Goldsztajn (talk) 23:57, 21 August 2026 (UTC)
No. Incredible that this has gone as far as a rfc without much more discussion. It's a proposal to blow up huge sections of the encyclopedia. Jahaza (talk) 00:55, 22 August 2026 (UTC)
this has been a pattern with this editor for like 5 years or so, they have now turned their scope to entertainment rather than sports Gnomingstuff (talk) 19:37, 22 August 2026 (UTC)
No because even in those cases where an encyclopedic article definitely cannot be written about an author, a page with an overview of their work is still useful for navigation. In those cases the author page is just a container to put encyclopedic content about their works, for example as an alternative to having multiple short articles connected by a navbox. (I would support requiring at least two works, since if an author is truly only notable for one work, it's probably meaningless to discuss them apart from that work. I don't see any benefit to rebranding articles about otherwise non-notable authors as "List of works of X", but it'd be a less objectionable compromise than deleting such articles outright.) • jhvxtalkedits 12:50, 22 August 2026 (UTC)
No, because while we profess to have articles for the notable, we should not be settling only for what WP:GNG covers, which is the noted. We have reasonable ways around that in place for scientists and such, where we can track their influence through citation rankings. It is reasonable to also allow some such evaluation in creative realms. --Nat Gertler (talk) 13:57, 22 August 2026 (UTC)
No per Asilvering. It seems like a useful way to help us organize the encyclopedia's coverage of notable topics, and from my initial impression I don't see a compelling case that it is being abused to permit coverage of non-notable topics. Sdkbtalk 16:12, 22 August 2026 (UTC)
No I believe it addresses an important gap in the GNG policy wherein creative works are seen and judged as an extension of the creator themselves, so specifically discussing the creator may not be seen as necessary. ᴢxᴄᴠʙɴᴍ (ᴛ) 06:58, 23 August 2026 (UTC)
No This has nothing to do with "inheriting" any form of notability. Because the subject is the one creating the thing, they are the notability itself, whether talking about a work created or a highly influential theory/body of research produced. They made the thing, they inherited nothing. The notability of the thing belongs to them directly. SilverserenC 20:20, 23 August 2026 (UTC)
Yes Notability is not inherited, full stop. Let'srun (talk) 21:54, 23 August 2026 (UTC)
Maybe we need to re-write this to explain it better. The important question isn't "Since Alice Author wrote three notable books, can't I have an article about each of the books, plus another one for Alice herself?" The point is more like "Rather than having three separate, standalone (and probably short) articles about each of the books, and then debating whether to have a fourth article about the author, how about we have one merged-up article (which I guess we'll name after the author, since picking just one book title won't work)?" See also all the debates about whether to have an article about Frank Founder and another article about the company he founded: if the reliable sources tend to talk about both, then sticking both the BLP and the founder in the same article isn't "inheriting"; it's just a practical merge result. WhatamIdoing (talk) 06:06, 24 August 2026 (UTC)
No: a creator is notable for what they have created. Their works give us the outline of their biography:
"X is/was a yyy active in [country/continent] in [period]. Their works include... [list of notable and other works]".
Anything more is a bonus. The article may, or may not, grow to include further biographical information as more is learned/published about the creator. PamD 09:23, 24 August 2026 (UTC)
No: As several above commentators have noted, there are many artists who are of encyclopedic interest because they have produced many notable works yet fail to meet any of the remaining WP:CREATIVE standards, and I see no reason to exclude them. Pudelpointed (talk) 19:13, 24 August 2026 (UTC)
No. Creators are notable for what they have created, just as athletes are notable for their athletic performance. It is nonsensical to throw out the in-depth coverage of those creations (when it exists) just as it would be nonsensical to require athletes to prove notability through sources that avoid discussing their athletic performances. —David Eppstein (talk) 00:22, 25 August 2026 (UTC)
No This is a weird misreading of WP:INHERITED and, as others have observed, misses the point of why creators are notable: the work they create. Removing this criterion would bias our coverage in favor of creators who are known for scandals instead of for their art. Stepwise Continuous Dysfunction (talk) 16:58, 25 August 2026 (UTC)
No. If the work has been the primary subject of multiple independent periodical articles or reviews, the creator does satisfy GNG. This proposal implies, for example, that Acts and omissions done by George Washington during his lifetime is a separate topic from George Washington, and that George Washington should only discuss his anatomy. The result would be a proliferation of articles with an unencyclopedic scope and a page name that is unreasonably difficult to search for. James500 (talk) 19:45, 27 August 2026 (UTC)
No. When a creator has one notable work, the creator redirects to the work. So when a creator has two notable works, we should return it to a redlink? No. It should be a way for someone to navigate to either work, and if the creator happens to have other reliably-sourced information about them, why not throw it in. Functionally, NCREATIVE#3 allows for a specialized type of list reskinned as a biography, and I am okay with that. theleekycauldron (talk • she/her) 21:54, 28 August 2026 (UTC)
Yes It is overly vague as to what constitutes a "major role" or a "significant work". Even if works are notable and have received reviews, that does not necessarily mean a person involved in its production is notable if there is a lack of coverage of that person. At the least this needs to be tightened up as to what type of creative roles and works it covers – a sole author of bestselling books has a stronger claim to this than one of the countless people involved in a film's production. Reywas92Talk 02:01, 29 August 2026 (UTC)
No. In-depth coverage about someone's works necessarily provides something about the person, style etc. For someone with a couple of books with a couple of reviews each, it is also better to collect everything in the biography instead of spreading it out per WP:PAGEDECIDE. Geschichte (talk) 07:09, 30 August 2026 (UTC)
Maybe NCREATIVE needs to add something similar to Wikipedia:Notability (books)#Merging to broader subjects, only saying "sometimes it's better to collect everything about a couple of books in a single article nominally about the author, instead of having multiple separate articles about the books". WhatamIdoing (talk) 21:28, 30 August 2026 (UTC)
No. I'm coming to this late, and others have made very eloquent arguments. What it comes down to, for me, is that creatives are notable for the work they create. And, at the end of the day, the notability guidelines are only guidelines: if there are other reasons that weigh against creating an article, then those can be taken into account. Chocmilk03 (talk) 21:27, 1 September 2026 (UTC)
No. This will tend to eliminate women. Also, until the "coast is clear" next year, we should not change any notability standards. Powerful men are seeking to find any excuse to eliminate our charitable status. Come back next January. Bearian (talk) 00:31, 3 September 2026 (UTC)
No per Asilvering for logistical reasons and per Stepwise Continuous Dysfunction because eliminating it will make it harder for us to write biographies of creators who have genuine notability but don't attract coverage about them in a media landscape that prioritises coverage of scandal and controversy. Dclemens1971 (talk) 11:53, 3 September 2026 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The chance that this proposal will pass after a full 30 days is negligible. With only one editor in support, the vast majority argued that co-creations should stil count towards a subject's notability and that a co-creator is a creator. They also argued that this could lead to arguments over which co-creator of a work should be the "primary" one. Further discussion of the main proposal can continue above and below. Chessenjoyer (talk) 16:05, 28 August 2026 (UTC)
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.
Should WP:CREATIVE#3 be modified to remove or played a major role in co-creating? 07:19, 21 August 2026 (UTC)
Survey (Applying WP:CREATIVE#3 only to the creator)
Yes, as second choice to removing. Much of the arguments against removing WP:CREATIVE#3 is that it is necessary for creatives who are not independently notable but have created a significant body of work. However, this reasoning doesn't apply to individuals who were not the creator; screenwriters, editors, etc etc etc. They are also where many of the issues with this guideline originate; a creator of several notable works is likely to meet WP:GNG, but that cannot be said of someone who was merely involve in the creation, even if the meet the nebulously defined "major role". Removing this aspect will go a long way towards addressing the issues with this guideline. BilledMammal (talk) 07:19, 21 August 2026 (UTC)
Respectfully, @BilledMammal, given that it's been a few days now, I think this second choice is snowing. Would you object to a close along those lines? GreenLipstickLesbian💌🧸 06:34, 26 August 2026 (UTC)
No "Major" is not that nebulously defined to most people, and neither is co-creator. This would exclude books which had two authors, books which had editors, a play which had two authors, all films, all documentaries, from counting towards the notability of their major co-creators. GreenLipstickLesbian💌🧸 07:49, 21 August 2026 (UTC)
Also, I feel like I have to note "merely involve[sic] in the creation" would already fail NCREATIVE #3 as written. The guideline does not allow what the RFC creator is worried about. GreenLipstickLesbian💌🧸 08:04, 21 August 2026 (UTC)
No. Co-creators of major works or major bodies of work are notable. And the "creator" vs. "co-creators" distinction the proposer makes is unwise, especially in the film context in which they are making it. Screenwriters, editors, and production designers all receive more professional recognition (e.g., Oscar nominations) than press, and these kinds of "primary" coverage are plenty of information for us to write encyclopedic articles from. I think the encyclopedia benefits from covering figures like Catherine Martin (designer) when she assembled her body of notable work rather than when say Vogue took an interest in her.--Carwil (talk) 12:12, 21 August 2026 (UTC)
No. Let's say a graphic novel, for example. We have an author who writes the story and the illustrator. Both should be recognized for their work on the book as co-creators. This is already clear as GLL explains above. Significa liberdade (she/her) (talk) 15:14, 21 August 2026 (UTC)
No per my rationale for Q1. -- LWGtalk(VOPOV) 16:17, 21 August 2026 (UTC)
No, the others have pointed out many examples where co-creation is the norm and we ought to be able to discuss each major contributor. Passing contributions are already disallowed. ~ le 🌸 valyn (talk) 16:38, 21 August 2026 (UTC)
No, per above and also because we do not need to codify the auteur myth in our guidelines. If someone is stretching the definition of "major role" that will be obvious. Gnomingstuff (talk) 18:48, 21 August 2026 (UTC)
No, this would introduce even more confusion into the guideline.Katzrockso (talk) 21:44, 21 August 2026 (UTC)
No. A co-creator is still a creator. Is Lilly Wachowski less notable because she only co-created The Matrix? pburka (talk) 22:51, 21 August 2026 (UTC)
NoWP:UCS. There's a problem with people claiming best boys are co-creators? Regards, --Goldsztajn (talk) 00:01, 22 August 2026 (UTC)
No. a co-creator is a creator. Jahaza (talk) 00:53, 22 August 2026 (UTC)
No Many creative realms rely substantially on creative teams. To look at the world through the lens of Black comic book characters who ended up in larger media (yes, we each have our lenses): Jack Kirby co-created the Black Panther with Stan Lee, who co-created The Falcon (i.e., the MCU's current Captain America) with Gene Colan, who co-created Blade with Marv Wolfman, who co-created Cyborg with George Perez. If each of these people had done nothing else (which is the case for none of them, admittedly), Stan, Gene, and Marv's co-creator status on multiple works of impact is a clear body of work of importance. -- Nat Gertler (talk) 14:27, 22 August 2026 (UTC)
No It would lead to big debates about who the "main creator" of something is. ᴢxᴄᴠʙɴᴍ (ᴛ) 07:01, 23 August 2026 (UTC)
No The whole point of that note is that not everything has a singular creator. That's just a factual statement. A book can be written by two or more authors, ect. You don't pick one as the "primary author", that's dumb. SilverserenC 20:22, 23 August 2026 (UTC)
No: "played a major role in co-creating" can do its work. PamD 09:28, 24 August 2026 (UTC)
No. What even is the rationale for this? If they played a major role, they are a creator. This seems less like something well-motivated than a way to increase wikilawyering by carving out exceptions for people who are deemed unworthy of counting as creators. —David Eppstein (talk) 00:24, 25 August 2026 (UTC)
No What's wrong with being a screenwriter? Or an editor? (It is widely maintained that Star Wars was saved in the editing room...) Stepwise Continuous Dysfunction (talk) 17:06, 25 August 2026 (UTC)
No - not everything has one singular creator (see just about every film or album ever) and this would therefore result in a lot of unnecessary confusion to change. Jishara (please ping upon response) (talk) 22:03, 25 August 2026 (UTC)
No. A co-creator is a creator. James500 (talk) 19:47, 27 August 2026 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Both proposals above are now closed, there's nothing else to discuss. FaviFake (talk) 07:58, 4 September 2026 (UTC)
Previous discussion hereBilledMammal (talk) 04:34, 21 August 2026 (UTC)
Reading the above-linked previous discussion, I do not see any stated examples of articles that have been kept per criterion #3 but should not have been. If it is correct that this criterion is not predictive of coverage -- indeed so non-predictive as to require its removal -- then I would expect there to be examples that would demonstrate that. Could some examples be provided? -- Visviva (talk) 04:51, 21 August 2026 (UTC)
A brief search turned up Ada McQuillan, who meets WP:CREATIVE through her contributions to several early films, but appears to lack any real coverage. I have no doubt many more can be found if I spent more than two minutes on it. BilledMammal (talk) 05:31, 21 August 2026 (UTC)
Is a scenario editor in a studio really an NCREATIVE pass, though? GreenLipstickLesbian💌🧸 05:54, 21 August 2026 (UTC)
She was a screenwriter for several movies; I think that is covered by WP:NCREATIVE. If you disagree, then please nominate for WP:AFD. BilledMammal (talk) 05:57, 21 August 2026 (UTC)
I think referring to her as a screenwriter is misleading or, possibly, just untrue; scenario editors aren't analogous to modern screenwriters. Their role was more technical, and I don't think you can say she actually created or played a major role in co-creating anything. Ergo, NECREATIVE#3 doesn't apply (at least, in my mind). GreenLipstickLesbian💌🧸 06:02, 21 August 2026 (UTC)
I'm not convinced, but as I said, if you don't think she is then please test it at WP:AFD. BilledMammal (talk) 06:07, 21 August 2026 (UTC)
Can you find me a source actually calling her a screenwriter? GreenLipstickLesbian💌🧸 06:15, 21 August 2026 (UTC)
According to this, she is credited as a screenwriter. However, this discussion is also getting to deep, so again I'm going to stop here; if you genuinely believe she doesn't meet WP:CREATIVE, then please nominate her at AfD and we will see what the consensus is. Otherwise, she is a good example of the issues with this guideline. BilledMammal (talk) 06:18, 21 August 2026 (UTC)
sorry, I should have been more specific -- something reliable and non-user generated? I don't think we should make statements of fact, or base Wikipedia's descriptors of people, on unreliable sources. GreenLipstickLesbian💌🧸 06:25, 21 August 2026 (UTC)
says Ada and Gladys wrote the screen play. The rest of the sources call both of them scenario editors.. In these sources there is no "screen writer". I believe this was typical of the era. Davidstewartharvey (talk) 06:20, 21 August 2026 (UTC)
Screenwriting in Britain by Ian W. MacDonald from Analysing the Screenplay 2010 https://doi.org/10.4324/9780203843383. "The new division of labour provided a route for promising aspirants to
enter the film industry. Writers could be taken on as Scenario Editor, where
they read submissions, and formatted stories into scripts as well as writing
Er, at a quick glance I'm not confident those films are notable, either? In solidarity, asilvering (talk) 07:03, 21 August 2026 (UTC)
As per BilledMammal, take to AFD and let the community decide. Davidstewartharvey (talk) 07:23, 21 August 2026 (UTC)
I don't have any interest in AfDing it, personally, and I'm not going to AfD something without trying to search for sources first. But I find it odd that this article is being used as an example of the problems with the guideline, when it looks like it's a problem with "no one has gotten around to this yet", which doesn't really have anything to do with notability or this SNG. In solidarity, asilvering (talk) 10:14, 21 August 2026 (UTC)
I am quite troubled that you are only conducting this brief search now. Generally, before proposing solutions to a problem, it is best to establish what the problem is and that it exists. In this case, being able to show that there are articles that pass NCREATIVE, don't pass any other criteria, and shouldn't exist. ~ le 🌸 valyn (talk) 16:33, 21 August 2026 (UTC)
As I've stated before many times in the past 18 to 20 months, certain powerful men want to find any excuse to yank our charitable status, and a major change in notability or other procedures could just be that excuse. Let's wait until after January 2027. Bearian (talk) 00:34, 3 September 2026 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
NOT AN RfC: WP:MERGE (MERGEREASON) as a guideline.
Just to be clear, this has had no prior planning and was actually inspired by this comment. Ever since the PAM-AfD merger earlier this year, WP:MERGEREASON has become commonplace at AfD as the foundational question for all merge proposal AfDs. This is good, as it means there is something to base discussion on to form a consensus. The issue I have is purely functional then. MERGE is an WP:INFOPAGE, which itself is not a policy or guideline. In practice, most editors who are active at AfD probably don't care, but we're at point now where the active admins are asking for discussion based on this information page.
The page is mostly instructional, but when WP:DELETE, WP:KEEP and WP:ATD outcomes are considered as PAGs, it makes sense to me, to include MERGE (or just MERGEREASON) under that same umbrella.
(Any editor is free to close this if it is deemed unimportant.) 11WB💬 01:59, 25 August 2026 (UTC)
Wikipedia:Merging is a "process" page, and process pages have traditionally had WP:NOTAG. For example, Wikipedia:Requests for comment is a process page that isn't officially a policy or guideline. (I mention that example because it says that you're not required to have a prior discussion before starting an RFC, no matter what rumor may have been passed around.) Wikipedia:Articles for deletion is another process page. WhatamIdoing (talk) 03:27, 25 August 2026 (UTC)
MERGE is already technically "pigeon-holed" as an INFOPAGE. I'm bringing this up here as the MERGEREASON section has gone beyond that to function as a regularly cited (default) guideline at AfD since the merger. 11WB💬 06:00, 25 August 2026 (UTC)
We do not have a coherent structure that requires pages containing accepted rationales to be tagged in any particular way. This is partly because Wikipedia:The difference between policies, guidelines, and essays is subtle and variable, and partly because pages can combine multiple elements, but also partly because how a page was tagged back in the day (when we finally [mostly] quit tagging pages without discussion) was a bit random. We had editors, for example, who believed that nothing should be called a "policy". It doesn't seem to make much difference in the end. WP:BRD has failed multiple WP:PROPOSALS to be declared a policy or guideline, and people still cheerfully cite it. Wikipedia:Five pillars isn't a policy, and yet editors regularly treat it as superseding any actual {{policy}}. The tag at the top of the page isn't the important part. WhatamIdoing (talk) 18:14, 25 August 2026 (UTC)
Thank you for the explanation. If you believe this is unimportant, as I said in my opening post, I don't mind this being closed. I'm not sure whether you are active at AfD, but I would have liked a few more editors to give their opinions on this. I don't particularly believe in the mindset of not bothering at the first hurdle, I acknowledge your opinion, but now I invite others also to leave theirs. 11WB💬 20:47, 25 August 2026 (UTC)
I'd be hesitant to codify this as a guideline. Merging is less drastic, and more easily reversible, than deletion. The devil is in the details with merges—exactly which content, where it should go in the parent article, and the particular reasons based on the state of the article at a given time. —Myceteae🍄🟫 (talk) 21:57, 25 August 2026 (UTC)
Specific sections can be assessed as guidelines. Banners aren't exclusively placed only at the top of such pages. 11WB💬 22:04, 25 August 2026 (UTC)
It's not the placement on the page but the content itself that gives me pause. What's written at WP:MERGEREASON is sensible but if the goal is to give it more authority, I'm not sure that's necessary or helpful. —Myceteae🍄🟫 (talk) 08:39, 26 August 2026 (UTC)
The actual problem with WP:MERGEREASON that's on display at the AFD that was linked is the failure to distinguish when blanking and redirecting is more appropriate than merging. 'Promoting' this to a guideline won't address that problem. —Myceteae🍄🟫 (talk) 08:59, 26 August 2026 (UTC)
I don't think there's harm in discussing it but it's worth noting that WP:PAGEDECIDE and MERGEREASON are fairly similar in semantic content and the former is on a policyguideline page. Alpha3031 (t • c) 22:15, 25 August 2026 (UTC)
As an aside, would there be any support for an RfC to promote Wikipedia:Notability to policy? The fact that it is a mere guideline has bothered me for years. FaviFake (talk) 06:48, 26 August 2026 (UTC)
Honestly, no. In this case I would endorse what @WhatamIdoing said above. No one would notice the difference and I personally believe it functions better as a guideline, rather than being enforced as a policy. 11WB💬 06:54, 26 August 2026 (UTC)
I've heard multiple people argue that WP:N is less important than [insert other policy] just because it's a guideline and not a policy. If we're gonna keep these meaningless labels at least we should apply them consistently. Why do you think it functions better as a guideline when similar pages like WP:NOT or WP:TITLE are policies? It could be argued that WP:N is more important than WP:TITLE. FaviFake (talk) 08:21, 26 August 2026 (UTC)
A policy, from my perspective, is enforced. If we take WP:CIVIL, a policy, this enforces editors to be civil with one another (as they would be expected to anyway). Violating that policy usually results in a sanction. For WP:N, a guideline, this is not the case. An editor is not going to be blocked for authoring a non-notable article. Instead, for intractable cases of authoring non-notable articles, several pages become relevant instead, such as WP:NOTHERE (which is itself an essay backed by policy). This is obviously just my perspective, in reality they are just labels. 11WB💬 08:36, 26 August 2026 (UTC)
It would be a mistake to think of blocking as the only important enforcement mechanism.
It also doesn't hold up in practice. For example, people violate the WP:PRESERVE policy all day long, and so long as their violations are aligned with common biases in the community, they'll even get praised for it; on the other side, nobody ever violates WP:ELNEVER #2, even though it's "just" a guideline. WhatamIdoing (talk) 06:01, 27 August 2026 (UTC)
I was making a personal observation of function, obviously any guideline or policy breach can result in a sanction. My main point is that policies generally hold the highest authority (with Arbitration and Foundation decisions being the few things that "outrank" them).
This is getting off-topic slightly however. The focus is on MERGE/MERGEREASON specifically. 11WB💬 06:08, 27 August 2026 (UTC)
No. —Myceteae🍄🟫 (talk) 09:09, 26 August 2026 (UTC)
Right... thanks for that. I was attempting to explain my perspective on Wikipedia's page label authority, but I suppose not everyone will agree. 11WB💬 10:07, 26 August 2026 (UTC)
I was responding to FaviFake's question. I do not support an RFC to promote Wikipedia:Notability to a policy. —Myceteae🍄🟫 (talk) 14:33, 26 August 2026 (UTC)
Oh. My mistake, apologies. I was slightly taken aback when I read that. There's nothing wrong with saying "no", but without anything else it came across as complete dismissal. I agree with you regardless, an RfC for WP:N isn't necessary. 11WB💬 00:44, 27 August 2026 (UTC)
I had started writing a long rationale but decided to just keep it simple.:) —Myceteae🍄🟫 (talk) 08:15, 27 August 2026 (UTC)
Going to courtesy ping @Randy Kryn, as I opened this discussion based on a comment they made at AfD (and they're still choosing to dismiss MERGEREASON now due to it being only an "information page"). This is the place to discuss this. If not, I'll probably just open an actual RfC to ask the question. 11WB💬 09:24, 30 August 2026 (UTC)
In a recent case editors are using the information page to argue that a 2021 film adaptation of a 2012 book, with the film and book written and produced by different people, should be merged. They present no overriding reason, which WP:GNG seems to require. This example shows that just because vocal editors sincerely want mergereason to replace GNG - and that a well-sourced film adaptation written and organized by different people a decade later has now become the same topic as the book - doesn't mean it should. Randy Kryn (talk) 10:24, 30 August 2026 (UTC)
We aren't living in the Wikipedia of yesteryear. 11WB💬 11:14, 30 August 2026 (UTC)
MERGEREASON is not "replacing" anything. That point of view is fundamentally incorrect and not based in reality. GNG is for deletion discussions, MERGEREASON is for merge proposals. For some reason, you are choosing to live in the days before the merger. You made the same argument in this recent AfD, consensus wasn't with you. In the ongoing Sanic AfD you were told by multiple editors that MERGEREASON is backed by WP:NOPAGE. You ignored them. It should be pretty apparent by now that you are wrong. If it is such a big deal that you won't accept an "information page" backed by a guideline, I'll hold an RfC so that MERGEREASON can be assessed by the community. 11WB💬 11:23, 30 August 2026 (UTC)
And yet you can't explain why a well-sourced 2021 film adaptation, written, directed, and voice acted by different people than the author of a 2012 book, should be merged into the article about the book other than, "merge". If GNG no longer applies to merges, that sourced stand-alone pages deserve their own article is antiquated thinking and that GNG is a relic of yesteryear, Wikipedia, she be in trouble. Randy Kryn (talk) 12:13, 30 August 2026 (UTC)
I did give a reason, WP:MERGECON. I also quoted the exact text: "Some topics that are independently notable are best covered in the same article in order to better serve reader understanding." This is the exact argument that has been put forth by the nominator. We both told you this explicitly. Yet, you've circled back to the same response. The reason these discussions loop is because you are choosing not to listen. Only you can change that. 11WB💬 12:18, 30 August 2026 (UTC)
Nothing in mergecon, an information page, justifies moving an established well-sourced page about a film into an article about a book published nine years earlier, with the film having no connection to the author of the children's book other than probably buying the rights to make a film. A problem here is that you are arguing that WP:GNG no longer applies to mergers when, in fact, it is a backbone premise of Wikipedia notabililty and article placement. Saying that GNG is antiquated, and almost saying outright that it should no longer apply, actually would change basic premises of the encyclopedia and give mergecon way more weight than it was designed to shape. Randy Kryn (talk) 12:29, 30 August 2026 (UTC)
Maybe it's time to remove "NOT AN" from the heading. FaviFake (talk) 13:13, 30 August 2026 (UTC)
Not at all Randy. An editor identifies if an article's content is better off featured elsewhere, that is the point of MERGEREASON. At the point of identification notability is accepted, and the question becomes where the content is best served for the reader. I accept the notability argument, at the point MERGEREASON enters, the question moves beyond that. You are not engaging with that, which is why merge proposals you have opposed citing GNG have not fallen your way. 11WB💬 13:40, 30 August 2026 (UTC)
The problem is the fundamental mismatch between deletion decisions and merge decisions. Various WP:MERGEREASONs are backed up by different guidelines, e.g. WP:BADFORK, WP:NOPAGE, and even the policy WP:NOTDICT. But if there is agreement that a subject is notable the merge decisions an editorial judgment about the best way to present and organize the content. Various policies, guidelines, and common practices factor into the decision but it ends up being highly dependent on the particulars in each case. —Myceteae🍄🟫 (talk) 15:46, 30 August 2026 (UTC)
More to the point, the lead of Wikipedia:Notability, less than two inches above the GNG, says Editors may use their discretion to merge or group two or more related topics into a single article. Merging two related topics into a single article is therefore officially endorsed by an Official Notability Guideline™. WhatamIdoing (talk) 21:23, 30 August 2026 (UTC)
@Randy Kryn, what makes you think that the WP:GNG "seems to require" an "overriding reason" for editors to choose which side of the Lumpers and splitters approach to follow in any given case? Is there any wording in the GNG that makes you believe this? WhatamIdoing (talk) 21:19, 30 August 2026 (UTC)
The GNG language is what I based that on, especially the second sentence. Sounds to me like a good reason has to be given to delete or merge an article deemed GNG compatible, with actual occurrences on the rarer side: "'Presumed' means that significant coverage creates an assumption, not a guarantee, that a subject merits its own article. A more in-depth discussion might conclude that the topic actually should not have a stand-alone article—perhaps because it violates what Wikipedia is not, particularly the rule that Wikipedia is not an indiscriminate collection of information." FaviFake, GNG has been with us a long time, weakening it shouldn't be done lightly. Randy Kryn (talk) 23:27, 30 August 2026 (UTC)
The GNG itself is exactly one sentence long: "A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject." There is no second sentence.
I think you have overinterpreted the explanation of the word presumed. "A more in-depth discussion" is not required (Think about it: If it were, you could never create an article for anything except the Least publishable unit without getting written permission in advance), and the reason for the decision need not be limited to the single "perhaps" example that is given. WhatamIdoing (talk) 03:48, 1 September 2026 (UTC)
This needs addressing as the March RfC did not foresee this. A lack of clarification has brought in (to put bluntly) nonsensical arguments, such as Randy's, that MERGEREASON does not apply simply because it is an "information page". 11WB💬 13:42, 30 August 2026 (UTC)
To any uninvolved editor, this discussion can be closed. I don't think there are any grounds for opening an RfC on this, and despite my belief it should be a guideline, don't have the energy or patience to try and make the case. 11WB💬 15:11, 30 August 2026 (UTC)
Perhaps the Wikipedia:Policies and guidelines and Wikipedia:What Wikipedia is not policies need to explicitly say something like "A rule or process does not have to be on a page that is tagged as an official written policy or guideline for it to be appropriate, accepted, and even required." WhatamIdoing (talk) 21:25, 30 August 2026 (UTC)
Yeah. If a policy is explained in another page it's still a policy. FaviFake (talk) 22:36, 30 August 2026 (UTC)
I'm not sure this will actually help anything. We have AFDs that close on the basis of WP:MERGEREASONs and at least one page that was kept on the basis of WP:SPLIT. Various policy and guideline provisions already support merging but editors disagree as to their applicability and weight in different situations. I realize the proposed language has broader implications than the merge/GNG question. I don't see it as particularly clarifying for this specific case or in general. —Myceteae🍄🟫 (talk) 23:53, 30 August 2026 (UTC)
If writing such a rule would reduce the number of times someone says "X must be promoted to guideline, because otherwise isn't not required enough", then I'd consider that to be an improvement. WhatamIdoing (talk) 03:50, 1 September 2026 (UTC)
RfC: AI use for generating citations within articles
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
This RfC is to ask whether a third exemption for the assistance or generation of citations in articles should be added to the WP:NOLLM guideline or not.
As of right now NOLLM is underdeveloped, which makes sense as the guideline only reached consensus in March of this year. There are specific use cases that AI could assist with, without violating WP:TSI and WP:V, such as the structuring of inline citations.
To provide an example, I asked Google Gemini the following:
"Please provide the code for an inline academic reference on Wikipedia, from this URL. Please include the authors, DOI and other general information that requires inclusion. https://www.nature.com/articles/s41586-026-10893-x."
After doing a search (presumedly to access the URL), Gemini outputted the following code:
I then used the text editor and used the template tool to do the same myself. Bear in mind, I have been editing for a while (and use academic references often), so for me this is second nature (no pun intended). I actually wasn't aware of how to add "et al.", so Gemini actually taught me something new!
As can be seen, Gemini outputted a less complete version without the URL, but it is generally on the way there. New editors may not be aware of NOLLM and believe that using AI to generate a source, with information they've inputted, is acceptable. In this case, Gemini has just taken what I've put in and extracted information directly from the URL. That leaves little to no room for hallucination (and if it managed to, then the AI in that instance would just suck regardless).
I don't believe this specific use case presents enough risk to be prohibited, and could reasonably be included as an exemption. This is why I have opened this RfC today. It has been on my mind for a while, and reasoned that with the ongoing RECALL, and overwhelming clean-up work WP:AINB participants continue to do daily, if this exemption is applied, it could take some of the load off. 11WB💬 07:51, 27 August 2026 (UTC)
Oppose, LLMs can be helpful to format references (although there are better ways to prompt than the one above), but this should not be a separate point in NOLLM for a couple of reasons. Firstly, the background code of wikitext, including citation templates, is not strictly article content. More importantly, LLMs can hallucinate in this as they can in anything else. LLMs will sometimes generate fake dois, urls, ISBNs, etc., even for citations which are otherwise valid. These sorts of source information mismatches are one of the signs that indicate LLM use, so leading editors to believe these uses always generate good citations is guiding good-faith editors towards being picked up for unchecked LLM use. CMD (talk) 08:18, 27 August 2026 (UTC)
(summoned by bot) Oppose as unnecessary per CMD. I also share the concerns about hallucinated parameters, which are often seen at AfC for things like ISBNs. There are a number of automated tools that can format citation templates without the need for LLMs, and we should encourage the use of these instead. In solidarity, nilnz 08:38, 27 August 2026 (UTC)
Oppose LLMs are as likely to hallucinate doing this as any other work. Also this takes more time and effort than using the already available tools who's abilities and limitations are known and understood. -- LCU ActivelyDisinterested«@» °∆t° 12:01, 27 August 2026 (UTC)
Oppose: This is something I support in theory but oppose in practice. There are too many cases where someone says they "just used AI to format the article" when the article text itself is also clearly AI, and sometimes they end up trickle-truthing out the rest of it ("ok I also used it to polish..."). I don't even think all of them are lying. I think a lot of people genuinely do not understand that "generating citations" and "finding citations" are different things, or that "pages=848–853" didn't just magically appear. I don't think the prompt you provided is similar to what the majority of people are using -- and I don't think most of them would grasp how it isn't similar.If your concern is the "overwhelming clean-up work," meanwhile, then even stronger oppose, this proposal will make the clean-up work harder because it's just one more exception for people to sealion about. Gnomingstuff (talk) 14:27, 27 August 2026 (UTC)
Oppose for all the reasons given in the !votes above (except that I can't see myself supporting it even in theory). If you have the URL, just use the tool that's already in the Visual Editor and check its output manually. Stepwise Continuous Dysfunction (talk) 16:09, 27 August 2026 (UTC)
Oppose, my experience of LLMs echoes CMD's. They've got a terrible tendency of making small, hard to spot errors when asked to produce references e.g. giving you the title of one paper and the author list of another. Red Fiona (talk) 18:16, 27 August 2026 (UTC)
Oppose. I don't think one example of an LLM giving a correct citation should be translated into allowing it sitewide. As already stated above, they can (and already do) hallucinate quite a bit. There's no guarantee that the LLM doesn't just make up parameters or insert hallucinated content into said parameters. Even if they could reliably do one citation, what if someone were to make several citations in a batch? There's no guarantee they would all be good citations and correctly formatted, so human review would be necessary (especially since unchecked LLM-generated content is doubly bad). Aside from my personal dislike of the use of LLM-generated content on Wikipedia as a whole, I just don't get the use to generate something you would have to manually review anyway, just in case it decided to not properly format your citation that one time. SmittenGalaxy|talk! 23:39, 27 August 2026 (UTC)
Oppose Even if AI can do some citations correctly, there is a real risk of AI hallucinations, especially when several citations are being generated. A lot of the times, visual editor would work just fine, and if not, filling in the citation manually should only take a few minutes. EaglesFan37 (talk) 07:08, 28 August 2026 (UTC)
Strong Oppose. A more convincing lie makes for more work, not less. Tools for generating correct citations automatically have existed for a long time; there is no excuse for instead using a tool that is fundamentally unsuited to the task. In solidarity, Autoinvective (🗨︎ 𓅬) 07:53, 28 August 2026 (UTC)
Oppose until they overcome the issue of LLMs hallucinating when they don't know. The example is a easy url to process compared to many and the prompt is more detailed than most would use, so I don't believe is indicative of real use. Until an LLM can admit to not knowing and also prompt users for missing information in requests, such as "What page numbers are you using as a source?", this is a no go for me. KylieTastic (talk) 09:22, 28 August 2026 (UTC)
Oppose, there's the old adage of hard cases make bad law, but this is apparently one for "easy cases make bad law". Just do it yourself. We've done that for many years now, and we've done fine with that. We do not need chatbots writing articles; we've written millions without them. (By the way, I initially screwed up my link to the article in my comment, but I fixed it, because I'm writing it myself. Write yourself; don't use chatbots.) Yes, I'm sure in some cases, a chatbot can get it right. In others, it will hallucinate or screw up. Write it yourself. SeraphimbladeTalk to me 12:41, 28 August 2026 (UTC)
Advise against LLM-generated citations, but exempt from sanctions Fundamentally, generating citations is a lot more like suggestions for "spelling, punctuation, capitalisation, grammar" than it is content creation, and we should treat it accordingly. If a user gives the LLM a fully formed citation and it returns a properly cited Wikipedia citation, that is largely verifiable; the editor should look over and match the fields, and should not be subject to blocking and other sanctions just because they used an LLM to do so. 11WB is correct that this process is now "second-nature" to a lot of people doing academic work, and we should create a policy that avoids biting people for routine, good-faith actions. However, in my experience, this kind of reformatting is prone to two failure modes: "helpful" hallucinatory additions (e.g., the LLM adds a completely made-up ISBN number) and field mismatches (e.g., the LLM adds an editors field when the template uses editor-last1 etc.). The best thing to do would be to connect editors with software-based tools that can handle these things correctly every time (for most cases, VisualEditor; Zotero plus Wikipedia Citation Template; the tools at Help:Citation tools). But frankly, our documentation is not user-friendly at all and should be dramatically improved.--Carwil (talk) 13:40, 28 August 2026 (UTC)
Amending my own !vote to Support with cautions: I do see use cases, outlined in discussion below, that don't have non-LLM software equivalents and we should separate citations from other problematic edits, while insisting that editors must carefully proofread their LLM output.--Carwil (talk) 15:44, 31 August 2026 (UTC)
Oppose. Why would you want to do this when both RefToolbar and Visual Editor have robust tools for turning a DOI into a fully formed citation. --Ahecht (TALK PAGE) 14:48, 28 August 2026 (UTC)
Strong Oppose There are already non-llm tools for this, why should we make an exception for something worse than we already have. —Leaf.Sheap⇖ /.°°.\ ⇗ (They•Them) 15:00, 28 August 2026 (UTC)
Also, writing this into policy would be pointless policy creep, I don't see how it could accomplish anything useful. —Leaf.Sheap⇖ /.°°.\ ⇗ (They•Them) 16:12, 29 August 2026 (UTC)
That isn't how Wikipedia works. The project can't just unilaterally decide to ignore a specific RfC because it could get written down. That logic doesn't work anyway as NOLLM is tiny as far as PAG pages go. This isn't a concern. 11WB💬 16:25, 29 August 2026 (UTC)
The concept of policy creep, and the corresponding Wikipedia essay WP:CREEP, is absolutely relevant to a proposal to add an additional carve out to the existing guideline. The fact that the current guideline is concise and allows limited exceptions does not render the 'creep' concerns irrelevant. Some editors understandably see adding more loopholes, exceptions, and special cases as a net negative. You may think the concern is unwarranted or that the benefits of the proposal outweigh the concern but —Myceteae🍄🟫 (talk) 18:33, 29 August 2026 (UTC)
Your comment looks like it was cut off. Regardless, I don't agree with that perspective. The point of RfCs such as this is to gather consensus so that loopholes can be avoided. That essay is flawed and is obviously not something I agree with or plan to pay attention to. Thanks. 11WB💬 02:10, 30 August 2026 (UTC)
Status Quo: as is often the case with these RFCs, one result might feed the sea lions and one result might embolden the newbie-biters. Sometimes it's better to just leave things be and spend your time mentoring newbies or doing cleanup. -- LWGtalk(VOPOV) 18:08, 28 August 2026 (UTC)
Oppose: we have deterministic tools for this and should not muddy the waters on AI use NicheSports (talk) 18:19, 28 August 2026 (UTC)
Oppose, to my experience this is a bad idea. And also not needed as citoid provides a reasonable good tool. Alexcalamaro (talk) 18:26, 28 August 2026 (UTC)
Big meh. Either the citation is completely identical to anything a human could have made, has no errors and would be not possible for anyone to tell it was generated by AI (since the content doesn't have AISIGNS), or it has hallucinations. In the first case, the current prohibition from NOLLM is unenforceable and in the second we don't want hallucinations.Katzrockso (talk) 18:28, 28 August 2026 (UTC)
Support I often use the Automatic option of the Cite function of the Visual Editor which generates a citation from a URL, as the OP describes. I don't know the details of the technology behind this but it isn't very good as it often garbles the output, doesn't use my preferred format and sometimes fails completely. Editors should be free to use other software solutions if they work better. As software may use a variety of algorithms and approaches, we should not try to micromanage the details; the key thing is whether it works or not.Note the background to this is the status quo that we often don't get citations at all because providing them is such a pain. For a fresh example, see Lake Ontario, which is currently in the news and getting lots of traffic. That has been tagged as needing more citations because it has extensive passages without any. But the absurd thing is that the tag required an edit request because the page is fully protected! Wikipedia is suffocated by such constraints and challenges and so some fresh thinking is needed. Andrew🐉(talk) 20:13, 28 August 2026 (UTC)
I just say many citation template generators still needs one to double check, and unfortunately LLMs aren't necessarily more reliable in doing so.--ZKang123 (talk·contribs) 09:17, 30 August 2026 (UTC)
Strongly oppose, absolutely not. Users should not be permitted to delegate one of the most important parts of an encyclopaedic article to their slop machines. This is not only a bad idea, but it doesn't solve any problems and would just create even more problems. This is also constantly used as an "excuse" by users caught using AI, who then claim to "only use it to format references" or something. Legitamising that idea in NOLLM is an awful idea that would just make an already difficult task even more difficult. We have finally gotten somewhere with our LLM guidelines, lets not start watering it down. ‑‑gurkubondinn 01:21, 29 August 2026 (UTC)
Provisional support Formatting citations is one of the most irritating parts of wiki editing and while Citoid and friends are great, they can't handle all possible forms citations come in. Hand formatted citations are quite error prone - typos, mistaken parameters, missing parameters etc - and we largely put up with that, so I am not sold on hallucinations as counterargument. Jo-Jo Eumerus (talk) 06:39, 29 August 2026 (UTC)
Support. We should not encourage people to use LLMs for citations, but we should not penalise them for doing so either. We want citations, and as pointed out generating them in this manner is routine for many people now. Thryduulf (talk) 12:40, 29 August 2026 (UTC)
Support or Status Quo: Unlike prose, citations are either correct or incorrect. It shouldn't matter how an editor produced a correct citation as the encyclopedia is the priority as described in WP:3P. Incorrect citations are disruptive. In the discussions at WP:Nollm, no one has objected to experienced editors fixing or creating templates with chatbots/agents. I expect we'd be able to find some language that reflects the underlying consensus that edits should be judged on their own merits. That said, I think our policy/talk time should be directed at how to slow the stream of slop. Most of the objections here are centered around avoiding any encouragement to slop edits. Maybe we should focus more on the onboarding of new editors or the volume of edits.
Oppose, for the reasons given by Nil NZ and Gnomingstuff above. In my comparatively short time participating in AI cleanup here, I have not been convinced that LLMs are reliable for this task. —Preceding unsigned comment added by Suðurhafsljósæta (talk • contribs) 13:19, 29 August 2026 (UTC)
oppose per above, there already exists robust tooling for citations and LLM usage runs the risk of hallucinations daysantdevtalk 03:20, 30 August 2026 (UTC)
Oppose I don't think the use of LLMs to generate citations are necessarily more helpful than the existing citation tools we have, and as always regardless we still have to double check and format our own citations. Also, in the said example (about et al.), one can always check the original template and their parameters. To add, there's also a case recently in my country when a student tried to defend their use of AI to format citations.--ZKang123 (talk·contribs) 09:17, 30 August 2026 (UTC)
Oppose, bringing any exception into the AI ban lessens its effectiveness in presenting a human written, human researched encyclopedia. Randy Kryn (talk) 10:45, 30 August 2026 (UTC)
Oppose, per CMD et al.[pun very much intended] It's not bad in of itself, but can lead to bad practices with uncaught hallucinations. Anyone that does it does so at their own risk, but it shouldn't be encouraged otherwise people won't be accountable since the rules said they could use AI. Theo wiki user (talk) 18:10, 30 August 2026 (UTC)
Incomplete RFC - I see a generic description of ability for cites so this RFC seems to be looking in that area, but there didn't seem an explicit and specific question or proposal. It does seem to have gotten a lot of knee jerk rejections, so it succeeded anyway in that it got a substantial response and gives a good sense of the room (that there is wide resistance to using LLM) enough for RFC to close. My impression that the WP rule will become OBE shortly anyway, but time will tell. Cheers Markbassett (talk) 20:07, 30 August 2026 (UTC)
What’s OBE? Thanks. Dw31415 (talk) 20:38, 30 August 2026 (UTC)
Presumably "Overtaken By Events", a military term based on that premise that no plan survives contact with the enemy. KylieTastic (talk) 20:55, 30 August 2026 (UTC)
In another words, yet another attempt to undermine the AI guidelines ("oh they'll inevitably go away, trust me bro") by someone who did not feel it necessary to weigh in when they were being discussed. Gnomingstuff (talk) 01:02, 31 August 2026 (UTC)
Or rather that the ultimate discussion was rapidly closed as a SNOW close before many editors could opine. Katzrockso (talk) 01:35, 31 August 2026 (UTC)
Gnomingstuff, please remember to assume good faith. Not everybody who disagrees with you about some aspect of AI is trying to "undermine the guidelines". Thryduulf (talk) 02:35, 31 August 2026 (UTC)
"Overcome By Events". Basically things are moving fast in this field in multiple dimensions -- capability is getting vastly better, new flavors of AI (so it's not just LLM), adoption making it ubiquitous (more and more folks using it to great extent so such content becomes unavoidable) and adaptation (more ways of using it). I think an analogy is to the early internet where teachers said to not use it as it was too unreliable and covered so little information. With hundreds of companies and trillions of AI development ongoing, I view it as highly implausible for WP policy to stay the same for long. Cheers Markbassett (talk) 02:44, 31 August 2026 (UTC)
Oppose at this time. If you check it thoroughly enough so that you're sure there's no error, you're not going to get flagged, and if you don't, you should be. --SarekOfVulcan (talk) 17:57, 31 August 2026 (UTC)
This comment seems to capture the majority: thoroughly checked use is acceptable in practice, even if the guideline appears to prohibit it. I fear that leaving exceptions unwritten makes community standards harder to learn and undermines trust that guidelines mean what they say. If thoroughly checked use is acceptable, the guideline should say so. Otherwise, it has Luddite vibes rather than emphasizing our objections to fabricated content and mechanical prose. Dw31415 (talk) 10:42, 1 September 2026 (UTC)
Use outside of content/prose elsewhere is not an unwritten exception, but a different topic, and one of not infrequent discussion. There have been many views raised for example over llm use for scripts and templates. CMD (talk) 11:39, 1 September 2026 (UTC)
(edit conflict) Exactly this. Policies and guidelines should say what they mean, otherwise they undermine not only that policy/guideline but the whole system of policies and guidelines. When a policy says X is prohibited but everybody turns a blind eye to breaches of it, including intentional ones, where then is the legitimacy of sanctioning someone else who, possibly accidentally, does something else that it says is prohibited? Thryduulf (talk) 11:42, 1 September 2026 (UTC)
Oppose because of the risk of hallucinations and easily overlooked missing end-block symbols. FineIllDoIt (talk) 19:51, 31 August 2026 (UTC)
Defer decision. As typing out a prompt to create citations is arguably more tiring than using current tools, the fact that people are using them suggests shortcomings in current tooling. According to the discussions below, we have recurrent issues with certain news sites and PDF files. Some people said batch creation could be a problem. We should gather usage details of citoid to understand how well/fast it works and when it fails, why. If citoid works well, it removes incentives to use LLM and the proposal will be moot. Redwolf Milkshake Fox 🦊 15:30, 1 September 2026 (UTC)
OpposeLLMs have a tendency to get small things wrong or just hallucinate things; it also creates a slippery slope where we are using AI to write citations- then let's get them to find them as well. This would introduce an irreparable number of errors. Also, it isn't as if it takes a long time to write a citation compared to the research required in writing, so it just seems completely mad to do so. Also, a blurring of the line makes it more difficult for new editors to fully understand, even if gone down to basics. In short: it is too much risk for zero gain (except for about 1/2 a minute).Equivalent-Text2598 (talk) 20:25, 1 September 2026 (UTC)
Oppose As written, this RFC is about using an LLM to format the parameters of a citation given a URL. That's using a sledgehammer to drive in a screw. Screwdrivers to accomplish this task as readily available. Changing a policy isn't the answer. A visit to WP:CITETOOL is. Davidwbaker (talk) 20:41, 1 September 2026 (UTC)
I was already wondering about the proliferation of suggested alternatives and WP:CITETOOL lists over 50! When you add the complexity of WP:CITEVAR, the result is a maze of mirrors. A virtue of the typical LLM tool is that its interface is already familiar and uses natural language. Users will tend to follow the path of least resistance and so, if we don't want people to take that, the alternative needs to be standard, clear and simple. Andrew🐉(talk) 21:42, 1 September 2026 (UTC)
Oppose: On balance it doesn’t sound like the benefits outweigh the contras; we have tools that work well enough, and we don’t particularly want to encourage lax attitudes to citations where that encouragement saves people only the smallest of effort. (Does typing into a chat even really end up saving you time in most cases? Call me back when you have a wrapper.) I also think it’s worth noting Katzrockso’s point: [If] the citation is completely identical to anything a human could have made, has no errors and would be not possible for anyone to tell it was generated by AI […] the current prohibition from NOLLM is unenforceable. Not that this pushes me much one way or another, but, well… “Big meh”. On the other hand, if a specific tool (“wrapper”, “harness”, whatever) were developed, this could easily be re-addressed. —HTGS(talk) 09:15, 2 September 2026 (UTC)
Oppose: Wikipedia already has citation tools, such as the tools built into visual editor. While these tools don't work in all situations, they are generally quite effective for most citations, leaving relatively little cleanup. In my experience, this works for about 90% of sources, not perfect, but also not a hallucinated citation. There are also external citation tools, such as the browser based Scribbr Citation Generator, which can be tried in the case that the built–in tools do not work, which can then be easily converted into Wikitext. As even a link is technically considered a citation, and editors can use that link to better format bare citations, making an AI carvout just doesn't seem neccessary. Mitchsavl (talk) 08:39, 3 September 2026 (UTC)
Supporthow is this any different than using the wiki tools (which often don't work)? At the end of the day the editor is responsible for their edits. Sir Joseph(talk) 13:47, 3 September 2026 (UTC)
My understanding is that WP:NOLLM forbids only generating article text via LLM, and has nothing to say about using LLMS for technical assistance, including minor formatting tasks of this nature. I oppose adding an explicit carveout (3-2-1 every single person caught for LLM use on the basis of broken citations is now using that as an excuse), but also oppose banning such use. Full disclosure: I have used an LLM for the very occasional minor formatting task; generally the kind that I could in principle write a script to do but which are never worth the effort individually, and never for generating citations. To my knowledge none of the (many, many) formatting errors I have made could be attributed to this usage, and I do check the output. If this becomes an actual problem we can ban the practice, I suppose, but as far as I can tell this was started on the basis of a hypothetical. Rusalkii (talk) 02:50, 5 September 2026 (UTC)
Oppose, but the suggestion and discussions are revealing that maybe the citation tools aren't well-known. (The difference between things like Citation bot and LLM tooling is the bots are better understood, and don't have risks of adding wrong info as a hallucination — They just won't work.) Silvestertaylor (talk) 07:05, 5 September 2026 (UTC)
The citation tools I've used sometimes garble the first/last name and date parameters, putting incorrect/incomplete information into them. Andrew🐉(talk) 10:06, 5 September 2026 (UTC)
This is also my experience, along with garbled title and publication names. I see no evidence presented that LLMs are actually any more likely to output an incorrect citation than any other tool. Thryduulf (talk) 11:02, 5 September 2026 (UTC)
Oppose for literally every reason already stated. — Hex•talk 12:25, 5 September 2026 (UTC)
Discussion (AI citations)
Is there a particular reason this was started on its own separate page, rather than at VPP? -- LCU ActivelyDisinterested«@» °∆t° 14:46, 27 August 2026 (UTC)
Decided to follow the bullet point under the second point of WP:RFCOPEN. I assumed high influx based on past RfCs on the topic. 11WB💬 14:49, 27 August 2026 (UTC)
I always think it's best to start at the appropriate page, and then move it off if it grows to big. You get better exposure that way. -- LCU ActivelyDisinterested«@» °∆t° 15:18, 27 August 2026 (UTC)
Anyone is welcome to move it back to the main page. I felt it more appropriate to do it this way as the main page is already quite large and previous RfCs for this topic have received a larger number of comments. 11WB💬 15:27, 27 August 2026 (UTC)
I've boldly done so. I didn't relish the thought of adding this to Wikipedia:Village pump archive §Special discussions, which I sometimes help out with, when there was no need for it to be on its own page. I wonder if this could be closed early per WP:SNOW. It would've been better to propose this as just a straight discussion at the idea lab first. Graham87 (talk) 11:26, 28 August 2026 (UTC)
@Graham87, it's been a day. WP:RFCEND suggests a minimum of 7 days. I expect this to be unsuccessful. This RfC serves a purpose to clarify whether not-strictly article content such as citations are exempt or not from the NOLLM guideline. As for the idea lab, I'm really not one to add extra steps in unnecessarily. 11WB💬 13:49, 28 August 2026 (UTC)
WP:RFCEND suggests seven days as a typical minimum, but a fuller quote of the surrounding text says: "An RfC should last until enough comment has been received that consensus is reached, or until it is apparent that it won't be. There is no required minimum or maximum duration; typically 7 days is a minimum, and after 30 days the discussion is ripe for closure." The comment subsequent to my last one at 13:40 (UTC) today noted an angle that hadn't previously been considered, so maybe it might be worth having this open for a few more days at the most, but I'll let other editors judge that. The idea lab would most likely have produced much the same feedback without the overhead of an RFC. Graham87 (talk) 15:03, 28 August 2026 (UTC)
I currently put the count at 17o/4s/2n (including myself in the 4 supports). That's just over a quarter that haven't directly opposed. Obviously I'm not saying this should be kept open for a ridiculous amount of time. But I do think pulling the plug after just 24 hours (as you proposed yesterday) would have been extremely premature. AfDs get 7 days minimum, and other consensus building venues get longer. My hope is that something can be added to the guideline to highlight whatever consensus is built here. 11WB💬 08:12, 29 August 2026 (UTC)
The person starting an RFC is allowed to gracefully admit defeat at any point. WhatamIdoing (talk) 04:33, 31 August 2026 (UTC)
Has anyone been sanctioned for this practice? Is this a topic of recurring disputes among editors interpreting and enforcing the current guideline? —Myceteae🍄🟫 (talk) 17:28, 28 August 2026 (UTC)
Don't know about the former but the latter yes Gnomingstuff (talk) 17:30, 28 August 2026 (UTC)
Are there a lot of cases reported to AINB, or massive cleanup efforts, where this practice is the only AI/LLM usage involved? If so, how are these cases even detected? I would not expect a well formatted, error-free citation to raise any eyebrows unless there is something else going on. I feel like I'm missing a lot of context as to why this is being raised. —Myceteae🍄🟫 (talk) 17:37, 28 August 2026 (UTC)
LLMs can have tells with how they format references, and of course the references often turn out to be nonsense which kind of gives it away. I don't think this stuff should be discussed anymore, the list of LLM tells that was created was used to help train LLM to hide those tells. So listing anymore is almost a WP:BEANS situation. -- LCU ActivelyDisinterested«@» °∆t° 22:53, 28 August 2026 (UTC)
OK. I get the BEANS point. I don't actually want an exhaustive list of tells, anyway. Just trying to understand the background on this proposal, which looks to be failing anyway. The RFC statement says if this exemption is applied, it could take some of the load off. But we don't know if there have been any massive cleanup efforts addressing just this practice. If the references are nonsense, which of course happens, that's a problem in and of itself and would presumably be grounds for a warning and further escalation even if some version of this proposal were adopted. —Myceteae🍄🟫 (talk) 23:28, 28 August 2026 (UTC)
The idea, as strange as it sounds, was for this to fail, as it clarifies that non-article content (in this case citations) are also subject to the guideline. An oppose or support close is a win in my eyes. 11WB💬 01:30, 29 August 2026 (UTC)
the list of LLM tells that was created was used to help train LLM to hide those tells.
this was one guy's viral marketing project to promote his startup, it does not deserve the attention it got Gnomingstuff (talk) 04:50, 29 August 2026 (UTC)
What I'm not understanding is why there isn't more intelligence built into the citation templates? Why isn't the Citoid logic built into the templates? If this were done then the editor would just need to invoke the template with a unique reference such as a DOI, ISBN or URL. The template would then look up and display all the details such as the authors, date, journal name and so forth. There might then be a second stage when all these details are archived, so fixing them.
Or, if multiple parameters continue to be input separately in the current fashion, then why doesn't the template do more to cross-check them and flag any inconsistencies?
So, if the templates did more of the work, this would tend to standardise the process and lighten the load on editors, removing the need for them to look around for ad hoc assistance such as LLMs.
You can draw from archived metadata with Template:Cite Q if you want. The other templates do flag some inconsistencies, but they're not magic and they can't be so broad as to generate copious false positives. CMD (talk) 08:12, 30 August 2026 (UTC)
I just want to point out here, that until somebody tests the various AIs and has each generate a certain number of varying academic or general web citations, we aren't to know what the actual% figure of hallucinations or other LLM-related issues that are outputted is. Until then, this is all based on assumption. 11WB💬 08:36, 30 August 2026 (UTC)
One of the few things we do have is User:NinjaRobotPirate/LLM, which highlights many different jobs that are undertaken on the project. I trust @NinjaRobotPirate's testing on this, as both an administrator who has experience with mop-specific permissions (which elevates credibility for stuff like this) and a working knowledge of AI in general. 11WB💬 08:41, 30 August 2026 (UTC)
One thing to keep in mind is that I was testing open weight LLMs on my $3000 desktop PC, which is pretty much the baseline minimum to get things done in the world of AI. To do much of anything beyond the minimum, I'd probably need to double that investment, which is hard to do. Most of these LLMs are pretty weak compared to the proprietary, subscription-based stuff that people usually use. I should probably test them in more practical situations, but I get distracted easily by fun questions like "who's the most moral character in Watchmen". AI is great at drudgery, but it needs to be supervised. The problem, in my opinion, is that too many people treat AI (especially chatbots) like it's a black box that, given any prompt (no matter how poor), it will spit out the truth, and they don't supervise it at all. NinjaRobotPirate (talk) 23:55, 30 August 2026 (UTC)
My comment above was actually not based on assumption, but on personal experience. The inconsistency checks in the current templates are also not based on assumptions, although they don't differentiate between errors caused by LLMs, faulty data, user error, or any other particular cause. CMD (talk) 09:30, 30 August 2026 (UTC)
I referred to many of the comments left in this RfC so far, rather than singling out any one editor individually. 11WB💬 09:33, 30 August 2026 (UTC)
@Andrew Davidson, you might be looking for m:WikiCite. (Citoid isn't "logic". It's a look-up service that checks hidden metadata in HTML pages and information that can be located through Zotero. And every time The New York Times tweaks their website, someone has to manually re-code the Zotero translator to keep it working –times thousands and thousands of websites, though that's the one that has caused the most problems for me personally over the years.) WhatamIdoing (talk) 03:55, 1 September 2026 (UTC)
{{cite book |last=Olney |first=Ross R. |title=Air Traffic Control |publisher=Thomas Nelson |year=1972 |isbn=978-0-8407-6154-5 |page=26}}
—on 30 August 2026
I think discussion would benefit from another example (above/side). I just tried this prompt. The current harnesses likely aren't generating the citations from weights. They are searching the web and generating text to fit the documentation. As the technology continues to evolve the LLM itself will play less-and-less a role in the available tools. I don't expect this to change anyone's mind and understand (and appreciate) the slop war we're in. I do hope we can get to something that better articulates the basic point: we don't want slop, we want a better encyclopedia... and how we get there doesn't matter. I guess I suggest the supporters to create some text in an essay. Dw31415 (talk) 16:11, 30 August 2026 (UTC)
On error checking just now, I see that it did the isbn number better than I would (isbn 13 with hyphens) have per docs Hyphens in the ISBN are optional, but preferred. Use the 13-digit ISBN – beginning with 978 or 979 – when it is available.Dw31415 (talk) 16:21, 30 August 2026 (UTC)
we don't want slop, we want a better encyclopedia... and how we get there doesn't matter. the fundamental issue underlying many of these AI-related discussions is that for some people it absolutely does matter how we get there. To the extent that people have argued that fully reliably sourced encyclopaedic information added by a human is OK but fully reliably sourced encyclopaedic information added by an LLM is not, even if the text is word-for-word identical. I fundamentally disagree with that view, but it is one held by multiple vocal participants in related discussions. Thryduulf (talk) 17:04, 30 August 2026 (UTC)
User:11WB - Thank you for asking. I expect the WP broad prejudice will not last, it seemed a bit off from when I first saw this and the tech is just advancing so fast and already become so ubiquitous that the policies look a bit unsustainable. (e.g. what about the forms of AI other than strict LLM? How do we address no AI imagery when all movies and photos involve AI? How do we avoid AI content at least indirectly when much academic and business production uses it and so the language they use is AI based?) There does seem to be transition difficulties similar in the coding field - I read Google now produces over 75% of code via AI, and hear AI is flooding Linux as Linux bug patches volume vastly accelerated - which overwhelms human checking capacity. Will see where this goes, but thanks again for asking about this niche. Cheers Markbassett (talk) 23:24, 30 August 2026 (UTC)
p.s. AI might not be judged so bad compared/contrasted to how well (i.e. badly) human citations do, and might have to consider whether we could even tell the source other than by the honor system. Anecdotally, I've seen enough types of flaws in human citation to not think all that well of those efforts. Content with missing cites, vague cites such as to a huge book without page number or quote included, misformatted cites, cites behind paywalls, wrong template cites, cite rot from rewritten or mistaken content, etcetera. Once even a plainly fraudulent cite. (They'd been told repeatedly they had to provide a cite or the content couldn't stay, so they made one up. And nobody spotted it as false for years.) Cheers Markbassett (talk) 23:42, 30 August 2026 (UTC)
So are you going to apologize for accusing people who have well-thought-out stances regarding AI of acting out of broad prejudice? Or are people who do AI cleanup exempt from being shown good faith? Gnomingstuff (talk) 04:34, 2 September 2026 (UTC)
I don't know what you're talking about - there isn't any person accused above, nor intent to do so. "WP broad prejudice" was intended and seems a factual label that is accurately and neutrally descriptive of the general consensus at WP as seen in current WP:LLM and recent discussions: A broad (i.e. general, non-specific, wide-reaching, without detail, lacking limit or cite to individual case, etcetera) and prejudice (judged before having a current case; view from prior experiences; preconceived tendencies not based on evidence; dislike; hostility) stance against use of LLM. Cheers Markbassett (talk) 15:27, 3 September 2026 (UTC)
Here's a simple use case where LLMs help and there's no easy alterative: converting multiple citations from an existing text source…
Prompt: Extract the citations included here and convert to Wikipedia citation templates: "see Lawrence Bryant, The King and the City in the Parisian Royal Entry Ceremony: Politics, Ritual, and Art in the Renaissance (Geneva: Droz, 1986); Gordon Kipling, Enter the King: Theatre, Liturgy, and Ritual in the Medieval Civic Triumph (New York: Clarendon, 1998); and Roy Strong, Art and Power: Renaissance Festivals, 1450-1650 (Suffolk: Boydell Press, 1984). Les Entrees royales françaises de 1328 a 1515, ed. Bernard Guenee and Françoise Lehouz (Paris: Editions du Centre National de la Recherche Scientifique, 1968), offers an overviewof French royal entries in the late medieval and early modern period.
Response (Gemini Pro): Here are the extracted citations converted into Wikipedia {{cite book}} templates:
* Bryant, Lawrence (1986). The King and the City in the Parisian Royal Entry Ceremony: Politics, Ritual, and Art in the Renaissance. Geneva: Droz.
* Kipling, Gordon (1998). Enter the King: Theatre, Liturgy, and Ritual in the Medieval Civic Triumph. New York: Clarendon.
* Strong, Roy (1984). Art and Power: Renaissance Festivals, 1450–1650. Suffolk: Boydell Press.
* Guenee, Bernard; Lehouz, Françoise, eds. (1968). Les Entrées royales françaises de 1328 à 1515. Paris: Editions du Centre National de la Recherche Scientifique.
Now these are all correct. And unlike the one-off cases mentioned above, I've started with a plausible source (a book footnote) and used the LLM to generate four templates. There are no DOI's to shortcut the process here. While technically an editor could use existing citation tools for this, the built-into-Wikipedia tools available involve copying and pasting individual fields 27 separate times. Alternatively (and this is what I would have done before competent LLMs), they could find all four books, add them to a Zotero library, and export as Wikipedia Citation Templates.
Concerns about hallucinations are a decent reason to encourage editors to either use software tools or obsessively check their LLM-synthesized citations, but (1) prohibiting LLM-generated and user-checked citations is objectively bad for the encyclopedia in such cases; (2) blocking a user who adds correct LLM-generated citations is an over-reaction.--Carwil (talk) 15:42, 31 August 2026 (UTC)
Usually even LLM users who are caught are just warned to knock it off, and aren't blocked unless they keep doing it over and over. My main concern with this proposal is even just watching the LLM notice boards, the VAST majority of the people who end up there are using middling models and don't check the output carefully, and tend not to exhibit signs that they understand how to responsibly use the tools. FineIllDoIt (talk) 22:32, 31 August 2026 (UTC)
Currently we don't do (1), and (2) has never happened (SarekOfVulcan explained this pithily above). CMD (talk) 01:04, 1 September 2026 (UTC)
Typing the LLM prompt arguably takes more time than using the citation tool, so when someone uses LLM instead, probably something about the tool is not working for them? Do we have statistics of how often the citation tool fail to resolve the citation from URL or dois? Redwolf Milkshake Fox 🦊 22:16, 31 August 2026 (UTC)
Quite often. Biggest news outlet in my country, Yonhap News, blocks Citoid entirely, forcing me to type details manually. Catalk to me! 22:22, 31 August 2026 (UTC)
Every single PDF. Thryduulf (talk) 23:54, 31 August 2026 (UTC)
I don't how rules like this can be enforced, unless the template is clearly hallucinated, I couldn't tell apart citoid and LLM generated refs.
Removing the incentives to use LLM by improving citoid (better pdf, news site support, batch import) could do everyone a favor. Redwolf Milkshake Fox 🦊 01:17, 1 September 2026 (UTC)
Dumb question: Is there a template where automation will replace an ISBN, Page with a properly formed citation?
or… Have we tried to advance the UI so that adding a citation is as easy as adding an internal wiki link? You say it’s harder to type into an agent which probably reveals how ignorant I am on how to create citations. I’ll look for a how-to but would appreciate a link if anyone beats me to finding it. Dw31415 (talk) 16:11, 1 September 2026 (UTC)
Have you tried adding a source in the visual editor? It's very easy in most cases. Katzrockso (talk) 16:32, 1 September 2026 (UTC)
Found Wikipedia:INTREF3. Yes, that’s what I’ve used dutifully up until now. Now I guess I understand better the motivation behind {{Cite Q}}. I hate pasting into forms. Dw31415 (talk) 16:47, 1 September 2026 (UTC)
I had no idea about Wikipedia:UCB. Thanks Headbomb. It’d be good to make that more prominent an option. Has that been discussed recently? Dw31415 (talk) 19:03, 1 September 2026 (UTC)
Okay Wikipedia:Citation expander is very good. I think we should propose a next step toward having that available by default. It handled the Air Traffic book example very well. Just providing {{cite book}} with isbn was expanded to include the other parameters. That said, it was only able to change:
{{cite web|website=[[The New York Times]]|url=https://www.nytimes.com/2026/01/27/us/politics/dca-plane-collision-faa.html}}
Whereas ChatGPT created
{{cite web|last=Kelly |first=Kate |title=Safety Board Blames F.A.A. for Multiple Failures in D.C. Crash |url=https://www.nytimes.com/2026/01/27/us/politics/dca-plane-collision-faa.html |website=The New York Times |date=January 27, 2026 |access-date=September 2, 2026}}
I don't think the notion that agents are slower and worse will hold up to scrutiny, especially as the technology evolves. I respect the point about keeping the guideline simple. I give this example just to check some of the assertions being madeDw31415 (talk) 01:27, 2 September 2026 (UTC)
I don't understand why is there even a discussion about this. If a tool fills a template faster than doing so manually, I just have to check that there are no mistakes instead of doing it the 1990s way, and the end result is exactly the same as doing it manually... then I see no reasonable reason to be against it. Cambalachero (talk) 17:13, 1 September 2026 (UTC)
I think the reason we are talking about this is there's a even faster way with less limitation (at the expense of lower accuracy) Redwolf Milkshake Fox 🦊 17:50, 1 September 2026 (UTC)
Comment. I share the distrust of oppose voters for simply giving an LLM a URL and hoping for the best, and have also seen LLMs free-form make up citations in tests. However, I could be convinced to support a NOLLM exemption for a more narrow case: converting an already existing text citation into Cite XYZ. No Web access, no URL. Just "transform what you see here into a citation template, exactly as you see it." I've checked the output and it seems like Google Gemini can handle this fine, and the times it raises issues are generally valid ones (e.g. if the citation itself was unclear or requiring feedback). SnowFire (talk) 16:57, 2 September 2026 (UTC)
Transfermarkt should be usable for squad lists etc.
Transfermarkt is currently completely outlawed as a source on Wikipedia, due to it's varying accuracy in terms of player transfer values. This begs the question as to why the ban isn't just for use as a verification for player values or transfer amounts. It's a perfectly accurate source for squad lists etc Edlectro28 (talk) 14:39, 27 August 2026 (UTC)
In an unrelated note (as it isn't Levivich's issue), that section marker drives me batty. What's wrong with actually using wikimarkup that you can copy and paste? Does anybody know offhand where the discussion was, if any? I'd like to see if there was a better justification than "it looks nice". --SarekOfVulcan (talk) 21:13, 31 August 2026 (UTC)
Totally agree, and it made it take like 3x longer to post the stupid subst template. I tried copying and pasting the link for the edit summary, and it kept spitting out all this stuff with %20's in it, I don't know why, couldn't figure out what was causing it or how to fix it. I would have posted this notice at AN too but just gave up instead. Levivich (talk) 21:15, 31 August 2026 (UTC)
%20 is an http escape for a space, and should normally just be replaced with underscores in a WP url. There's a similar code for the apostrophe in ANI -- I just tried to find an example, but couldn't come up with one offhand. SarekOfVulcan (talk) 21:22, 31 August 2026 (UTC)
I'm not sure what exactly you're taking issue with? I don't think anyone has mandated using a section symbol for links in discussions. Some tips for anyone who does want to use them: for those using the desktop wikitext editor, the toolbar below the text box can be used to insert the character. The {{section link}} template can be used to avoid duplication in the wikitext. There are also user scripts to make it easier to copy links for headings or comments to the clipboard (here's mine). isaacl (talk) 17:48, 2 September 2026 (UTC)
A community discussion at the administrators' noticeboard has placed all pages with content related to Kurds and Kurdistan, broadly interpreted, under the extended confirmed restriction...
This literally means that, for instance, by the letter of the wording, BGM-71 TOW, which has one single word on the topic on the page - that being listing "Kurdistan" in the 'Operators' section - has the entire page on an American anti-tank missile system falling under ethnic-conflict-based extended confirmed restrictions because it has 'content related to Kurds and Kurdistan' on it. I'm pretty sure this was not the intent of the sanction, so perhaps this wording should be slightly tweaked to, say, all content related to Kurds and Kurdistan, broadly interpreted? - The BushrangerOne ping only 22:22, 31 August 2026 (UTC)
That certainly seems poorly worded. I do not think the intent was to allow any editor the ability to ECP an entire article by adding a single sentence to it that can be reasonably construed as being related to the GS subject. I do not see a reason why that would be like that instead of just prohibiting editing the related content, like we do for WP:CT/AI, and I don't think there's any topic area that warrants harsher restrictions than that one does. –Maltazarianᚾparleyinvestigateᛅ 23:00, 31 August 2026 (UTC)
I think the typical application has always been the same as for PIA, SA etc. The wording should be corrected signed, Rosguilltalk 23:06, 31 August 2026 (UTC)
I think the wording should be kept the way it is. As it stands, admins can use their discretion to add ECP protection to a page, and they're likely to decide against that. But with the current wording, if a new-ish editor complains that the article they want to abuse isn't "Kurdish enough" to justify protection against them, then they can be pointed at that line, which should end the argument (though not necessarily their whining). WhatamIdoing (talk) 04:06, 1 September 2026 (UTC)
That is why I suggested changing it to "all content" (functionally, removing "pages with"), which would still neatly resolve the issue (and is, as Rosguill mentions, as it has been functionally applied in practice before I took a moment re-reading it today and did a double-take). Because, as I observed, the current wording puts all pages with any Kurd-related content under WP:ECR (which is not the same as WP:ECP) in their entirety. To give a direct example: as it stands right now, this edit to Eurocopter EC120 Colibri is an ECR violation, at that article mentions that a number of EC120s have been operated by the traffic police of Kurdistan, Iraq. That is, naturally, ridiculous. But that is also the literal result of the sanction's wording as it stands. - The BushrangerOne ping only 06:06, 1 September 2026 (UTC)
Agreed, this is much broader than all the extended confirmed restrictions imposed on CTs by ArbCom (WP:PIA explicitly allows for only "parts of a page" which fall within the topic area being affected by the restriction!)
The text of Wikipedia:General sanctions/Kurds and Kurdistan#Remedies on the other hand has the stricter wording only extended-confirmed editors may make edits related to the topic area and the restriction applies to all edits and pages related to the topic area, broadly construed. I would support amending the summary text to more accurately reflect this (which surely more accurately reflects the intention of the restriction!) Caeciliusinhorto-public (talk) 09:56, 1 September 2026 (UTC)
As a note those quotes are actually standard ECR rules - note the top of PIA which says The contentious topics procedure applies to all pages and edits related to this contentious topic and only extended-confirmed editors may make edits related to the topic area, with certain exceptions. - The BushrangerOne ping only 14:28, 1 September 2026 (UTC)
It's also worth noting that a similar setup (ArbCom CTOP, community ECR) applies in the Armenia-Azerbaijan topic area, and I believe that GS predates KURD's. —Jéské Courianov^_^vLook outit's Jimothy! 17:58, 2 September 2026 (UTC)
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))
Survey (RECALL)
speedy close and workshop a larger RfC around recall. There's no rush to open more limited RfCs, particularly when discussion is ongoing. voorts (talk/contributions) 13:08, 2 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)
Option F added below is superior to Option A (which is my second choice). I Oppose options B & D and am neutral regarding C. Thryduulf (talk) 19:55, 3 September 2026 (UTC)
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)
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)
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)
A, but not sure about whether to speedy close or not. --SarekOfVulcan (talk) 13:41, 2 September 2026 (UTC)
Currently at F > E > A, oppose B/D. --SarekOfVulcan (talk) 20:00, 3 September 2026 (UTC)
Option A. This doesn't need to be speedily closed. A larger RfC on the recall process is unnecessary.Katzrockso (talk) 19:41, 2 September 2026 (UTC)
Option C - Any signatures added after the 30-day period should be reverted off lest there are questions down the road about whether or not signatures were valid. All other positions are non-starters. —Jéské Courianov^_^vLook outit's Jimothy! 19:47, 2 September 2026 (UTC)
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)
Anything but Option D as that is a drama nightmare waiting to happen. Gnomingstuff (talk) 20:23, 2 September 2026 (UTC)
A without prejudice to a larger discussion on recall. Tazerdadog (talk) 20:30, 2 September 2026 (UTC)
A (second choice: F 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)
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)
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)
That sounds more like a disaster waiting to happen. FaviFake (talk) 09:20, 3 September 2026 (UTC)
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) —
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)
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)
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)
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)
You missed "may"! FaviFake (talk) 10:32, 3 September 2026 (UTC)
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)
The interpretation was first brought up starting from this comment in the original discussion, in case you're interested. I note that Some1 has !voted for Option C, so I really hope I didn't misunderstand or misrepresent their earlier comments. FaviFake (talk) 14:03, 3 September 2026 (UTC)
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)
Thank you for the clarification! FaviFake (talk) 23:23, 3 September 2026 (UTC)
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)
Same here that it doesn't make sense, but it does seem that some people hold that position. --Super Goku V (talk) 20:04, 3 September 2026 (UTC)
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)
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)
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)
Supposedly, C means that someone can try to sign after 30 days has passed and have it count, which goes against my understanding of the Phase II RfC. So, I support A and Option E: "Petitions open for 30 days without receiving 25 valid signatures are closed as failed." --Super Goku V (talk) 10:13, 3 September 2026 (UTC)
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)
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/C 09:25, 3 September 2026 (UTC)
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/C 09:30, 3 September 2026 (UTC)
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)
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)
A - For any process that has a clear time limit and a clear vote threshold (not !vote), the time limit should be strict. —Rhododendritestalk \\ 12:18, 3 September 2026 (UTC)
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)
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)
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)
Speedy close per above. This RFC is a waste of time as there is nothing of substance being proposed. -- LWGtalk(VOPOV) 23:51, 5 September 2026 (UTC)
@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)
Discussion (RECALL)
Isn't A and C the same but worded differently?– robertsky (talk) 12:14, 2 September 2026 (UTC)
A is for some reason keeping signatures that are late on the petition for some reason, but they won't count. --Super Goku V (talk) 02:47, 3 September 2026 (UTC)
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)
This RfC seems to show a lack of understanding of why a time limit was imposed and open-ended petitions were rejected. voorts (talk/contributions) 13:07, 2 September 2026 (UTC)
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)
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)
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)
I meant half-baked, not half-assed. voorts (talk/contributions) 18:38, 3 September 2026 (UTC)
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)
I agree with the last part; the result of this RfC should not affect the currently open petition. FaviFake (talk) 22:29, 3 September 2026 (UTC)
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)
How much discussion is necessary to initiate an RfC? Katzrockso (talk) 14:40, 3 September 2026 (UTC)
"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."
It felt like we were wrapping things up and were going to decide between an RfC or accepting the proposed wording. --Super Goku V (talk) 18:42, 3 September 2026 (UTC)
If there had been a WP:RFCBEFORE maybe we would have the missing option with any signatures after the the 720 hours reverted or struck not left. Leaving late signatures not reverted or struck is just leaving it open to confuse people who just look and see 25+ signatures. KylieTastic (talk) 14:03, 3 September 2026 (UTC) strike as I missed there was some discussion Wikipedia_talk:Administrator_recall#Closing_failed_petitionsKylieTastic (talk) 14:20, 3 September 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
There was a suggestion in the recall archives to use bots to close them which had a few opposes. Personally, I would say that most to all of the issues raised then would be resolved now by having a bot close the discussion for review at the 30 day mark and having an editor confirm if 25 votes were not received at the deadline or if a 25th signature just made it in and the petition had yet to be checked and closed. --Super Goku V (talk) 18:30, 3 September 2026 (UTC)
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)
Huh? I don't see what you are meaning here. --Super Goku V (talk) 19:56, 3 September 2026 (UTC)
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)
First sentence: That's the idea? Second sentence: We would. The reviewer. --Super Goku V (talk) 20:01, 3 September 2026 (UTC)
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)
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)
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)
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)
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)
I think that we could do something similar with a countdown timer template such as Template:Days left. It won't be perfectly up to the minute, but it should give editors a notion of whether the deadline is close. WhatamIdoing (talk) 04:39, 4 September 2026 (UTC)
If it is that much of a cost, then gotcha. --Super Goku V (talk) 05:30, 4 September 2026 (UTC)
If you don't want to strike or revert late signatures, there's always the option of adding an explanatory note. WhatamIdoing (talk) 04:36, 4 September 2026 (UTC)
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)
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)
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)
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)
Good point! FaviFake (talk) 09:20, 5 September 2026 (UTC)
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)
(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)
I actually do support F verbatim, including "reverted or struck". Thryduulf (talk) 10:11, 6 September 2026 (UTC)
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)
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)
RFC: changes to NPOL
I have started an RFC on changes to NPOL at WT:Notability_(people)#RFC:_Change_to_NPOL to clarify sourcing expectations for local elected officials and candidates. All editors are invited to participate. - Enos733 (talk) 21:58, 4 September 2026 (UTC)
Technical
Partial blocks for a group of pages
I'm guessing that this is impossible, but asking in case I've overlooked something.
Is it possible to partial-block someone from all pages that match a certain criterion, without specifying the pages in question? (I know about namespace blocking; I'm not talking about that.) For example, we have several thousand mainspace pages beginning with the string "National Register of Historic Places". Could someone be blocked from all of them? It sounds like an admin could spend a massive amount of time applying 100+ separate partial blocks of 50 pages each, but I'm envisioning a block from all pages in which this string appears.
Of course, I understand that it's probably better to issue a sitewide block in such a situation; I'm strictly asking about the technical aspects. Nyttend (talk) 07:36, 27 August 2026 (UTC)
Also interested in this, as I have an IP range which only vandalises certain pages, but there are a lot of them, and I can't block the full range completely because there's a massive amount of collateral damage. Also, last time I tried to partial block the range, it restricted me to 10 pages at a time... Black Kite (talk) 07:47, 27 August 2026 (UTC)
Not what was asked for, but the limit is now 50 and you can create multiple blocks. Certes (talk) 11:34, 27 August 2026 (UTC)
Ah, that's useful to know, thanks. Black Kite (talk) 11:38, 27 August 2026 (UTC)
A related use case that occurred to me in a recent discussion is partial blocking a page and all of its subpages. Probably most relevant in the Wikipedia space, where it could eg. block all AfDs, instead of the entire Wikipedia space. CMD (talk) 11:14, 27 August 2026 (UTC)
It is not possible today to do this. It seems in the realm of feasibility. Izno (talk) 15:56, 27 August 2026 (UTC)
There's a security risk in this, as it means that a non-admin could effectively block or unblock a user from a page simply by renaming it. That's why partial blocks by category were rejected in T190349 and why cascading semi-protection is diabled. Another solution might be to block the user from any pages linked from a certain page (such as mediawiki:partial block/User:Example) that is protected so it can only be edited by administrators, but that was rejected in T208175 for not being transparent with logging. @Chipmunkdavis Partial blocking from subpages is currently an open task on Phabricator: T242670. --Ahecht (TALK PAGE) 16:16, 27 August 2026 (UTC)
Definitely the wrong tool, but probably technically possible with an edit filter? LittlePuppers (talk) 20:14, 28 August 2026 (UTC)
Can someone explain why cascading semiprotection isn't possible? From reading the Bugzilla report years ago, I remember a couple of major reasons it was disabled — if page A were cascade semi-protected, a non-admin could semiprotect page B by transcluding it onto A; and the cascaded pages ended up being fully protected instead of semiprotected. But on principle, the idea sounds great, and I don't see why software couldn't be modified (1) to ensure that the cascading protection be semi, and (2) to allow full protection and cascading semiprotection to be applied concurrently to a page. Is there some fundamental reason that the software can't be rewritten to work this way? Would it be possible, but preposterously difficult to do such a rewrite? Is there some logical hole in this thinking that would still permit non-admins to semiprotect pages somehow? Nyttend (talk) 10:41, 29 August 2026 (UTC)
The problem was indeed that if page A had cascading semi-protection, then any autoconfirmed non-admin could semi-protect any other page by transcluding it onto A. This was fixed by making it so that editing a page with cascading-protection applied requires the ability to apply protection. Since we have no groups that can apply protection but not edit fully-protected pages, cascading semi-protection was eventually removed as an option as being redundant.Your suggested change wouldn't really fix the original issue. Say A was fully-protected and cascade-semi-protected, and already transcludes B. Then people could cascade-semi-protect any other page by transcluding it onto B, therefore B also needs to be editable only by people who can protect pages and you're back to the current situation. Anomie⚔ 22:30, 29 August 2026 (UTC)
Ah, I didn't remember that it worked that way; I thought that "transclude X onto Y" semiprotected X only if X had been given the semiprotection. Take your example and transclude C onto B: I knew that B would be semiprotected, but I thought C wouldn't be, unless it were also transcluded onto A. Thank you for the correction. Nyttend (talk) 20:36, 31 August 2026 (UTC)
Limitations of the Wikipedia app?
I asked a question at the Help Desk: Wikipedia:Help_desk#Can a Wikipedia-app editor ask a question here? which snowballed until it was suggested that I bring it up here. Does anyone have any enlightening suggestions? I have only used the app on this one device (a Samsung Galaxy tablet) so perhaps it's just me. But I have recently updated the WP app (to Version 50603-r-2026-08-25). Thanks. • ~2026-46677-01 (talk) 01:11, 29 August 2026 (UTC)
It sounded like you needed help signing into your account on the Wikipedia app. My knowledge is limited to the iOS app, but I'd imagine it be similar: hit the little person icon, then click the "Log in/Join Wikipedia" button. There, there should be fields for username and password, where you can put those details (or create an account). Again, this is just on the iOS app.
That being said, while you did say you want to stay on the app, I would not recommend using it on non-mainspace articles. The app is only really built for (Article:) and Talk: pages, not anything else. I used to use the app only, but began using the web when I started editing non-mainspace and talkspace pages. It is much more customizable, is easier to use, and is generally just better in my opinion. Also, I would recommend using a logged-in account as that would make it a lot easier to communicate on Wikipedia and keep track of your edits. Axolitl(talk|contribs) 02:47, 30 August 2026 (UTC)
I do what you describe in your first paragraph and it pushes me out to a session in my default browser, where I have a different TA to the TA I had in the app. My experience (detailed in the Help Desk thread) is that it is not possible to log in within the app. Surely this should be rectified. Also it would be nice if the app and browser used the same TA (but I *can* log in in the browser). I am using a Samsung Galaxy tablet with Samsung Internet browser. ~2026-46677-01 (talk) 06:27, 30 August 2026 (UTC)
Sorry, I should have said: If I do what you describe in your first paragraph, it fails with one or other of the two errors I described in the HD thread (but stays in the app). If I "Search" for Special:UserLogin, *that* is what pushes me out into the browser. • ~2026-46677-01 (talk) 06:41, 30 August 2026 (UTC)
Special:LogIn would definitely not work, as that is kind of what I talked about above. You need to use the native login on the app. What errors are you encountering when you do so? Axolitl(talk|contribs) 15:03, 30 August 2026 (UTC)
Someone must have changed something since yesterday, because the presentation has changed a bit and login in the app now *works*! Thank you. ~2026-46677-01 (talk) 04:48, 31 August 2026 (UTC)
BUT ... Once I'm logged in there's nothing to confirm that (the little-person icon is not shown anywhere) unless I save the edit and look for who did it, and how do I log out? ~2026-46677-01 (talk) 05:47, 31 August 2026 (UTC) ("icon" added) ~2026-46677-01 (talk) 05:49, 31 August 2026 (UTC)
Weird. My knowledge on the Samsung app is limited, but on my iPhone there is a small person icon which, if I click on, says my username along with settings, my user page, and an option to log off. Axolitl(talk|contribs) 05:55, 31 August 2026 (UTC)
Before the change, the little-person (LP) icon (as 50/50 B&W) appeared on the Editing, Preview and Summarise_edit pages (but failed on all 3). Now, before I logged in it appeared only on the Summarise_edit page (now as an LP outline in a crossed circle). I clicked it, entered userID and password, and it went through with nothing to indicate success or failure, but now the LP icon was absent, and the saved edit was made by my logged-in ID. The LP icon has remained absent ever since. ~2026-46677-01 (talk) 06:17, 31 August 2026 (UTC)
Meaning, I suppose, that they have forgotten to show it for a logged-in user. ~2026-46677-01 (talk) 06:20, 31 August 2026 (UTC)
Hello all,
This is Amal Ramadan and I support the Wikipedia mobile apps team, on Android, you can confirm that you’re logged in by opening the More tab, where your account details and the option to log out are shown; the person icon is only used in the iOS app.
And for any further questions you can email us through the support emails:
android-support@wikimedia.org or iOS-support@wikimedia.org ARamadan-WMF (talk) 07:39, 2 September 2026 (UTC)
What "More" tab? Please understand that I am using a tablet and as I reply to you now I am using the browser and am a TA (46677). If I swap apps and go into the Wikipedia app things are different: I have entered WP:SAND and am in the Sandbox (to make it specific for you to understand "where I am"). I see the Wikipedia:Sandbox heading and the text some user has put there (ABOVE the "Welcome to this Sandbox page" box, but that is a different apparent deficiency in the app that I don't want to go into now). Across the top of the app screen I see: 1) a back-arrow, 2) the "Search Wikipedia" wide box, 3) literal "[7]" (which is the number of pages I happen to have open in the app at the moment), 4) the "Bell" icon, and 5) the "three vertical dots". Across the bottom of the screen are icons with text labels: "Save", "Language", "Find in article", "Theme", and "Contents". (So no "More" so far.) If I click the "three vertical dots" I see a drop-down list on the right-hand side with icons for: "Share", "Watch", "Talk page", "Edit history", "View on map" (greyed out), "New tab", "Home", "Categories", "Edit article", and "Customise toolbar". There are no Tabs, that's in the browser only. I have done edits in the app and they are attributed to my logged-in identity, but I do NOT see the little-person icon anywhere, or anything else that looks like it might log me out. So how do I log out? ~2026-46677-01 (talk) 10:11, 2 September 2026 (UTC) (minor edit) ~2026-46677-01 (talk) 10:14, 2 September 2026 (UTC) Another (bigger) edit ~2026-46677-01 (talk) 10:21, 2 September 2026 (UTC) (Yet another minor edit) ~2026-46677-01 (talk) 10:29, 2 September 2026 (UTC)
It sounds like you are currently in the article view, which is why you are seeing the article toolbar rather than the app’s main navigation, please tap the back arrow in the top-left corner to leave the article view and return to the app’s main screen,now you should see the main navigation bar across the bottom, “More” is the tab on the far right; tap “More,” then tap your username or account details, where you will find the option to log out.
If “More” still does not appear after returning to the main screen, please let us know your Wikipedia app version and tablet model and send a screen recorded video to above listed email. ARamadan-WMF (talk) ARamadan-WMF (talk) 13:35, 2 September 2026 (UTC)
Yes, the "More" tab is where you described, and when I click it it does open a panel with my username at the top, but when I click that I get a mostly-blank screen with the message in the centre: "Wikipedia does not have a user page with this exact name. Generally..." and below that a button which says "Go back" (which does go back), but it leaves me still logged in. ~2026-46677-01 (talk) 13:57, 2 September 2026 (UTC)
Also, Axolitl above at 05:55 31 August 2026 (UTC) said ...on my iPhone there is a small person icon which, if I click on, says my username along with settings, my user page, and an option to log off. I assume that was on every page, not having to go to the main page and find it in a tab. That "icon on every page" operation was what the Android version of the app used to do (but the icon didn't work, so I was always a TA). Hopefully that presentation will eventually be restored. ~2026-46677-01 (talk) 20:26, 2 September 2026 (UTC)
(Former ~2026-46677-01 speaking:) I was trying various actions and did something I don't fully remember, but I ended up logged out in both the app and the browser. With the new TA something displayed a link to the info in WP:TA. I was happy with an ID that only lasted 90 days, but I do log in occasionally, and if it's going to renew my TA every time I do that, that is excessive. Looks like I ought to do what people suggest and usually log in. ~2026-47922-63 (talk) 03:20, 3 September 2026 (UTC)
Allow Wikivoyage style maps on EN WP
Wikivoyage has many incredible interactive maps, that are interactive right within the article space. Some examples:
Looked at turning on this ability here but it appears we need this gadget. Thoughts? Doc James (talk · contribs · email) 03:30, 29 August 2026 (UTC)
I support incorporating this on en:WP. I just looked at the first example above and found that I could pan the map worldwide and even locate my own house using the maximum zoom! Mike Turnbull (talk) 14:58, 29 August 2026 (UTC)
Support – First impression is that, while not revolutionary, this has real applications in some articles thanks to the layers feature and the clickable markers, which show a picture of the point of interest and its wikilinked name. That last feature can surely be used to great effect in articles about historical districts of some cities, for example: The Hague (use the layers to disable stuff like food and transportation). –Maltazarianᚾparleyinvestigateᛅ 19:56, 30 August 2026 (UTC)
I hope it does not need to be stated that my support is conditional on the implementation not breaking a bunch of important stuff. –Maltazarianᚾparleyinvestigateᛅ 21:08, 30 August 2026 (UTC)
This is probably not gonna happen, as the maps are static on en.wp specifically because of the load live maps would cause on the maps cluster. We always use click to load interactions everywhere for that reason. The maps on wikivoyage are an exception because of wikivoyage being very maps oriented and because of them having a historic precedent from before they joined us. However it hasn't been evaluated in a long time, so it can be asked.
And no, that gadget doesn't have anything to do with that. The gadget is wikivoyage's OLD map system, from before the times of wikivoyage. It isn't used on english wikivoyage (although some other languages still haven't updated their maps to the new system and DO use it. —TheDJ (talk • contribs) 20:11, 30 August 2026 (UTC)
Support whatever works. TheDJ: can you provide some links to the map tools, gadgets, etc. on WikiVoyage? Are the interactive OWID maps on English Wikipedia a load problem for the servers? See Commons:Help:Interactive data graphics by Our World in Data. Maybe some of these Wikivoyage map tools can be moved to English Wikipedia, or adapted to do so. Or combined with Wikipedia map tools. Keeping the best parts. Is money needed for more servers, etc.? --Timeshifter (talk) 21:01, 30 August 2026 (UTC)
I am not able to figure out how to interactive with it without it going full screen... additionally there is no line giving distances. Plus it would be nice to be able to simply use the ones from WikiVoyage. Doc James (talk · contribs · email) 11:57, 31 August 2026 (UTC)
Yes this is what "click to load" means. You first have to interact with the element before the javascript loads and the element becomes interactive. This is our policy for all Wikimedia interactivity (with the exception of wikivoyage maps). —TheDJ (talk • contribs) 10:26, 1 September 2026 (UTC)
Not sure what you mean with "no line giving distances" btw. As far as I can tell wikivoyage has a line because a wikivoyager has defined that the line should be drawn. —TheDJ (talk • contribs) 10:29, 1 September 2026 (UTC)
If you look at Wikivoyage, in the left lower aspect of the map their is a line that shows you how far 20 km is. If you click on said line it even changes to USA units. It helps a great deal to put maps into perspective. Doc James (talk · contribs · email) 12:27, 1 September 2026 (UTC)
It would be nice if one could click on the map and it would become interactive in place, rather than increasing to full screen size. Doc James (talk · contribs · email) 12:28, 1 September 2026 (UTC)
Why? then you need to click twice, because most maps are the size of a postage stamp in English Wikipedia. I think what you MEAN to say here perhaps, is that the [ ] icon on the thing isn't enough of an indication that the element is interactive. I could get behind that idea. —TheDJ (talk • contribs) 16:45, 1 September 2026 (UTC)
The maps here on this article are a decent size Oranges_and_Lemons. Yes you click the right upper corner [] icon and it becomes full size and interactive. Else you click anywhere else on the map and the zoom in and out button appear and the distance line appears. And the overlays options appear. And it becomes interactive in place. At least that is my though for UX.
Also discovered that the version of the kartographer extension here on EN WP is different from that on EN WV, which i imagine is why the map options are different. Doc James (talk · contribs · email) 16:57, 1 September 2026 (UTC)
In my opinion, the biggest reason we don't have better maps on English Wikipedia, is that we don't have enough editors to learn how to write complex maps. It is difficult because you need to learn about maps, coordinate systems, openstreetmap, wikicode, kartographer, wikidata all at the same time. That is a problem for most wikieditors. Another point is that articles (unlike on wikivoyage) generally only deal with a SINGLE topic and location and thus there is often no need to show more than one element IF a map is used. And lastly, many of the articles that could use maps like this are already very old and as editors we don't really update established articles, a lot is stuck in a state of 10+ years ago with only antivandalism work and minor modifications happening. If you are interested in things like that, I advice Wikipedia:WikiProject_Maps, Kartographer help page, Commons mapdata and some English Wikipedia specific enhancements on top of that at Template:OSM Location map —TheDJ (talk • contribs) 10:57, 1 September 2026 (UTC)
The hope was to be able to copy over a bunch of maps from Wikivoyage like the G20 one. Doc James (talk · contribs · email) 12:25, 1 September 2026 (UTC)
@TheDJ: Could we use Wikivoyage maps on Wikipedia if we converted them to "click to load" for Wikipedia use. They could stay the same on Wikivoyage. That way people could copy over useful maps to Wikipedia more easily than creating new ones. Changes could be made as needed too. And the same tools would be on Wikipedia (except for the one change of "click to load"). So completely new maps could be created. So maps might be copied over from Wikipedia to Wikivoyage too. We already have an existing pool of editors familiar with the Wikivoyage map tools, and many probably edit a little on Wikipedia. So that makes things a little easier. As someone who has been working on a particular form of US choropleth maps for a few years, I know what you mean about the lack of map editors. We need a Help:Map index of help pages, kind of like the Help:Table set of around 25-30 table help pages. They get a lot of page views. I watch nearly all of them. --Timeshifter (talk) 15:11, 1 September 2026 (UTC)
Oppose per TheDJ and Matma Rex. Izno (talk) 20:07, 31 August 2026 (UTC)
@Izno: Neither of them said they oppose allowing Wikivoyage style maps on EN WP. They both are just pointing out problems and alternatives. --Timeshifter (talk) 20:29, 31 August 2026 (UTC)
Yes, one can still oppose per someone even if the someone doesn't use the word oppose in their statement. Izno (talk) 20:31, 31 August 2026 (UTC)
So you oppose because there may be some problems per TheDJ: "However it hasn't been evaluated in a long time, so it can be asked."
The maps can be converted to "click to load interactions" if need be.
And it is good there are some existing map tools as suggested by Matma Rex. But Doc James looked at the Matma Rex suggested tool, and said that he likes the WikiVoyage ones better.
So let's evaluate the map tools at WikiVoyage. Nothing TheDJ or Matma Rex said blocks that. --Timeshifter (talk) 21:47, 31 August 2026 (UTC)
No, that's not how consensus works. I am free to say "I think the rationales and/or alternatives provided/identified by some other people are sufficient to oppose the addition of this as a gadget of any sort". Izno (talk) 21:58, 31 August 2026 (UTC)
Doc James said "it appears we need this gadget." I don't think he cares what tools or gadgets are used, as long as they get the job done. Since the particular gadget he linked to is not used on English Wikivoyage according to TheDJ, then we can look at other tools on Wikivoyage, Wikipedia, and elsewhere. You apparently are not interested in adding any map functionality from Wikivoyage, and I still have no clue why. --Timeshifter (talk) 23:23, 31 August 2026 (UTC)
Sigfig combined with UN population template
The total population figure given in the infobox of Asia just struck me as absurdly precise, and I tried {{Significant figures}} on it. However, the result was in scientific notation, unexpectedly. Any idea why that is? What format does {{UN population}} output its figures in? --Florian Blaschke (talk) 23:30, 30 August 2026 (UTC)
It seems that {{Significant figures}} automatically returns scientific notation if the input figure is >=10 digits long (demo). All the example inputs on the template page are shorter than that, so this isn't shown there. Suðurhafsljósæta (talk) 09:57, 31 August 2026 (UTC)
I've updated the docs to include this. Suðurhafsljósæta (talk) 10:13, 31 August 2026 (UTC)
The documentation at {{UN population}} gives examples of how to provide approximate figures. – Jonesey95 (talk) 16:07, 31 August 2026 (UTC)
I have hopefully implemented a solution on Asia using {{#expr}}. Kind of looks messy, but works. Axolitl(talk|contribs) 02:43, 3 September 2026 (UTC)
Looks good to me! Thank you for the comment, that will definitely be useful in the future.:) Suðurhafsljósæta (talk) 07:30, 3 September 2026 (UTC)
Page preview image when the top image is a page from a PDF
I've noticed that if the top image in article is a page in a PDF on Commons, the page image used in previews (search results, link popups) is for the cover of the PDF not the page specified. Is this is a bug? Or is this normal? Is there a way to fix it?
For example, the top image on Old Bolsheviks is defined by File:Альбом по истории ВКП(б) (1926).pdf|page=57, but when hovering on a link to Old Bolsheviks the preview image is the cover of the PDF not page 57. – Scyrme (talk/solidarity) 03:38, 31 August 2026 (UTC)
I initially posted this at the help desk, but received no replies. I'm hoping maybe someone here may know whether this is a bug. – Scyrme (talk/solidarity) 03:39, 31 August 2026 (UTC)
Thanks for the suggestion. I've added a notice there. – Scyrme (talk/solidarity) 06:11, 31 August 2026 (UTC)
Navigation popups is a 2004 tool for advanced editors that has nothing to do with page images and the page previews functionality —TheDJ (talk • contribs) 11:06, 1 September 2026 (UTC)
This is a known problem that is tracked (since 2018) at phab:T211754 —TheDJ (talk • contribs) 11:06, 1 September 2026 (UTC)
Nothing to do but wait more, then? – Scyrme (talk/solidarity) 21:21, 1 September 2026 (UTC)
I can suggest making it a wishlist item. Seem like a good candidate for that. —TheDJ (talk • contribs) 21:26, 1 September 2026 (UTC)
"A link was made"
Screen recording
More than half of the notifications I get in my Wikipedia inbox every day are "A link was made from X to Mark Girolami." For all of these notifications, clicking on the notification (desktop) or diff option (mobile) does not show the actual diff where a link to Mark's age was added. After looking at Special:WhatLinksHere/Mark_Girolami, it looks like most of the incoming links are via the Template:Guy Medal template.
I don't think this is a bug per se, but I was wondering if a) could the watchlist notification functionality be changed to not notify me about new incoming links via transcluded templates? and b) if not, could the diff option be updated to show the diff where the template was added to the page, rather than a random edit? BhamBoi (talk) 13:10, 31 August 2026 (UTC)
@BhamBoi: The link was added to the template 23 August. You probably get a notification about the first article edit after that. It will soon slow down. When the template is added to articles in the future you get a notification about that edit. I don't think it's realistic to get the system changed. You can disable page link notifications for all pages at Special:Preferences#mw-prefsection-echo. PrimeHunter (talk) 14:23, 31 August 2026 (UTC)
That makes a lot of sense, thanks! BhamBoi (talk) 14:33, 31 August 2026 (UTC)
It would be wonderful for someone other than the original author to be able to opt in to receiving notifications for new links to pages. For example, almost every new link to Zunz needs to be amended to lead to Leopold Zunz instead, and this would be an easy way to know when such a fix is needed. Certes (talk) 18:33, 31 August 2026 (UTC)
That feature-request is tracked at phab:T66090 (which I've cleaned-up a little bit). Quiddity (WMF) (talk) 19:12, 31 August 2026 (UTC)
For Disambig pages in particular, the (currently Beta Feature) Suggestion Mode sub-feature for Special:EditChecks#disambiguation should help reduce the quantity of incoming links, in the future. Quiddity (WMF) (talk) 19:28, 31 August 2026 (UTC)
Thanks again; that should help with dabs. We've also done a lot of work on cleaning up bad links to non-dabs (iPhones sold by Apple the fruit, etc.) Certes (talk) 22:34, 31 August 2026 (UTC)
Another strange redlinked category
The latest run of Special:WantedCategories features a redlinked Category:Wikipedia extended-protected redirects, with one template redirect in it, even though the category was moved to Category:Wikipedia extended-confirmed-protected redirects almost ten months ago. However, the category is not directly declared on the page itself, and is being transcluded from somewhere other than any of the page's actual content, so I can't find where it's coming from in order to fix it.
So could somebody look into this? Thanks. Bearcat (talk) 16:20, 31 August 2026 (UTC)
Looks like it's already fixed. Someone got to it before I could check it. Max (talk) 16:25, 31 August 2026 (UTC)
Category:Current qualifications
Hello. I would like to add the following article — 2027 FIFA Women's World Cup qualification (UEFA)(and a few similar ones) — into some kind of "current" category. I don't think the Category:Current sports events is suitable for this purpose. Maybe we should create a new category; above, in the section title, I suggested one name. Of course, it could be adjusted a bit. What do you think about this? Thanks, Maiō T. (talk) 19:38, 31 August 2026 (UTC)
Thank you Jonesey; I didn't know about that option. So I'm wiser now. 😉 Maiō T. (talk) 09:47, 1 September 2026 (UTC)
Tech News: 2026-36
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
A new format for the Community Wishlist is open for feedback. You can read the proposed ideas on Meta. This new process plans to improve how wishes are triaged, voted on, and prioritized in a way that is transparent and balanced across project families and language editions. This consultation is open for two weeks.
Updates for editors
The latest release of the Wikipedia Android app 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.
The Reading Lists feature was enabled for all logged-in users on Bengali, Chinese, Czech and Vietnamese Wikipedias on August 25, after several months as a beta feature. Reading Lists will be available to all logged-in users on Arabic, French and Indonesian Wikipedias on September 1, followed by English Wikipedia on September 14, and all other Wikipedia wikis on September 28.
At the end of the month, some logged-out readers on Bengali, Czech, Persian, English, and Polish Wikipedias using the Minerva skin on mobile will see an updated navigation bar in an A/B test. The test will compare the current navigation bar with a new version designed to make it easier to find information more quickly. The goal is to determine whether these changes encourage readers to return more often. This experiment will not change the experience for logged-in readers and/or editors.
Editors who maintain redirects, templates, and categories used on redirect pages now have improved ways for finding and curating redirects. Previously, redirects pages could not be searched. Two new search keywords, onlyredirects: and withredirects:, now allow redirects to be searched directly and can be combined with existing keywords such as incategory:, intitle:, and insource:.
The ISBN lookup tools for generating citations were recently not working because of external service problems. Developers are working on solutions.
View all 30 community-submitted tasks that were resolved last week. For example, an issue where searching for pages by category using deepcat could return no results or unrelated results has now been fixed.
Updates for technical contributors
The domain of URLs for thumbnails is changing from upload.wikimedia.org to thumb.wikimedia.org. The old URLs will continue to work for the foreseeable future but MediaWiki will advertise the new domain instead. URLs to other types of media such as original files, videos and transcodes will still be served from upload.wikimedia.org.
The Wikimedia Math API is now deprecated. These endpoints will be fully sunset by the end of September 2026. Developers who call these endpoints should transition to alternative math rendering solutions, such as the native MathML or MathJax. Third-party MediaWiki installations that utilize the Math extension for formula rendering are required to upgrade to v1.43+ to avoid disruption of service.
Thank you. The new ability to search within redirects will be very useful, especially for certain gnoming tasks. Certes (talk) 09:47, 1 September 2026 (UTC)
Unfortunately, there is no UI yet to facilitate these keywords. So you have to input them manually. —TheDJ (talk • contribs) 10:17, 1 September 2026 (UTC)
Image not loading the SVG
When I looked the SVG, I seen the image is missing so it not loading on wikipedia?
On a similar but different map, I'm seeing this error "Error rendering SVG /tmp/tmpqfmkk6kp: maximum depth of 50 nested layers has been exceeded" Ladsgroupoverleg 09:56, 2 September 2026 (UTC)
Phase 3: Reading lists full feature rollout
Hi everyone,
TL;DR: Reading lists are going to be deployed to English Wikipedia September 14. You can read the FAQ about the feature here.
Starting September 14, editors on English Wikipedia will start to see a bookmark icon next to the watchstar. This bookmark allows users to save articles to read later, as part of the reading lists feature.
This screenshot shows how the saved articles page appears on desktop, using Vector 22 skin.This screenshot shows how the saved articles page looks on mobile web using Minerva skin.
In April the Reader Experience team launched reading lists to all Wikipedias as a beta feature for the desktop and mobile web browser. This beta period helped us to both validate the usefulness of the feature and to fix bugs for a smoother, more polished user experience. We are now confident in the feature’s readiness as a full feature.
What the feature is:
This feature is one of our first efforts toward providing Wikipedia readers with a way to participate in their reading experience. With declining pageviews to Wikipedia and fewer readers returning to the site, we hope that by encouraging this kind of engagement with Wikipedia, more readers will return more frequently, with some of them eventually becoming future editors. The feature is already highly utilized on the Apps, where it has contributed to improved reader retention.
What we learned from the beta:
During the beta period, 93% of users surveyed responded that the reading list feature was useful to them. At first, the beta feature design replaced the watchstar with the bookmark icon. We heard feedback from editors that this was disruptive to their workflows and disappointed some editors who wanted to use the feature alongside their watchstar usage. As a result, we updated the design so that logged in editors will see both buttons in the toolbar. This change was rolled out into the beta feature in July.
The experience will be as follows:
Desktop: Users will see both watchstar and bookmark icon above the article in the toolbar. They will also see both saved list and watchlist in the top nav, and both the watchstar and bookmark icon in the sticky header.
Mobile: Users will see bookmark icon at the top of the article, with the watchstar in the overflow menu.
We also plan to start giving logged out readers on mobile web the option to create an account by showing them the bookmark icon with a pulsating blue dot the first time they see it to indicate that it is new. This is based on findings from an experiment we conducted across German, Spanish, Italian, Portuguese, Polish, Dutch, Turkish, and Urdu wikis from May 18 - June 18, showing logged-out readers on mobile web a bookmark icon instead of the default. We will start showing the bookmark icon to logged out users on mobile web instead of the watchstar throughout September.
How the full feature will be implemented:
The full feature first rolled out to Bengali, Chinese, Czech, and Vietnamese Wikipedias on August 25, then Arabic, French, and Indonesian Wikipedias September 1, soon to be followed by English Wikipedia September 14. The feature will then be deployed to all wikis globally September 28. After the rollout, reading lists will no longer be a beta feature, but rather be available to all logged-in users. Users who are logged in across multiple devices will see items they have saved synced across devices, including items saved from the Wikipedia App.
What is coming next:
In the beta survey, we received 800 open-ended comments. Suggestions for future additions included folders, collections or categories, notetaking, sharing or exporting, and supporting more namespaces. We look forward to exploring these and other ideas as the feature matures. We plan to add the capability for users to create collections of articles within their saved items, as users already can in the Apps, to the web feature in October.
We encourage you to try out the full feature and give us feedback on the project page. Do you have any other ideas for reading lists based on this information? Please let us know.
This is great news. I have really been enjoying reading lists on the app and as a beta feature on the desktop browser. Thanks! Suðurhafsljósæta (talk) 09:28, 1 September 2026 (UTC)
Just please be very wary with the suggestion of "sharing" such lists (onwiki, that is), please don't reinvent Wikipedia:Gather which was in that regard similar, and was a disaster. Apart from this, this looks at first glance to be a really good feature, thanks. Fram (talk) 10:50, 1 September 2026 (UTC)
Thanks @Fram! Definitely agreed and understood on the sharing lists point. Confirming that the feature is only for private, personal Reading Lists. It does not create publicly viewable lists, allow for sharing on-wiki, or ask editors to moderate user-generated list content. EBlackorby-WMF (talk) 14:23, 1 September 2026 (UTC)
Thank you! Fram (talk) 14:28, 1 September 2026 (UTC)
@EBlackorby-WMF I see the "Saved" page has a lock icon. I personally find this a bit confusing since I'm left wondering what exactly am I being protected from?:) Sohom (talk) 11:29, 1 September 2026 (UTC)
@EBlackorby-WMF I'm guessing it is to indicate that the page is not editable from there? —TheDJ (talk • contribs) 13:01, 1 September 2026 (UTC)
The lock is to indicate that the lists are private to the user, and they are not shareable on-wiki like what we had with Gather. KFilbert-WMF (talk) 13:07, 1 September 2026 (UTC)
First, when searching "Electrical grid security in the United States" in the search bar, the short description for the Moore County substation attack article comes up ("2022 shooting of electrical substations in North Carolina, USA") rather than the article's own short description, which is set to none. Second, the coordinates from the Metcalf sniper attack article appear at the top of the Electrical grid security in the United States article, which is quite misleading.
Is there an easy workaround to avoid these issues, or would there need to be some background changes to the way the #section-h: command works? Zeibgeist (talk) 10:50, 1 September 2026 (UTC)
Fixed by adding "|noreplace<!-needed to prevent this SD from being used at Electrical grid security in the United States->" (with valid HTML comments, adjusted here so that they show) to the two transcluded articles. Perversely, our choice to put local short descriptions at the top of articles conflicts with the software's choice to prefer the last short description present in an article. The "noreplace" option was created instead of deciding to place the short description at the end of the article. – Jonesey95 (talk) 12:14, 1 September 2026 (UTC)
@Jonesey95: Thank you, that fixes the short description issue. Is there a way you're aware of to prevent the coordinates from the Metcalf sniper attack article from appearing at the top of Electrical grid security in the United States? This seems a bit trickier, since we'd ideally want to transclude the infobox (where the {{coord}} template is placed) but only have the coordinates appear in the infobox rather than both the infobox and title area. Zeibgeist (talk) 13:02, 1 September 2026 (UTC)
{{Excerpt}} is what you want, I believe. Having the infobox in this list article doesn't make sense to me. If you really want it, you may be able to include it using |templates=Infobox, perhaps with a bit more added (I haven't tested it; see the template documentation). – Jonesey95 (talk) 13:12, 1 September 2026 (UTC)
Thank you! I agree that transcluding the infoboxes is unnecessary, so this seems like a good solution. Zeibgeist (talk) 13:35, 1 September 2026 (UTC)
I fixed the wonky transclusion by just using a named section in the two other articles. That way the named section can be precise about what to copy over and specifically to not copy the infobox or the short description. — GhostInTheMachinetalk to me 14:18, 2 September 2026 (UTC)
@GhostInTheMachine: The transclusion issue was already fixed by Jonesey95 through the use of the {{excerpt}} template. It looks like the change you made results in the exact same text being excerpted, but there could be something different in the background that I'm not seeing. Zeibgeist (talk) 17:48, 2 September 2026 (UTC)
I should probably have changed {{excerpt}} to just plain #section:Metcalf sniper attack|lead. That would have clarified the point that it is better to use a named section — GhostInTheMachinetalk to me 18:58, 2 September 2026 (UTC)
Yes, Excerpt does a lot of processing which would be better done in MediaWiki (but, given that it isn't, is better done in Excerpt than nowhere). Excerpt was originally designed for the specific application of portals, where section transclusion isn't sufficient. Its wider adoption came as a bit of a surprise, and some of its uses in mainspace may have more effiicent alternatives. Certes (talk) 19:18, 2 September 2026 (UTC)
SD and ordering
Out of curiosity: Is there a reason why short descriptions aren't set to noreplace by default? My instinct is that not transcluding short descriptions should be the default behavior, with the ability to transclude in specific scenarios. My layman's reading is that transcluding by default makes it easier to write infoboxes that automatically generate short descriptions, but there is probably something I'm missing. Zeibgeist (talk) 13:45, 1 September 2026 (UTC)
Seconded. When multiple short descriptions appear in an article, we almost always have a carefully hand-crafted SD on line 1 followed by generic efforts generated via transclusions (normally of templates, but sometimes of article leads). Line 1 usually has the best SD (and should be improved or removed if it doesn't). The only use case I can see for replacing by default is when article A includes firstly the lead from article B and secondly a template; in this case article B's SD may be so specific as to be wrong, so the generic template SD is better. However, almost all templates which produce SDs use noreplace anyway, so that's not an argument for retaining the current default. Certes (talk) 14:01, 1 September 2026 (UTC)
The noreplace option is always used in infobox-generated short descriptions, so that a manual short description placed in an article will take precedence. I don't know what would happen if noreplace were the default and there were two "noreplace" SDs on a page; probably something undesirable. The whole SD system is a pile of hacks, since the English Wikipedia refused to use Wikidata short descriptions (for good reason, IMO) and a system for creating and using them had to be created just for us. Changing MOS:ORDER would fix this technical issue, but I stay away from MOS talk page drama. Changing which SD MediaWiki chooses (currently the last one it finds in rendered wikitext; would need to change to the first one it finds) would also address our MOS:ORDER technical issue, but that would require developers to make a change. – Jonesey95 (talk) 14:04, 1 September 2026 (UTC)
Thank you for the additional details. Intuitively, it makes sense to me to have short descriptions at the top of articles. Modifying MediaWiki to use the first SD it finds seems like a reasonable change given that we place short descriptions at the top per policy. Or we could just change MOS:ORDER, like you said. A chicken and egg problem I suppose. Zeibgeist (talk) 14:16, 1 September 2026 (UTC)
I think the best (and only?) place to change the default is in {{Short description}}. That template currently passes its second parameter (which is "noreplace" or absent) through to the SHORTDESC magic word. Instead, Template:Short description would add |2=noreplace to the magic word by default but would accept a new optional parameter |2=replace (for which I can think of no use case) to suppress that behaviour.
{{Short description|Type of foo}} → {{SHORTDESC:Type of foo|noreplace}} (second output parameter is new)
{{Short description|Type of foo|noreplace}} → {{SHORTDESC:Type of foo|noreplace}} (as before)
{{Short description|Type of foo|replace}} → {{SHORTDESC:Type of foo}} (second input parameter is new)
Does that work? Certes (talk) 14:27, 1 September 2026 (UTC)
This template-specific behavior should be discussed at the template's talk page and linked from Wikipedia talk:Short description so that people who are familiar with the template's intricacies can comment. – Jonesey95 (talk) 14:57, 1 September 2026 (UTC)
"Music video director" should probably be renamed "List of Music video directors". Any time I've ever moved an article I've messed it up. This would likely happen twice as bad if I moved it to a list article. Any help would be appreciated! Thank you. Magnolia677 (talk) 12:34, 1 September 2026 (UTC)
@Zeibgeist: I doubt it's a controversial move. I just mess up the move, and leave a trail of mess behind that someone else cleans up. Moving it to a list article would make it worse. I can try and report back though. Magnolia677 (talk) 15:10, 1 September 2026 (UTC)
I am now noticing that List of music video directorsList of music video directors has a page history going back to 2011, so this would definitely be a situation for a requested move. Feel free to drop a message on my talk page if you would like assistance opening one. Zeibgeist (talk) 16:25, 1 September 2026 (UTC)
Wayback Machine off-line?
I apologize if this is not the right forum, but does anyone know what's going on with the Wayback Machine? Bgsu98(Talk) 13:51, 1 September 2026 (UTC)
I haven't been able to open archived pages on the wayback machine for several days. Schazjmd(talk) 14:04, 1 September 2026 (UTC)
Same here, I've been getting a 429 error (Too Many Requests). But given the few times a day at most that I might look for an archived URL, that status doesn't seem right. Declangi (talk) 23:53, 3 September 2026 (UTC)
Possible error on G15 speedy deletion edit summaries
When an administrator deletes an article under CSD G15, this bug happens. Instead of:
G15: Unreviewed LLM-generated content (communication intended for the user: <reason>)
it appears like:
G15: Unreviewed LLM-generated content (communication intended for the user<reason>),
giving the illusion that the text is quite jumbled inside. So if the reason was "Explanation Here", the deletion message would've been "G15: Unreviewed LLM-generated content (communication intended for the userExplanation Here)". I'm not an admin, but this is likely a bug within Twinkle or the standard administrators' toolset, in where the reason to CSD G15 tag a page gets jumbled within the "user"/"references" text in the deletion summary.
(Example deletion message is copied from Draft:Steve Sole) —SimpleObjects-9ei 🍂/🌰/🤗 (see talk) 21:40, 1 September 2026 (UTC)
Hey, should we test if the G15 deletion message works now by creating a... dummy AI draft? I have one on queue but a bit embarrassed to do it. —SimpleObjects-9ei 🍂/🌰/🤗 (see talk) 23:17, 1 September 2026 (UTC)
I've created two pages for deletion in my userspace, User:Nyttend/test page for deletion and User:Nyttend/test page for deletion 2, and will ask someone else to delete them. Nyttend (talk) 21:06, 4 September 2026 (UTC)
Note that, to reproduce the original bug case, you'd have to put something like {{db-g15|communication=yes|reason=some other reason too}} on the page. You didn't do that in either of those. Also note that the intended result was "(communication intended for the user and some other reason too)" rather than "(communication intended for the user: some other reason too)" as the report here thought. Anomie⚔ 22:17, 4 September 2026 (UTC)
Sorry, but you didn't specify an original bug case that has this error — the only difference between your "instead of" and "appears like" is the colon and space, and Steve Sole's deletion log has a colon and space in this place. Since you suggested that it might be in the standard administrators' toolset, I wanted to demonstrate how it works with the standard toolset: I'm proving that it's not somehow a problem with the standard. Nyttend (talk) 20:55, 5 September 2026 (UTC)
All I suggested was that I fixed the problem. Anomie⚔ 22:29, 5 September 2026 (UTC)
SimpleObjects-9ei, please check the deletion log entries for these two pages. Nyttend (talk) 21:20, 4 September 2026 (UTC)
@Nyttend, both deletion messages just show "G15: Unreviewed LLM-generated content" and don't show the reason. Anyways, I (intentionally) created this AI draft using Gemini, CSD tagged it with a placeholder explanation and wait for an admin to delete it with or without Twinkle. —SimpleObjects-9ei 🍂/🌰/🤗 (see talk) 00:49, 5 September 2026 (UTC)
The test didn't exactly work the first time around — an admin noted that you'd both created it and requested its deletion, so he just G7-deleted it. (This makes sense: someone might argue that it wasn't really AI-generated, but there's no question that it qualified under G7.) I've undeleted it and redeleted it; see its deletion log. It doesn't match your "appears like", saying simply communication intended for the user and your reason here, which makes sense because the tag indicates that it has communication intended for the user, and the tagger added extra information. Nyttend (talk) 21:00, 5 September 2026 (UTC)
Thankfully it went as Anomie was expecting, now showing "G15: Unreviewed LLM-generated content (communication intended for the user and <reason>", although my expectations were to place a ":" instead of an "and". —SimpleObjects-9ei 🍂/🌰/🤗 (see talk) 21:35, 5 September 2026 (UTC)
This is a Twinkle bug. I reported it a couple months ago here. ~ A412talk! 23:46, 5 September 2026 (UTC)
I doubt it's a Twinkle bug, versus Twinkle reading the incorrect metadata included in the deletion notice since Special:Diff/1327414148 (until Special:Diff/1372707107 fixed it). Anomie⚔ 00:50, 6 September 2026 (UTC)
Highlight editor contributions to a specific page?
Is there a tool that will allow you to quickly identify what content on a specific page was added by a specific user? I'm aware of Wikiblame, but that requires you to search specific content; I'm looking for something more like "User X wrote sentences 4, 11, 23, 54, and 76 in the current article". Nikkimaria (talk) 01:05, 2 September 2026 (UTC)
Polygnotus's been blocked as a sock. Someone needs to maintain their scripts, the most popular of which is DuplicateReferences. Any takers? msk 16:16, 2 September 2026 (UTC)
Darn, I just found out this morning. Do scripts in a blocked user's userspace continue to work? —ClaudineChionh (she/her · talk · email) 23:31, 2 September 2026 (UTC)
Yes, but someone still needs to fix bugs. A blocked user can't do that. msk 23:42, 2 September 2026 (UTC)
[No action needed] Error message when saving large test edit
Hi, everyone! Just for tracking purposes, I'm reporting a message that appeared when I tried to save a large edit, Special:Diff/1372926931.
Server timed out
The maximum request time of 60 sec. was exceeded.
[4cad18e9-8f63-4936-adb9-9d2bd6f87c08] 2026-09-03 00:52:48: Fatal exception of type "Wikimedia\RequestTimeout\RequestTimeoutException"
The green check mark with "Your edit was published" eventually loaded after several minutes when I opened Cephalopod size in a new browser. The edit had gone through, so the actual result of my action matches my expectation except the error message and slow loading.
I was using the source editor on desktop, Firefox 153.0.4 (64-bit). Rotideypoc41352 (talk·contribs) 01:05, 3 September 2026 (UTC)
Yeah, reverting it took a much shorter time; it's the number of cite errors my initial large edit caused. This is on the 2010 wikitext editor, btw. Thanks for reading, Rotideypoc41352 (talk·contribs) 01:10, 3 September 2026 (UTC)
For the first one, there appears to be a Wikidata edit war happening, but maybe I misunderstand. If all of the errors are caused by {{PH poverty incidence}}, you might ask at the template's talk page, or ping the template's editor. Exec8, who appears to be moderately active. – Jonesey95 (talk) 05:09, 4 September 2026 (UTC)
Lovely. Does Wikidata have any protection against edit waring the way we do here? Zackmann (Talk to me/What I been doing) 05:15, 4 September 2026 (UTC)
The errors are now approaching 2,000... I have TFDed the relevant template to find a good solution... Zackmann (Talk to me/What I been doing) 04:50, 5 September 2026 (UTC)
I have fixed the template by editing it. Other problems remain. I have posted at the project's talk page. – Jonesey95 (talk) 06:01, 5 September 2026 (UTC)
Passing template output as parameters to another template
Template/module-dabbler here, trying to chain together several different general-purpose templates. I have one module that parses a page's name to extract some details to return a string composed of parameters to feed to another template that then processes them. Seemed simple enough to do {{processor| {{#invoke:parser}} }}, where parser parses {{PAGENAME}} and processor gets parser's result. However, it seems like the entire parser's result is forced into the first un-named parameter to processor, even though the result is a string that looks like a set of pipe-delimited name=value pairs.
As an example, see User:DMacks/C6H12O6, where the live result is not the same as when the processor (specifically {{User:DMacks/parameter-reader}}) is a hard-coded version of the parser (specifically Module:MolFormIndex) result. Anyone know the correct way to do this, or do I need to rewrite it all within a single module that does both steps of the process? DMacks (talk) 04:22, 3 September 2026 (UTC)
@DMacks Your example doesn't work because the output from {{#invoke:MolFormIndex|parameterize}} is not preprocessed, so it's treated like a single string literal for the most part. The only way to do this in wikitext would be to manually preprocess the entire template call using something like {{Expand wikitext|{{((}}User:DMacks/parameter-reader{{!}}{{#invoke:MolFormIndex|parameterize}}{{))}}}}.
I think you'd be better off with replacing "parameterize" with "parameterize and call". This way, you could pass the arguments directly from Lua without having to use any hacks. The syntax would be something like frame:expandTemplate{ title = frame.args.call, args = TABLE_OF_ARGUMENTS }. Instead of outputting the arguments as wikitext, you would add them to a Lua table and them call the template using that table. – BrandonXLF (talk) 07:14, 3 September 2026 (UTC)
Global blocks
I have the gadget enabled that displays blocked usernames/signatures as struck out. I noticed today that a user was editing here, but was struck out. On looking at their details, they were globally blocked some months ago. "(Date) (user) globally blocked (user) with an expiration time of indefinite (account creation disabled)". I was under the impression that a global block prevented editing any wiki. Is this not the case? Black Kite (talk) 18:10, 3 September 2026 (UTC)
Yes, but that gadget doesn't detect global blocks. – SD0001 (talk) 19:54, 3 September 2026 (UTC)
(Not sure that was exactly the question that was being asked) SarekOfVulcan (talk) 20:03, 3 September 2026 (UTC)
Oops, I misread. And it turns out someone updated the gadget two months ago to detect global blocks! – SD0001 (talk) 20:17, 3 September 2026 (UTC)
Ah, yes, they are. I was unaware of this functionality, thanks. Black Kite (talk) 11:51, 4 September 2026 (UTC)
Multi ref issues
I am attempting to fix up various referencing issues at Cultural impact of Taylor Swift and am running into multiple ref bundles that are throwing Harv warnings, see Ref 332, Ref #381, and Ref #523. I tried using Template:multiref2 on one of the multis but that caused different problems... If anyone knows how to fix errant multiple references, please take a look, tell me what's wrong here, the best way to fix the issues...and thanks in advance. Shearonink (talk) 03:09, 4 September 2026 (UTC)
There are no errors there. Nothing to fix. – Jonesey95 (talk) 05:12, 4 September 2026 (UTC)
I didn't say there were errors, but there are several Harv warnings at the moment. The references I mentioned about aren't quite working correctly... - Shearonink (talk) 05:19, 4 September 2026 (UTC)
OK, no "issues" then. See this talk page thread for details on what is causing the warnings that you see. – Jonesey95 (talk) 05:56, 4 September 2026 (UTC)
HELP! Tried archiving a talk page and have royally screwed it up
In the time it took for me to write out what all had happened, I see that Pppery has already corrected my mistakes. Thanks so much. Carry on, nothing to see here anymore. - Shearonink (talk) 05:04, 4 September 2026 (UTC)
Redirects to magic words
South African current events redirects to 2026 in South Africa and must be updated annually. Is there a way to use {{CURRENTYEAR}} in page names? I already tried, but it blanked the whole page in preview; I figured there was a preview error (either it should be a working redirect, or it should display the code), but when I saved it, the result was just a blank page. Nyttend (talk) 21:01, 4 September 2026 (UTC)
@Nyttend: It's not possible. Help:Redirect#Syntax says: "Note that the redirect link must be explicit – it cannot contain magic words, templates, etc." PrimeHunter (talk) 21:47, 4 September 2026 (UTC)
See title and page. For some reason, even though there is a pinpoint at the correct location, the map is centered in center-left Algeria. Infoboxes and maps are not my specialty, so I was wondering if someone could explain this to me and how to fix it. Thanks! EatingCarBatteries(contribs|talk) 08:04, 5 September 2026 (UTC)
The process of elimination usually narrows down the problem. I've tried various things in preview including deleting everything inside the infobox except a single set of coordinates, which didn't work. It still didn't work when I changed |coordinates1= to |coordinates=. I also tried pasting in an infobox from another article, namely Pleasure Island (Walt Disney World), where the mapframe works as intended, but mysteriously the mapframe broke when used at Avengers Campus. After all that, I assumed the problem was something outside the infobox, so I deleted all the page contents except the infobox, but that didn't work either (even when the infobox was the working one I copied in from another article). Since infobox mapframes also sometimes use data from Wikidata, I checked there. The map displayed by the coordinate location property on Wikidata is centered on the correct location. I don't know what else could be causing this. – Scyrme (talk/solidarity) 09:37, 5 September 2026 (UTC)
I tried looking at old revisions. Though old revisions don't necessarily display exactly as they did in the past due to changes to templates etc. I wanted to see whether the issue affects every revision or only appears in revisions after a certain date. The most recent and only revision I could find which did not center the map on Algeria is the first one, when the article was created, however it was incorrectly centered on Northeastern Iran instead. This is because the coordinates given were for the site in France. Putting the {{coords}} for that site into |coordinates= makes the map center on Northeastern Iran again. Importantly, just changing the coordinates for the numbered coordinates parameters had no effect on the map, Only adding {{coords}} to the unnumbered |coordinates= parameter resulted in a change in the displayed map. This suggests the infobox is taking the coordinates from Wikidata. – Scyrme (talk/solidarity) 09:58, 5 September 2026 (UTC)
Pasting the infobox from Avengers Campus into Pleasure Island (Walt Disney World) confirms. firstly, that the coordinates parameters in the infobox aren't being used by the mapframe, and, secondly, that the problem is specific to Avengers Campus (or its Wikidata item?) not its infobox. The copied-over infobox displayed the same map that the infobox at Pleasure Island (Walt Disney World) already currently displays (because it's pulling the coords from the Wikidata item linked to Pleasure Island (Walt Disney World), which are identical to those currently in the infobox). – Scyrme (talk/solidarity) 10:19, 5 September 2026 (UTC)
At this point I'm out of ideas. Hopefully these attempts help someone else figure out what the problem is. – Scyrme (talk/solidarity) 10:22, 5 September 2026 (UTC)
The infobox has three sets of coordinates for locations in California, Paris and Hong Kong, so where is the map supposed to be centered? I suggest to just omit it with | mapframe = no. PrimeHunter (talk) 11:34, 5 September 2026 (UTC)
I've gone ahead and done as you suggested, though it would be nice to know what exactly caused this problem. – Scyrme (talk/solidarity) 16:18, 5 September 2026 (UTC)
No idea about the specific problem, but I note that the Algeria location seems to be the mean of the California and Hong Kong coordinates, while the northern Iran location seems to be the mean of the France and Hong Kong coordinates. Anomie⚔ 18:14, 5 September 2026 (UTC)
Duplicated footnote
Any clue why the first note on 1902–03 FC Barcelona season is duplicated? I can't find [a] in the text, and it shows up correctly in preview. LittlePuppers (talk) 19:58, 5 September 2026 (UTC)
@LittlePuppers: The same happens for me in preview, also if the only code is {{football box collapsible|team2 = '''[[Galliope]]'''{{efn|Name of the English ship at the port of Barcelona}}}}. Special:ExpandTemplates shows it outputs team2 twice, one of them in style="display:none" which prevents Galliope from being displayed there, but doesn't prevent the note from being displayed later. It could use note instead like |note = '''Galliope''' was the name of the English ship at the port of Barcelona. It displays the text in another place and I don't know the significance of this ship. Maybe Barcelona played a team from the ship. PrimeHunter (talk) 21:23, 5 September 2026 (UTC)
Interesting, I was wondering if it was the template producing something hidden. It's weird that it doesn't show that way for me in preview. I'll ask at {{football box collapsible}} and see if they have a suggestion/best practice (i.e. if I should just replace everything with |note=); I was attempting to replace some random superscript "footnotes". LittlePuppers (talk) 21:36, 5 September 2026 (UTC)
It seems to me that anything placed inside of display:none should not be rendered. I have submitted T437152 to see if the developers agree. – Jonesey95 (talk) 00:33, 6 September 2026 (UTC)
I'll be surprised if they do, since figuring out whether something is hidden is a fairly tricky problem. Even in your example there, some JavaScript might later adjust the styling, or a stylesheet somewhere might override the inline style with !important. Anomie⚔ 00:48, 6 September 2026 (UTC)
To avoid the stray footnotes, and keep that generated hCalendar data clean, I think the best solution would be to either:
Not put footnotes in the team1 and team2 arguments to the template
Have the template remove footnotes and other formatting when generating the invisible metadata
I'm currently in vacation (from talk page) and thus I'm on my phone right now. As of writing, there is a bug in the search bar that only occurs in mobile with desktop mode while logged in but can ONLY BE REPRODUCED IF THE "Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page" gadget is enabled. The search bar appears to be setting a specific size and thus the search bar takes up two lines. —SimpleObjects-9ei 🍂/🌰/🤗 (see talk) 21:12, 5 September 2026 (UTC)
"You have a new talk page message" text visibility on dark mode
was told to come here from someone at Teahouse, i just realized that the colors for the "You have a new talk page message" pop-up doesn't exactly fit well in dark mode.. the yellow and the blue is way too light, which makes it hard to see exactly what it is saying... is there a fix for this? TuffMangoPhonk6741 (talk) 06:38, 6 September 2026 (UTC)
Proposals
Proposal to require independent sourcing for all political endorsements
If you came here because someone asked you to, or you read a message on another website, please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.
However, you are invited to participate and your opinion is welcome. Remember to assume good faith on the part of others and to sign your posts on this page by adding ~~~~ at the end.
Note: Comments may be tagged as follows: suspected single-purpose accounts: {{subst:spa|username}}; suspected canvassed users: {{subst:canvassed|username}}; accounts blocked for sockpuppetry: {{subst:csm|username}} or{{subst:csp|sock username|sockmaster username}}.
I propose removing the provision in Wikipedia:Political endorsements that allows local consensus to overrule our general policy that facts be sourced to independent reliable sources for organizational endorsements. Specifically, I propose striking the following sentence from the guideline: Local consensus can determine whether a specific list requires independent sources or sources connected to the organization itself, such as its website or official social media accounts.
Support: With the amount of horserace coverage every campaign gets, if no independent sources are covering an endorsement, it lacks WP:WEIGHT. Dcpoliticaljunkie (talk) 20:36, 29 July 2026 (UTC)
Support I didn't think the carve-out was a good idea seven years ago when I proposed that RfC. —Rhododendritestalk \\ 23:25, 29 July 2026 (UTC)
Support per WP:VNOT and WP:DUE, as other editors have pointed out. A social media post or other statement endorsing a candidate is a primary source for the endorsement. It might be verifiable, but that doesn't make it due for inclusion. Inclusion of endorsements should require secondary sources. It should also require independent sources, because, e.g., a list of endorsements published by a campaign might be secondary and verifiable, but it doesn't establish WP:DUE. We should only include endorsements when reliable, secondary, independent sources (like history books and newspaper articles) establish that inclusion of the endorsement is due. Levivich (talk) 00:19, 30 July 2026 (UTC)
Comment. This is not meant to be a put-down: from what I know, WP:VNOT necessitates consensus but not necessarily "sources need to be this type", and WP:DUE does not necessitate source secondariness or independence. DUE only needs sources to be "reliable", and WP:RSPRIMARY separates secondariness and reliability by saying "Wikipedia articles should be based mainly on reliable secondary sources" and even saying primary sources "can be both reliable and useful in certain situations". Needless to say, these issues of VNOT and DUE are quite annoying. LightNightLights (talk • contribs) 01:01, 30 July 2026 (UTC) (edited 02:47, 30 July 2026 (UTC))
I don't read the current guidance as suggesting an exception to DUE or VNOT. And it doesn't allow for citing a source from the campaign, only sources from the endorsing organization itself. DUE is contextual and can be assessed in a number of ways. For example, only including organizations with blue links to articles would be a reasonable bar to set in national and other high profile races. —Myceteae🍄🟫 (talk) 02:29, 30 July 2026 (UTC)
...and WP:BESTSOURCES if we're going to nitpick over various parts of WP:NPOV (emphasis added): In principle, all articles should be based on reliable, independent, secondary published sources with a reputation for fact-checking and accuracy. When writing about a topic, basing content on the best respected and most authoritative reliable sources helps to prevent bias, undue weight, and other NPOV issues.
Wikipedia policies aren't laws. They're not well-written. Just because the words "independent" or "secondary" don't appear in the specific section WP:DUE doesn't mean that one can make a determination about what content should be included in an article from non-independent or primary sources. But in case there was any doubt about this, there's the WP:BESTSOURCES section of NPOV.
Bottom line: to determine if content should be included in Wikipedia, we must look to the highest-quality, most-reliable, most recent, secondary, independent, published sources. That's what our core content policies and guidelines say when you put them together, even if it's spread out across a bunch of different pages and sections, like WP:VNOT, WP:DUE, WP:BALANCE, WP:BESTSOURCES, WP:REPUTABLE, WP:AGEMATTERS, and a bunch of other places. Levivich (talk) 21:21, 30 July 2026 (UTC)
You can certainly make an argument that that is the case. It is certainly not what is written in the policies and guidelines. I think we should go by what is written in the policies and guidelines, not what words editors wish were in the policies and guidelines.
That section of WP:BESTSOURCES does not have the 20-year consensus you claim below - it was added relatively recently (a few years ago, if I'm remembering right). It's certainly a good thing, but it's a goal to aspire to, not the end-all of every discussion and certainly not a license to excise every non-secondary non-independent source from discussion altogether.
WP:BESTSOURCES, despite your allusion to the other WP:UPPERCASE in WP:NPOV, is the only place in the NPOV policy where the word "independent" is contained. WP:AGEMATTERS has nothing to do with independent sources, so it's curious why it's being cited here.
However, both WP:REPUTABLE and WP:BESTSOURCES say that articles should be based on "reliable, independent, published sources". That is certainly not the same thing as saying that any use of a non-independent source to supplement particular information is not permissible or should be completely banned. I completely agree with the WP:BESTSOURCES statement that articles should be based on reliable, independent, published sources. I do not agree that non-independent sources should be banned, which is probably why that is supported by none of the policies and guidelines you've cited. Katzrockso (talk) 23:58, 30 July 2026 (UTC)
That's a lot to cover: what I quoted from our PAGs is in fact written in our PAGs. I claim no 20-year consensus below. (There's no plausible way to understand the words "20-year veteran" as referring to the age of consensus rather than the age of an account.) Nobody is trying to excise or ban every non-secondary non-independent source. NPOV isn't the only policy that talks about having independent sources, another example is WP:RS. WP:AGEMATTERS was being cited here because the prior sentence said most recent. Based on ... is certainly not the same thing as saying that any use of a non-independent source to supplement particular information is not permissible or should be completely banned, so it's a good thing that nobody is arguing that any use of a non-independent source to supplement particular information is not permissible or should be completely banned. I do not agree that non-independent sources should be banned either, and so I'm glad that's not required by any PAGs.
And yet I believe endorsements are the type of content that should be cited to the reliable, independent, secondary sources that our PAGs say articles should be based on.
I don't know why you wrote that long series of fabrications, misinterpretations, strawman arguments, and putting words in my mouth I never said, requiring me to write this long correction, but I'd appreciate it if you didn't do that to me again. Levivich (talk) 00:23, 31 July 2026 (UTC)
Policy does not support looking to the "we must look to the highest-quality, most-reliable, most recent, secondary, independent, published sources" to establish what is WP:DUE, not only because these are often contradictory and exclusive. We don't look to sources that don't exist, but evaluate those that actually exist and see which ones are the best to base our articles on (which is different than the inclusionary criteria for particular elements of content). Moreover, the policy that determines whether or not we include things remains WP:WEIGHT and WP:BALANCE, which once again do not mention the independence of sources. I once again think that editors should read the words that in a policy, not the words that they wish were in a policy.
For example, WP:AGEMATTERS explicitly points out that the "most recent" source is certainly not always the most reliable source, so we should not simply look for the "most recent" source, but the WP:BESTSOURCE when evaluated holistically. There are numerous reasons why we might prefer an older source to a newer one. "Most recent" is certainly not a good summarization of WP:AGEMATTERS.
Adding in auxiliary information like endorsements is certainly not the same as writing the bulk of our articles. Indeed, WP:SELFSOURCE states the great majority of any article must be drawn from independent sources. I don't find any conflict whatsoever between WP:RS, WP:NPOV (specifically WP:REPUTABLE and WP:BESTSOURCES) and using a non-independent source to verify an endorsement, because using a source is not the same as basing an article on a source.
The argument presented here is effectively one that non-independent sources should be banned - you present no distinctive argument that wouldn't apply to every single use of a non-independent source. Indeed, there is no particularity to the argument here specific to the context in question - political endorsements. That suggests, or rather proves, that the issue is not specific to political endorsements, but with the use of non-independent sources altogether. Whether or not you take your argument to its logical conclusion is no import to me, you can call it fabrications, misinterpretations, strawman arguments, and putting words in my mouth I never said or whatever you like.
If we are talking about fabrications, misinterpretations, strawman arguments, and putting words in my mouth I never said, we can start with this:
what I quoted from our PAGs is in fact written in our PAGs
I never stated or suggested that the quotes you provided were in any way made up. What I suggested was the the accompanying commentary misrepresents existing PAG, which is a charge I still contend is true. Katzrockso (talk) 02:34, 31 July 2026 (UTC)
You said It is certainly not what is written in the policies and guidelines, but what I'm saying is in our PAGs, is in our PAGs. I'll show you in a moment. But first my Bernie impression: I am once again asking that you not put words in my mouth. Nobody is calling for banning all non-independent sources. Just because someone thinks non-independent sources shouldn't be used to source political endorsements doesn't mean they think non-independent sources shouldn't be used for anything. You can call that the argument's "logical conclusion," but it's actually a strawman argument: you're arguing against something (a total ban) that nobody is arguing in favor of.
Now, the first sentence of WP:BALANCE, key words bolded:
An article should not give undue weight to minor aspects of its subject but should strive to treat each aspect with a weight proportional to its treatment in the body of reliable, published material on the subject.
If no independent RS is writing about an endorsement, if the only people writing about an endorsement are the endorser and endorsee (both non-independent), then that is, indisputably, a low proportion of coverage in RS, it's like 1 or 2 sources out of all sources when only non-independent sources are writing about it and no independent sources are writing about it. Because of this low proportion of RS covering the endorsement, it's a "minor aspect" to which we should not give "undue weight."
Generally, the views of tiny minorities should not be included at all, except perhaps in a "See also" to an article about those specific views.
If an endorsement is only published by the endorser and/or endorsee (who are non-independent), and no other RS are writing about it (so no independent RS), then it's a "tiny minority" (1 or 2 sources out of all sources) and so that view should not be included at all.
In sum: if the only place an endorsement is published is in non-independent sources, such as a social media post by an endorser, or a campaign website, then that means the endorsement is a tiny proportion of RS, a tiny minority of RS, and therefore the endorsement should not be included, per WP:BALANCE and WP:DUE, even though those sections don't have the word "independent" in them. Levivich (talk) 04:39, 31 July 2026 (UTC)
Support It's time that the local tolerance for this be deprecated per VNOT and DUE. Generally concur with the above comments. -Ad Orientem (talk) 00:38, 30 July 2026 (UTC)
Support Why even would we allow local consensus to override higher level authority? That's stupid. — Very Polite Person (talk/contribs) 00:53, 30 July 2026 (UTC)
Mildly oppose Just to give some background information to others here, I'd have to imagine that this discussion is coming from the 'discussion' that we had here? I would like to point out that the provision regarding organization endorsements explicitly says that there isn't a consensus regarding sourcing, so I don't exactly agree that local consensus is overruling the rule. I very much do prefer independent sourcing when available, but there are definitely places where it just won't be. If an endorsement isn't mentioned in an independent article, I don't think it inherently means that they aren't notable, especially in elections like state legislatures that do get far less media coverage than national or statewide ones. These types of endorsements are also helpful in things like nonpartisan elections and help readers get a better idea of the candidates that were or did run. I would go along with the rule if the carve-out does get removed, but I do think that it could remove some important information for a lot of elections that just don't get as much media attention as they deserve.ABlitzz (talk) 01:42, 30 July 2026 (UTC)
Thanks, that's helpful. I was about to ask for links to articles that were viewed as including problematic examples and/or to prior discussions about this. —Myceteae🍄🟫 (talk) 02:20, 30 July 2026 (UTC)
Support I do believe that independent sourcing is necessary. --Enos733 (talk) 04:49, 30 July 2026 (UTC)
Support. If reliable and independent secondary sources can't be bothered to cover an endorsement, neither should we.Cortador (talk) 11:03, 30 July 2026 (UTC)
Oppose on principle. I'm not fond of the way some people increasingly like to claim that every individual fact (that they dislike) in an article has to pass WP:N-level sourcing to be included, rather than using editorial judgement and consensus to determine what is relevant to the topic. As Myceteae noted below, the opening statement of this RFC itself is already erroneously biased in that direction. Anomie⚔ 14:35, 30 July 2026 (UTC)
What is important to a topic is ultimately determined by reliable and independent sources. Once we as editors start determining that based on primary sources, it's just original research. Cortador (talk) 16:02, 30 July 2026 (UTC)
Yes, that's exactly the kind of bogus argument I'm talking about. Thanks for the example. Anomie⚔ 18:21, 30 July 2026 (UTC)
Thank you for your clear, policy-based argument. Cortador (talk) 18:38, 30 July 2026 (UTC)
You're welcome. It's nice when someone appreciates what the policies actually say rather than fictions like "OR requires multiple independent sources, not just reliable ones". Anomie⚔ 19:09, 30 July 2026 (UTC)
Whom are you citing? Cortador (talk) 20:50, 30 July 2026 (UTC)
Anomie, did you seriously just call our core content policies WP:V and WP:OR "bogus"? That's wild from a 20-year veteran. WP:BESTSOURCES literally says: In principle, all articles should be based on reliable, independent, secondary published sources with a reputation for fact-checking and accuracy. So arguing that endorsements shouldn't be included unless they're in reliable, independent, secondary published sources is ... very much in line with very old and very widely accepted core Wikipedia policy. I'm not sure how you can characterize that as "bogus." Levivich (talk) 19:01, 30 July 2026 (UTC)
"Bogus"? "Falsehoods"? Suggesting I'm a troll? In response to people saying "we should have independent sources"? What's with this ridiculously-unwarranted hostility? What the heck has gotten into you today? Levivich (talk) 20:42, 30 July 2026 (UTC)
You can have an article that is WP:Based upon reliable independent sources without every single line in the article being cited to an independent source. It would, in fact, be quite "wild" to suggest that only reliable, independent, secondary sources are permitted by policy. WhatamIdoing (talk) 18:50, 5 August 2026 (UTC)
What is the material—such as facts, allegations, and ideas—for which no reliable source has ever been published in question here? Katzrockso (talk) 20:55, 30 July 2026 (UTC)
Oppose per AnomieX. This is just an extension of the primary sourcing paranoia - WP:DUE says precisely nothing about the independence of a source or whether it is primary, secondary or tertiary. Editors often attribute to particular policies meaning that is contained nowhere within them, and unfortunately DUE is in the club. From the original RfC, the point that I find most pertinent is that newspaper endorsements are organizational endorsements that could be of relevance to our articles, but tend to receive less coverage than other types of endorsements. When mandating secondary, independent sourcing, editors must consider whether these secondary, independent sources will tend to produce a bias in their coverage that will tend to affect our coverage. In this case, I don't think this bar has been met.As for WP:VNOT, this is of tangential relevance to this guideline, as it is silent on the independence of sources or whether they are PTS. Indeed, it simply says that consensus can decide that a verifiable fact does not improve an article. This applies to everything, including content sourced to independent, reliable, secondary sources.Katzrockso (talk) 20:54, 30 July 2026 (UTC)
I'd be curious if anyone could find even one newspaper endorsement that should be in an article that is not mentioned by any independent source. In practice, the bit we're debating here has nothing to do with newspaper endorsements and everything to do with, say, a barely notable advocacy group that issues two hundred endorsements that nobody reports on but make it into two hundred separate Wikipedia lists. —Rhododendritestalk \\ 21:31, 30 July 2026 (UTC)
When you define "should be in the article" as "has independent sourcing" and then find that every example that should be in the article has independent sourcing, it's hardly surprising. Katzrockso (talk) 21:44, 30 July 2026 (UTC)
I'm not sure how that responds to what I said. To rephrase: what's an example of a newspaper endorsement that was not covered by an independent source? (because there are an awful lot of the other kind, where we cite social media posts of local advocacy groups to add them en masse). —Rhododendritestalk \\ 21:46, 30 July 2026 (UTC)
Any newspaper from a small region covering an endorsement from another newspaper from that region is, from a certain POV, not an independent source (given that they're business rivals and whatnot). So I'm going to guess... the vast majority of newspaper endorsements can't be covered by an independent RS? GreenLipstickLesbian💌🧸 22:20, 30 July 2026 (UTC)
I'm not sure I've ever seen the "it's not independent if the subject is a competitor/rival of the source" argument, but certainly haven't seen consensus for that. —Rhododendritestalk \\ 22:53, 30 July 2026 (UTC)
WP:IIS states that an independent source lacks conflicts of interest (i.e., there is no potential for personal, financial, or political gain to be made from the existence of the publication).Katzrockso (talk) 23:11, 30 July 2026 (UTC)
This is now a tangent. If someone would like to make the case that e.g. we can't use CNN or NBC to report on FOX because they're not independent, or that relationship is somehow radically different at a different geographic scale, that's probably a discussion for another place. I'm happy to be pinged there, but cannot imagine any real consensus for it beyond a "yeah, I sorta guess you could say there's technically a COI, but no that's not a reason to decide they lose their independence". I could be wrong, but again we're getting away from the point here. —Rhododendritestalk \\ 23:18, 30 July 2026 (UTC)
Nobody's arguing that strawman; I hope I'm not putting words in Katzrockso's mouth, but I like to think we've been pretty clear than independence is not the be all and end all when it comes to newspapers reporting on each other. (Though the potential COI is something I do take into consideration when I'm sourcing and writing articles; I hope you're not asking me not to?)GreenLipstickLesbian💌🧸 23:24, 30 July 2026 (UTC)
The mistake here is thinking that non-independent sources are some "bad" category of sources that we need to completely eschew. They certainly need to be used more carefully, but they aren't supposed to be some verboten evil that needs to be excised from every article, despite the increasing tendency to characterize anything that isn't an SIRS as such.
I don't see how by the definition of independent sources used by Wikipedia, they are independent. If you'd like to propose a change to the WP:IIS essay or WP:ORGIND guideline, I wouldn't be necessarily opposed. For what it's worth, WP:ORGIND also specifies that competitors are not independent;
Independence of the author (or functional independence): the author must be unrelated to the company, organization, or product. Related persons include organization's personnel, owners, investors, (sub)contractors, vendors, distributors, suppliers, other business partners and associates, customers, competitors, sponsors and sponsorees (including astroturfing), and other parties that have something, financially or otherwise, to gain or lose.
I would say that this is probably where I'm at as well. I can see the concerns that people have and are bringing up, but I think that, for the most part, the guidelines are fine as they are currently. ABlitzz (talk) 23:30, 30 July 2026 (UTC)
I have no opinion on whether those lists should exist, but if people are wanting to change a guideline to make articles as short and incomplete as possible because they don't like that type of article, it seems very much like Wikipedia: Disrupting Wikipedia to make a pointKatzrockso (talk) 02:14, 6 August 2026 (UTC)
We prefer to use other words for that, like "defending Wikipedia" and "having high standards". ;-)
Seriously, where to draw the line is something different people can have different opinions about. WhatamIdoing (talk) 02:43, 6 August 2026 (UTC)
Support Lists of endorsements seem to be a blatant violation of WP:SOAP which is policy and states that Wikipedia is not a soapbox...or a vehicle for propaganda, advertising, and showcasing. The proposal raises the bar and so is a move in the right direction. Andrew🐉(talk) 21:01, 30 July 2026 (UTC)
Support, this is how we decide whether something is worth mentioning. Things that are not worth mentioning probably aren't worth mentioning. Thebiguglyalien (talk) 01:23, 31 July 2026 (UTC)
Oppose (Just to be up front, my opposition stems from my opposition to the rigid applications of criteria #2 generally, eventhough I agree with the principles behind it) Endorsements are, by definition exercises of expression of bias, of advocacy of a subjective opinion. Lists are means to comprehensively present relevant factual information in an organized manner for ease of consumption. Lists of endorsements therefore would by definition conflict with various basic WP principles, but their continual existence are tolerated/accepted/even desired by some of us because they comprehensively enumerate relevant factual information in a succinct, organized manner, allowing reader to draw insights and informed assessment. If we accept that premise, then rejecting an undisputed entry that meets criteria 1 & 3 by rigidly enforcing the independent aspect of criteria 2 without any consideration of weighing of other facts (such as the reliability aspect of criteria 2, local context, scale of the contest, substantive relevance or significance of a particular entry to the particular context) is to me quite illogical. 1) Given endorsement is an expression of bias, an unindependent source, such as the endorser themselves, actually is the ultimate reliable source. 2) Existence of independent source is generally an strong indicator of notability but only an reasonably good indicator of relevance. Some inconsequential endorsement get attention because they are unique or interesting or even entertaining, while some clearly consequential endorsement get no little media play because they were expected or boring but nonetheless impactful. For example, endorsements of politicians by celebraties like actors or singers often get covered in the news for their entertainment value, because they are interesting and unusual, but they rarely have meaningful impact on electoral outcome. An endorsement from a former office holder that retired long ago may general little press interest while having huge impact (especially in internal contests like primaries or nomination fights where older voters, and long time party activists are have greater presence.) Ultimately, the purpose of this policy is to ensure entries included in such lists are realiable, notable, relevant and consequential. Exisitence of independent sources would be decent indicators for those things but not conclusive proof, and the absence of independent sources certainly does not conclusively disprove any of those things. If the notability of the endorser, the factual reliability of the endorsement, and its relevance to the the subject election are not in dispute, exclusion would arguably amount to censorship. JacobW2 (talk) 15:10, 31 July 2026 (UTC)
An endorsement from a former office holder that retired long ago may general little press interest while having huge impact (especially in internal contests like primaries or nomination fights where older voters, and long time party activists are have greater presence.) This isn't really germane to this proposal since the current exclusion currently only affects organizational endorsements, not individuals. For what it's worth, I don't think be opposed to a very narrow exception for current (and former) officeholders who represent(/ed) part of the constituency being contested. If anything, the fact that a former elected's endorsement is excluded unless covered by independent media but an endorsement by an organization, however irrelevant, can be included cited to only their website highlights how odd the status quo is. Dcpoliticaljunkie (talk) 19:08, 2 August 2026 (UTC)
Note for closer - I have changed my username since !voting in this discussion ―"GraveDragon-X"(hihi) 16:12, 10 August 2026 (UTC)
Support per above. There's a reason local consensus can't overrule global consensus, especially on notability. FaviFake (talk) 22:51, 31 July 2026 (UTC)
Notability has to do with whether an article should exist for a topic, it has nothing to do with whether content should be included in an article. Katzrockso (talk) 23:54, 31 July 2026 (UTC)
Oppose - What to do about noteworthy endorsements by media outlets that are covered by the outlet's competitors is an excellent point. (Plus, there's the issue of organizations and independent sources potentially disagreeing that I brought up below.) WP:DUE would apply regardless and seems orthogonal to this issue. Gnomingstuff (talk) 23:03, 31 July 2026 (UTC)
Still hoping for even one (and preferably more) example of noteworthy endorsements by media outlets that are covered by the outlet's competitors, but this is the last time I'll mention it. It's a big flood gate to leave open for a hypothetical. —Rhododendritestalk \\ 23:18, 31 July 2026 (UTC)
I can't find any independent coverage of The Detroit Metro Times endorsement of Abdul El-Sayed as an example. According to our article, it's the largest circulating newspaper in the Detroit Metro area, which is the largest city in Michigan. I think that's pretty noteworthy. Katzrockso (talk) 00:02, 1 August 2026 (UTC)
Well, largest circulating weekly:) but regardless we have an article about it and I, too, cannot find independent coverage. Thanks for digging up an example. I'm more inclined to support an exception for certain kinds of companies/organizations (like notable media outlets), but still not quite convinced it's in our best interest to include every endorsement by every organization or company, regardless of what they are or how much they're written about. —Rhododendritestalk \\ 00:27, 1 August 2026 (UTC)
Who said we have to include every endorsement by every organization or company, with or without independent sources? Anomie⚔ 01:07, 1 August 2026 (UTC)
I completely agree that we shouldn't be including every endorsement by every organization or company. The status quo of guideline doesn't require this, and if that is what happens in practice, I would support any effort to trim non-notable and non-noteworthy organizations. Katzrockso (talk) 03:04, 1 August 2026 (UTC)
As the person who has added a lot of the endorsements to the Michigan Senate race's article, which is the article that kind of seems to have started all of this, I'm just wanting to give some of my own thoughts here. There have definitely been a lot of endorsements listed in articles that I haven't added simply because the endorsers don't have a Wikipedia page. If they have a Wikipedia page, I'll usually add them because that's a symbol, in my mind, that they're notable enough to be added. If they have no Wikipedia page, then I'll typically avoid adding them to articles unless there's another reason that would make sense (i.e. a local or House election where a candidate is endorsed by a notable person in the city/district but the endorser doesn't have a Wikipedia page). Personally, my opinion is that if there is a source that follows the guidelines and the endorser is notable enough due to having a page here or some other reason, then there's no reason not to add in the endorsement ABlitzz (talk) 13:06, 1 August 2026 (UTC)
Joe Celebrity might be notable for his movie career… but that does not mean his political opinions are worth noting. Blueboar (talk) 13:45, 1 August 2026 (UTC)
I can understand the point you're making there, but wouldn't editors be interfering with the neutrality of the page if we're able to just decide who is relevant and who isn't? As long as the endorser has a good source and page, I really don't see a reason why they shouldn't be included. Under your example, it could also show the start of Joe Celebrity getting more involved in the political scene and becoming prominent in both movies and politics. ABlitzz (talk) 15:23, 1 August 2026 (UTC)
plus Joe Celebrity would probably be covered by outside media anyway by dint of being a celebrity; the WP:DUE concerns would remain unchanged Gnomingstuff (talk) 20:08, 2 August 2026 (UTC)
The status quo requires independent sources for individual persons endorsing a candidate, so that isn't a question at the moment. Katzrockso (talk) 20:57, 1 August 2026 (UTC)
By this interpretation, most articles about news orgs would fail notability guidelines since almost other source would be considered a competitor and therefore not independent. This seems to be something to address within that guideline (stipulate that media outlets that are competitors of each other are independent) rather than this one. Dcpoliticaljunkie (talk) 16:13, 4 August 2026 (UTC)
Notable news organizations tend to get at least some coverage in journals, books, and other newspapers not operating in the same market; for an example, the Weekend Times, a Malawian tabloid that operated for only about 6 years, is primarily based upon such sources. GreenLipstickLesbian💌🧸 18:10, 4 August 2026 (UTC)
In practice, though, I would also like to note that the community treats newspapers and academic journals very differently than commercial organizations in general. (You can argue that a newspaper as an actual isn't technically a corporation, but that's splitting hairs in most cases). WP:NJOURNAL and WP:NNEWS are essays, but they do emphasize impact/influence as a pathway to notability that we'd never allow under a typical application of NCORP. GreenLipstickLesbian💌🧸 18:21, 4 August 2026 (UTC)
I agree that we treat articles about publishers differently from articles about other businesses, but I think it's practical of us. Sometimes we need that information as editors. WhatamIdoing (talk) 18:59, 5 August 2026 (UTC)
Oppose The inclusion/exclusion of a particular endorsement that lacks independent sourcing can always be debated on the article's talk page, just like with any other disputed content. Some1 (talk) 23:42, 31 July 2026 (UTC)
Oppose. I'm just not seeing any evidence of an actual problem here that needs solving. At 2026 United States Senate election in Michigan §Endorsements, there are far fewer organizations listed than individuals. As others have noted, celebrity and other "big name" endorsements are prone to garnering at least some media coverage even when their encyclopedic value is questionable. PACs and political organizations, whose endorsements may be less newsworthy, may be a more meaningful reflection of a candidate's ideology and support base. Looking at other articles that were shared at Talk:2026 United States Senate election in Michigan#Organizational endorsements, most have much shorter endorsement lists. Weighting these lists towards celebrities and other individuals is of no value to these articles. The current guidance is in no way an exception to WP:DUE or any other broadly applicable policy or guideline. —Myceteae🍄🟫 (talk) 18:54, 1 August 2026 (UTC)
Oppose - current system functions quite well, and WP:DUE doesn't appear to be violated because of it - I don't see a reason to prevent endorsements being sourced to verifiable primary sources. Jishara (talk) 00:53, 2 August 2026 (UTC)
Support per Rhode and TBUACzarking0 (talk) 07:31, 2 August 2026 (UTC)
Support I agree that generally primary sources may be used for a wide variety of information. But this provision is so poorly written, it should go. The first glaring mistake was its mention of largely discredited local consensus, when it could of just used "editors may", but even worse it then suggests that verifiability is all you need for content additions, and that is plainly untrue, see WP:VNOT. No editors at any article can vote to ignore the other content policies, and no guideline can either. -- Alanscottwalker (talk) 19:42, 2 August 2026 (UTC)
Just to be clear, I would also oppose a rule that said only secondary sources count. That's not what DUE requires, in every case, we may use primary sources. I think the rule should still go because of its poor wording. Go back to the drawing board, get ride of "local consensus" and make clear the all content policies not just V matter. Alanscottwalker (talk) 21:20, 10 August 2026 (UTC)
Oppose. This would create a more stringent sourcing requirement than that of most other content where the concern here isn't the veracity of the endorsements, but whether they are DUE. Jessintime (talk) 15:21, 5 August 2026 (UTC)
More stringent sourcing requirements for content having to do with BLPs is never a bad thing. ―"Ghost of Dan Gurney"(hihi) 17:16, 5 August 2026 (UTC)
"All significant points of view" has never included content limited to primary sources. Cortador (talk) 19:07, 7 August 2026 (UTC)
Where in the policy does it say that? Katzrockso (talk) 19:47, 7 August 2026 (UTC)
It's under verifiability. Cortador (talk) 21:11, 7 August 2026 (UTC)
What part of the Wikipedia:Verifability policy states that significant points of view excludes content limited to primary sources? As far as I am aware, "significant points of view" is a term of art specific to the Wikipedia:Neutral point of view policy and isn't explicitly defined anywhere. Katzrockso (talk) 21:51, 7 August 2026 (UTC)
@Cortador, a simple example of when a primary-only viewpoint is needed is when someone is accused of a crime, and they deny it. We rarely have secondary source material for that (that would mean a source that analyzes, evaluates, interprets, etc. their denial, rather than merely repeating the fact that the accused person denied the accusation), and it is the near-universal practice of the community to mention the existence of such denials, even if they have to be sourced to the subject's social media (which is both primary and non-independent). We can't meet the goals of either the BLP policy or the NPOV policy by removing the accused's POV about his innocence from a Wikipedia article just because there isn't a high-quality secondary source. We need a source that is strong enough to support the claim in the article (the usual claim being "He denied the accusations"), but a fairly weak source is strong enough for that.
(Undefined words have their dictionary definitions, so "points of view" in the policy is the same as Point of view (philosophy).) WhatamIdoing (talk) 22:29, 7 August 2026 (UTC)
News articles include responses from accused people all the time. I don't know where you get the idea that this "rarely" happens. Cortador (talk) 08:30, 8 August 2026 (UTC)
@Cortador, most news articles are primary sources. See WP:PRIMARYNEWS. A typical newspaper article is a:
non-self-published,
independent, and
primary source.
(Also short. The longer it is, the more likely it is to be a secondary source.) WhatamIdoing (talk) 17:38, 8 August 2026 (UTC)
No, they absolutely are not. You are confusing how e.g. academics use that term with how it is used on Wikipedia, and so is that essay. Cortador (talk) 19:58, 8 August 2026 (UTC)
The policy WP:PRIMARY itself says "A primary source is a first-hand account of an event. Primary sources may include newspaper articles...". It specifically calls out breaking news: "For Wikipedia's purposes, breaking news stories are also considered to be primary sources". WhatamIdoing (talk) 20:10, 8 August 2026 (UTC)
This sort of mess is why I still think WP:PSTS should be moved into an essay, rather than being part of the WP:No original research policy. It's a heuristic that people like to give far too much weight to. Anomie⚔ 23:32, 8 August 2026 (UTC)
I don't think it should be moved into an essay, but I do think it should be in a separate page. WhatamIdoing (talk) 23:49, 8 August 2026 (UTC)
Support As if RS do not care, why should we (see wp:undue). Slatersteven (talk) 12:16, 9 August 2026 (UTC
Oppose - this is a case where one size doesn't fit all. While with US presidential elections and nominations there are always numerous published sources listing endorsements this is often not the case for smaller contests, particularly with the decline of the media. The recent 2026 New Democratic Party leadership election for example was not closely covered by the media until the last few weeks so even though there were prominent endorsements by current and former politicians these were often only reported on the candidate websites and press releases and did not receive "independent" coverage until very late, if at all. This gave an unbalanced and misreprestarive impressio of the relative support candidates had. Major political parties such as the NDP have strict campaign rules and a leadership candidate who falsely claimed endorsements would have been fined or expelled - but even so we had editors insisting these endorsements could not be listed, even though under the circumstances they were reliable (due to the consequences for candidates for making false claims), due to global wikipedia rules. Some sort of flexibility is required and if there are other reasons why a self-reported endorsement can be considered reliable, then that should be sufficient. Wellington Bay (talk) 15:32, 9 August 2026 (UTC)
Oppose: many of the others gave good reasoning. Especially for the smaller cases, not every endorsement is going to be covered by a secondary one. I also believe that wikipedia should in general consider being more open to primary sources though that would probably warrant a separate discussion. Also, WP:PRIMARYNOTBAD explicitly states "Primary sources can be reliable, and they can be used. Sometimes, a primary source is even the best possible source", so there should be no good reason to support removing this section. Wikieditor662 (talk) 16:37, 9 August 2026 (UTC)
Oppose Media coverage varies wildly depending local market and perceived importance of the position. One size fits all fails when most English-language local print media in Canada is owned by a small number of conglomerates that have eliminated local coverage outside major markets. American markets may get horserace coverage; we're lucky to get any mention of equines. G. Timothy Walton (talk) 18:20, 9 August 2026 (UTC)
That's a failure of the Canadian media ecosystem, not of Wikipedia's policies. Our job is not to provide original reporting or comprehensive lists of data, but encyclopedic content that reflects what reliable, independent sources say. ―"GraveDragon-X"(hihi) 02:46, 10 August 2026 (UTC)
Our job is not to ignore valid information when no "reliable, independent sources" are available. One could argue that Canadian English-language media has almost no reliable, independent sources left outside a few major urban markets. G. Timothy Walton (talk) 18:15, 10 August 2026 (UTC)
If something isn't covered at all in reliable, independent sources, then it lacks due weight. ―"GraveDragon-X"(hihi) 12:02, 11 August 2026 (UTC)
Support Endorsement cruft takes up a huge amount of space on election articles, to the point that 5 of the top 50 longest articles are about state-level elections. Requiring third-party coverage would be a great way to cut down on this. I would even propose going one step further and applying the MOS:CULTURALREFS standard of secondary/tertiary sources that discuss the endorsement in depth, not just a brief mention. --Ahecht (TALK PAGE) 21:37, 9 August 2026 (UTC)
and because Ballotpedia is an independent source that reports all endorsements for all US elections (both state and national), I don't see any effect of this rule on most of these election-related articles. WhatamIdoing (talk) 22:01, 9 August 2026 (UTC)
That, and, Texas and California are really big and have a lot of districts. I'm not surprised that their election articles are prone to being very long. These articles vary somewhat in the number of endorsements listed per candidate and in the promotion of individual vs. organizational endorsements but it doesn't appear to me that organizational endorsements are driving this problem—to the extent it is a problem that need solving. Maybe some other approach is needed to trim these articles or maybe the size of these articles is acceptable and unavoidable given the nature of the subjects. —Myceteae🍄🟫 (talk) 22:13, 9 August 2026 (UTC)
Just a reminder that the United States is not the only country in the world that has elections. Ballotpedia is useless outside the US. Wellington Bay (talk) 01:04, 10 August 2026 (UTC)
+1 —Myceteae🍄🟫 (talk) 15:41, 10 August 2026 (UTC)
I compared 2021 2021 California gubernatorial recall election §Endorsements with Ballotpedia's notable endorsements list in the same race, as this is the only true US state-level race in the list of long pages. For the recall question, I count 38 organizational endorsements on our list and 36 on Ballotpedia's. This is not a meaningful difference. Our article contains many more individual endorsements than organizational, despite already requiring a higher standard for independent sourcing. If we look at the section sizes, §Endorsements is up there but the big problem is §Results. Again, this is just a result of having a very large state. I suspect that the table formatting and markup is increasing the bytes but this is an attempt to make a massive amount of data digestible. If the size of this article is truly a concern then some intervention besides removing (at most) two endorsements is needed.
Section sizes in 2021 California gubernatorial recall election
We both responded to your similar sentiments about Ballotpedia below. The only examples of 'problematic' articles provided have been US elections articles. (For the record, I don't find the endorsements sections of these articles especially problematic.) I offered an alternative explanation for why California and Texas elections articles are prone to being so large. —Myceteae🍄🟫 (talk) 15:50, 10 August 2026 (UTC)
Oppose. Not all media in every country is created equally. Certain places are going to cover endorsements more than others, and I think that is in of itself biased, as it will result in certain regions having better coverage than others.-- Earl Andrew - talk 02:36, 10 August 2026 (UTC)
Comprehensive lists of endorsements are inherently promotional and if the media in a certain region don't bother to point them out, that's no one's fault. ―"GraveDragon-X"(hihi) 02:56, 10 August 2026 (UTC)
It's the media's fault, not no one's fault. We shouldn't be slaves to large corporate media that chooses to ignore most local news. G. Timothy Walton (talk) 18:18, 10 August 2026 (UTC)
I disagree with the notion that listing endorsements is strictly promotional, or that it has no encyclopedic value. It's supposed to tell readers something about the candidate's support base, affiliations, and affinities, and is often relevant to campaign finance. —Myceteae🍄🟫 (talk) 18:32, 10 August 2026 (UTC)
Systemic bias is an issue on Wikipedia, but there's not typically consensus to lower standards to the level of "include it because it exists, regardless of whether anyone has judged it worthy of note". —Rhododendritestalk \\ 16:20, 10 August 2026 (UTC)
I agree that we wouldn't want to lower standards, but my concern about this problem is:
we're talking about requiring higher standards, not the ordinary ones, and
the point is to deal with lists of endorsements in US, and this proposal will have no effect on lists of endorsements in the US.
A proposal that would address the identified problem would sound something like this:
If there is a reasonably comprehensive list of endorsements at Ballotpedia (or a similar site), then link to that webpage in the Wikipedia:External links. When a comprehensive external list is available, articles should contain only a high-level summary of endorsements in the article, e.g., "The candidate has been endorsed by anti-tax advocacy groups and law enforcement agencies[1]" (when reliable sources directly support such summaries) or information about endorsements that produced significant media attention, e.g., "The Abrasive Activists club announced an unsolicited endorsement and donation, causing the candidate to disclaim the endorsement, return the money, and announce support for raising taxes[1]" or "The candidate was endorsed by the prime minister, and the election result was widely seen as a test of the PM's political influence[1]".
Support. If the endorsement isn't reported on by independent RS, then it's not passing the bar for BALASP (and if the candidacy/election itself has so little sourcing that an endorsement announcement from 1-2 non-independent sources actually is proportionally weighty coverage-wise, then either the subject itself is not notable or there's a pressing case for IAR). By policy, Wikipedia articles about a person, company, or organization are not an extension of their website, press releases, or other social media marketing efforts. Endorsements are inherently promotional, self-serving, and (when sourced from the endorser as an individual person) are SPS with claims about third parties. They should be contextualized, or at the very least noticed, by independent RS.I also don't see how a political campaign shouldn't be held to the same standards as Listings to be avoided include, but are not limited to: business alliances, clients, competitors, employees ... equipment, estates, offices, store locations, contact information, patent filings, products, sponsors, subdivisions and tourist attractions.JoelleJay (talk) 20:13, 10 August 2026 (UTC)
One way that political endorsements differ from these other listings to avoid, as I said elsewhere is that they may tell readers something about the candidate's support base, affiliations, and affinities, and is often relevant to campaign finance. There is some superficial similarity between political endorsements and business business alliances or (corporate) sponsors but there are meaningful differences. —Myceteae🍄🟫 (talk) 21:22, 10 August 2026 (UTC)
If an endorsement actually tells readers something meaningful about the candidate, then that especially deserves to be validated as real and attention-worthy by an independent RS and ideally contextualized. What's stopping malicious announcements by bad actors or self-promo ones by businesses hoping to have their name associated with a candidate? JoelleJay (talk) 11:35, 11 August 2026 (UTC)
This is the kind of case-by-case assessment that can be made on the article talk page. I'm not seeing evidence that this is a real-world problem. Primary sources are almost always reliable for statements about what the source itself says. Effective self promo will, by definition, be picked up elsewhere so this doesn't necessarily address that, anyway. —Myceteae🍄🟫 (talk) 14:46, 11 August 2026 (UTC)
These considerations should not be applied case-by-case according to whether editors think an endorsement carries some implicit meaning, they should be the default. JoelleJay (talk) 15:49, 11 August 2026 (UTC)
What part of BALASP says that things can't be sourced to non-independent sources? Katzrockso (talk) 21:45, 10 August 2026 (UTC)
The part that says coverage should be proportional to how the topic as a whole is covered in RS (so something being citable to only source will almost certainly be proportionally trivial), and also per V Self-published sources may be considered reliable if published by an established subject-matter expert, whose work in the relevant field has previously been published by reliable, independent publications.[g] Be careful when using such sources: if the information in question is suitable for inclusion, someone else will likely have published it in independent, reliable sources.[1] with note [1] stating Self-published material is characterized by the lack of independent reviewers (those without a conflict of interest) validating the reliability of the content. Further examples of self-published sources include press releases, the material contained within company websites, advertising campaigns, material published in media by the owner(s)/publisher(s) of the media group, self-released music albums, and electoral manifestos:. Press releases, social media, and company websites are SPS and thus considered non-RS by default, but even when they are RS (topic experts) we are still cautioned against using them because if the information in question is suitable for inclusion, someone else will likely have published it in independent, reliable sources. ABOUTSELF, being roughly equivalent in reliability to expert SPS, should be interpreted in the same way. JoelleJay (talk) 11:53, 11 August 2026 (UTC)
Notwithstanding your contentious interpretations of other parts of the policy, so something being citable to only source will almost certainly be proportionally trivial seems to be false. Why would an endorsement reported by one reliable independent source be a higher WP:PROPORTION of the reliable sources that an endorsement reported by one reliable non-independent source, according to WP:BALASP. I'm not asking about other policies, I'm asking about what BALASP says. It seems to be a common occurrence here to cite policies for things they don't say. Katzrockso (talk) 13:19, 11 August 2026 (UTC)
Because an endorsement reported by the endorser and endorsee is less coverage of that endorsement than the endorser's and endorsee's reports plus an independent source?Our policies on acceptable SPS use explicitly discourage including information that is not published in independent RS even when it's by an expert; why would this be treated differently for political endorsements? JoelleJay (talk) 15:06, 11 August 2026 (UTC)
Most reports of endorsements are primary sources that merely report what the endorsement itself says. We are often told to treat primary sources that offer no transformative commentary as the same source as the original - why is that any different here?
Joe Schmo endorses Linda Lesson for local office. She announces it on her campaign website.
Local outlet FOX11 publishes a short story that is essentially just the endorsement.
I don't see why the presence or absence of the story from FOX11 has any impact on the PROPORTION. Katzrockso (talk) 15:13, 11 August 2026 (UTC)
I don't either. A PROPORTION issue would arise if we wrote a lengthy paragraph quoting extensively from a press release and no other sources, especially if this is done to the exclusion of other endorsements in the same race. But I don't see the problem with list entries where the organizational endorsement list is a relatively short part of the article and endorsements for all candidates are subjected to uniform criteria such as only including blue-linked wiki-notable orgs. —Myceteae🍄🟫 (talk) 15:31, 11 August 2026 (UTC)
The calculus is ≤2 pseudo-RS vs ≤2 pseudo-RS + 1 independent actual RS. Why should the organizational endorsements have a lower requirement for reliability than the individual endorsements? Also we don't limit the endorsers to just blue-linked orgs... JoelleJay (talk) 15:48, 11 August 2026 (UTC)
There isn't any question about reliability here - reliable sources are still required for adding endorsements. Also, we do require that the listed organizations are notable. See WP:Political endorsements, point #1 under organizations. Whether or not they need to be blue linked is something the guideline says can be decided at an article level, but that's a distinction without a difference, as Wikipedia should eventually cover all notable topics. Katzrockso (talk) 17:55, 11 August 2026 (UTC)
I wrote "blue-linked" rather than "notable" specifically because there is a difference here. JoelleJay (talk) 12:20, 12 August 2026 (UTC)
What's the difference? Editors can, by consensus, create more restrictive WP:LISTCRIT than required by policy. Katzrockso (talk) 13:15, 12 August 2026 (UTC)
There is a practical difference. Blue-linked is an objective, binary status. This criterion can prevent disputes about entries that some editors argue are "probably notable" or "likely to pass GNG soon" or whatever. —Myceteae🍄🟫 (talk) 14:58, 12 August 2026 (UTC)
Blue-linked has trinary status: blue article, blue redirect, and red link.
It's also gameable (Oh, you require an article to exist? Okay, here's a three-sentence, two-source stub article). I would not recommend using it as a blanket recommendation. That approach works best when we have very long lists and need an arbitrary way to shorten it. WhatamIdoing (talk) 17:05, 12 August 2026 (UTC)
Blue-linked is binary (red or blue). Whether it's a standalone article or a redirect and the quality of the linked article are additional considerations. We could drill down even further on redirects—does it target a list entry that just names the org or a multi-paragraph section describing the org in detail? I'm not suggesting "blue-linked" is a good universal criterion for endorsement lists. Merely disagreeing with Katzrockso's assertion that "notable" and "blue-linked" is a distinction without a difference. To be clear, I mostly disagree with JoelleJay. But if the organizational endorsements list in a particular article is really out of control—something I've yet to see convincing evidence of—both the current wording of WP:ENDORSED and the broadly applicable WP:SELCRIT guidance permit additional requirements at the article level. The tools and guidelines are already in place to manage these endorsement lists. —Myceteae🍄🟫 (talk) 18:13, 12 August 2026 (UTC)
Start with Donald Trump endorsements (a dab page) for the lists that I assume triggered the creation of the guideline. WhatamIdoing (talk) 19:28, 12 August 2026 (UTC)
Good grief. Still, probably a better argument for trimming individual endorsements and consolidating state party endorsements. I did chuckle at:
Well, for one, I would also support a requirement that endorsements have secondary coverage in addition to the current proposal that the coverage be independent. But that's not what's under discussion right now. An independent RS reporting an endorsement verifies that it is considered genuine and noteworthy enough to mention by an RS. It does not involve editors combing through (and validating identities within) social media to hand-curate endorsements themselves and requiring it would preempt editors trying to interpret the equivalents to RECs in non-Anglophone countries and non-American political systems. JoelleJay (talk) 15:36, 11 August 2026 (UTC)
I don't think we need to have a requirement for independent sources to prevent social media being used as sources. We could simply ban social media as a source, if that were deemed necessary. Katzrockso (talk) 16:44, 11 August 2026 (UTC)
The issue isn't social media, it's being an SPS. JoelleJay (talk) 12:23, 12 August 2026 (UTC)
The issue isn’t either of those… the issue is whether the specific endorsement in question is meaningful or trivial. The issue WP:VNOT and WP:DUE - not WP:RS. Blueboar (talk) 12:43, 12 August 2026 (UTC)
VNOT is not a license to exclude content, it simply says we don't have to include verifiable content. It's a bludgeon to use against newbies who think that since they have a source it has to be included. This is about creating a higher requirement for adding endorsements than our policy on RS requires - VNOT doesn't mandate anything of the sort. Katzrockso (talk) 13:14, 12 August 2026 (UTC)
You invoked the picture of editors scrounging up social media posts to find endorsements and the issues of identity validation. Those are not issues with campaign website endorsements, despite being self-published. What are the issues with self-published sources (generally and not specific to social media posts) in this context? Katzrockso (talk) 13:12, 12 August 2026 (UTC)
I think that social media was given as an example because social media is one of the few kinds of self-published sources that we (almost) all agree are SPS. If you look at an article like Cass Review (warning: CTOP), there are a number of sources that I'd say are self-published, but which reasonable people could disagree over the application of the WP:SPS rules, such as a white paper from a think tank, open letters from advocacy organizations, and even a Google Doc organized by two professors as part of a larger project. I think the community does sometimes make a distinction between levels of self-publication (in addition to the WP:EXPERTSPS exemption). WhatamIdoing (talk) 17:02, 12 August 2026 (UTC)
Oppose. Obviously by WP:PRIMARY we can trust an organization's own attestation of support. And we do not require independent sourcing of trivial material. (For instance, if Joe Biden tweets out "I had a dog named Wooper as a child", we would generally not require anything else to include that in the childhood section of his article.) A requirement of independent coverage for a couple of words in the latter half of an article is overkill. RedSlash 03:14, 11 August 2026 (UTC)
If Joe Biden's tweet about having a dog in childhood is the only mention of that dog, then it absolutely should not be included in his article because it fails DUE and BALASP. JoelleJay (talk) 11:20, 11 August 2026 (UTC)
Having a dog isn't a "viewpoint", so DUE is not very relevant.
BALASP asks editors to use their judgment. If the tweet were the only source for having a childhood dog, we would omit this, because editors do not judge the possession of a childhood dog to ordinarily be basic information for a biography in an encyclopedia; if the tweet were the only source for the names of his parents or his birthdate, we would include it, because editors do judge that information to ordinarily be basic information for a biography in an encyclopedia. WhatamIdoing (talk) 17:24, 11 August 2026 (UTC)
I've always wondered why DUE seems to be overused to apply to everything except actual viewpoints. Katzrockso (talk) 17:56, 11 August 2026 (UTC)
Because it has an easy, memorably shortcut? Also, because you see someone else use it this way, so you assume they're correct and repeat their usage. To be fair, NPOV's organization was pretty bad for years. We've made some progress with stepwise rearrangements and the occasional clarification, but we've been taking it in baby steps, once or twice a year, to make sure that we're not accidentally breaking anything. WhatamIdoing (talk) 18:07, 11 August 2026 (UTC)
Support: This isn't really about primary vs secondary - its more about whether coverage is WP:DUE. Can we really say that endorsements are due if independent sources can't be bothered to discuss them?Nigel Ish (talk) 20:21, 12 August 2026 (UTC)
The proposal requires only that an WP:INDY source mention the endorsement in passing (not a full "discussion" of the endorsement). WhatamIdoing (talk) 22:22, 12 August 2026 (UTC)
As I read it, the proposal isn't to do anything but remove the present project guidance. This would just throw it back to general policy. If a better, more subtle, project guidance can then be written and gain assent, that's another discussion to have later. Alanscottwalker (talk) 13:22, 13 August 2026 (UTC)
True, but the section heading is ==Proposal to require independent sourcing for all political endorsements==, so I suspect that it will be interpreted as requiring INDY sources, rather than merely removing the sentence and reverting to standard rules (which permit the use of non-INDY sources). WhatamIdoing (talk) 16:48, 13 August 2026 (UTC)
Any closer should not mangle policy, nor can they change policy, when all that is being proposed is to remove a sentence in a local guideline. All it can mean is the sentence won't be there. -- Alanscottwalker (talk) 17:43, 13 August 2026 (UTC)
I'm concerned about all of it. A closer will have to make sense of the actual opinions expressed in the RFC and future editors will have to interpret and implement the RFC outcome. And if participating editors thought they were !voting on something meaningfully different this is likely to lead to more disputes and frustration. —Myceteae🍄🟫 (talk) 20:49, 13 August 2026 (UTC)
I'm not that "concerned" because, we often have quite good closers that separate the wheat from the chaff, and any overstep or irrationality in the close is subject to call-out and review. Alanscottwalker (talk) 21:38, 13 August 2026 (UTC)
The editor who started the RfC said:
With the amount of horserace coverage every campaign gets, if no independent sources are covering an endorsement, it lacks WP:WEIGHT.Katzrockso (talk) 17:27, 13 August 2026 (UTC)
People make confused or confusing statements or arguments regularly, an argument does not change policy nor any guideline. The local guideline is poor, beginning with its use "WP:Local Consensus", as if agreement in a project guideline can override any general policy. Alanscottwalker (talk) 17:46, 13 August 2026 (UTC)
Do you think that any closure of this discussion that ends with consensus in favor of the change would not immediately be followed by an addition to the guideline requiring independent sourcing for organizational endorsements? Katzrockso (talk) 19:41, 13 August 2026 (UTC)
The local guideline may be poor, and the wording of this RFC certainly is—as I and others have pointed out from the beginning—but many editors have (reasonably) interpreted the intent as requiring independent sources and many !votes and comments have been on this basis. —Myceteae🍄🟫 (talk) 20:11, 13 August 2026 (UTC)
You can't require anything by removing the sentence. Practically, all these discussions on Wikipedia wander around hither and yon. That's just the way is.
To answer the above question, if anyone else wants to require anything new, they need to get agreement on a new sentence and it needs to align with policy, which this sentence does not. It is bedrock principle that verifiability does not end the issues of whether something should be content. Alanscottwalker (talk) 21:01, 13 August 2026 (UTC)
But you can require something by having a discussion in which many editors agree that it should be required, even if the first post does not propose exactly the thing that the discussion formed a consensus for. WhatamIdoing (talk) 21:05, 13 August 2026 (UTC)
This project is not an experiment in anarchy. Write down in guideline how to guide people and conform that guidance with policy, otherwise there is no consensus on it, that's one of the lessons of WP:local consensus. Alanscottwalker (talk) 21:13, 13 August 2026 (UTC)
This is a consensus-based project. It is not a parliamentary system, in which proposals have to be voted on as-is. If someone proposes "X", and the community forms a consensus for "Y", then "Y" is the winner. There is no law that says "Oh, but it can't be "Y", because that wasn't the original wording, and letting editors form a consensus without a formal proposal and a !vote is too chaotic for some people". Indeed, the law of the wiki is the opposite: Whatever the community agreed upon is what the community agreed upon. WhatamIdoing (talk) 23:07, 13 August 2026 (UTC)
This is a consensus based project that formulates its consensus in words that it writes down in policies and guidelines. To the extent it makes people search through random pages for maybe what people thought ten years ago, it is a failing. But now you are demonstrating my earlier observation that these discussions go all hither an thither.Alanscottwalker (talk) 23:17, 13 August 2026 (UTC)
I agree that this is a consensus-based project that documents most of its consensus in words that it writes down on policy and guideline (and help and info and essay) pages. However, my point is that when consensus is formed in a discussion, the consensus is not constrained by the OP's first comment. We could have an RFC with a question "Shall we say that this BDP is a rapist?" and end up with a consensus that the image in the infobox needs to be changed. It's true that discussions sometimes go hither and thither, but the fact that a discussion has wandered into unplanned territory does not invalidate any consensus that was formed in that discussion. WhatamIdoing (talk) 03:40, 14 August 2026 (UTC)
How does this sentence not align with policy? You can certainly disagree with it, but it doesn't say that verifiability is sufficient to include something. Katzrockso (talk) 21:43, 13 August 2026 (UTC)
Ah well, even if everyone agreed with you on what it is trying to do (which they don't), it obviously has created confusion due to its poor writing. Again, that means it has no consensus. Alanscottwalker (talk) 21:54, 13 August 2026 (UTC)
We have no consensus on the ONUS question, yet it remains in policy. Katzrockso (talk) 19:21, 14 August 2026 (UTC)
Oppose: Endorsements are often of encyclopedic interest. There been a significant decline in local news coverage in many communities. In cases where the race is of encyclopedic interest, the candidates meet notability guidelines, and the endorsements are themselves of encyclopedic interest (which admittedly is probably not something that can be decided categorically; some endorsements, e.g. by novelty groups are not) we can rely on WP:PRIMARY. Pudelpointed (talk) 19:29, 24 August 2026 (UTC)
Discussion (endorsements)
As was pointed out in the "BEFORE" at WP:RSN, the framing that the current guidance allows local consensus to overrule our general policy that facts be sourced to independent reliable sources is not quite accurate. A "dependent" primary source is often reliable for a statement made by the source itself, such as an explicit endorsement on an official website or social media account. WP:SELCRIT provides some general guidance but more or less allows for local consensus at the level of individual list articles. All that said, I can imagine these lists getting out of hand. WP:WEIGHT, WP:PROMO, WP:INDISCRIMINATE, and other general principles apply to endorsement list articles. —Myceteae🍄🟫 (talk) 21:45, 29 July 2026 (UTC)
Yup… while a selfpub source can reliably verify an endorsement, WP:VNOT and WP:DUE apply. We need independent reliable sources to demonstrate that the endorsement matters enough for us to mention it. Blueboar (talk) 21:57, 29 July 2026 (UTC)
What happens if an independent source claims Organization A endorsed Candidate B, but Organization A says it isn't an endorsement (and it's not a clear-cut case of either side being wrong)? Gnomingstuff (talk) 22:30, 30 July 2026 (UTC)
Has that actually happened to a significant degree? Cortador (talk) 12:10, 5 August 2026 (UTC)
I would think that endorsement lists generally include uncontroversial, uncomplicated entries. Beyond that, this has to be a case by case determination and is not something a general guideline can address. —Myceteae🍄🟫 (talk) 16:51, 5 August 2026 (UTC)
Given that WP:BALLOTPEDIA is a WP:GREL source and WP:INDEPENDENT of all the candidates, and given that they collect long lists of https://ballotpedia.org/Political_endorsements: What practical effect do we think this will actually have? We're literally going from "you have to have a reliable source" to "you have to have an independent reliable source and BTW https://ballotpedia.org/Political_endorsements is an independent reliable source that includes nearly all of the bona fide endorsements for US candidates", which at least as far as US articles are concerned, means that we're pretty much wasting our time here. WhatamIdoing (talk) 19:12, 5 August 2026 (UTC)
Ballotpedia is a great source for US elections, perhaps, not so much for the rest of the world. This looks like a case of making rules suitable for the US based on US conditions and assuming they should apply worldwide. Wellington Bay (talk) 15:42, 9 August 2026 (UTC)
I think you're right. I also think this was probably prompted by the upcoming US elections. WhatamIdoing (talk) 19:36, 9 August 2026 (UTC)
There is an ongoing debate in Canadian politics articles where some editors argue that self-published social media posts or campaign websites are sufficient for inclusion in endorsement lists, regardless of independent coverage. On local talk pages, this frequently leads to attempts to establish a WP:LOCALCONSENSUS for inclusion of these into a "list of endorsements" which closely resembles the tables used in AP2 articles (see 2026 Ontario Liberal Party leadership election#Endorsements for the most recent example of this debate coming up). Requiring independent secondary coverage, even for organizations and at "local" talk pages ensures that Wikipedia endorsement lists reflect encyclopedic WP:WEIGHT. ―"GraveDragon-X"(hihi) 18:23, 10 August 2026 (UTC)
Ordinary discussions about how to best apply/comply with our policies and guidelines are not LOCALCONSENSUS violations. I suggest reading WP:LOCALCONSENSUS, especially the bit that says:
YDesired outcome: A small number of editors arrive at an agreement about how to best apply sitewide policies and guidelines to a given Wikipedia article.
If it is not clear enough that this "Desired outcome" (emphasis in the original) is not a LOCALCONSENSUS, then let me know, and I'll see about clarifying that, possibly by adding a sentence that says "Doing this is not a 'local consensus' and does not violate this policy." WhatamIdoing (talk) 20:35, 10 August 2026 (UTC)
I would opine that some editors are arguing to be allowed to decide that Nrelevant sitewide policies and guidelines should not apply to particular articles, on account of "poor" or "slow" secondary coverage. ―"GraveDragon-X"(hihi) 21:19, 10 August 2026 (UTC)
There's no policy or guideline that requires secondary coverage for a small detail, such as whether a candidate was endorsed by an organization. Arguing that primary and/or non-independent sources should be allowed within the confines of the relevant sitewide policies is the opposite of arguing that relevant sitewide policies and guidelines should not apply. The WP:PRIMARY policy says "Primary sources that have been reputably publishedmay be used in Wikipedia". Why are you arguing against the long-standing sitewide policy? WhatamIdoing (talk) 00:14, 11 August 2026 (UTC)
If anything, I am arguing that a simple tweet or candidate website is insufficient sourcing for inclusion of endorsements of individuals on Wikipedia per WP:ENDORSE/WP:DUE. If they have not been covered by independent, secondary sources, why would Wikipedia, if Wikipedia's purpose is to be a reflection of what is written in reliable, secondary sources? ―"GraveDragon-X"(hihi) 00:45, 11 August 2026 (UTC)
Wikipedia's purpose is to be an encyclopedia that fairly represents all the sources, which sometimes requires including facts that are not written in secondary (=analytical, evaluative, interpretative, etc.) sources.
Note that WP:ENDORSE doesn't even mention WP:SECONDARY sources, much less require them. ENDORSE says editors working on an article can choose to use sources connected to the organization itself, such as its website or official social media accounts for endorsements by organizations.
The arguments in Canadian politics articles centre around individuals, not organizations, which are specifically covered by WP:ENDORSE. I am aware that this specific RfC is in regards to organizations only. ―"GraveDragon-X"(hihi) 01:06, 11 August 2026 (UTC)
Even for individuals, ENDORSE does not require secondary sources. WhatamIdoing (talk) 01:10, 11 August 2026 (UTC)
The text on WP:ENDORSE literally says This means endorsements should not be sourced solely to a Tweet or Instagram post by the endorser, endorsee, or an affiliated individual or organization, for example. If my semantics are poor, I apologize, but editors are arguing that a simple tweet or a link to www.JaneDoe2026.ca/my-endorsements should be enough for inclusion of individuals. ―"GraveDragon-X"(hihi) 01:22, 11 August 2026 (UTC)
That's under "2. Lists of endorsements should only include endorsements which have been covered by reliableindependent sources" in ===Endorsements by individuals===
The difference between WP:SECONDARY and WP:INDEPENDENT sources is not mere semantics. It is the difference between a source that analyzes an endorsement ("The ____ endorsement of my esteemed opponent has proved an embarrassment to his campaign; I should be appalled to think that such a deplorable organization approved of my platform") and one that has no vested/financial interest in the outcome (e.g., a news outlet). WhatamIdoing (talk) 01:52, 11 August 2026 (UTC)
In fairness, which definition of primary source one uses and how it categorizes news articles is a semantic issue. A mess that's been acknowledged earlier in this discussion. Of course, our house definition is what ultimately matters in assessing the application of P&G. —Myceteae🍄🟫 (talk) 01:59, 11 August 2026 (UTC)
True; there's a quite traditional definition that says anything published within a few years of any event is automatically a primary source, which would mean that "must have a secondary source" would mean "cannot be included until the election has been over for several years". But that definition is mostly people writing about pre-modern history, and 'our house definition' does not require that. WhatamIdoing (talk) 02:20, 11 August 2026 (UTC)
And you have resources like this and usage in different disciplines and contexts. Most descriptions I've seen, including ours, will say that newspapers (and by extension, online news articles) can be primary or secondary depending on various factors but the factors differ as do the determinations based on a particular factor. —Myceteae🍄🟫 (talk) 02:38, 11 August 2026 (UTC)
anything published within a few years of any event is certainly the definition I was taught, and it's the one I use for anything pre-2016 or so. (This is a viewpoint which does not make you popular at AFD) GreenLipstickLesbian💌🧸 02:39, 11 August 2026 (UTC)
Because it would mean we can't write about anything that happened recently, which I think is a viewpoint that would garner very little support in a community wide discussion. Katzrockso (talk) 02:42, 11 August 2026 (UTC)
Only because there is further confusion that reliable = secondary (or tertiary). Even though our P&G don't say that, it's no surprise that this is a source of conflict and confusion. —Myceteae🍄🟫 (talk) 02:51, 11 August 2026 (UTC)
If our notability criteria specify secondary sources are required and we say that recent coverage (ie within the last few years) is all primary, then nothing in the last few years is wiki-notable. Katzrockso (talk) 03:11, 11 August 2026 (UTC)
But we already have tons of articles on ongoing infectious disease outbreaks, natural disasters, elections, upcoming films, etc. built almost entirely on news articles and other sources we define as primary. Maybe some of these are able to scrounge up two or three secondary sources. I agree that GreenLipstickLesbian's definition would be unworkable but there already seems to me to be a disconnect. Anyway, this is increasingly off-topic… —Myceteae🍄🟫 (talk) 03:54, 11 August 2026 (UTC)
And now hopefully you see why even I, a bit of a hardliner of this, have a built in post-2016 exception clause for anything not excessively contentious. (If you can't find a source 5 to 10 years after the event with sigcov and everything, is the event notable? I say no, obviously not, other editor say yes, obviously yes. ) GreenLipstickLesbian💌🧸 03:55, 11 August 2026 (UTC)
Back when the word secondary was first added to WP:N (in 2007), we had a different definition of WP:SECONDARY. When it spread to the explanation of the GNG (you may have noticed that it's not in the GNG sentence itself), the notion of "secondary means secondhand" was very popular. If a house burned down on Monday, and a journalist interviewed an eyewitness for Tuesday morning's paper, then that was "secondary". It's wrong, and we've moved firmly away from that during the last decade, but I think that anyone concerned about secondary sources at AFD should remember that 'secondary' back in the day was a very low bar indeed. WhatamIdoing (talk) 04:31, 11 August 2026 (UTC)
You're right that our guidelines and practices should take a global view. A relatively small number of articles have been provided as examples in this and the other linked discussions to illustrate what exactly the problem is, and all of these have been US elections articles. If we were to adopt the proposed rule and follow the guidance that Ballotpedia is generally reliable, the likely outcome would be that US election articles remain largely unchanged—or expanded, as Ballotpedia likely catalogues endorsements that aren't in some of our articles—while endorsement lists for other countries' elections are trimmed unless there is a similar source that can be used to catalogue endorsements for every either country. Or if we wanted to limit/down-weight Ballotpedia endorsement lists, we'd have to impose an even higher bar that at least two independent sources are required for organizational endorsements. —Myceteae🍄🟫 (talk) 22:30, 9 August 2026 (UTC)
Out of curiosity, I looked at Ballotpedia's Abdul El-Sayed page. I count 58 "organizations" under his endorsements in the 2026 senate race. Our article on the senate race lists just 37 in the primary (8 labor unions, 25 organizations, 1 political party, 2 newspapers). —Myceteae🍄🟫 (talk) 22:35, 9 August 2026 (UTC)
I also looked at the size of 2026 United States Senate election in Michigan. The Democratic primary endorsements section is indeed huge. If we require independent sourcing then it would be reasonable to pick Ballotpedia as our standard bearer. Nearly doubling the number or organizational endorsements would only worsen the problem. Size aside, I don't think the article would be improved by including non-notable orgs like Cat Ladies For America. I suppose we could come up with additional criteria to duplicate the output of our current practice. This is an awfully convoluted fix, to the extent there is even a problem here.
Section sizes in 2026 United States Senate election in Michigan
If you came here because someone asked you to, or you read a message on another website, please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.
However, you are invited to participate and your opinion is welcome. Remember to assume good faith on the part of others and to sign your posts on this page by adding ~~~~ at the end.
Note: Comments may be tagged as follows: suspected single-purpose accounts: {{subst:spa|username}}; suspected canvassed users: {{subst:canvassed|username}}; accounts blocked for sockpuppetry: {{subst:csm|username}} or{{subst:csp|sock username|sockmaster username}}.
Should any of the following be added to WP:ITNBLURB:
If reliable independent sources generally describe an election as not free and fair, ITN should generally not report or indicate this characterization.
If reliable independent sources generally describe an election as not free and fair and Wikipedia has an article surrounding this, consensus at ITN can develop to report or indicate this characterization.
If reliable independent sources generally describe an election as not free and fair, consensus at ITN can develop to report or indicate this characterization.
If reliable independent sources generally describe an election as not free and fair, ITN should generally report or indicate this characterization.
Remove elections from ITN/R as the current formulation too often results in insignificant elections in microstates being posted while elections which are actually important such as the Mayor of NYC, the Scottish government or the Indian state legislative assemblies are denied. The nominal RfC question is badly formed because ITN/R doesn't determine the format of blurbs. The fact that such postings are often contentious is a further reason to have open discussion without any ITN/R constraints which lead some to suppose that elections should be posted in a mechanical, monotonous way. Andrew🐉(talk) 20:10, 30 July 2026 (UTC)
Thank you for pointing out the flaw in the RFC question (the first person after 24 days of workshopping...). I have reworked it to hopefully resolve the concern. 1brianm7 (talk) 21:06, 30 July 2026 (UTC)
Your constant prejudice against the politics of small nations is duly noted. Again. However, the course of action you are calling for does not form part of any of the proposals currently under discussion. GenevieveDEon (talk) 21:14, 30 July 2026 (UTC)
ITN/R is explicit prejudice − an arbitrary list of supposedly important topics regardless of the actual coverage and facts. My position is that we should judge topics on their merits, not by preconceived prejudice. Andrew🐉(talk) 22:05, 30 July 2026 (UTC)
I think Andrew and Masem's allegations of non-NPOV selective posting and WP:RGW on WT:ITN are credible and should be investigated. Thebiguglyalien (talk) 01:15, 31 July 2026 (UTC)
I can agree that ITN should be more open to posting sub-national elections; the most recent NYC election was inarguably one of the biggest political news stories in the world last year. But instead of posting it, ITN - as per usual - shot itself in the foot by caring more about strict adherence to its incoherent set of unwritten rules than doing anything resembling what it's supposed to do. But I don't think this would be solved by removing national elections from ITN/R. ITN/R blurbs and RD postings are the only semi-functional parts of ITN precisely because they bypass these debates over what is "significant." We just need to stop making the mistake of acting like anything that's not ITN/R is automatically not blurbworthy at all. That, and nuke ITNSIGNIF, and maybe also replace our whole ITN/C community with different editors who'll be able to form a consensus to fix the broken mess that is ITN, because with every passing year I lose faith that the bunch we have now will ever be able to agree to do that. Vanilla Wizard 💙 21:01, 31 July 2026 (UTC)
Oppose instruction creep that doesn't appear to be well-justified by prior discussions. This more or less aligns with options 3/4, but I'm not seeing a reason why we need a separate instruction about this that wouldn't simply be subject to regular workshopping of the ITN hook to reflect RS coverage. Even when blatantly unfair, election results tend to be significant (if nothing else, confirming the intended continuity of the ruling regime), protests resulting from rigged elections can also be quite significant, and judging fairness is itself a gradient, not a binary. That having been said, I think that Andrew D's concerns above could perhaps be resolved by adding a clause that ITN should also run blurbs for elections for cities and dependencies with a population in excess of [2 million? 5 million? 10 million?] signed, Rosguilltalk 20:21, 30 July 2026 (UTC)
Oppose instruction creep. I don't see any evidence that the status quo (option 3) is not working. How a blurb should be worded depends on the circumstances of the individual election and every other option is too rigid to account for this. I don't see any benefit in explicitly stating that consensus may be for or against mentioning how free and fair an election is. Thryduulf (talk) 20:48, 30 July 2026 (UTC)
I would be glad if this RfC establishes 3 as a status quo. Some admins have removed any wording not in the fashion of "wins" from the main page, even when it was established at the nomination (link to ERRORS discussion). 1brianm7 (talk) 21:03, 30 July 2026 (UTC)
3 is not the status quo. 1 is the status quo - we don't editorialise, and saying someone was "declared the winner" under some circumstances but not others is clear editorialising. —Amakuru (talk) 12:30, 24 August 2026 (UTC)
ITN guidelines are largely silent about the issue in question and so there isn't a documented status quo. The RfC provides examples of various ways of posting election results which seem to cover all the options. What happens just seems to depend on which admin gets to post the blurb. Andrew🐉(talk) 12:44, 24 August 2026 (UTC)
Looking at the examples provided, during the Putin blurb, was the community and various admins all going against policy when they debated and consensus eventually landed "editorializing". Parroting authoritarian propaganda is editorializing, not not doing so. 1brianm7 (talk) 12:53, 24 August 2026 (UTC)
Oppose either of the options numbered 1, support any of the others, with a preference for option 3 - I think it's misleading to have a policy against mentioning the unfairness of an election if that unfairness is widely reported in reliable independent sources. I'm less concerned with the exact phrasing of the rule, but I do see the concern about instruction creep. With option 4, although I am in favour of its sentiments, there is the risk that the requirement to include such a reference might lead to such stories not being posted at all, because the nature of the reference cannot be agreed. Options 2 and 3 are both close to my understanding of the status quo, and clarify it. I do not think that we should specifically be avoiding posting elections simply because they are unfair - but I do have a preference for mentioning the unfairness. GenevieveDEon (talk) 21:14, 30 July 2026 (UTC)
either of the options numbered 1 - I've rerenumbered the second option 1 to #5 to reduce confusion 1brianm7 (talk) 23:36, 30 July 2026 (UTC)
Remove ITN, first choice. Remove elections from ITN/R, second choice. Follow the sources, third choice. If the sources say it's a "sham" election, say that so-and-so won a "sham election." If they say it's a "rigged" election, ITN should say so-and-so won a "rigged election." If they say it's an "election with widely-reported irregularities," then we should say so-and-so won an "election with widely-reported irregularities." Levivich (talk) 21:25, 30 July 2026 (UTC)
Follow the sources on ITN? An interesting idea, but we'd need to set up a sort of crash course at WT:ITN so they understand how sources are used on Wikipedia. Thebiguglyalien (talk) 01:13, 31 July 2026 (UTC)
To put it in terms of the options, I support 4 the most, also support 2, 3, and 5, and oppose 1. Levivich (talk) 23:00, 26 August 2026 (UTC)
Remove elections from ITN/R. This would solve the current problem and a host of others.Katzrockso (talk) 22:51, 30 July 2026 (UTC)
It wouldn't really, since all those controversial / sham elections would be nominated under the normal ITN process... Khuft (talk) 18:59, 31 July 2026 (UTC)
Option 3 is the best out of the options. Katzrockso (talk) 20:12, 25 August 2026 (UTC)
Generally oppose, free is not a binary, fair is not a binary. Reporting purported election results without going over the same arguments repeatedly seems the purpose of the ITN/R entry, mandating freeness and fairness assessments will not aid with that goal. CMD (talk) 01:31, 31 July 2026 (UTC)
Oppose cover all in the same way and don't judge. The reader is not stupid and sees bias. Let's not give them more opportunity to see it.--Wehwalt (talk) 12:42, 31 July 2026 (UTC)
If RS say one thing is an election, and another thing is a sham election, and we call both things an "election," we're misleading the reader. If RS say one thing is "X", and another thing is "called 'X' but not actually X," and we call both things "X", we're lying to the reader. On the main page. Dropping "sham" or "rigged" before "election" would be a lie of omission.
"Free" and "fair" aren't just adjectives describing some kinds of elections, they're prerequisites for something to even be an "election." We shouldn't use the word "elect" when the reality is "appoint" (or "self-appoint"), even if government propaganda uses the word "elect." Levivich (talk) 13:26, 31 July 2026 (UTC)
Can editors opposing any changes mention whether they think the status quo is along the lines of "ITN participants can propose and gain consensus for blurbs that report or indicate an election not being free or fair" or whether it is "Any blurb that mentions an election not being free and fair is procedurally invalid and will be altered by ITN admins to omit it", and whether that extends to the subtle games with wording Masem mentioned below), even if ITN participants supported such a blurb. Anyhow, Support 3>4, oppose 1 and 2; whether an election was a sham is the second-most important thing after the result, on equal significance with the election happening. Support 5 - the fact that a military dictator decided they needed a fancy new title is not inherently significant. 1brianm7 (talk) 14:03, 31 July 2026 (UTC)
Can editors opposing any changes mention whether they think the status quo is along the lines of "ITN participants can propose and gain consensus for blurbs that report or indicate an election not being free or fair" or whether it is "Any blurb that mentions an election not being free and fair is procedurally invalid and will be altered by ITN admins to omit it" this is a false dichotomy. Editors can reach a consensus to mention that, but if they haven't then it won't be included in the blurb. If admins are altering blurbs against consensus that's a problem that none of the changes proposed here can solve. Thryduulf (talk) 14:29, 31 July 2026 (UTC)
I'm kinda at a loss here. Admins are doing that (see the discussion I linked in my reply to you above). When asked why, they said that's how it has always been done and to start a discussion at WT:ITN if you want it changed. I did, there was no consensus, so I started this RfC. What should I have done?1brianm7 (talk) 14:47, 31 July 2026 (UTC)
A significant contingent of editors respond to proposals to mention or indicate sham-ness by saying that there is an unwritten rule to never do so. I can't think of a way to prevent that simpler than a written rule saying that it is allowed. 1brianm7 (talk) 15:08, 31 July 2026 (UTC)
I'd be fine with removing elections from ITNR. Just because I started the RfC doesn't give me any say on how people !vote, and the only reason I didn't include it as an option was that no one had related it to the specific issue at play. I knew removing them would solve my issue by collateral, but I hadn't seen a way it was related. Aquillion's comment below was the first to do that. 1brianm7 (talk) 03:16, 29 August 2026 (UTC)
Oppose change, keep status quo / keep elections in ITN/R – "X is declared the winner of" is just a wordier way of saying "X wins". As mentioned before, the arguments on whether an election is "free or fair" is arbitrary and ITN editors will never agree. If protests are significant enough where they would normally merit a blurb, it would make sense to merge the two blurbs together. If reliable sources are reporting on a specific aspect of an election, such as voter turnout in the 2021 NewCaledonia referendum or the recent HongKong election (in which the pro-China camp, pro-democracy camp, and international media all focused primarily on turnout), then it would also be appropriate to include that in the blurb when also reflected by the targeted article. Nice4What (talk · contribs) ♥ 14:35, 31 July 2026 (UTC)
Support this initiative in general; agnostic re exact wordings. I never really agreed with the "consensus" that we should use standardised wording when posting election results (sham or not). Our guidance should be what reputable sources say, and if they tend towards questioning the freedom and fairness of certain elections, we should be free to editorialise accordingly. (And: Keep all elections at ITN/R - not sure why that is even being questioned here as irrelevant to this proposal - the Russian "election" will be nominated anyway when it happens, whether as ITN or as ITN/R) Khuft (talk) 19:07, 31 July 2026 (UTC)
we should be free to editorialise accordingly No! Absolutely not! The personal opinions of ITN editors should not determine how we describe election results. The last thing we need is editors only using the term "sham elections" for regimes they personally disagree with. Warudo (talk) 15:24, 3 August 2026 (UTC)
Follow the sources/target article language above all else. I guess this is an anything except 1 with a preference for 4 !vote? But it really does just depend on what the sources say. Wikipedia is not a publisher of original thought, ITN even less so. It should just be a chain of repetition: ITN should follow what the article says, the article should follow what the sources say, simple as. This should be the only thing that determines whether the language of the blurb can or should suggest that an election is contested, not what us at ITN have to say about it.
As CMD pointed out, it is not possible for us to cleanly and objectively separate "real" elections from "sham" elections because most countries on Earth don't fit neatly into a binary between true democracies and true dictatorships; it's a spectrum and most of the world is somewhere in the middle, and where exactly a country falls on that spectrum will vary from election to election as countries either backslide or democratize over time. This is why it needs to be determined on a case by case basis, based on what the sources say and how much weight article writers assign to those sources, how an election should be described. If the article can say the election was described by international observers as neither free nor fair, then ITN can. If the article can't say it, ITN can't say it. Easy as that, no need to complicate things or debate it at ITN/C. If this is contested, contest it at the article talk page, not ITN/C. The less leeway ITN gives itself, the better. Not just with regard to election blurbs, but all blurb discussions, because this mindset that ITN is somehow separate from the articles it features & gets to act as its own decisionmaking body with minimal objective instructions is really the root of every one of ITN's problems. Oppose removing elections from ITN/R, agree with Khuft that it's not really clear why that's even being discussed.
Oppose. It's not for us to judge elections in such a way; we can note that observers view an election as unfair. Instructions creep, too. 331dot (talk) 20:55, 31 July 2026 (UTC)
To be fair to the nom, the options provided are about how/if we should follow the sources, not leaving it up to us to judge elections ourselves. Noting that observers view an election as unfair is roughly options 2-4, but opposing all of them and forming no consensus here would leave us stuck with the current situation where the editors feel they are allowed to judge elections themselves. ITN doesn't have an instruction creep problem, but I wish it did. It has a "there are no instructions" problem. Vanilla Wizard 💙 21:16, 31 July 2026 (UTC)
Exactly that we have no instructions. I'd note that about half of the oppose votes are doing so because there is no need to spell out the status quo (one) and another half are doing so because there is no need to spell out the status quo (roughly two or three). 1brianm7 (talk) 21:52, 31 July 2026 (UTC)
Oppose / keep status quo Pretty much agree with Nice4What. Readers can always click on the blurb's wikilink to the election page to learn more about the election, including its controversies. If "reliable independent sources generally describe an election as not free and fair", then that would usually be covered in the article's lead. Some1 (talk) 23:24, 31 July 2026 (UTC)
From news style: To "bury the lead" is to begin the article with background information or details of secondary importance to the readers, forcing them to read more deeply into an article than they should have to in order to discover the essential points. - perhaps we should just adopt the format "John Smithis set to continue as president of example.", we wouldn't be deceiving the reader anymore (if they don't click on the link, which most won't) 1brianm7 (talk) 00:52, 1 August 2026 (UTC)
Oppose any changes. Any articles we post where they are described as shams should say as much in the articles in question. We don't need to editorialize in the blurbs or in what we post. All election blurbs say anyway are "[person] was elected as [title] of [country]", and that is all that needs being said in most cases. The article is the ideal place for expansion upon the circumstances around the election. DarkSide830 (talk) 01:08, 1 August 2026 (UTC)
I think that's the whole issue that is being flagged here... "X was elected" implies a democratic process was adhered to, which isn't the case in sham elections. It is editorialising, but in the opposite direction (if that makes any sense) because it doesn't follow what reputable sources would be saying. Khuft (talk) 10:15, 1 August 2026 (UTC)
"X was elected" implies a democratic process was adhered to I don't think that's true. It implies that an election was held and that that X was declared the winner of that election, but it doesn't imply anything about the nature of the election - after all whether a process is "democratic" or not is neither a binary nor objective, whether the defined process (whatever its nature) was followed is frequently not knowable until days or weeks (at least) afterwards and sometimes contentious. For example whether the 2020 United States presidential election was "democratic" and whether the defined process was followed depends on who you ask - e.g. those who believe Donald Trump's claims, those who believe the Electoral college is not democratic, etc. Thryduulf (talk) 20:04, 1 August 2026 (UTC)
Oppose change This proposal seems to rely on a biased view that free and fair elections is the control stage and any departure from it needs to be indicated. In the same way we don't characterise elections as 'free and fair', there's no point to do so if they're 'non-free and unfair'. In any case, the reader can view the article for further details. Democracy is a view, not a universal rule. --Kiril Simeonovski (talk) 21:08, 1 August 2026 (UTC)
Support. This isn't AfD. This is literally just "is this newsworthy enough to make the front page of Wikipedia". Putin or Kim Jon Un winning "reelection" by a 90-10 margin once again is just not newsworthy. This is the same reason that a tornado in Kansas won't make ITN unless its death toll is absurd, whereas a similarly powerful tornado in Tokyo would definitely make it regardless of death toll. Man bites dog is news, dog bites man is not. RedSlash 03:21, 11 August 2026 (UTC)
Oppose per Darkside. The status quo is fine whereby we declare someone was elected and that's it. No editorialising, no saying they were "declared the winner" (unless we go down that route for all elections) and no notes saying it was "not free and fair". Such details can be covered fully in the article. Cheers —Amakuru (talk) 12:26, 24 August 2026 (UTC)
Oppose editorialising. Stephen 01:17, 25 August 2026 (UTC)
Remove all elections from ITN (with exception). Apply an ROTM like rule: only elections which receive widespread international coverage and demonstrate results of an unexpected or unusual nature (landslide, result against opinion polling, 1st election after period of dictatorship etc) - it would necessary to demonstrate a consensus amongst the sourcing of the exceptional nature of the election. So for example the 2012 US presidential election would be a no, but 2016 could be a yes (election with a minority of the vote). This would potentially also allow elections at any level (eg Rodrigo Duterte being elected mayor of Davao City from an ICC gaol cell in Den Hague). Regards, --Goldsztajn (talk) 14:00, 26 August 2026 (UTC)
I understand your general point and it's a good one. But what does ROTM mean, please? ROTM doesn't seem to help? Andrew🐉(talk) 14:36, 26 August 2026 (UTC)
I'm guessing "ROTM" means "run of the mill". Thryduulf (talk) 14:53, 26 August 2026 (UTC)
That seems correct, considering that WP:ROTM exists. Warudo (talk) 14:58, 26 August 2026 (UTC)
Remove elections, and strenuously oppose 1 in strongest possible terms. Of these options, I favor 2-4, but the correct thing to do is to remove the requirement for elections entirely. Something like Vladimir Putin is elected President of Russia for a fifth term is an absolutely non-neutral framing that leaves out vital context. But the real underlying problem here (and the reason why people who clearly support 1 are opposing the whole thing instead, knowing that the current status quo favors their position) is that because elections are listed by default, we end up with situations where eg. that utterly inappropriate sentence for Putin gets to start as the default and then editors who like that framing can oppose a consensus that would add necessary qualifications to it, resulting in that ending up on the front page. The unqualified statement of Vladimir Putin is elected President of Russia for a fifth term, without mentioning the fact that it was not free or fair, should also require clear affirmative consensus and if people cannot reach one then we say nothing about it at all. I believe that the obvious fact that we should say something would prod everyone to compromise and find some wording that acknowledges the problems; the issue is that right now, since the "default" heavily favors one side in that dispute, they have no incentive to compromise because if they just reject everything they will get a statement on the front page that inappropriately makes it sound like Putin (or whoever) was democratically elected, without having to actually produce an affirmative consensus for it at any point. The only way to solve this without more red tape is to remove requirements for elections entirely so we start from a blank slate each time. --Aquillion (talk) 19:08, 26 August 2026 (UTC)
Remove ITNR, or at least remove elections from ITNR I've been complaining for years about the "donut-hole" problem with ITNR: You should need consensus to post something to the main page, but once the item is added to ITNR, you need consensus to NOT post it. The original purpose as stated is to note items that have "presumed" significance so that we do not waste time with trivial opposition. In practice, it is used as a cudgel against substantive opposition by suggestion that consensus exists currently because two editors approved it ten years ago. GreatCaesarsGhost 17:17, 28 August 2026 (UTC)
I agree with you but am not understanding what it has to do with donut holes. I thought these would be actual holes but find that they are what's made with the cut-out dough. See list of doughnut varieties for more confusion. Andrew🐉(talk) 18:02, 28 August 2026 (UTC)
Indeed, and thanks. I often forget how incomprehensible the American version of welfare must be to outsiders. So much so that "welfare" is a pejorative! GreatCaesarsGhost 15:14, 31 August 2026 (UTC)
Remove elections from ITN/R "Let them fight!.gif" j/k, but it's too complex to have rules without the rules themselves being overly complicated. Case by case consensus is needed for elections. Jahaza (talk) 19:30, 28 August 2026 (UTC)
I don't have enough background to know exactly which option would best suit my comment, but simply it should follow reliable sources. There certainly shouldn't be rules that how reliable sources discussion a topic should be ignored, that would be against NPOV. On case by case basis the election should be described as reliable sources describe them, editors shouldn't inject their own bias by ignore those descriptions. Reading through what others have said I believe that's remove elections from ITN/R. -- LCU ActivelyDisinterested«@» °∆t° 23:02, 28 August 2026 (UTC)
Oppose categorically barring any topic from ITN. 331dot (talk) 15:16, 31 August 2026 (UTC)
Discussion (ITN elections)
An issue that I've raised is that the determination of what is or isn't a sham election, or what is or isn't a free-and-fair election, is not an objective meausure. There are election watchdog groups that will review an election and sometime after the election will assess the free-and-fairness but not in time for ITN's purposes; and even if these groups deem an election to be a sham, their statements should be included with attribution as other similar groups (like SPLC for hate groups), to keep it out of wikivoice. Which leaves us with journalism commentators making that assessment at the time of the election, which we should avoid resting too much weight on even if it seems clear they are correct. ITN's blurbs need to stay factual as they are all in wikivoice - we don't have room for attribution or sourcing like article space has, so trying to force in a claim that an election was a sham or not free-and-fair just doesn't work. We can play subtle games with the wording, de-emphaizing "win" and more "selected" or "named" in the cases of such elections like in Russia, though we should also be consist with that across known free-and-fair elections too. Masem (t) 13:37, 31 July 2026 (UTC)
It is also worth noting that there are times when different observers have different opinions about how free and fair a given election is (although usually only in degree). Thryduulf (talk) 13:58, 31 July 2026 (UTC)
The alternative just as problematic - we present an election as-if it were a true election ("Russia elects" or "Putin wins"). "wins" and "elects" have specific implications and invoke particular meaning for a reader, so it is simply not neutrally reporting the facts if in fact we are reporting on a sham election. Instead, we would be misinforming our readers. Katzrockso (talk) 22:09, 31 July 2026 (UTC)
+1 - If there is clearly a dispute over whether an "election" was really an election at all, and there is due weight to note this in an article lead, then presenting the event as an election in Wikivoice with no qualifiers is very much an NPOV vio. NPOV is about giving due weight to relevant perspectives, failing to do this is not neutral. The only sensible solution is to assess the sources and the article content to determine whether there is due weight to present an election as contested. Writing "Vladimir Putin wins the Russian presidential election" with no asterisks as though it were a totally normal and legitimate election is just as much of a WP:WEIGHT vio as "Joe Biden is declared the winner of the United States presidential election amid allegations of fraud"; both unduly promote a WP:FRINGE perspective. Vanilla Wizard 💙 23:11, 31 July 2026 (UTC)
The problem is whether an election is a sham or not , regardless of how many journalists are commenting on it within the days of that election, is subjective and cannot be said in wikivoice. It falls under NPOV that the claims should be attributed and given context which is fine in the article body, but in the short sentence we have at ITN, we have no room for attribution and context. (This is true for all ITN blurbs, they have to be presented in wikivoice so must be demonstrated fact and not subjective assessments). WEIGHT obviously applies in article space as to put the sham aspect up high in the lede, but obviously outside wikivoice, eg: "Putin wins the Russian president election in what many observers consider as a sham election." but that's language that can't work at ITN. Masem (t) 01:12, 1 August 2026 (UTC)
That's why there are wording formats we can say that do not imply that the election was a fair one without going there, like "X is elected as president in the 2026 Y election." That applies if the election was fair or not, but we should be using that same format for all elections so that we're clearly not putting our finger down on the marker. Masem (t) 01:07, 1 August 2026 (UTC)
Article board
These days it seems hard to find Wikipedia editors to collaborate on things. My suggestion is that a new discussion page be started, known as the Article board, or alternatively the Collaboration board. It would be a place where users could discuss changes to articles and collaborations on Wikipedia. I've created the page, but listed it as a proposal for now.
I'd like to address that although this is often done on talk pages, or on WikiProjects, they often are not active enough to have much of an effect. The benefit here is that this place would be active and centralized.
If there is disagreement over this, we could do a trial run for a certain period of time and see how it works. NewAccount7295 (talk) 15:43, 13 August 2026 (UTC)
What approach do you suggest to make a new location more active than the existing ones? Note the Wikipedia:Articles for improvement initiative has existed for many years (it's currently changing its procedures and will become a section on the main page). The key challenges I see are how to get enough editors to regularly use the new location, and how to connect these regular users to the pages they are interested in. Although I generally think it would be more fruitful to connect users with others that have similar interests (thus re-invigorating WikiProjects), other approaches can of course be tried. isaacl (talk) 16:53, 13 August 2026 (UTC)
@Isaacl As a major discussion page this would be added to the "Other areas of Wikipedia" list, which can be seen on the Main Page, and linked to from many othetr places. The activity can thus come naturally. That is a secondary concern.
It is less likely to go inactive than the WikiProjects which only have a limited number of interested editors in the first place. This page can coexist with them. Think of it as "WikiProject General". NewAccount7295 (talk) 17:15, 13 August 2026 (UTC)
I feel attracting participants is a primary concern, not a secondary one. Without critical mass, there won't be incentive to use the page. To give a new location the best chance for success, I think there should be a plan of how to integrate it into existing workflows. isaacl (talk) 17:23, 13 August 2026 (UTC)
@Isaacl This is why we do a test run and see how it works. I've roughly explained a starting point. Link it from the Main Page, the Community portal, and other places as a major page, akin to the Help desk, Teahouse, and Reference desk. Something editors know they can use and something that is known about prominently. NewAccount7295 (talk) 17:34, 13 August 2026 (UTC)
Sure, I have no issues with trying things out. I'm just concerned that if we don't try to give it the best chance for success and it doesn't do well at first, further tests will be stymied for years by editors citing its first failure (as has happened with the articles for improvement initiative). isaacl (talk) 17:43, 13 August 2026 (UTC)
@Isaacl Good point. I presume it would be given the best chance for success if this is what we did. I don't see how it wouldn't be given that. NewAccount7295 (talk) 17:48, 13 August 2026 (UTC)
Someone proposed a WikiProject Miscellaneous recently.
@WhatamiIdoing This is not a proposal for WikiProject, but rather a discussion page/noticeboard. I compared it to one since many will draw the similarities in that the discussion places for the WikiProjects are where users go to work with other editors on something specific. The collaboration here isn't as coordinated as a WikiProject.
For example, this is a place someone could go and start a thread about an article they want to create, and are asking if anyone wants to help out with it and discuss it there. NewAccount7295 (talk) 21:28, 13 August 2026 (UTC)
This is a proposal for a group of people to work together to improve Wikipedia. Wikipedia:A WikiProject is a group of people who want to work together to improve Wikipedia. That is literally the definition of a WikiProject. This is therefore a proposal for a WikiProject (well, two of them). WhatamIdoing (talk) 17:40, 1 September 2026 (UTC)
WhatamI... Well put regarding built and they may not come. But the success rate is probably around 5-7% or so. Yesterday, all my dreams... (talk) 08:45, 14 August 2026 (UTC)
Most editors edit articles they are interested in. Often this is a particular subject area or type of editing, such as copyediting. WikiProjects and, in some cases, noticeboards are better suited for this. And there's Wikipedia:Articles for improvement. Of course there are many editors with broad interests and skillsets but I anticipate that attracting and sustaining a critical mass of editors interested in generic "collaboration" or "improvement" with an otherwise infinite scope will be difficult. —Myceteae🍄🟫 (talk) 20:23, 13 August 2026 (UTC)
Hi, I'm Sonja and I lead the product teams who develop the contributor experience at the Foundation. Connection and collaboration is something we're also very interested in -- we even have a team dedicated to this topic:) The Connection team has been investing in the CampaignEvents extension over the last couple of years, and one recent intervention that might be interesting to you is Collaborative Contributions, which allows organizers to track edits towards a goal and set up worklists for participants to collaborate on. We're exploring additional feature improvements for worklists right now and plan to expand the concept to personal worklists as well, so that anyone can create a list of articles they want to work on and invite other volunteers to collaborate with them without having to host a big event or WikiProject. Feedback that has come up from other community members is that they for example would want to get signals about the quality of the article or even leave a note to the next editor. If you have more ideas of feedback, we're happy to hear it! Copying @Udehb-WMF here who could get you invited to future community calls, for example. SPerry-WMF (talk) 21:25, 13 August 2026 (UTC)
Thanks, that sounds great! My only concern is that having personal worklists for select people to help with might encourage the formation of cliques (which makes newbies' experiences worse, factional conflicts etc.), moreso than having 'public' worklists like in the proposal above or at a WikiProject would Kowal2701 (talk, contribs) 21:31, 13 August 2026 (UTC)
The idea behind personal worklists is that anyone can create one for themselves, and we actually hope that newcomers will so as well. In fact, I think this could be a great way to bring them back after they made some edits, because they have something tangible they can do next. You're making a good point about the formation of cliques and newcomers feeling left out though, and that's definitely something to keep in mind as we expand this concept further. SPerry-WMF (talk) 20:44, 21 August 2026 (UTC)
Sorry, but as WhatamIdoing said above, the "build it and they may not come" issue has to be resolved first. Unfortunately we do not have a "human magnet" to attract knowledgeable editors regardless of any additional infrastructure. C'est la vie. Yesterday, all my dreams... (talk) 08:51, 14 August 2026 (UTC)
@Yesterday, all my dreams... I have already stated how that could be resolved (at least partially). Remember, the Article board isn't a WikiProject. It is just a discussion page! It may have those that frequent it, or those that only use it occasionally. NewAccount7295 (talk) 15:37, 14 August 2026 (UTC)
I am aware that it is not proposed as a Wiki project. But in the end we are all only speculating about the level of participation. My prediction (and WhatamIdoing's) is different from what you predict. But we can not expect uniform predictions among all users. So only time will tell, given that as the man said: predictions are hard, specially about the future. Yesterday, all my dreams... (talk) 19:50, 14 August 2026 (UTC)
Are there any policies or guidelines for notice boards? I found Wikipedia:Noticeboards, which is an information page. It says noticeboards are not good places to recruit more editors to work with you. If you want to edit collaboratively, try posting a message at a relevant WP:WikiProject instead. This isn't binding and shouldn't be taken as me saying you can't do this, just sharing what I've found. —Myceteae🍄🟫 (talk) 22:16, 14 August 2026 (UTC)
These days it seems hard to find Wikipedia editors to collaborate on things. This is a problem, and it's a good thing to try to solve. I think the main problem is that there's two sorts of conversions that need to happen. First, you have to convert readers into editors, which is no small feat. Once those readers become editors by starting to copyedit or make small corrections on articles they come across, you then need to funnel those editors from the "front-end" of editing (simply making changes to articles) and into the "back-end" of editing (participating on discussion boards and talk pages, getting involved with wikiprojects, backlog drives, etc etc.)
I think that second step is Wikipedia's million-dollar question. How do you mobilise all the "casual editors" into a workforce capable of tackling larger projects in an organised manner? That, I think, is the bigger problem to try to solve, rather than creating new venues that all those "front-end" editors still won't see. Athanelar (talk) 08:42, 19 August 2026 (UTC)
I think the page could serve as a noticeboard for "You are invited to give your thoughts on X talk page" (what's the template for that anyway), rather than being the actual page of discussions. Also, as some have mentioned, the Articles for Improvement talk page could also act as the noticeboard for this. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 04:45, 6 September 2026 (UTC)
You're thinking of the {{Please see}} template I think. Thryduulf (talk) 09:02, 6 September 2026 (UTC)
@Altenmann I didn't say anything was wrong with AFI. This suggestion is for a different (even if similar) purpose, like a user can come on and talk about new articles they want to create and see if anyone is interested in collaborating on them. It is more of a discussion page and less of a process anyway. NewAccount7295 (talk) 02:17, 25 August 2026 (UTC)
Sounds a bit like Wikipedia:Requested articles, which is known to be inactive. We could do something similar through AFI like you suggested, but AFI itself isn't that active. Might change when TWAFI is added to the Main Page. NewAccount7295 (talk) 02:44, 25 August 2026 (UTC)
I am extremely pessimistic about an extremely unfocused board. Whoever likes to edit everything, they are already on New page Patrol. Whoever wants to stick to subject there are bots that report new pages on particular subject. Sometimes when I create a new article on a subject I think iportamt (rarely, I must admit:-), I (1) post notices in several Wikiprojects and (2) in talk pages of major articles related to the subject, and (3) wikilink aggressively. And almost NEVER have I any help. The most recent examples: I may understand why nobody cares aboutMa'aseh Buch, but I am sure everybody is an expert in "Gallicisms":-). --Altenmann>talk 02:40, 25 August 2026 (UTC)
I think the problem is right there in the proposal: the OP envisions it as a place where editors can find someone to help them. The problem is, there are no helpers sitting around and thinking "If only there were some place where I could help someone else with their interests and their articles, since I've got no interests of my own". Everyone already has a to-do list.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Another one of these non-constructive joke topics, closing this early. These are some pointers/explanations I hope the OP will read:
most of the time (TFA is) about some Australian military officer is wrong, according to the TFA requests page: The TFA section aims to highlight the range of articles that have "featured article" status ... and wherever possible it tries to avoid similar topics appearing too close together without good reason. Additionally see WhatamIdoing's comment at the bottom, and the queue for: Aug, Sept, Oct.
As what JacobTheRox said, WP:VOLUNTEER, all of us are using our own time to improve the encyclopaedia, without getting paid. Even I am spending the time to write up this explanation instead of simply adding the closed discussion templates. Any donations made, as Polygnotus notes, go to the Wikimedia Foundation for, among other things, server costs, and not editors. (This is why you don't see ads on Wikipedia.) Undisclosed paid editing is not allowed on Wikipedia anyway.
For discussions on changing how TFA works, try Wikipedia talk:Today's featured article. The village pumps are only when changes would apply to a broad set of articles, and that a singular talk page will not work.
Every day Wikipedia has a feature called ‘From today's featured article’, and most of the time it’s about some Australian military officer. Google AI tells me a dedicated bunch of Australian editors who are huge fans of their country’s military history have gamed your system so the whole English-speaking Wikipedia-using world gets these stupidass bios day after day. Nobody on Planet Earth cares about these people except that clique of without-a-life editors. And if it’s not another colonel it’s some antipodal jock, also of zero interest to anyone in the northern or western hemispheres, where the game he plays is unknown and utterly uncared-about. There is something wrong with a system that chooses these Aussie things day in and day out. I grant you it’s not the ebola virus or nuclear disaster or Donald Trump, but I go to Wikipedia every day so for me it is a big pain in the ass -- and I’m sure not just for me. And I hold up my end over here; I donate regularly because I believe in the mission and appreciate it a lot.
I also edit from time to time, but mostly just grammar and usage since I am quite old and don’t have much of a lifetime left to learn all the greater and lesser arcana of Wikipedia’s hopelessly complex (for me) structure, system and myriad editing rules. I don’t know my way around Wikipedia and have given up hope of ever learning it –it’s just too hard for me -- so I am all but sure I have sent this squawk to the wrong place. Please, whoever reads this, if anyone does, please be kind enough to send it on to where it needs to go if someone who might care wants to do anything about this ridiculous daily practice and can.
You can't reach me to acknowledge this because my email is currently messed up in a very complicated way, but NO, I don’t want to be part of a discussion – I don’t have time -- but I do want to register a complaint.
Thank you. ~2026-39362-93 (talk) 08:45, 21 August 2026 (UTC)
WP:VOLUNTEER – people write about what they're interested in. I myself, write a lot about the railways of the UK, which is interesting to a much smaller subset of the population than say, Taylor Swift. But that doesn't mean I want to write about Taylor Swift (nothing against her personally) and that doesn't make the editors who write about her any more useful or any better than me. You say you just want to complain and not discuss, but that's not really how Wikipedia works. You're arguing that today's featured article should be based on some arbritary measure of how relevant a topic is, which you don't suggest any options for, and thus the best course of action would be to go to the WP:IDEALAB and start by working that out. (in solidarity), JacobTheRox(talk|contributions) 12:13, 21 August 2026 (UTC)
Wikipedia:Today's featured article/requests explains the process of choosing the Today Featured Articles. You can also request Featured Articles for the TFA there. Variation in topics is a goal of the process. Rolluik (talk) 13:05, 21 August 2026 (UTC)
For as long as I've been an editor, the Military History Project had an ethos of getting articles up to the highest standards ("deep" rather than "wide"). This has resulted in a disproportionate number of Featured Articles created by the project. Australians are over-represented and Americans unrepresented on Wikipedia relative to their populations, although both are minorities in the global English-speaking world. Hawkeye7(discuss) 22:59, 21 August 2026 (UTC)
@~2026-39362-93 Please stop donating. You are not donating to us, you are donating to the WMF, an organisation with more money than you could ever dream of. See WP:CANCER. Polygnotus (talk) 00:18, 22 August 2026 (UTC)
I actually think there is a reasonable complaint here. Unfortunately, there is no easy solution. Today's featured article relies on having featured articles in a particular topic area and someone making a good nomination. We should be aware of gaps, biases, imbalances, over/underrepresentation, etc. and we should try to address it but ultimately this all depends on editors working in different areas to generate featured articles and nominations. —Myceteae🍄🟫 (talk) 01:34, 22 August 2026 (UTC)
I vaguely remember we had exactly same problem with Gibraltar-related articles popping up every day in WP:DYK. But I do nor remember how it was resolved. --Altenmann>talk 02:53, 25 August 2026 (UTC)
They were limited to one a day. See more at Wikipedia talk:Did you know/Gibraltar-related DYKs. I believe that project eventually came to a natural end. However, the issue faced by TFA is different in that it is about drawing from a limited pool. See Wikipedia:Featured articles that haven't been on the Main Page, where the Warfare category has the largest number of entries, with runners-up Music and Sport and recreation. If TFA ever does a streak of the Gillingham F.C. season articles then we're in for some real repetition. CMD (talk) 03:44, 25 August 2026 (UTC)
The Gibraltar thing was caused by an editing contest. FA isn't affected by those (for better or for worse). WhatamIdoing (talk) 18:26, 1 September 2026 (UTC)
Here's the problem I have with this complaint. On August 21st, the OP complains that "most of the time it’s about some Australian military officer". But the preceding FAs were:
August 14th: The European rabbit (Oryctolagus cuniculus) is a species of rabbit native to the Iberian Peninsula and southwestern France.
The number of Australian officers in the previous week was exactly one (1). Looking through Wikipedia:Today's featured article/2026, it looks to me like there have been only three Australian military people this entire year. That's a lot less than "most of the time".
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.
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)
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>talk 19:05, 24 August 2026 (UTC)
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)
Support footnote. Some texts are waaaay to long for a hatnote. --Altenmann>talk 19:47, 24 August 2026 (UTC)
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.
That's not crazy long. Joe vom Titan (talk) 20:09, 24 August 2026 (UTC)
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>talk 20:18, 24 August 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
@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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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. BD2412T 20:39, 29 August 2026 (UTC)
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)
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)
The issue is not limited to mathematics articles. A recent edit linking machine to machine when the process was manually carrying a tray of cards from one machine to another. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:31, 31 August 2026 (UTC)
If there's a template on most of these articles, Template:No newcomer task could be added to the template, and thus propagate to all the articles transcluding it. WhatamIdoing (talk) 18:43, 1 September 2026 (UTC)
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)
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)
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)
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.
That's entirely unrelated to the topic of machine-generated changes. –jacobolus(t) 20:02, 1 September 2026 (UTC)
(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)
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)
@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)
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)
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)
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?
Or is the problem really just that newbies are making edits that light up your watchlist, and you wish they'd leave "your" articles alone? WhatamIdoing (talk) 00:59, 2 September 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
Good, you have just described the first steps in a machine learning approach to doing it. Yesterday, all my dreams... (talk) 20:44, 1 September 2026 (UTC)
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)
@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)
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)
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)
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)
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)
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)
Okay, so there were about 2000 edits. Can you go check them? It sounds like there are potentially another hundreds of errors there. –jacobolus(t) 05:21, 2 September 2026 (UTC)
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)
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)
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)
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)
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)
Your argument is built on the unproven claim that I'm wrong about those links. WhatamIdoing (talk) 03:13, 5 September 2026 (UTC)
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)
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)
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)
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)
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)
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)
I didn't realize "No newcomer task" was a thing. Should we just blanket add that to all technical articles? –jacobolus(t) 22:13, 1 September 2026 (UTC)
I mentioned it above. I don't think that blanket application to hundreds of thousands of articles is a good idea. WhatamIdoing (talk) 00:27, 2 September 2026 (UTC)
A simple bot could do it, but would require an Act of Congress, so to speak. Yesterday, all my dreams... (talk) 04:54, 2 September 2026 (UTC)
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)
Make inline dispute tags more visually prominent and machine-readable in page output
This LLM-generated text has been collapsed and should be excluded from assessments of consensus.Further, it's too bad your AI didn't tell you that what you had it propose already exists as an option. Anomie⚔ 11:54, 1 September 2026 (UTC)
The following discussion has been closed. Please do not modify it.
Problem
When a specific sentence or clause carries an inline dispute template — {{Disputed inline}}, {{Dubious}}, {{Contentious label}}, {{NPOV inline}} — the marker is typically a small superscript link, while the disputed text itself renders as ordinary prose. In lead sections of contested articles the visual weight is heavily asymmetric: the claim reads as settled, and the fact that it is under active challenge is easy to miss entirely.
Two examples, deliberately chosen from opposite ends of the political-temperature scale:
Priority claims in the history of technology.Claims to the first airplane flight opens by stating that the Wright brothers were first to achieve sustained, controlled, powered heavier-than-air manned flight, then notes that several other aviators have claimed priority and that much controversy surrounds those claims. The dispute is institutional rather than fringe — Brazil teaches Alberto Santos-Dumont as the inventor of the airplane, and in 2013 the Connecticut legislature passed a bill naming Gustave Whitehead as first to fly — and the article itself quotes Charles Gibbs-Smith conceding that the criteria for powered flight remain to some extent a matter of opinion. The contest is definitional, not evidentiary. Yet the opening clause reads as a plain fact, and that is the clause that travels.
Contested characterizations in politics and history.Zionism carries inline dispute markers on statements in its lead. The markers are present and correctly placed; they are simply far quieter than the sentences they qualify, and a reader skimming the first paragraph will absorb the characterization without registering that it is under active discussion.
The point of pairing these is that the failure mode is structural, not ideological. It shows up identically in an aviation article nobody edit-wars over and in one of the most heavily watched pages on the project. Fixing it does not require anyone to agree about Zionism, or about the Wright brothers.
Downstream
The same asymmetry propagates. Wikipedia content is consumed at scale by search engines, scrapers, dataset builders, and LLM training and retrieval pipelines. Parsoid output does wrap transclusions in typeof="mw:Transclusion" with data-mw, so the template is technically recoverable — but there is no stable, documented signal saying "this specific span of text is disputed," and nothing in that shape surfaces through the action API or in wikitext-derived datasets.
The observable result is that mirrors and knowledge-graph sites routinely reproduce our lead sentences verbatim while dropping every qualifier around them. Ask a search engine or an assistant who invented the airplane and you will get an unhedged answer, sourced substantially from us, with the controversy we documented stripped out. Our own editorial judgment is discarded silently, and we have no mechanism to notice.
Proposal
Treat inline dispute templates as first-class semantic annotations on a text span, rather than as a footnote-style link appended after it. Concretely:
Extend the inline dispute templates to accept the disputed text as a parameter, so the marked span is explicit rather than implied by placement.
Give the disputed span a defined, documented CSS class and a machine-readable attribute in Parsoid HTML identifying it as disputed, along with the dispute type and a link to the relevant talk-page section.
Strengthen the default visual treatment (something more legible than a superscript, but restrained enough for lead sections), with the distinction not conveyed by color or icon alone, per WP:ACCESS.
Expose the same information through the REST/HTML output so downstream consumers can distinguish disputed spans from uncontested article text without parsing templates themselves.
Scope
This does not propose that Wikipedia adjudicate disputes, change due weight, or grant fringe positions parity. It changes nothing about what we say — only how clearly we mark what we have already decided is contested. It is a presentation and metadata change downstream of existing WP:NPOV and WP:V practice.
Sensible defaults matter: the treatment should be prominent enough to be noticed and quiet enough that it does not become a weapon in content disputes or clutter articles carrying many tags. Category:All accuracy disputes currently holds roughly 15,800 pages, so whatever we choose has to degrade gracefully at scale.
Offer
I am a software developer and would like to do the work rather than just file the idea. I am willing to write the requirements, implement the template and Parsoid/output changes, submit patches, respond to code review, and see an approved implementation through. If engineering resources are the constraint, I am also willing to help pursue funding.
Questions
Is VPPR the right venue for the community half of this, with a Phabricator task for the technical half — or should this start at WP:VPT or as a MediaWiki RFC?
Has something along these lines been proposed and declined before? I checked WP:PEREN and did not find it, but I may have missed prior discussion.
Which stakeholders should be looped in — the maintainers of the dispute templates, the Parsoid/Content Transform team, or others?
AmitaiErfanian (talk) 02:32, 1 September 2026 (UTC)
Aside from the obvious LLM concerns, there already exist a family of templates which (if I'm understanding correctly) do what AmitaiErfanian is suggesting: e.g. {{citation needed span}}, {{dubious span}} et al. Maybe we should do more to encourage the use of those templates where appropriate (currently the non-span versions are enormously more popular) but the issue isn't that it isn't possible to do this. Caeciliusinhorto-public (talk) 11:21, 1 September 2026 (UTC)
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)
Current labelDefault label
Survey (button name)
Yes. And other language Wikis usually say discussion, eg Italian, French etc. Yesterday, all my dreams... (talk) 16:07, 3 September 2026 (UTC)
Yes because:
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.
I have already seen these reasons, no need to ping in an edit summary please. --ABx11 (she/they) 00:44, 4 September 2026 (UTC)
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)
@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)
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)
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)
You know, having learned to dabble (a tiny bit) in the site API... I bet you USD $1 that list of 6000 is bigger. — Very Polite Person (talk/contribs) 14:52, 5 September 2026 (UTC)
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)
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)
No per ... Very Polite Person below.
I'm confused. Very Polite Person has always supported this proposal from the start, saying it's a very good idea. You're the first person to oppose. FaviFake (talk) 22:59, 3 September 2026 (UTC)
That's because I misattributed a comment, my opposition is per Anomie not VPP (my apologies to both). Thryduulf (talk) 23:05, 3 September 2026 (UTC)
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)
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)
If all the other equivalent encyclopedias apparently use their native tongue "Discuss", why wouldn't we want to be doing it how the others are? — Very Polite Person (talk/contribs) 00:18, 4 September 2026 (UTC)
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)
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)
True, and it's the latter, no idea if there's a way to request data collection via survey (there should be) Kowal2701 (talk, contribs) 02:42, 4 September 2026 (UTC)
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)
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)
(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)
No per Maddy from Celeste BilledMammal (talk) 00:19, 4 September 2026 (UTC)
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)
Furthermore, Talk and Discuss are synonyms, so I'm not seeing the tangible benefit. --ABx11 (she/they) 00:44, 4 September 2026 (UTC)
No Way, way too many references to "the talk page" litter the database and help guides. This would make "the talk page" harder to find and I don't see the value. * Pppery *it has begun... 03:11, 4 September 2026 (UTC)
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)
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)
(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)
Yes "Discussion" is a noun, while "talk" is a verb. Velocifyer (talk) 17:27, 4 September 2026 (UTC)
From the Merriam Webster dictionary: "Talk: noun ... 4: a formal discussion, negotiation, or exchange of views —often plural" - Donald Albury 19:02, 4 September 2026 (UTC)
They probably meant to say that "Talk!" can also be interpreted as a verb while "Discussion" can only be interpreted as a noun. FaviFake (talk) 19:40, 4 September 2026 (UTC)
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)
No I do not see a net positive from making the change. - Donald Albury 23:23, 4 September 2026 (UTC)
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)
No per Thryduulf. —Kusma (talk) 20:49, 5 September 2026 (UTC)
Discussion (button name)
Presumably, "Talk:Foo" would automatically be created (or maintained) as a redirect to a given "Discussion:Foo"? BD2412T 16:53, 3 September 2026 (UTC)
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)
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"...
...and that's it? If so can you make the RFC a teeny bit clearer that it's a MUCH smaller but impactful change, and as editors there is no actual impact? — Very Polite Person (talk/contribs) 22:40, 3 September 2026 (UTC)
Yes, exactly!Done, and i also added a side-by-side image comparison for clarity FaviFake (talk) 22:52, 3 September 2026 (UTC)
Why change just the label and not also the namespace? Levivich (talk) 23:07, 3 September 2026 (UTC)
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)
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)
Oh, this is the talk page? I wanted the discussion page. I must have clicked the wrong thing. ~2026-47946-04 (talk) 07:21, 4 September 2026 (UTC)
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)
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)
You know what, I take back what I said. I would not be opposed to adding "page". Axolitl(talk|contribs) 20:37, 5 September 2026 (UTC)
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)
This is a good idea, and will avoid rewritting years of documentation calling it the “talk page”. Velocifyer (talk) 19:15, 5 September 2026 (UTC)
With the exception of the first, the labels are supposed to be verbs. It's an article: talk about it, edit it, view its history, etc. WhatamIdoing (talk) 20:39, 5 September 2026 (UTC)
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)
Language barrier possibly, “talk” is a more recognizable word than “discussion” and it’s also an imperative verb
to be clear I don’t expect this to have an earth shattering effect but literally any tiny improvement would help Gnomingstuff (talk) 23:40, 3 September 2026 (UTC)
Would be curious though to hear whether other wikis have this problem to the same extent (proportionate to their size obviously) Gnomingstuff (talk) 23:41, 3 September 2026 (UTC)
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)
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)
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)
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)
This sounds like something that could genuinely, and without significant collateral, be A/B tested. CMD (talk) 03:04, 4 September 2026 (UTC)
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)
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)
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)
Wait, who added this RfC? The signature appears malformed. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 08:12, 5 September 2026 (UTC)
It's normal to end the statement of the RfC question with just a timestamp, since it isn't supposed to express anyone's opinion. ;; Maddy from Celeste (WAVEDASH) 08:16, 5 September 2026 (UTC)
I see. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 08:21, 5 September 2026 (UTC)
This is officially permitted. About 10% of RFCs use that style. A lot of editors never even notice. WhatamIdoing (talk) 20:44, 5 September 2026 (UTC)
After initiating discussion at VPT and then being told to obtain consensus to add gadgets, I'm now suggesting here a local gadget that should reduce Large thumbnail size to just max-width. This is a response to the declined task I'm showing you now. Well, I'm more worried about not just potential copyright infringement (despite reassurances in contrast) but also poor execution of the Large thumbnail size. If the gadget were to be created, the gadget should be enabled by default. Well, a gadget like this is limited to registered users, but this should be the first step before proposing some sort of coding for especially logged-out users (i.e. TAs) to see. George Ho (talk) 16:39, 4 September 2026 (UTC)
Could you explain your proposal in layperson terms? What's the status quo and what would your gadget change? FaviFake (talk) 08:39, 5 September 2026 (UTC)
The proposal should be more visually comforting to registered users setting the thumbnail size preference to "Large" option. Indeed, the Large option currently enlarges smaller images, especially non-free (i.e. fair use) ones. The Phabricator task on this issue was, unfortunately, declined because they seemed unwilling to complicate the coding that was merged with some newer coding system called "Parsoid".
Status quo? Since the task was declined, the Large option as-is still enlarges smaller files, i.e. goes beyond images' max size.
The gadget should be indefinite until Phabricator people decide to reopen the task and then work on the issue with the Large thumbnail option. In other words, I can't guarantee that the gadget 100% changes things as, per usual, logged-out users don't have a choice to enable gadgets.
Hopefully, a layperson can understand this reply, right? George Ho (talk) 09:12, 5 September 2026 (UTC)
So basically:
Currently, users who set their thumbnail size preference to "Large" are shown raster images larger than their actual size.
Your gadget would force these images to display at their actual maximum size.
Your gadget would force these images to display at their actual maximum size.
Not exactly. The Regular and Small options should display sizes smaller than maximum size and/or Large option. The gadget may still shrink any option to smaller (but still maximum) size if smaller than Regular and/or Small. It should not enlarge an image smaller than any given thumbnail option. George Ho (talk) 10:45, 5 September 2026 (UTC)
Yeah that makes sense, thanks. FaviFake (talk) 10:49, 5 September 2026 (UTC)
I'm still confused here. It seems intuitive to me that all thumbnail should be displayed at the smaller of preference size and image size, regardless of what the preference size is (i.e. images should never be displayed larger than they actually are). Is this what your gadget will do? Thryduulf (talk) 11:06, 5 September 2026 (UTC)
That is what is being described. It's not a huge issue given it applies only to registered users with specific settings, but I support it in the sense that it should be the default (intuitive as you say). Hadn't seen the developments since Phab:T421524 was unfortunately declined, glad someone has it in hand as the WMF have abandoned it. CMD (talk) 11:21, 5 September 2026 (UTC)
As said by ChipmunkDavis, that's what the proposed gadget intends to do. Too bad the Phab devs abandoned the task. George Ho (talk) 17:43, 5 September 2026 (UTC)
Idea lab
Replace fundraising banners with 'we need more editors' appeal
Let's ignore your comments about the WMF's Reserve (accounting), as it's both misleading and irrelevant. $300M as the economy teeters on the brink of a recession is how much actual experts recommend the WMF to have in their operating reserves.
Let's instead talk about getting more editors. I'm in favor of the goal. I've got some suggestions about the order in which we do things.
If we wanted to make a difference in this area, the research-backed approach might be an education campaign aimed at highly active editors. Specifically, we know that editor retention is improved when patrollers and other editors follow the rule to Wikipedia:Revert only when necessary, and whenever possible to build on an imperfect contribution (e.g., replacing their bad source with a good one, removing only part of an addition while keeping some visible fraction of it, adding a clearer explanation, etc.).
There's not much point in recruiting new editors if we're going to run them right back off again by reverting their attempts to contribute.
Therefore, I suggest that we first look at ways to improve retention of newcomers. After we think we can retain a decent fraction of the newbies, we can look into trying to get more newbies. WhatamIdoing (talk) 21:05, 3 August 2026 (UTC)
The active editor graph suggest that it's stable over 10 years, while the new editor graphs is going down. Of course I agree that we need to be more friendly, but I don't think most of Wikipedia are so bad that it scares newbies off. Most newbie contributions are not reverted. Anyways I might be overly thinking about a Signpost article that suggests that the number of new users is decreasing (admitedly not by a lot annually), although that might not be a huge deal. Alpha Beta Delta Lambda (talk) 21:27, 3 August 2026 (UTC)
I think it's a big problem, and I agree with the goal. I think that we need more than a banner to solve the problem. WhatamIdoing (talk) 21:36, 3 August 2026 (UTC)
This is of course a big problem, but I think we might be trying to find the perfect solution. It might not make a huge difference, but it'll still (hopefully) make a positive difference. Alpha Beta Delta Lambda (talk) 21:54, 3 August 2026 (UTC)
WhatamIdoing, as always graphs need context. Please also show a graph of the number of articles. Let me put it this way, if the number of doctors in a country remains stable, but the population goes up five fold, quality of care will go which way? That is the issue. Yesterday, all my dreams... (talk) 12:03, 4 August 2026 (UTC)
Our editors-per-article ratio has been declining at the same time that our article quality has been improving. Doctors-per-capita is at best an imperfect analogy. WhatamIdoing (talk) 20:24, 4 August 2026 (UTC)
Do you have a graph of editors per article ratio? Is it scary? Yesterday, all my dreams... (talk) 20:37, 4 August 2026 (UTC)
I don't think it's scary, but it is 8 or 9 times as many articles per editor as it was back in the day. WhatamIdoing (talk) 20:18, 16 August 2026 (UTC)
This was discussed before: the pro-fringe editors were banned, or left Wikipedia voluntarily. Mind you, not everybody having fringe beliefs ceased editing, many of them understood that Wikipedia isn't for ventilating their own opinions, so they don't create problems. And, yup, it's hard to hold mainstream views upon every topic. tgeorgescu (talk) 02:17, 30 August 2026 (UTC)
Honestly, I don't think the declining number of editors is a big deal. You'd expect to see numbers declining since the low-hanging fruit of article drafting has been harvested aggressively, and wide swathes of the encyclopedia's articles on topics that fundamentally aren't changing are in a pseudo-maintenance mode at this point. CoffeeCrumbs (talk) 01:08, 9 August 2026 (UTC)
On the other hand, I have a long list of articles I want to write, more than I will get to in the time I have left, I am regularly returning to articles I worked on in the past to add to them (I just enlarged a B-class article by 25% in the last 3 days), and most articles in Wikipedia are still far too short. Half-a-dozen new regular editors in the areas I work in would help. Donald Albury 01:23, 9 August 2026 (UTC)
Yes, but... As I said below, it is not just "writing" but updating. Some articles have had no meaningful updates for 15 years. That requires knowledgeable editors. Alas I have no idea how to get them. Yesterday, all my dreams... (talk) 03:48, 9 August 2026 (UTC)
How, indeed, to recruit new editors who are at least as interested in updating and expanding existing articles as they are in creating new articles? I see new editors that seem interested in working on existing articles in areas I work on, but most do not stay around for very long. So retention is also a problem. I have not been interested in mentoring, and was disappointed by the lack of response from student editors when I worked with the education program more than a decade ago. So I don't have an answer, either. Donald Albury 13:35, 9 August 2026 (UTC)
We are in agreement. I keep looking at the activities of editors, like this. He knew the subject, then just evaporated away. Some of his speculations persisted for long. Also this user. They come and go and because we have so many articles no one has time to check or update what they have done, and material gets outdated year after year. Yesterday, all my dreams... (talk) 17:49, 9 August 2026 (UTC)
I would love it if we could do both. This ought to be tested if it hasn't been already Kowal2701 (talk, contribs) 21:46, 3 August 2026 (UTC)
Yeah, I'm not sure why do I think it has to be one of the other, of course it can be both "please donate" and "please edit". Alpha Beta Delta Lambda (talk) 21:54, 3 August 2026 (UTC)
Can suggest it at the WP:FUNHUB btw, though tbh I'd like to see testing of it on its own as well Kowal2701 (talk, contribs) 22:44, 3 August 2026 (UTC)
This isn't a criticism of your suggestion, there's nothing wrong with it; that being said there's currently an elephant in the room that the WMF unionizing conflict is getting worse, and depending on how that goes it might affect what is done with donation banners. Gnomingstuff (talk) 06:50, 4 August 2026 (UTC)
I guess this idea could also be a replacement of the fundraising banner. Alpha Beta Delta Lambda (talk) 09:55, 4 August 2026 (UTC)
(A bit off-topic, I'm sorry.) I think much more is needed than a banner. When I joined, nineteen years ago, so many editors were encouraging: "Be bold! Make an edit!" I rarely read this any more. Lova Falk (talk) 10:12, 4 August 2026 (UTC)
I absolutely agree, this is a big issue. Perhaps we can throw that phrase more. The idea though is that the banner would encourage readers to make an edit or ten. Alpha Beta Delta Lambda (talk) 10:29, 4 August 2026 (UTC)
It's not just the words. We need to back up the words with action, or people will feel like we lied to them. WhatamIdoing (talk) 20:25, 4 August 2026 (UTC)
Of course, but I'm not sure we're breaking a promise. Wikipedia promises to be "the free encyclopedia that anyone can edit", and as far as I can tell we aren't lying about that. If you meant that we semi-constantly revert their edits, I'm not sure what could be done other than to remind experienced editors to revert only when necessary. Alpha Beta Delta Lambda (talk) 21:00, 4 August 2026 (UTC)
I've previously written about English Wikipedia's structural issues that make it unattractive to many co-operative editors. They essentially make content-dispute resolution ineffective and provide incentive for poor behaviour. Any edit one makes, no matter how small, has a sword of Damocles hanging over it: another editor can vociferoously object, and one has to decide if it's worth getting into a discussion about it or not. Either way the outcome is often poor: one can just move on, with a constant irritant that aggressive behaviour typically wins out, or one can end up spending an unbounded amount of time trying to find common ground with an editor not interested in co-operating. Even if most interactions aren't like this, just a few can suck all the joy out of editing. For better or worse, though, the portion of the community that likes to discuss these matters generally places a higher priority on the ability for everyone to weigh in, which is enabled by the current decision-making traditions. isaacl (talk) 22:29, 4 August 2026 (UTC)
Isn't co-operation required? If one consistently can't co-operate isn't that blockable? Alpha Beta Delta Lambda (talk) 10:21, 5 August 2026 (UTC)
By English Wikipedia's decision-making traditions, in the absence of clear disruption, whether or not one is being co-operative or just engaging in vigourous discussion is decided upon by a consensus-based discussion. So every disagreement requires a weighing of options: is the worth the effort to build a consensus for one's point of view? Since discussion participants are self-selected amongst those who happen upon the discussion, the outcomes are frequently uncertain. It's a constant drag on enthusiasm that can wear editors out. isaacl (talk) 16:54, 5 August 2026 (UTC)
@Isaacl There's no way to ask this question without sounding a little rude, but, given that we're talking about editor retention: you've been around since 2006. In that time, you've made (according to xtools) around 16% of your edits to mainspace -- and over 60% to Wikipedia project namespaces. Is that idea that Any edit one makes, no matter how small, has a sword of Damocles hanging over it because somebody might object to it what keeps you from editing more of the encyclopedia?GreenLipstickLesbian💌🧸 04:04, 15 August 2026 (UTC)
Yes, as I've discussed in various places, I'm essentially an unretained editor. I've documented reasons on the editor retention page, and as I mentioned, discussed many of English Wikipedia's structural issues on my community page. isaacl (talk) 06:46, 15 August 2026 (UTC)
Is it accurate to call yourself an unretained editor, though? You're very active (especially in high-drama areas), you're one of the few people on the planet who knows what ARBCOM is and participate regularly, I see you frequently in these BTS discussions. Can "unretained" ever be an accurate description of anybody with north of 20,000 edits to a website over 20 years? GreenLipstickLesbian💌🧸 08:26, 28 August 2026 (UTC)
Only in theory. In practice, especially if you edit in more contentious or POV-influenced areas, there are so many ways around this you eventually give up and move on. Intothatdarkness 18:00, 24 August 2026 (UTC)
That describes my experience well. I’ve completely given up on editing articles, because the community is so toxic. Mevsherd (talk) 06:00, 23 August 2026 (UTC)
I think that we need to do a better job welcoming editors. For example, I never got properly welcomed to wikipedia, which discouraged me from editing. Velocifyer (talk) 17:47, 13 August 2026 (UTC)
There are two issues here. One is that we need more editors, and a banner may be a good way to help with that. The other is that aggressive fundraising is not universally popular with readers or editors. Those two points are almost orthogonal, the overlap being that they might compete for the same screen space. The current reaction to union developments may be relevant here. Although I don't think it's being proposed, one way to deliver a message to the WMF would be to interfere with fundraising banners, leaving a free slot which could be used to recruit editors. Certes (talk) 11:14, 4 August 2026 (UTC)
My unhelpful comment on the subject is that we generally need better editors, not more editors. Of course, since I don't know a way to get better editors that's hardly actionable. Except of course by getting more editors and hoping that the better ones remain. (Certainly, regular Wikipedia users are typically pretty good!) Dingolover6969 (talk) 19:57, 4 August 2026 (UTC)
I've given up on trying to get "better" editors, because trying to find "the one" in 100,000 is needle-in-haystack region for me. WhatamIdoing (talk) 20:26, 4 August 2026 (UTC)
I would say we need "knowledgeable" editors. Please consider the talk page Talk:Reason maintenance. The last discussion was 15 years ago before I commented today. The last meaningful edit to the article was also 15 years ago by an editor who left long ago. Many articles are way out of date and not enough editors who understand the subject well enough to do anything. Yesterday, all my dreams... (talk) 09:21, 8 August 2026 (UTC)
YES, this would show that the problem is taken seriously.
The proposal is somewhat extreme, we could also consider hybrid approaches, in the spirit of "contribute to Wikipedia with your time or your money". Alaexis¿question? 15:01, 2 September 2026 (UTC)
I think periodically using a banner to encourage users of the site to become editors would be an excellent idea. This need not preclude the continued use of banners to solicit donations to the Foundation, although we ought to avoid having too many banners too much of the time. Dionysodorus (talk) 16:33, 3 September 2026 (UTC)
I'm pretty sure that the end result was some new accounts, a smaller number of of edits (most donors were confused about what to do after creating an account; we had very limited onboarding tools back then), and a bunch of complaints from English Wikipedians. WhatamIdoing (talk) 02:32, 4 September 2026 (UTC)
Replace the hyphen in html titles with an en dash
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.
The reason I brought this here rather than /PR is that I have no idea if or how this could be changed. (please mention me on reply) (in solidarity), JacobTheRox(talk|contributions) 16:15, 17 August 2026 (UTC)
Yes, it can be changed. No, it's not difficult to change. Either we would need one of the Wikipedia:Interface administrators to do it, or we would need a config change request. Someone at Wikipedia:Village pump (technical) you which one. Jon (WMF) could probably tell us whether there is an important reason for using a hyphen-minus instead of a spaced en dash in that place. WhatamIdoing (talk) 19:01, 17 August 2026 (UTC)
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)
Any admin can edit MediaWiki:Pagetitle, doesn't have to be an iadmin. A developer would only be needed if we think the default (for all MediaWiki sites everywhere) should be changed. Anomie⚔ 22:39, 17 August 2026 (UTC)
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)
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)
@JacobTheRox: Would this be done with a raw UTF-8 character or a HTML Escape code? A escape code would prevent mojibake. Velocifyer (talk) 17:06, 3 September 2026 (UTC)
You're right, I didn't think of that. I still see very little incentive to make this change besides personal preference. SuperPianoMan9167 (talk) 17:37, 3 September 2026 (UTC)
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)
Most of the time the separator isn't actually visible to readers as it gets cut off by the limited horizontal space for the tab title. SuperPianoMan9167 (talk) 20:46, 3 September 2026 (UTC)
Also, how is a dash more correct here? The traditional separators for HTML titles are hyphens and pipes. SuperPianoMan9167 (talk) 20:48, 3 September 2026 (UTC)
It's "more correct" in the sense that if it were being laid out for printing on paper, then a good typesetter wouldn't use a Hyphen-minus there. WhatamIdoing (talk) 02:16, 4 September 2026 (UTC)
What about another character, like a pipe? Does that have the technical issues an en dash has? It would avoid going against the MoS. Ham II (talk) 08:26, 26 August 2026 (UTC)
The pipe character is in ASCII, so it would avoid any potential technical issues that an en dash might have. SuperPianoMan9167 (talk) 13:55, 26 August 2026 (UTC)
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.
What would the benefit be? I really can't think of any. RoySmith(talk) 19:58, 2 September 2026 (UTC)
Are you saying that software could parse <title> and strip " - Wikipedia" rather than <h1> which is how the title is stored? (in solidarity), JacobTheRox(talk|contributions) 17:56, 3 September 2026 (UTC)
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)
In my experience, Wikipedia's standards are poorly understood and poorly followed. For example, it is the norm for articles to contain opinions stated as fact, because some "reliable source" can be found expressing those opinions. What's especially concerning is that experienced editors, administrators, and so on, will routinely demonstrate poor understanding of (or caring about) Wikipedia's principles, such as the differences between "reliable source" applied to opinions, facts, publishers, authors, and so on.
Part of the culprit is Wikipedia's bloated and long-winded "explanations" of these principles. Typically, when trying to figure out some policy, I wade through interminable explanations, essays, and contradictory information. In many cases, a simple series of checkboxes or a flowchart would suffice, and be much clearer, cleaner and generally comprehensible. What makes the the whole experience really frustrating is that there is no expertise or authority in the implementation of the standards. Everything is just a vote, yet the function of standards and policies to rise above popularity contests. Administrators do not enforce standards, and the vaguely defined "consensus" cannot enforce them when it's grasp of the concepts is poor, or when there is political/religious bias, as there often is.
I think Wikipedia is stale and basically dead, and in order to improve it needs to be a source of education for its editors on certain rudimentary philosophical concepts. For example, the difference between factual claims and interpretations. It does no good to have a few thousand words of essays and elucidations on "Wikivoice" and "NPOV" and "RS" if editors don't understand what makes a claim subjective or objective. Mevsherd (talk) 16:10, 19 August 2026 (UTC)
If you feel an experienced editor is wrong on what a reliable source is, that's a matter to take up with them, and failing that, the community. We're only as good as those who participate. Yes, admins do not enforce standards because admins have no more authority than anyone else on matters of content. If editors are disruptively ignoring standards, though, that's a matter for admin intervention to prevent disruption(not enforce standards).
A "poor" grasp of policy is often subjective, as different people can disagree about a policy in good faith.
Is there a particular matter that has prompted this grievance? If consensus is "vague", clarification should be sought. 331dot (talk) 16:37, 19 August 2026 (UTC)
But, I didn't say this: "If you feel an experienced editor is wrong on what a reliable source is," That misrepresentation kinda proves the point. This strikes me questionable: "Yes, admins do not enforce standards because admins have no more authority than anyone else on matters of content." Shouldn't it be: nobody has more authority than anybody else on standards-compliant content? And, actually it is contradicted by Wikipedia's non-conventional definition of "consensus" as not, actually, meaning consensus. For example. "Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes." That's simply not what "consensus" means, and just lets the community delude itself with some narrative that it decides things by consensus but not really. Who, exactly, is doing this "gauging based on the merits," if not an admin, hm? Mevsherd (talk) 18:58, 19 August 2026 (UTC)
It sounds to me like you want to change Wikipedia to accommodate and lock in your views; the antithesis of a collaborative project. 331dot (talk) 19:10, 19 August 2026 (UTC)
Can you answer the question: Who, exactly, is doing this "gauging based on the merits," if not an admin? Mevsherd (talk) 19:41, 19 August 2026 (UTC)
This is a collaborative, volunteer project. The answer is, anyone who wishes to in collaboration with anyone else who wishes to. If that's not your cup of tea, that's fine, you're not a bad person- then you should go somewhere that is more compatible with your vision of what an encyclopedia project should be. 331dot (talk) 19:49, 19 August 2026 (UTC)
Anyone who thinks they are up to the task, see Wikipedia:Closing discussions. Certain types of discussions do need an admin to close, for example deletion discussions because only admins can delete pages, and ban discussions because only admins can ban the scoundrel. It ties into what I wrote below: it's all about integrating into the community and acquiring WP:CLUE. If you don't have enough clue, you will make a bad closure, people will yell at you and it will be reversed. If you are clueful and make a good closure, that won't happen. --Maddy from Celeste (WAVEDASH) 19:49, 19 August 2026 (UTC)
Maybe it's the matter on your user talk page? It sounds like you want some appointed board of some kind to enforce standards. That would present myriad issues. 331dot (talk) 16:40, 19 August 2026 (UTC)
I think Wikipedia is stale and basically dead, and in order to improve it needs to be a source of education for its editors on certain rudimentary philosophical concepts. For example, the difference between factual claims and interpretations. It does no good to have a few thousand words of essays and elucidations on "Wikivoice" and "NPOV" and "RS" if editors don't understand what makes a claim subjective or objective.
Or perhaps some editors just take a different philosophical position on those questions? Who says Wikipedia has to adopt a realist epistemology? Social constructionism, for example... --Maddy from Celeste (WAVEDASH) 16:44, 19 August 2026 (UTC)
As an example, I tend to take the philosophical position that anyone complaining that Wikipedia's standards are either too soft or too rigourous has never actually been "in the weeds" actually debating anything and thus does not appreciate just how Wikipedia's policies and guidelines work in practice. —Jéské Courianov^_^vLook outit's Jimothy! 16:58, 19 August 2026 (UTC)
Polemical Section Titles Are Pathetic. signed, Rosguilltalk 17:00, 19 August 2026 (UTC)
If the philosophical points don't have a clear meaning, then they shouldn't be standards. If Wikipedia's actually position is that there is no enforceable difference between opinion and fact, then it should not have policies stating otherwise. And, if it is going to have policies distinguishing fact from opinion, e.g. what can be stated in "wikivoice,", then it should take on, as a serious endeavor, the education and training of editors to make the distinction. Mevsherd (talk) 19:06, 19 August 2026 (UTC)
Who would create and operate an apparatus to train editors? If training was required to edit Wikipedia, very few people would participate. Perhaps that's what you want? There are other encyclopedia writing projects that limit participation to experts or other designated people. 331dot (talk) 19:12, 19 August 2026 (UTC)
The training is editing articles, reading policies, guidelines and essays, lurking in discussions, participating in discussions, and so on, i. e. becoming part of the community and learning its norms and practices. Reverting an experienced editor giving you advice, calling it a "pompous lecture" is not that. --Maddy from Celeste (WAVEDASH) 19:26, 19 August 2026 (UTC)
A few observations: 1) The editor has a template stating they've been editing for almost 20 years. 2) The statement they want to add is a subjective opinion. 3) They are attempting to add it in "wiki voice", i.e. as a statement of fact. 4) Their attempted compromise was to add a "citation needed" tag. 5) The edit explanation is that few people would disagree with it.
So, someone who has been editing for 20 years should know the difference between an opinion and a factual claim, should know that citations, even when provided, do not change opinions into facts, and few people disagreeing with an opinion (e.g. Taylor Swift is cuter than Kierkegaarde) also does not change the opinion into a fact. This kind of thing is totally mundane and rampant, even among 20+year admins who have been on Arbcom. That's pathetic. Mevsherd (talk) 19:26, 19 August 2026 (UTC)
So- if you disagree with that edit, you're free to use the appropriate channels to address it. That's exactly what is supposed to happen. 331dot (talk) 19:50, 19 August 2026 (UTC)
You're really just not understanding what is being said, and I see you've been editing for 14 years and an administrator for 8. I don't know how to say it more clearly. When it is common, widespread, nearly a norm, that editors with 20 years of experience, and administrators with years of experience, don't understand the policies, there is something wrong. The edit in the diff is clearly an opinion, and yet: 1) someone with 20 years of experience wants to add it as a factual statement, and 2) thinks that adding a reliable source would make it acceptable as a factual claim in wikivoice, and 3) thinks that being a popular opinion makes it a factual claim. That kind of thing is rampant, and that's pathetic.
Let's put it another way. What is the evidence that Wikipedia's standards and policies are succeeding? For instance, Maddy from Celeste said editors are trained in standards and principles by "editing articles, reading policies, guidelines and essays, lurking in discussions, participating in discussions, and so on, i. e. becoming part of the community and learning its norms and practices." So, I am saying that the training isn't working, e.g. there is rampant violation of standards by editors with decades of experience; that, in turn, leads to inane dramas, distractions, alienation, and widespread violations of the standards. What is your evidence that the training is working? Mevsherd (talk) 21:10, 19 August 2026 (UTC)
Have you discussed this issue with the 20 year experienced editor? Or is it that you just do not want to bother? If you view something as violating a policy, it is up to you to address that. No one else.
How would you require formal training? Who would set it up? Who would conduct it? Who would determine who is approved or not? There are hundreds of thousands of editors- this would be a massive undertaking. Again, you seem to want to lock in your particular viewpoint as to how Wikipedia should operate. The whole point of Wikipedia is that different people with different backgrounds participate.
Requiring formal training for an editor would fundamentally alter this project and reduce participation. We have people all over the world of all ages participating here. You seem to want to put an end to that. You might find a project that does only permit approved editors more acceptable than this one- and that's fine. 331dot (talk) 21:38, 19 August 2026 (UTC)
You're really just not understanding what's being said. I don't know what else to say. Mevsherd (talk) 01:04, 20 August 2026 (UTC)
Is it me not understanding you, or you not understanding everyone else in this thread that is saying the same thing? What is more likely? 331dot (talk) 10:55, 20 August 2026 (UTC)
I think it will make more sense if you read "editors with 20 years of experience, and administrators with years of experience, don't understand the policies" with an implied the same way I do, and obviously, my understanding is correct. WhatamIdoing (talk) 04:23, 23 August 2026 (UTC)
Again, did you discuss your concerns with the 20 year experienced editor? Yes or no? 331dot (talk) 10:59, 20 August 2026 (UTC)
This sort of thing is exactly what discussion is for. If you view an edit or article to be in violation of the guidelines, discuss it; how much experience an editor has shouldn't matter in the long run. Your point seems to be that it is the norm for editors not to understand the guidelines and policy. The whole point of Wikipedia is that we can collaborate to make versions of articles within the guideline; even if one editor slips up. —Leaf.Sheap⇖ /.°°.\ ⇗ (They•Them) 14:50, 20 August 2026 (UTC)
I also wanted to point out that the sentence they added has been removed from the article at this point, just like how Wikipedia is supposed to work. —Leaf.Sheap⇖ /.°°.\ ⇗ (They•Them) —Leaf.Sheap⇖ /.°°.\ ⇗ (They•Them) 14:55, 20 August 2026 (UTC)
If other editors disagree with your interpretation of what is fact and what is opinion, and you are right but fail to convince other people, then the failure is the strength of your arguments rather than Wikipedia. Wikipedia is a collaborative project that is never complete, and always in need of improvement. If you're in disagreement over a contentious subject you need to bring other editors over to your side. Being right isn't enough you have to persuade others to agree, that's not just an issue on Wikipedia in real life is just the same. You can tell people they don't understand, and fail, or you can help people to understand and maybe accomplish the change you wanted. -- LCU ActivelyDisinterested«@» °∆t° 20:22, 19 August 2026 (UTC)
"If other editors disagree with your interpretation of what is fact and what is opinion," The difference between fact and opinion is not itself opinion. If it were, then a fundamental Wikipedia policy would be nothing but opinion, and settling disputes "based on the merits" would be non-sensical. Your comment doesn't, actually, have much to do with what I said. Do you understand what I am saying? Mevsherd (talk) 01:11, 20 August 2026 (UTC)
Do you have a specific example in mind? Vague rants like this are unlikely to gain any traction. Gnomingstuff (talk) 21:36, 19 August 2026 (UTC)
I gave an example from the article on Sylvia Plath, and the comment above is another example. ActivelyDisinterested, who I think has been editing for 5 years, thinks a fundamental Wikipedia policy is just an opinion. The difference between "Taylor Swift is cuter than Kierkegaarde" and "Electrons have a negative charge." is purely subjective according to people here, yet the difference is a formal part of policy. Mevsherd (talk) 01:15, 20 August 2026 (UTC)
The Sylvia Plath example involved the editor Martinevans123 who has lately been in hot water for paraphrasing too closely. Martin is an amiable chap but seems to have difficulty with writing of the sort we aspire to. And so he is currently getting further personal tuition and so that is in hand. I myself am a 20 year veteran too but am often scolded for my sins.
Such staffing issues are a fundamental feature/flaw of Wikipedia as it is the encyclopedia that anyone can edit and so the standard disclaimer which you find on every page explains that
The structure of the project allows anyone with an Internet connection to alter its content. Please be advised that nothing found here has necessarily been reviewed by people with the expertise required to provide you with complete, accurate, or reliable information. That is not to say that you will not find valuable and accurate information in Wikipedia; much of the time you will. However, Wikipedia cannot guarantee the validity of the information found here.
Essentially, you get what you pay for. Wikipedia is produced on the cheap and so its quality is quite variable. But, per perfect is the enemy of good, it seems to suffice. So it goes...
Critical assessments of poems, or even of one poet's entire work, tend to be subjective rather than factual, don't they? I think if we have good sources for opinions, from notable critics, there's no reason why they can't be used. I'd agree though that statements shouldn't appear in the lede section of an article unless discussed in the main body, especially if tagged as uncited. Sometimes being hopefully provocative doesn't pay off... Martinevans123 (talk) 15:52, 20 August 2026 (UTC)
Please don't state what you think I mean, especially when you're wrong. My point, that you completely missed, is that this is a collaborative project and you need to get other people to agree with you. That applies whether you are right or wrong. -- LCU ActivelyDisinterested«@» °∆t° 12:22, 20 August 2026 (UTC)
Since almost none of the replies to my original post demonstrated understanding of what I was saying, I'll try again.
The community, supposedly, has goals: to create an encyclopedia that is neutral, verifiable, and not original research. How does the community know how well it is achieving those goals? How does it--can it--be held accountable for providing neutrality, verifiability, and avoiding original research? One way might be that it has a way of measuring the encyclopedia's neutrality, verifiability, and absence of original research. So, one measurement might be, say 67 out of 100. After some policy changes are implemented, another measurement is taken, and the score is 82. Thus, there is accountability, and the accountability indicates whether the project is improving or backsliding. I believe Wikipedia does nothing like that, and has no ability to do anything like that. Another kind of measurement is more anecdotal: Do editors who should have expertise in Wikipedia's standards, reliably demonstrate that expertise? For example, do editors with many years of experience, and admins, understand the difference between a factual claim and an opinion? Do they consistently follow the standards relevant to these different statement types? I recall lessons on the difference between fact and opinion in primary school: it is rudimentary. My experience is that editors with 20+ years of experience, and admins, routinely try to insert opinions into articles as facts, and routinely argue that if the opinion is found in a reliable source or very widespread, that means it can be stated as a fact. In other words, experienced editors are inept at implementing Wikipedia's most basic standards, standards which in some cases are taught in secondary or even primary school.
That's pathetic.
So, maybe Wikipedia needs to be provide some sort of educational or training dimension to its editors. Lessons that might be taught to, say, 12-year-olds. Right now, it just has a huge morass of essays, guidelines, and god-knows-what-else, which are confusing and bog down education instead of facilitating it. It also has a community narrative that it is based on neutrality, verifiability, and avoiding original research, while having no actual measurement of how well it provides such things--no reality check on its adherence to its standards. Mevsherd (talk) 16:19, 20 August 2026 (UTC)
We do have processes to check. You can question any edit anytime, or anyone's actions anytime. We all hold each other accountable. You may do this right now. What you're saying is you don't want to bother. You want it done for you. 331dot (talk) 16:25, 20 August 2026 (UTC)
I think you should stop responding. You are just not understanding what is being said. Mevsherd (talk) 16:28, 20 August 2026 (UTC)
Again, what is more likely? That I'm not understanding you, or that you are not understanding literally everyone else on this thread saying the same thing?
You want to fundamentally change this project from anyone being able to edit it to only vetted and approved people editing it- people who have undergone your unspecified "training". Am I wrong about this?
If you see someone offer an opinion as a fact inappropriately, it is incumbent upon you to address it. You approach the person, or the community at large, and say "hello, I'm concerned that this edit you made violates policy, for (reason)". This isn't rocket science. We hold each other accountable. 331dot (talk) 17:05, 20 August 2026 (UTC)
"You want to fundamentally change this project from anyone being able to edit it to only vetted and approved people editing it- people who have undergone your unspecified "training". Am I wrong about this?"
Yes, you are wrong. I've said nothing like that. Mevsherd (talk) 19:19, 20 August 2026 (UTC)
You want to require editors to undergo formal training to participate here- so, presumably, editors who do not undergo that training would not be permitted to participate here. Ergo, you want to change this project from "anyone can edit" to "anyone who undergoes our training courses can edit". In order to do that, people need to be vetted and approved. 331dot (talk) 19:26, 20 August 2026 (UTC)
most of the replies you are getting are about how to engage with editors that add these statements as facts, and this is not bad advice, approaching the editor on their talk page or the article talk page.
But the point you start from is absolutely been a problem for nearly a decade, worsened that we are trying to edit neutrally in the midst of a culture war. Editors want to take recent opinion made by one or two RSes and call that fact in wikivoice, justifying this under DUE or other asoects of NPOV. Wikipedia needs to be written conservatively (from the middle ground, not in the political/ideological way), and we should by default put any statement that is possibly subjective with attribution and not in wikivoice. Only over time (order of decades) and with analysis from experts and academics can we consider that a subjective idea has widespread agreement over a long period of time, and present that as fact in wikivoice. But editors, even experienced ones get caught up on wanting to write content to right great wrongs, and are quick to incorporate material that may support that moral view in wikivoice. We need more restraint overall. Masem (t) 16:41, 20 August 2026 (UTC)
....which is all good to call out and address, but doesn't require us to be all vetted and approved by some unspecified body before that can happen. The OP is free to, right now, call out any inappropriate edits they see, such as their claimed issue with a "20 year experienced" editor. 331dot (talk) 17:08, 20 August 2026 (UTC)
I did not say this: "require us to be all vetted and approved by some unspecified body." Please stop making things up. Mevsherd (talk) 19:20, 20 August 2026 (UTC)
I think a lot of editing involves a decision-making procedure that could easily be guided by a flow chart or series of check-lists. The more words there are explaining, describing, pontificating on some policy, the more the policy become an inkblot, which people can interpret any way they want. Mevsherd (talk) 18:19, 21 August 2026 (UTC)
My experience is that editors with 20+ years of experience, and admins, routinely try to insert opinions into articles as facts, and routinely argue that if the opinion is found in a reliable source or very widespread, that means it can be stated as a fact. In other words, experienced editors are inept at implementing Wikipedia's most basic standards, standards which in some cases are taught in secondary or even primary school.
For someone so concerned about standards this is a hell of a wad of weasel wording. "Editors," as a generic group, no names named, many people are doing this. If there are specific edits to specific articles that you take issue with then deal with them on the talk pages for those specific articles. Gnomingstuff (talk) 18:32, 20 August 2026 (UTC)
"Weasel words" applies to articles, not people describing their experience on a Talk page. The rest of your comment has little to do with what I said, and since I've said it about five times now, that's pathetic.
How does the community know how well it is doing its job of providing a neutral, verifiable, OR-free encyclopedia? If we wanted to put a grade on it, a D- or A+ or something in-between, on what basis would we do it? I've asked this about six times now. Mevsherd (talk) 19:24, 20 August 2026 (UTC)
On a volunteer project, we do as well as we hold each other accountable to standards. There's no standards body to approve or deny content other than ourselves. Until we have a paid staff to do that, that's just the way it is.
I've asked you a few times now if you have approached editors who in your view have made edits that violated policy to discuss your concerns with them. 331dot (talk) 19:28, 20 August 2026 (UTC)
I would suggest reading Wikipedia:Wikipedia is a work in progress. I'd be quite upset if my teacher took a paper I was in the middle of writing and gave me a failing grade, just because I hadn't finished yet. And it's hard to really judge progress over time because the scope of what we could plausibly cover (ex. the number of notable people, events, concepts) is always increasing. Also, it would be an opinion to place that kind of judgement, because it would depend on what we considered to be the most important measures of success (ex. if we were more neutral on Tuesday, but had less original research on Wednesday, different editors could reasonably disagree about on which day the article was "better.") SomeoneDreaming (talk) 03:35, 21 August 2026 (UTC)
I don't know about the community, and measuring compliance is difficult, but one fun heuristic I use to check whether Wikipedia is perhaps somewhere near the ballpark of doing its job okay-ish on a topic, at least in contentious areas, is the extent to which it is the target of hysterical disinformation campaigns and attacked in partisan media/on social media by people whose value systems are not aligned with Wikipedia's (despite the often delusional or dishonest claims they may make to the contrary). If those people are complaining about something, it's often a good sign for me because they are usually full of shit. That's my experience anyway. Sean.hoyland (talk) 11:29, 21 August 2026 (UTC)
The other issue is that not all opinions are attributed as doing so would sometimes create a false impression. If most agree with one position, and a small minority disagree, then attributing the position to a couple of its supporters creates a WP:FALSEBALANCE. Some form of educating new editors could be helpful, as so many misunderstand what NPOV asks of them. As to how we are held accountable, by each other and by the research that has been done by external academics about the quality of the encyclopedia. -- LCU ActivelyDisinterested«@» °∆t° 19:22, 20 August 2026 (UTC)
A Perfect Example
Here's a discussion of a very fundamental and simple policy, in which two editors, each with 20 years of experience, can't agree. One of them is an adminstrator, and the other described themslelves like this: "In my 20 years here, I've written more of Wikipedia's policies, including the policy on writing policies and guidelines, than you have made edits ever." (this person is clearly wrong about the policy).
So, 20+year editors and administrators are arguing about basic concepts--does an opinion need to be attributed in-text if it's widespread. And, that is common. That is evidence that the community's education and training methods are nearly non-existent. I don't mean it's a problem that editors in general debate such things; I mean it is a problem that 20+ years of experience and adminship promises little educational value, clarity, or expertise on simple points.
WAID is right, and I say that as someone who has spent many discussion arguing with them. -- LCU ActivelyDisinterested«@» °∆t° 16:46, 22 August 2026 (UTC)
As far as I can tell, the primary disputant is you (which would have been helpful to mention), and not an English Wikipedia administrator, and not with 20 years of experience (at least under this account name). No one else in that discussion has agreed with your proposed change. isaacl (talk) 17:43, 22 August 2026 (UTC)
I was referring to this exchange:
Every statement of opinion (biased or not) needs in-text attribution to explain that it is an opinion and give context to why that opinion is held to make sure it is not said in Wikivoice. There are very limited exceptions such as a summaization of such opinions in the lede, or as like a leading transitional statement in prose (eg "Some experts believe X.(no source) Expert 1 says this (source). Expert 2 says that (source)..." etc. Masem (t) 10:53, 21 August 2026 (UTC)
This claim that every statement of opinion needs in-text attribution is not true. According to this policy, in-text attribution is not appropriate for opinions that are "described as widespread views, etc". WhatamIdoing (talk) 17:42, 21 August 2026 (UTC)
Both 20-year editors, at least one administrator. My main point is not that Masem is right and WhatamIdoing is wrong (although that is the case)--hopefully that's clear. Mevsherd (talk) 17:54, 22 August 2026 (UTC)
Thanks for the clarification; linking to a specific comment would have been helpful when it was the only one made by that editor. For better or worse, it's unrealistic to expect 100% of experienced editors to be in lockstep with their understanding of community norms and guidance. isaacl (talk) 18:14, 22 August 2026 (UTC)
But, there is no such expectation. The stated problem is that it is "common, widespread, nearly a norm, that editors with 20 years of experience, and administrators with years of experience, don't understand the policies." Also, this particular case is not merely a "community norm and guidance." It is foundational: “This policy is non-negotiable, and the principles upon which it is based cannot be superseded by other policies or guidelines, nor by editor consensus." Wikipedia:Neutral point of view. Mevsherd (talk) 04:00, 23 August 2026 (UTC)
I don’t see how this or any anecdote proves that something is “common, widespread, nearly a norm.” I’m sorry that you’ve had a bad experience here but remember that editing is optional. If you think the entire project is pathetic, you don’t have to keep engaging. SomeoneDreaming (talk) 04:48, 23 August 2026 (UTC)
@Masem wrote: "Every statement of opinion (biased or not) needs in-text attribution...There are very limited exceptions..."
Do you know what that means? It means "Not every statement of opinion needs in-text attribution", because "Every" minus "exceptions" = "Less than every". WhatamIdoing (talk) 04:16, 23 August 2026 (UTC)
And the exceptions I gave, mostly in terms of placing summary context in the lede (for example, most film ledes typically list how how the film was received broadly that reflects the Reception section), or a leading summary statement that is followed by multiple statements of opinion that are sourced and with in-text attribution for purposes of narrative flow ("Some sciences believe X to be true (no source). Scientist A said this (source), Scientist B said that (source)..."). A standalone statement of opinion in the body absolutely needs in-line attribution and written outside wikivoice, no matter how many sources claim that same opinion. Masem (t) 11:25, 23 August 2026 (UTC)
Also, people have legitimately different ideas about what constitutes "an opinion". The theory of gravity can fairly be construed as "a fact" (with some definitions) or as an interpretation of facts, which would be "an opinion" (according to other definitions). WhatamIdoing (talk) 06:40, 27 August 2026 (UTC)
As stated below, you are generally correct if we consider quantification beyond 2 values. So no need to defend yourself further. Yesterday, all my dreams... (talk) 16:36, 2 September 2026 (UTC)
Sorry, that deduction regarding quantification may be so in two valued logic, but the real world is not two valued, as uncertainty quantification and fuzzy logic show. So Masem is generally correct. Please consider: People are generally born with 10 fingers, with some exceptions. Yesterday, all my dreams... (talk) 16:31, 2 September 2026 (UTC)
There's a DYK on the main page at the moment which is amusingly apposite:
Did you know ... that philosophers discuss whether truth is correspondence between statements and facts, coherence among beliefs, or something else?
As philosophers don't agree on such fundamentals, Wikipedia is unlikely to do better.
Philosophers are in the business of debate. If they agree, they are out of business. How many philosophers does it take to change a lightbulb? 12, one to change it, and 11 to debate the existence of the lightbulb. Yesterday, all my dreams... (talk) 16:21, 2 September 2026 (UTC)
Typically, when trying to figure out some policy, I wade through interminable explanations, essays, and contradictory information. In many cases, a simple series of checkboxes or a flowchart would suffice, and be much clearer, cleaner and generally comprehensible.
I think a lot of editing involves a decision-making procedure that could easily be guided by a flow chart or series of check-lists. The more words there are explaining, describing, pontificating on some policy, the more the policy become an inkblot, which people can interpret any way they want.
There's too much explaining, not enough "how to"--discrete steps like: "To add a 'See also' section, do this...."
It does no good to have a few thousand words of essays and elucidations on NPOV, if editors don't understand what makes a claim subjective or objective. —Preceding unsigned comment added by Mevsherd (talk • contribs) 18:14, 24 August 2026 (UTC)
If only the world operated on such a black-and-white clear-cut way, especially in regards to anything even remotely controversial. Given sources' inherent biases, individual journalists' inherent biases, and the proliferation of literalfakenews, a flow-chart would not help anyone save for those who are already experienced in assessing sources, who wouldn't generally need it in the first place. A greener assessor would likely find a flow-chart byzantine and impenetrable. —Jéské Courianov^_^vLook outit's Jimothy! 18:20, 24 August 2026 (UTC)
You are free to make a flowchart if you wish (some user essays even live in WP-space) but being provocative, whether you intended it or not, is likely counterproductive to the community adopting it. In the interest of full disclosure, I also disagree with your assessment that the statement added to the Plath article is necessarily subjective (there can be objective differences in bodies of work, and objective indicators of collusion) and overturning our current practice of effectively treating academic consensus as fact is highly unlikely to succeed and most likely seen as detrimental by the community to large parts of our coverage, regardless of any perceived subjectivity, so any flowchart should account for that. Alpha3031 (t • c) 23:30, 25 August 2026 (UTC)
Hello. I don't know what you mean by this: "overturning our current practice of effectively treating academic consensus as fact is highly unlikely to succeed and most likely seen as detrimental by the community to large parts of our coverage, regardless of any perceived subjectivity,"
The policy is that "Shakespeare is the greatest playwright in English literature" and "genocide is an act of evil" should not be stated as fact, yet they are consensus opinions. Mevsherd (talk) 04:54, 26 August 2026 (UTC)
I don't understand what you're saying. But, I consider this and the ongoing discussion here to be ongoing evidence of a problemm. If I understand correctly, you've been editing for 20 years and Alpha3031 for over 10, and many others in this discussion possess similar experience, and yet people fundamentally can't agree on a basic, core policy: “This policy is non-negotiable, and the principles upon which it is based cannot be superseded by other policies or guidelines, nor by editor consensus." You basically can't contribute (at least not well) to the project without understanding neutrality, and yet multiple editors haven't learned what's expected after two decades here. I realize "pathetic" is not usually a constructive term, but, honestly, don't you think it's kind of pathetic? Mevsherd (talk) 14:39, 26 August 2026 (UTC)
You're attributing well reasoned disagreement to ignorance ('haven't learned'). But some diversity of opinion is a healthy thing. We have some neutrality maximalists, we have Deletionism and inclusionism on Wikipedia, and so on. That this place isn't 100% Groupthink is a good thing. MrOllie (talk) 16:32, 26 August 2026 (UTC)
[...] Alpha3031 for over 10, and many others in this discussion possess similar experience, and yet people fundamentally can't agree on a basic, core policy:
Well, how time flies I guess, but for some reason I suspect the issue is less that there is insufficient consensus on the meaning of a policy than the fact that said consensus does not appear to be consistent with your interpretation of it.
"This policy is non-negotiable, and the principles upon which it is based cannot be superseded by other policies or guidelines, nor by editor consensus."
If I may draw your attention to the the initial paragraph of that page, a mere two paragraphs prior to the one your quoted sentence is from:
which means representing fairly, proportionately, and, as far as possible, without editorial bias, all the significant views [bold mine] that have been published by reliable sources on a topic.
It is not true, for example, that drawing distinctions between bodies of work would be analytically proscribed by such a policy.
I realize "pathetic" is not usually a constructive term,
I respectfully submit that the time of such a realisation is a time when it would be appropriate to consider more judicious terms, rather than double down on contraventions of our cconduct policies. Alpha3031 (t • c) 08:36, 27 August 2026 (UTC)
And all the flowcharts and checklists in the world won't stop an editor who's convinced they're right and everyone else is wrong. They'll simply use the tool to "prove" their point and then insist everyone else needs to show good faith or something. Flowcharts and checklists are also notoriously bad at dealing with nuance...unless they're incredibly massive and probably only usable by the person who created them. And if you think this is easy, go spend some time in the MoS stuff where people will fight to the death about things like capitalization or where a comma goes. Intothatdarkness 13:32, 26 August 2026 (UTC)
A new archival bot for Newspapers.com
It has come to my attention that while public-domain newspaper content on Newspapers.com cannot be directly archived using archival tools (in this case, the Wayback Machine), clippings can. (Clippings are fragments of a newspaper article uploaded to Newspapers.com) Therefor, and I would like some thoughts and suggestions on how this could be done: (I have no knowledge of how bots work) a bot should be made to automatically archive (using Wayback) any cited content in Wikipedia from Newspapers.com pre-1929 that is a clipping. If Newspapers.com ever went down, or their servers lost access to the content by whatever means, there would still be a copy of it online so that they wouldn't get tagged with[failed verification]. How would one go about making this a thing/ironing out specifics? Ilov3gam3z (talk) 00:58, 20 August 2026 (UTC)
Editors should be citing how they actually accessed the source. Katzrockso (talk) 05:17, 20 August 2026 (UTC)
not required at all. You have to give enough info that any person can figure out how to locate the source, but how you, the editor adding content, got it is not a question. For example researchgate.com is a copyright iffy place that some publish their scientific papers at outside of copyright-locked down journals. As long as my cite is to the journal article using normal cite formats of volume, issue, page # and DOI, it doesnt matter if I read it from the journal (perhaps via wiki library card access) or from researchgate. Masem (t) 13:17, 20 August 2026 (UTC)
I don't fully understand what you mean here, but if it is about the TM:Newspapers.com template, this will just scrape the page for any clipping links from the site (Newspapers.com template or Cite news) and archive. If you are talking about the fact we shouldn't rely on online archives exclusively, not everyone can access the original text. Ilov3gam3z (talk) 11:29, 20 August 2026 (UTC)
A URL is never required for print sources. True, not everyone can access the original text of an offline newspaper. However, that's true for almost every source (e.g., {{cite sign}}, which generally requires someone to physically travel to the location of the sign, not to mention the swingeing fees charged for some academic journal articles, which many people can't afford to pay). WhatamIdoing (talk) 04:36, 23 August 2026 (UTC)
newspapers.com is already an archive, we should not be caching their content. They are storing static images of print sources which aren't going to change. (Contrast that to web news sources which can change dynamically and can disappear from sites without a trace if they aren't archived). Masem (t) 11:37, 20 August 2026 (UTC)
Looking online, I see a few discussions of people talking about how their clippings broke after a falling out between a newspaper and newspapers.com. (this should only affect non-free information, but if a newspaper still running today from before the public domain cutoff date loses licensing with the site, there is a good chance some info from before gets caught in the cross-fire) Also servers can go down, etc. etc. I'm surprised IABot doesn't do this honestly. Ilov3gam3z (talk) 11:52, 20 August 2026 (UTC)
if content disappears because a deal falls through between a published paper and newspaper.com, but we are already using the citation that makes zero harm to WP:V, it only makes it more difficult to access to source, likely now requiring local, on foot access to the palers archives, but not considered a factor for a source per wp:v. Masem (t) 13:12, 20 August 2026 (UTC)
It wouldn't get a [failed verification], but a [dead link]. I also don't get the criticism of citing newspapers.com above, it is literally just a somewhat-accessible archive of sources that usually are a few days wait from editor access. 1brianm7 (talk) 12:19, 20 August 2026 (UTC)
As others have said, this wouldn't be a failed verification because an archive link, or other web link, is in no way required to cite an old newspaper. Creating a backup of a backup as a routine matter of course seems a bit fussy. On the other hand, having stable links is a benefit to the project. Reliable sources do need to be accessible and if there is a dispute between future editors about the accuracy of a cited statement, where the source can no longer be accessed, that is a problem. My impression is that Newspapers.com is generally regarded as a reliable (stable) archive. How often does this issue occur where they lose access to a particular paper's content? —Myceteae🍄🟫 (talk) 14:21, 20 August 2026 (UTC)
From what I have seen online, decently rarely. Still though, it is always good to have another backup in case things go awry. This would be a pretty minor and low effort task for a bot to do and I don't see any normal problems with bots affecting this, like WP:CONTEXTBOT. It just seems like a good thing to have, I guess. And about dead link vs failed verification; it would still eventually result in the content being removed if there is no other source. although now that I am thinking about this maybe NoMore404 covers this already? unsureIlov3gam3z (talk) 14:32, 20 August 2026 (UTC)
Failed verification means an editor saw the source and found it did not support the material presented. That would be grounds to remove. On the other hand if something is a dead link, remival is not appropriaye and instead other avenues to find snd generate a proper citation per wp:v should be done. Only if going for something like FA or GA would then removal of material soyrved to an unresolved dead link be appropriate. If we are citing an article off newspapers.com, the citation should point to the original paper, not the newspaper.com, and that will never be a dead link, just one that might be more difficult to verify if the articke disappears on newspapers.com. Masem (t) 14:55, 20 August 2026 (UTC)
The problem I see locally, and one I will not be surprised to see happening elsewhere, is that access to old issues of the local newspaper have become very difficult. The local paper disposes of old print editions after one year. The paper periodically sends microfilm reels of recent issues to the local library district. The library in turn places the microfilm reels in the archives of the local historical society. The last time I checked, the archives and library of the historical society were kept in an unstaffed building. Access to anything in the archives, including the microfilm reels from the newspaper, requires that a staff person from the historical society be available to open the building and sit there while the archived material is consulted. If the paper becomes unavailable on newspapers.com, access to anything published prior it to going online will be very, very difficult. And if anything should happen to the microfilm archives, ... Donald Albury 20:51, 20 August 2026 (UTC)
I've come to think of this, and similar challenges, as "Schrödinger's accessibility". I realize the metaphor is imperfect. I participated in a series of discussions around sourcing for David Gillow. At one point someone located a photograph of a newspaper clipping that was posted on the Twitter account of the subject's family member. The clipping lacked full publication details but it was assumed to be from The Herald (Zimbabwe). While there was no serious concern that it was fraudulent or doctored, editors could not confirm whether archives of The Herald from that time period existed anywhere else outside the private collection of someone connected with the subject. It was repeatedly asserted that one could make an appointment to view the government's Herald archives in Harare but there was no confirmation of the procedure nor that they held a copy of the particular edition and article in question. —Myceteae🍄🟫 (talk) 21:34, 20 August 2026 (UTC)
It wouldn't be removed, because you can still go to a library and look at the actual, physical newspaper (or perhaps a microform copy). --Maddy from Celeste (WAVEDASH) 14:56, 20 August 2026 (UTC)
It *could* result in content being removed but I don't think this is the likeliest outcome. It would be a case-by-case determination. Suppose an editor uses a Newspapers.com archive to support an extraordinary claim. It goes unnoticed for years and then a new group of editors have reason to doubt it and the source can no longer be accessed. I think there would be a discussion and determination based on the particulars. We have a fairly high tolerance for dead links and hard-to-access sources. —Myceteae🍄🟫 (talk) 14:57, 20 August 2026 (UTC)
Automatically grant certain users with autopatrolled rights
The NPP backlog is at historic highs, around 31,500 articles unreviewed. Users have been stepping back on NPP due to burnout concerns. A one month backlog drive cannot fix the 31,500 article backlog. That's why I have a new idea, if a user has created 10 articles, contributed at least 1,000 unreverted bytes to a GA/FA, and hasn't had at least 10% of created articles be deleted they automatically obtain autopatrolled rights. This may be a low bar; however, our Wikipedia community can no longer deal with NPP burnout. CostalCal (talk) 00:28, 26 August 2026 (UTC)
Note: This would not be a replacement for the existing manual autopatrolled rights request process. Editors who don't meet these specific criteria could still apply through the manual process.
@Chipmunkdavis The difference about this is that I'm proposing automatic autopatrolled rights, not NPR rights. CostalCal (talk) 00:56, 26 August 2026 (UTC)
That was discussed there, with an initial proposal of 100,000 edits and 10 years. CMD (talk) 01:02, 26 August 2026 (UTC)
@Chipmunkdavis We're running into another problem. That's not enough users to give autopatrolled to solve a major Wikipedia backlog. According to Wikipedia:List of Wikipedians by number of edits, only 1,000 or so users have 100,000 edits. Many of them are inactive, blocked, or haven't been on Wikipedia for 10 years. Since 3,500 people already have autopatrolled rights. The number of users who don't have autopatrolled and meet the criteria would probably be around 300 active users or so. (User:Certes mentioned it was 374). This is too little amount of users. CostalCal (talk) 01:16, 26 August 2026 (UTC)
I may not be typical but most of my page creations are redirects, which get patrolled by a bot without troubling the humans at NPP. Most of the rest are disambiguation pages. Perhaps those could be patrolled by a bot too. Of course, I could create a dab then overwrite it later with a promo for my garage band, but that's more work and more obvious than just hijacking a backwater page patrolled years ago. Certes (talk) 08:25, 26 August 2026 (UTC)
Yes. Lots of other ideas there as well so I would definitely suggest interested editors join the discussion at WT:NPP#NPP backlog is now over 30,000. RFCBEFORE for emergency measures RFC, which has just over a hundred comments as of the time of writing this. Personally I think splitting off the queue into subqueues (especially for notability) is most likely to make a major impact on the main queue. Alpha3031 (t • c) 01:23, 26 August 2026 (UTC)
I think this defeats the purpose of autopatrolled rights, and the criteria seems easy to circumvent. aesurias(ping me in your reply, or I won't see it) (talk) 00:57, 26 August 2026 (UTC)
the criteria seems easy to circumvent.
Should the criteria be more specific? Ideally, I don't want too few users to obtain the right. CostalCal (talk) 01:20, 26 August 2026 (UTC)
I brought this up earlier this year, but I don't think it was very popular with editors. GrinningIodize (you just lost the game) (talk) 20:56, 26 August 2026 (UTC)
I think that what we need is a clearer understanding of how often, and why, NPP folks look at an article but do not choose to click the 'Patrolled' button. A few weeks ago, I looked at a small sample (e.g., 10 consecutive articles) stuck in the NPP queue, and it looked like the main problem was simply that nobody wanted to click the final button, and thereby permanently put their name in the log as somehow 'approving' it. I believe that how many NPPers view an article without taking action is something the WMF can track and study for us, if we ask. WhatamIdoing (talk) 07:00, 27 August 2026 (UTC)
I've never done NPP but would it be useful to have another button marked with a more concise version of: "Been looked at; marginal or difficult case; second opinion needed"? Such pages could go into a shorter queue for experienced NPPers or subject experts to assess. Certes (talk) 10:27, 27 August 2026 (UTC)
That might give statistics on how often that happens, but not why. Best to ask the people doing the patrolling.
The two biggest categories of things I look at and don't mark reviewed one way or another are the categories where the appropriate course of action is time consuming.
1) It's probably LLM but there are no G15-level errors and writing a solid LLM deletion rationale takes forever and a ton of source reading (Brandolini's law)
2) The topic is probably notable but the sourcing in the article is bad, and either searching for sources or doing WP:BEFORE that there aren't any takes forever. This is more of a problem for back-of-queue, because these are easy draftifies at front-of-queue. ~ A412talk! 16:09, 27 August 2026 (UTC)
Yes, I agree that it would give statistics on how often rather than why. IMO we need both. The numbers would (if they turn out like I think they will) erase the worry (by non-NPPers) that the articles at the back of the queue simply haven't ever been looked at. And by looking at some articles with high numbers of views but low numbers of actions, we might find quantitative evidence supporting our belief, which is that the ones that aren't marked as reviewed usually have the same handful of characteristics.
For example: How often do you tag the articles in 1) and 2) with {{AI-generated}} and {{Notability}}? My impression is that this is mostly not happening to back-of-queue articles, but adding these tags would probably save the next NPPer some effort, and it might even prompt improvements by the article's creator. WhatamIdoing (talk) 16:27, 27 August 2026 (UTC)
Part of the problem is that it takes nontrivial work to determine that an article deserves {{AI-generated}}, and if I've done that I've probably done enough work to write the PROD / AfD rationale. Fair point on {{Notability}}, and I think your point is stronger for that tag, in that we wait around until a reviewer is willing to put the notability stamp on. ~ A412talk! 18:07, 27 August 2026 (UTC)
Would you be happier with an {{AI check requested}} tag, aimed at the editor who has some suspicions, but who hasn't done the work to determine whether the stronger tag is warranted?
My overall POV is that NPP shouldn't require "nontrivial work"; I'd rather have a "Yup, no hoax/vandalism/copyvio/other CSD candidates here, it looks okay overall, and I'll tag this one possible issue so the subject-matter experts can take over". WhatamIdoing (talk) 19:30, 27 August 2026 (UTC)
Yes, also an AI background check. CostalCal (talk) 16:56, 29 August 2026 (UTC)
Given the large backlog, I think we should mark all 3+ year old articles and all 1+ year old redirects as reviewed. In solidarity, Dafootballguy (Want to talk?) 01:07, 26 August 2026 (UTC)
This would only remove pages which have been turned into their current form more recently than the date in the queue. Quickly checking redirects, the oldest real unreviewed redirects are from February 2026. Skarmory(talk •contribs) 03:03, 26 August 2026 (UTC)
Strong disagree, articles that don't get reviewed for a year are those most likely to have problems with them. If nobody has reviewed it, it's because its sources are likely very old, are difficult to check for sigcov, or it is of low quality.--Boynamedsue (talk) 05:49, 26 August 2026 (UTC)
@Dafootballguy, redirects that are older than 180 days are already removed from the NPP queue: see here. Cheers, SunloungerFrog (talk) 07:10, 26 August 2026 (UTC)
We already mark old redirects as reviewed using a mw:PageTriagecron job. I think the cutoff is 6 months.
How many actually old unreviewed articles are there? The dates shown in Special:NewPagesFeed are misleading. For example, it says Government of Yemen is unreviewed since 2002, but it's actually been in the queue for only about 7 hours. Looking at the five "oldest", most are only a day or two old, with one that is six weeks old. WhatamIdoing (talk) 07:20, 27 August 2026 (UTC)
quarry:query/108532 selects a list of unreviewed articles whose creation date is older than six months, but filters out any that have edits within the last six months that are tagged as mw-removed-redirect, thus excluding article creation over a redirect. As of a few days ago (I'm on mobile and it's awkward to re-run the figures), it suggests that:
a creation date of more than 6 months ago is 9577 unreviewed articles
more than 9 months ago, 5193 unreviewed articles
more than 12 months ago, 2266 unreviewed articles
I think the logic is sound, but would welcome suggestions for improvement. I think the numbers will be there or thereabout. Cheers, SunloungerFrog (talk) 08:59, 27 August 2026 (UTC)
I looked at the first three in that Quarry query (Peter Isacksen, Ferns N Petals, and Barry Mano), and I do not understand why any of them have not been marked as reviewed. WhatamIdoing (talk) 16:35, 27 August 2026 (UTC)
I could hazard that some reviewers might take a look at those three articles and think:
Peter Isacksen: sourced mainly to local newspapers, can't access any of the newspaper.com sources because I have to fill in something at WP:TWL and haven't, so I can't really check WP:V...
Ferns N Petals: Indian company, WP:NEWSORGINDIA, could be promo (just look at the WP:REFBOMB at the end of the lead 😱!), WP:NCORP is really strict...
Barry Mano: basically sourced only to obituaries, WP:NOBITS is a thing...
...best be on the safe side and leave them to someone else in case marking them reviewed is the wrong thing and I get told off for it. And then move on to something that only has one unreliable source, draftify it, and breathe a sigh of relief. Cheers, SunloungerFrog (talk) 20:10, 27 August 2026 (UTC)
I think you're correct: We have "best be on the safe side...in case marking them reviewed is the wrong thing and I get told off for it" on the one side and "Why is there such a huge backlog?!" on the other side. Well, the first answers the second: We have a huge backlog because we have structured and incentivized the process to produce a huge backlog. If we don't want a huge backlog, then we need to change the NPP structure (e.g., an official {{guideline}} that says determining notability isn't NPP's job) or change people's behavior (which, in the case of yelling at people for holding a less-deletionist view of potentially 'promotional' content, I think is basically impossible. I mean, with sufficient thrust, pigs fly just fine, but we're never going to get sufficient propulsion on that point). WhatamIdoing (talk) 20:25, 27 August 2026 (UTC)
Feel free to create an RFC question in the workshop about NPP not checking notability anymore if you want. However I suspect it would not receive much support. From my anecdotal observations, you and Joe Roe are the biggest proponents of it, and in general most others think checking notability is a fundamental part of NPP. –Novem Linguae (talk) 23:44, 27 August 2026 (UTC)
I know that people don't necessarily read materials even if offered. But for people who are trying in good faith to follow instructions, I believe guidelines, info pages, help boxes, etc. should offer brief information about LLM guidelines (with links) whenever relevant, so people have an opportunity to see them before they write something with a LLM and get warned about it.
I don't think adding it to that template will move the needle much. Judging by the amount of spam by people who think talk pages are themselves ChatGPT, and the enormous cleanup job they leave in their wake, no one reads them. Gnomingstuff (talk) 06:16, 27 August 2026 (UTC)
"A large fraction of users will not be deterred by any warnings" is almost certainly true, but that doesn't mean we can't try to figure out how to communicate with the remainder.
I do think that for this sort of thing we perennially have more information than anyone is going to read. The current template has three different ways of essentially saying "be nice", so perhaps cut or consolidate one of those and replace it with a note about not using LLMs? I can't say I think it will help very much but I don't expect it to hurt and think it's more likely to be useful than the current state. Rusalkii (talk) 08:01, 27 August 2026 (UTC)
Relatedly, I've been thinking about proposing that we 'blacklist' (i.e. block from being published) edits that 'contain' AI watermarks, though unfortunately this'd mean we'd have to run every edit through all APIs of major AI companies' detectors (we'd also need to repeal WP:LLMTRANSLATE). It'd massively reduce AI cleanup (which might finally become manageable) and take the pressure off of NPP and AfC, while also practically ending the biting of newbies for LLM use. A WMF dev is looking into feasibility, but some points:
the notice would need to be tailored towards good-faith newbies
false positives would need to be near non-zero, possibly ensured by setting a lower bound for word count (i.e. positive byte change, eg. edits of +1000 bytes or more)
If technically feasible (and I haven't the foggiest whether it would be) some sort of whitelist for edits that explicit state they are translations (presumably in the edit summary) might help with the LLMTRANSLATE issue. Obviously translators would have to know to specify this and it's something that could be abused but its not something that clueless newbies (of any faith) would do.
Any lower bound of bytes would need to be bytes of prose, otherwise things like large tables would get caught and while that can sometimes be an AI sign a detector tailored towards prose isn't going to be reliable.
Not only would this need to be technically feasible it would need to be technically feasible at a massive scale. Something lhat would relieve load this area would be only checking the edits of those who are not autopatrolled. There will still be many people whose edits will be checked unnecessarily (e.g. me, I don't write enough articles to be autopatrolled but I know not to use an LLM) but it's the best proxy I can think of, at least at the moment.
There needs to be some way to report false positives. One possible one that comes to mind is quoting a passage written by someone else that was LLM-generated. Whether such a quote would be DUE or not is something that can't be determined automatically.
yeah, it's not a panacea and people will probably just use text spinners or whatever to get around it, but hopefully such a move would stop the bulk of it (or we just whittle this down to something feasible/viable) Kowal2701 (talk, contribs) 11:31, 29 August 2026 (UTC)
A basic way to get a lot of people's attention could be to add an editnotice similar to the one we already have concerning copyright, say for all non-extended confirmed users? ;; Maddy from Celeste (WAVEDASH) 21:19, 27 August 2026 (UTC)
No, just avoid instruction creep and walls of text. The higher the number of links, instructions and requirements, the less likely someone is going to read them. Cambalachero (talk) 13:18, 31 August 2026 (UTC)
There is also the question of relative importance; the talk headers need to note the absolutely fundamental talk policies and instructions, and AITALK honestly doesn't seem absolutely fundamental like e.g signing posts or avoiding copyvio. Jo-Jo Eumerus (talk) 16:07, 2 September 2026 (UTC)
Most newcomers use the Reply tool (or Edit requests), so they don't need to be told about signing their posts. Here's a sample of 24 hours' worth of Talk: page edits that aren't using one of the common auto-signing tools. WhatamIdoing (talk) 02:48, 4 September 2026 (UTC)
I support this proposal. Another advantage of this is that this may get into the LLM input, and most off-the-shelf LLMs would likely push back against a request that violates "the rules". Naturally, it's not hard to override it, but most of the users who post AI slop on talk pages are not sophisticated and even modest friction may deter them/ Alaexis¿question? 16:02, 2 September 2026 (UTC)
I agree. We can not accurately estimate what percentage will be affected, but X% is better than zero. So I also support it. Yesterday, all my dreams... (talk) 16:17, 2 September 2026 (UTC)
I have been considering filling my userpage with invisible text about the rules regarding AI on wikipedia. Although, I'm not sure if the big labs crawl pages that aren't supposed to be indexed as consistently. MetalBreaksAndBends (One for all) 16:19, 2 September 2026 (UTC)
Just realized you were talking about getting into the llm's input at inference time, rather than getting into the training data. MetalBreaksAndBends (One for all) 17:36, 2 September 2026 (UTC)
It refers to "inappropriate adult-child relationships", which is vague and could be misconstrued as referring to platonic relationships where children become acquainted with strangers on the Internet without any sexual or romantic intentions by either party. I suggest the phrase "romantic or sexual adult-child relationships" instead.
The policy's mention of children has caused some debates at Talk:Clop (erotic fan art), where some people interpreted it as being relevant to fictional characters that represent children. Therefore, I suggest that we add a note clarifying that the child protection policy only deals with actual children and not fictional ones.
Perhaps we should look into revising this thing? Here's my idea for what the lead might look like if revised:
"Wikipedia regards the safety of children using the site as a key issue. Wikipedia does not tolerate romantic or sexual adult–child relationships, and any editors who attempt to use Wikipedia to pursue or facilitate such relationships, who advocate for such relationships on- or off-wiki (e.g. by expressing the view that such relationships are not harmful to children or expressing support for known pedophile advocacy groups), or who identify themselves as pedophiles, will be blocked and banned indefinitely."
I would personally go a step further to remove the "expressing the view that such relationships are not harmful to children" since it seems like it's pushing one POV a bit too much and could get editors into hot water if research suggests a contrary idea and they attempt to add information about it, but I doubt that this would get anywhere in the Wikipedia's current climate.
(Obligatory disclaimer because a bunch of people keep misinterpreting my comments: I'm not a pedophile and I don't advocate for pedophilia. I can't believe that I even have to say this, but apparently making the slightest comment on the matter leads to editors jumping in to warn me that I'm somehow violating the child protection policy.) GrinningIodize (you just lost the game) (talk) 21:20, 26 August 2026 (UTC)
I forgot to add the note part to the lead too: "Note that in this policy, 'child' refers to real-world children and not fictional characters." GrinningIodize (you just lost the game) (talk) 21:21, 26 August 2026 (UTC)
”Inappropriate” is not limited to sexual or romantic interactions. Blueboar (talk) 22:05, 26 August 2026 (UTC)
Are you aware of any examples of cases where someone pursued some other kind of inappropriate relationship forbidden under that policy? It would seem that we should try to keep the policy as clear-cut as possible since it has great consequences for whoever it is applied to. GrinningIodize (you just lost the game) (talk) 22:13, 26 August 2026 (UTC)
Are you aware of any actual problems caused by the current wording? —Myceteae🍄🟫 (talk) 22:32, 26 August 2026 (UTC)
For that particular part, not really, but I can see how it would easily become problematic. I don't see why we shouldn't reword it unless there's some case that I'm missing here that can't be resolved some other way (ANI perhaps?). GrinningIodize (you just lost the game) (talk) 22:44, 26 August 2026 (UTC)
I'm not really sure we'd always know if there were actual problems caused by the current wording. If someone engages in a relationship that is, by the wording of this policy "inappropriate" they would be blocked and banned, and essentially nobody would consider an appeal - for good reasons if the relationship is/was one we desire to shun (for want of a better term) but we wouldn't hear about it if the relationship wasn't one of those. Thryduulf (talk) 22:57, 26 August 2026 (UTC)
I understand that and addressed it in my comment below. —Myceteae🍄🟫 (talk) 22:59, 26 August 2026 (UTC)
We should not loosen up this policy. I understand that the idea is to tighten the language but I do not support trying to over-define this policy and make ever finer distinctions. "Someone could misinterpret it" or "someone did read it differently in one discussion" is not compelling here. I don't expect to be made aware of cases where actions are taken under this policy but there would need to be a much stronger signal that there is a problem with this policy. I participated in the Clop fan art RFC. Although one editor brought up their interpretation of this policy repeatedly, this was ultimately a minor part of the discussion and was not determinative to the outcome. —Myceteae🍄🟫 (talk) 22:54, 26 August 2026 (UTC)
It's not so much a loosening as removing extra implications that the community might not have desired when it decided on that policy. GrinningIodize (you just lost the game) (talk) 23:01, 26 August 2026 (UTC)
I'm not sure we don't want them. I get that inappropriate is open to interpretation. I think romantic or sexual is too narrow. But even if we add that, people can argue about whether this or that is romantic or sexual. Plenty of grooming behavior is not per se sexual or romantic but is part ultimately inappropriate given the end game. I guess we'll see what people think. —Myceteae🍄🟫 (talk) 05:06, 27 August 2026 (UTC)
I do think it is worth looking at the policy and seeing whether all the plausible good-faith readings match what we want to allow and what we want to disallow. The answer might be that they do and no changes are needed, but we can't know that unless we look at it with an open mind. Thryduulf (talk) 00:56, 27 August 2026 (UTC)
What benefit does Wikipedia have from allowing adults to facilitate any type of relationship with children? Katzrockso (talk) 01:16, 27 August 2026 (UTC)
When the relationship is something like mentor to mentee, Wikipedia can derive significant direct benefit. Purely platonic friendships can indirectly benefit the project (an editor who feels welcome and part of the community is more likely to stick around). The are obviously not intended to be covered by the term "inappropriate relationshpis", and are probably not covered by reasonable interpretations of that word, but they are unquestionably are covered by your term "any type of relationship". Thryduulf (talk) 01:30, 27 August 2026 (UTC)
Nope. If anything the discussions at the Clop article shows we should make the policy more strict. -- LCU ActivelyDisinterested«@» °∆t° 12:16, 27 August 2026 (UTC)
In what way? Are you arguing in favor of censoring clop representations of these entirely-fictional non-human characters? That doesn't make a ton of sense to me personally. GrinningIodize (you just lost the game) (talk) 14:02, 27 August 2026 (UTC)
You may not person see a ton of sense in it, that doesn't mean that other will agree with you. -- LCU ActivelyDisinterested«@» °∆t° 14:35, 27 August 2026 (UTC)
Yes the encyclopedia might contain images that some people find offensive, if they are appropriate in context. Discussions on whether an image is appropriate aren't won by shouting !NOTCENSORED!. -- LCU ActivelyDisinterested«@» °∆t° 17:22, 27 August 2026 (UTC)
Whether Clop and similar images are or are not suitable for Wikipedia is nothing to do with the child protection policy, which is about not causing real-world harm to non-fictional children. Thryduulf (talk) 16:28, 27 August 2026 (UTC)
When interacting with children, we must ALWAYS be extra cautious. Even a platonic mentor situation can have unanticipated harmful results. Blueboar (talk) 17:08, 27 August 2026 (UTC)
This appears to be a response to a different comment, but there is a big difference between relationships that are inherently harmful and relationships that can sometimes have unintended harmful side effects. The latter describes pretty much every relationship between any two people. We should always be careful, but if we interpret that to mean prohibiting all interactions between adults and people under 18 we won't have a next generation of editors. Thryduulf (talk) 17:52, 27 August 2026 (UTC)
Whether the are or not is an opinion, but saying they're not doesn't just been they not. -- LCU ActivelyDisinterested«@» °∆t° 17:20, 27 August 2026 (UTC)
I'm saying that sexually explicit images of fictional child like characters may not be appropriate, and could be an child protection issue. That they do not cause harm isn't even certain. They may be legal in the US but that doesn't mean they are immediately excluded from child protection issues. It is your opinion they are not, but just saying that doesn't make it so. -- LCU ActivelyDisinterested«@» °∆t° 17:59, 27 August 2026 (UTC)
The appropriateness or otherwise of sexually explicit images of fictional children are objectively not relevant to a policy that is about non-fictional children. We base our policies and guidelines on evidence, and unless you have some to bring to the table to show that the law in the United States is wrong we go by what the experts say. The most recent sources I've been able to find all say the same thing:
Sexually explicit deep fakes and similar of children are harmful. These are real children, so provide no evidence for your argument.
Sexually explicit images of adults can be manipulated so they appear to depict children. These images may sometimes harm the adult (depending on the circumstances) but that's not a child protection issue. There is no evidence these harm real children.
Some people who sexually abuse children use sexually explicit images of fictional children as part of that abuse. The harm there is the abuse, not the images (I can't immediately find it, but one source I remember reading compared it to sexually explicit role play using a child's non-sexual plush toys, the role play is harmful the toys are not)
One thing that I've not actually been able to find discussed in reliable sources is a comparison with cartoon violence and children's behaviour. Whether there are any negative effects is debated, but any impact is felt by those consuming the violent images not by the fictional characters experiencing the fictional violence.
Separately, people showing sexually explicit images to children is a child protection issue, but the issue is the behaviour of the person showing children those images not, inherently, with the images themselves (in exactly the same way as if they were showing images of gore). Thryduulf (talk) 18:25, 27 August 2026 (UTC)
If you have evidence to show that children are not harmed in anyway by images showing sexualised fictional children then go ahead, I'm not arguing the negative. You show that the US law is actually correct and should be the basis for policy in this international project. -- LCU ActivelyDisinterested«@» °∆t° 18:34, 27 August 2026 (UTC)
No, its not on me to prove a negative it's on you to prove a positive. If there any evidence of images of fictional children (let alone fictional characters that are not even human) causing actual (not theoretical) harm to actual, real, non-fictional children then show it. I've completely failed to find any and I've been looking (on and off) for years. I've seen headlines, but they have all turn out not be based on any evidence at all or based on evidence that shows something different. Thryduulf (talk) 19:03, 27 August 2026 (UTC)
On the contrary, I think we would need a very clear reason to say something like "sexualized cartoon images of childlike characters are never considered harmful to children" in our policy. What a bizarre thing to add. No one was blocked or banned for defending the Clop art pictures. One editor raised the child protection issue repeatedly but the photo was removed because the majority of editors found it out of place in the article for other reasons. —Myceteae🍄🟫 (talk) 22:21, 27 August 2026 (UTC)
We wouldn't say that unless there is specific evidence backing up that claim, and I haven't found that. What I also haven't found is any evidence that they are harmful. What this policy should be explicit about is that its purpose is preventing real-world harm to real-world children. It shouldn't attempt to present an exhaustive list of things that (sometimes) do or don't result in that type of harm. Rather the onus should be, as it always should be with every policy, on those who invoke it to demonstrate that it is relevant to the situation in which they want to apply it - based on evidence if it is disputed. Thryduulf (talk) 00:05, 28 August 2026 (UTC)
But there is nothing in the policy as written that says anything about fictional children or cartoon depictions of children. Someone raised it in a discussion once and it went nowhere. And in fairness to that editor, their concern was about harm to real-world children and they weren't advocating for anyone to be blocked or banned as a result of statements made in the discussion. And, again, the outcome of the RFC was not based on this policy. No users were sanctioned, no statement were removed or suppressed, and the files remain hosted on Wikipedia and Commons. We would never get anything else done if we "clarified" a policy every time someone references an interpretation that others disagree with or find irrelevant to the discussion and no action is taken under said policy. The onus is on editors suggesting a change to persuade the community that it represents an improvement. —Myceteae🍄🟫 (talk) 00:51, 28 August 2026 (UTC)
Editors proposing changes should explain why they would improve the community. Gennybell (talk) 08:19, 29 August 2026 (UTC)
Editors should show how changes help the community. Liztruss811 (talk) 08:22, 29 August 2026 (UTC)
This is a solution looking for a problem. The policy does cover fictional children, not just real children, as it talks about "relationships" not just individuals. It doesn't include appropriate relationships like mentoring already as there is a clear consensus that mentoring is an appropriate relationship. The wording is adequate as is. Each case is decided individually, per our standard review, but everyone knows what "inappropriate" is when they see it. There is no reason to water the policy down to allow fictional depictions, which is against our core values. This is not constructive. Dennis Brown - 2¢ 08:28, 29 August 2026 (UTC)
The policy seems pretty clear to me ("This policy is about the behavior and actions of adult editors with regards to children"). It is not a content policy, but a conduct policy. I do not quite see what it has to do with fictional ponies. —Kusma (talk) 09:10, 29 August 2026 (UTC)
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.
It has become a well-known trope amongst certain circles for years that you can see if someone is Jewish by looking in their Wikipedia early life section. Currently we have a Jew-tagging policy, but it is only enforced in the first paragraph. Many editors (including but not exclusively malicious ones) put the fact that someone has Jewish heritage in the early life section. The problems are that it is not applied consistently to all ethnicities and religions, it is used as a trope, and it is often not notable at all.Koubaki (talk) 19:59, 29 August 2026 (UTC)
Can you provide any evidence for any of this, such as articles where it is happening? Phil Bridger (talk) 21:11, 29 August 2026 (UTC)
It's not specific articles, it's a trope that has been circulating in certain circles and I think we need to address it. Koubaki (talk) 22:20, 29 August 2026 (UTC)
In order to address a trope we must first check if it's true. Phil Bridger (talk) 09:05, 30 August 2026 (UTC)
I've withdrew this proposal, but I was talking about enforcing it, currently it's only an essay. Koubaki (talk) 10:33, 30 August 2026 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Requiring RFCBEFORE discusisons/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)
None of that requires an RFCBEFORE discssion and editors routinely argue an RFCBEFORE discussion isn't required to start an RFC. voorts (talk/contributions) 14:11, 2 September 2026 (UTC)
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)
I know that. That's why I am proposing to start an RfC that would require workshopping for certain RfCs. voorts (talk/contributions) 14:32, 2 September 2026 (UTC)
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)
And in case this is getting frustrating, this is the sort of quagmire you're suggesting be required:) Kowal2701 (talk, contribs) 14:47, 2 September 2026 (UTC)
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)
For workshopping amendments to PAGs maybe have "recommended" or "strongly recommended" as an option to add to PROPOSAL Kowal2701 (talk, contribs) 22:55, 2 September 2026 (UTC)
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)
Yes. Thank you for that framing. I'm open to other ideas as well. voorts (talk/contributions) 15:32, 2 September 2026 (UTC)
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)
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)
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)
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)
Again, this discussion is a workshop to formulate an RfC, not to discuss the merits. voorts (talk/contributions) 19:12, 2 September 2026 (UTC)
(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)
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)
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)
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)
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)
What topics do you have in mind? Katzrockso (talk) 19:23, 2 September 2026 (UTC)
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)
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)
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)
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)
Well if the closer believes consensus is to close, and you believe the situation was wrong to close, close review exists. Such closes due to rfcbefore already exist and will continue to exist regardless User:Bluethricecreamman(Talk·Contribs) 13:41, 4 September 2026 (UTC)
Not saying ofc if these were good closes or bad (and quite a few are), but they do exist . User:Bluethricecreamman(Talk·Contribs) 13:43, 4 September 2026 (UTC)
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.
I'm not sure what more is actually wanted than what already exists in the WP:RFC page, as quoted here: "It may be helpful", and it's sometimes not helpful. Anyone who wants to make a change specifically to the Wikipedia:Policies and guidelines should really be looking at Wikipedia:Policies and guidelines#Substantive changes instead of expecting the RFC page to have special instructions that will affect maybe as much as 5% of the RFCs each year (and probably closer to 2%). WhatamIdoing (talk) 03:27, 4 September 2026 (UTC)
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)
Then the rule you want to enforce already exists. Why are you trying to reinvent the wheel?
Or are you mainly looking for a way to prevent other people from having the discussions that they want to have? WhatamIdoing (talk) 03:48, 4 September 2026 (UTC)
Can you please stop assuming bad faith? Reasonable people can disagree on these issues. voorts (talk/contributions) 15:18, 4 September 2026 (UTC)
Here's my starting point:
We're WP:NOTBURO, so we avoid proposals to add another bureaucratic step to processes.
Our primary approach to the rules is descriptive (=writing down what people are already doing).
Our primary approach to policy writing is not prescriptive (=changing the rules so I can force the community to change its behavior).
Creating a rule to "fix" a small fraction of uncommon cases is WP:CREEPY.
Do those sound like reasonable principles to you? Do you subscribe to all of them? WhatamIdoing (talk) 22:40, 4 September 2026 (UTC)
This discussion is about framing an RfC. I am not here to debate the substantive issue with you. voorts (talk/contributions) 23:07, 4 September 2026 (UTC)
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)
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.
I think it looks good as long as it is bolded that its a requirement specifically for policy or guideline or information page changes. User:Bluethricecreamman(Talk·Contribs) 00:25, 5 September 2026 (UTC)
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.
Maybe we should re-point the shortcut, to make it align with editor's guesses about what the WP:UPPERCASE 'should' point to? WhatamIdoing (talk) 00:46, 5 September 2026 (UTC)
What section would you put this in? voorts (talk/contributions) 00:47, 5 September 2026 (UTC)
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)
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)
"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)
Please note that I am adding this section above the April Fool's section which was started earlier but appears below, because the section edit link on that one isn't working, but the link on §Requiring RFCBEFORE discusisons/workshops works fine. I took a couple of shots trying to figure out what was wrong, but am leaving it to the next person who wants to give it a go. (I did have an idea to contribute, but that'll be for another time.) Mathglot (talk) 05:25, 6 September 2026 (UTC)
Aha, it may be the previous section; this one is uneditable too. Good luck, Mathglot (talk) 05:26, 6 September 2026 (UTC)
I've replaced the equals signs in the boxed section with = and that seems to have done the trick. Has this bug been reported on Phabricator yet? Thryduulf (talk) 08:45, 6 September 2026 (UTC)
Actually I spotted that that edit broke the box, but when I remembered to preview that was the {{box}} template thinking the <span> was a parameter so I just removed the span for now as it wasn't really needed. However this is something that would benefit from a more technically knowledgeable person taking a look at. Thryduulf (talk) 08:55, 6 September 2026 (UTC)
(note that this ad changes every time the cache is regenerated, for example when a new comment is added. To refrence a specific ad, use its number.)
It would be very funny if these fake ads were added in between every subsection on April Fools day. To avoid messing with watchlists, this should be done without editing articles. Is this a good idea? Velocifyer (talk) 14:55, 5 September 2026 (UTC)
See Wikipedia:Rules for Fools#General #1, All jokes and pranks must be kept out of the "article" [...] namespaces. Jokes that affect articles, including files, categories and templates that are used in the article namespace,[11] will be treated as vandalism.. Thryduulf (talk) 15:28, 5 September 2026 (UTC)
I meant that this would be added as an interface change, not an edit. Velocifyer (talk) 15:48, 5 September 2026 (UTC)
I understood that, but it would still impact the article namespace. It's a hard no from me. Thryduulf (talk) 16:29, 5 September 2026 (UTC)
A different suggestion for April 1: disallow ANY April Fools pranks whatsoever. I'm a hard no on any new encroachment. Fund-raising depends on how people view our pedias. People around the planet depend on wikipedians' international reputation for caring about the quality and integrity of the effort. Anything that makes individual wikis look otherwise is contrary to the purpose of Wikipedia. BusterD (talk) 16:35, 5 September 2026 (UTC)
I am fully with BusterD on this one. Lova Falk (talk) 17:22, 5 September 2026 (UTC)
While I find most of the April Fools content rather boring (maybe it just gets old after 20 years), some levity is important. I think people generally trust Wikipedia too much, so the general public would benefit from seeing more vandalism and more jokes that make it clear that Wikipedia can be edited by anyone and, while better than any other existing encyclopaedia, is not always reliable and despite our best efforts, carries some bias. Your other point about reduced fund-raising is only an issue in the very long term, if at all: if you look at User:Guy Macon/Wikipedia has Cancer you will see that the WMF has more than enough money to run the wikis for a very long time without any donations. (They might not have enough money to do some of the other stuff they want to do, like spending it on expensive lawyers to fight unionisation, but I find it hard to see less money for that as a bad thing). —Kusma (talk) 20:08, 5 September 2026 (UTC)
I decided not to opine over-much. Velocifyer's suggestion was to make fake advertisements with the purpose of fundraising, and my reply was that deliberately choosing to make deceptive links to the various language pedias as a method of fundraising might run counter to our collaboration's purpose. BusterD (talk) 21:15, 5 September 2026 (UTC)
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)
@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)
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)
The question is whether this will help new editors to develop good judgement. LittlePuppers (talk) 04:55, 16 August 2026 (UTC)
Please just throw me in a ditch. Polygnotus (talk) 18:48, 15 August 2026 (UTC)
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)
Fixing this error improves the comment's correctness. — Hex•talk 15:46, 16 August 2026 (UTC)
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)
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)
Kill it with fire. The only good thing about this is that it appears we have the ability to turn it off. Tazerdadog (talk) 20:54, 15 August 2026 (UTC)
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)
@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)
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.
Let's nip this in the bud please before it becomes a fait accompli (if it hasn't already). Incredible that there's been no community consultation about this AFAICT Kowal2701 (talk, contribs) 22:35, 15 August 2026 (UTC)
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)
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)
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)
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)
It's just very difficult to have a constructive discussion/approach when most are worried/anxious they're going to end up ignored and powerless Kowal2701 (talk, contribs) 01:14, 16 August 2026 (UTC)
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)
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)
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)
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.
Okay, anyway -- more to come from team members who are deeper in the details. MMiller (WMF) (talk) 04:03, 16 August 2026 (UTC)
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)
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)
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)
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)
Okay, I was looking at a different file from Gnomingstuff and one which is at least a few weeks old. Take that how you will. LittlePuppers (talk) 06:19, 16 August 2026 (UTC)
Glancing through what is (I think) the latest (and much longer) version, there may be some improvement, but most of my thoughts still apply. LittlePuppers (talk) 06:29, 16 August 2026 (UTC)
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)
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)
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.
Further context or not, saying "the Atlantic" is not going to cause confusion. CMD (talk) 07:06, 16 August 2026 (UTC)
"American English is preferred on Wikipedia", great so it's not just wrong but will make a bad situation worse. -- LCU ActivelyDisinterested«@» °∆t° 09:07, 16 August 2026 (UTC)
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)
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•talk 15:58, 16 August 2026 (UTC)
The sheer quantity of bullshit from the WMF is exhausting at this point. Cremastra (talk·contribs) 04:41, 17 August 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
Or, if you don't like the above 4-tilde signature, --Guy Macon (talk) (3 tildes), --01:13, 16 August 2026 (UTC) (5 tildes), or --01:13, 16 August 2026 (UTC)Guy Macon (talk) (7 tildes).
Guy, on that last one, you don't need to add a signature at all anymore. Discussiontools will do it for you. I haven't added one to the end of this post, for example. In solidarity, asilvering (talk) 01:04, 16 August 2026 (UTC)
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)
Guy would need to be using DiscussionTools for that, but unfortunately they are using classic full page source editing where none of those helpful things will occur. DLynch (talk) 13:13, 16 August 2026 (UTC)
FYI I made Module:Word count, I can refine this further if you think it would be useful. It does not 100% solve the issue you mention Czarking0 (talk) 15:57, 16 August 2026 (UTC)
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)
+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)
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)
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)
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)
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)
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)
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)
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)
@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)
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)
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)
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)
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)
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)
That’s a fair point; I hadn’t thought of that. (Yet another reason why this is a terrible idea.) Cheers, 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯(𝔱𝔞𝔩𝔨) (any/all) In solidarity. 05:39, 16 August 2026 (UTC)
The solution for this is making prompts publicly available and allowing each community to tweak them. Alaexis¿question? 06:36, 16 August 2026 (UTC)
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.)
Most adults have a lot more experience with spelling than they do with Wikipedia's guidelines. LittlePuppers (talk) 06:58, 16 August 2026 (UTC)
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)
That would definitely fix that issue (I’m surprised I didn’t think of that, to be honest). Cheers, 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯(𝔱𝔞𝔩𝔨) (any/all) In solidarity. 00:11, 17 August 2026 (UTC)
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)
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)
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)
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.
More information suggested copyedits ...
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
Close
Most of these seem like pretty decent suggestions, don't dip into npov/tone danger zones, and are simple enough for new editors to review and handle. ScottishFinnishRadish (talk) 00:14, 20 August 2026 (UTC)
Also, that might be the first time my first random article click wasn't about a sports ball player. ScottishFinnishRadish (talk) 00:15, 20 August 2026 (UTC)
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)
Why is it a problem that people use Grammarly? RoySmith(talk) 20:02, 20 August 2026 (UTC)
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)
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)
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)
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)
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.
Honestly can't put it any better than that. I do appreciate the response and understand it is the weekend. Gnomingstuff (talk) 07:18, 16 August 2026 (UTC)
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)
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)
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)
Thank you. Sorry, I didn't know who was in the team working on it, I trust all these people. Kowal2701 (talk, contribs) 06:51, 16 August 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
@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.
We can use AI to find typos, but fixing them actually requires an experienced Wikipedian. Polygnotus (talk) 15:33, 16 August 2026 (UTC)
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)
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)
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.
The good news is that volunteer devs can do it, but they will run into the problem that it won't work as I explained above. Polygnotus (talk) 15:46, 16 August 2026 (UTC)
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'm very willing to help test this part of the tool. I have experience with editors doing this well and less well. In solidarity, —Femke (talk) 🐦 15:58, 16 August 2026 (UTC)
@Femke You can try WP:SCRIPTREQ, the people there are a lot more agile than the WMF is.
Please ping me if you have something I may be able to help test it. Polygnotus (talk) 16:02, 16 August 2026 (UTC)
Tbh I still think we should look at incorporating SEWP articles here as 'simple summaries', but that's a different discussion Kowal2701 (talk, contribs) 15:47, 16 August 2026 (UTC)
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)
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)
Adding a CTA, if we get consent from the Simplewiki regulars, may be a good idea. Polygnotus (talk) 16:04, 16 August 2026 (UTC)
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)
What kind of typos is AI fit to resolve that WP:AWB is not? Czarking0 (talk) 20:13, 16 August 2026 (UTC)
One thing I'm having in mind are typos that depend on the context to make sense of them (or to whether there is a typo to begin with). Chaotic Enby (in solidarity · talk · contribs) 20:19, 16 August 2026 (UTC)
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)
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 solidarity 20:49, 16 August 2026 (UTC)
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)
I'm saying it might be correct (not that it is correct), but determining whether it is is a judgement call I don't want an AI to make. * Pppery *(alt)in solidarity 21:22, 16 August 2026 (UTC)
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)
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)
(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)
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•talk 16:02, 16 August 2026 (UTC)
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)
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)
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 ‑‑gurkubondinn 00:26, 17 August 2026 (UTC)
"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)
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. ‑‑gurkubondinn 11:06, 17 August 2026 (UTC)
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
Note: this week, I'm going to see if we can share a spreadsheet so you can see all of the model-generated suggestions in one place rather than having to tap around the wiki looking for them.PPelberg (WMF) (talk) 00:59, 17 August 2026 (UTC)
I wrote a small script so you can view the list of suggested edits on an article without needing to enable the beta feature, switch to VisualEditor, or add that line to common.js to enable "experimental" suggestions: User:DVRTed/sandbox/edit-suggestions.js. — DVRTed (Talk) 03:06, 17 August 2026 (UTC)
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)
@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.
ii. Seeing all of the suggestions in one place so that you don't have to hunt them down yourself.PPelberg (WMF) (talk) 22:49, 17 August 2026 (UTC)
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)
The latter would fail WP:NOLLM, so that would be a complete nonstarter. The former is not great either. ‑‑gurkubondinn 23:15, 17 August 2026 (UTC)
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)
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. ‑‑gurkubondinn 23:44, 17 August 2026 (UTC)
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)
@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)
@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?"
ii. Please correct me if I've misinterpreted what you've said PPelberg (WMF) (talk) 05:32, 19 August 2026 (UTC)
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)
I really appreciate and agree with the branding note Rhododendrite gives here. Best, Barkeep49 (talk) 22:48, 16 August 2026 (UTC)
A humorous interlude
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)
Also available in Africa. I think I'll stick to the Commons maps. Certes (talk) 14:30, 17 August 2026 (UTC)
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)
I don't know about this particular channel but loads of them are (almost) fully automated with no human in the loop. Polygnotus (talk) 15:39, 17 August 2026 (UTC)
Then again, aside from quite a few mistakes, have you all seen the "Chloe vs History" channel on youtube? Quite the advancements in AI lately. Some of the advancements have been made on this channel, which should probably have a Wikipedia page. Randy Kryn (talk) 15:42, 17 August 2026 (UTC)
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)
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)
PS, it doesn't take AI to generate garbage maps. Some people are able to do it all by themselves with nothing more technologically advanced than a sharpie. RoySmith(talk) 16:22, 17 August 2026 (UTC)
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)
"Chiiicago". AAND it's in multiple places at once. Ladies,Gentlemen and enbies, The Chicago hivemind.Starlet 01:43, 25 August 2026 (UTC)
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)
I'd support that. I've had enough with AI turning everything to shit, and clearly WMF can't take no for an answer. Tercer (talk) 15:55, 17 August 2026 (UTC)
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.
The WMF is a different story unfortunately. Polygnotus (talk) 15:59, 17 August 2026 (UTC)
Does Polygnotus always refer to himself in the third person? RoySmith(talk) 16:03, 17 August 2026 (UTC)
Polygnotus does not. But Polygnotus could! Polygnotus (talk) 16:05, 17 August 2026 (UTC)
AI, or LLM? Cluebot, for example uses machine learning (AI but not LLM) to great benefit with remarkably few errors. Certes (talk) 16:36, 17 August 2026 (UTC)
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)
I would absolutely support a ban on AI (LLMs) for (direct or indirect) content generation or suggestion. Ita140188 (talk) 19:12, 17 August 2026 (UTC)
I would support this on principal, at least until the AI industry stops being complete garbage. —Leaf.Sheap⇖ /.°°.\ ⇗ (They•Them) 21:18, 17 August 2026 (UTC)
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)
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)
What would you think of suggestions more along the lines of what I outlined here? ScottishFinnishRadish (talk) 18:32, 20 August 2026 (UTC)
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)
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)
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)
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)
I would support a ban on generative AI touching any Wiki content regardless of whether LLMs improve. JoelleJay (talk) 11:30, 22 August 2026 (UTC)
Continued discussion
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?
Alright -- more to come as we get into those questions. -- MMiller (WMF) (talk) 23:53, 17 August 2026 (UTC)
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)
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)
That is an excellent and fitting username. Polygnotus (talk) 01:53, 18 August 2026 (UTC)
One time I said that I didn't know what "Director of Product" means (I am not a native speaker) and the ex-CEO of the WMF started attacking and accusing me because she couldn't handle mild criticism. Polygnotus (talk) 03:11, 18 August 2026 (UTC)
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)
@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)
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)
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)
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)
Thanks for the response, this is already much more transparency than the last time around and I appreciate it.
I am a bit confused as to whether these questions are for us and for you. Gnomingstuff (talk) 17:35, 18 August 2026 (UTC)
@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)
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)
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)
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)
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://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://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://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://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)
@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)
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)
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)
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)
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)
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)
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)
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)
@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)
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)
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).
What about the other types of LLM suggestions besides NPOV? Well, let’s keep talking here about whether they have potential. Note: we're working on making a spreadsheet available to you all so that you can see all of the suggestions in one place. -- SSalgaonkar-WMF (talk) 17:13, 18 August 2026 (UTC)
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)
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)
@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)
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)
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)
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)
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)
Find some typos that can be fixed or copy that can be edited at https://en.wikipedia.org/wiki/Mircea_II_of_Wallachia. If I were going to refine it I would probably break results down to things that need review from someone with varying levels of experience so you can filter the output to users based on experience. For instance, checking if the source said first born or firstborn is a great task for someone trying to step up from beginner editing. ScottishFinnishRadish (talk) 15:10, 21 August 2026 (UTC)
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)
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)
My apologies if I just read past it and didn't notice, but where is this CSV file? RoySmith(talk) 00:49, 19 August 2026 (UTC)
@RoySmith In , GnomingStuff dug it up. CMD (talk) 01:11, 19 August 2026 (UTC)
Got it, thanks. RoySmith(talk) 01:14, 19 August 2026 (UTC)
We'll be sharing a clearer spreadsheet version (with the most up-to-date entries) tomorrow, per Peter above. HTH. Quiddity (WMF) (talk) 01:17, 19 August 2026 (UTC)
Why are we working on suggestions?
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)
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.
And I just reread your post and realized you already did #2. LittlePuppers (talk) 21:21, 18 August 2026 (UTC)
@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.
On the topic of gadgets and user scripts, we're with you here. In fact, doing what you described helped prompt the work we're partnering with @Alaexis on to turn a tool he wrote for identifying cases where a source might not support its associated claim into a new experimental suggestion. PPelberg (WMF) (talk) 23:13, 18 August 2026 (UTC)
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)
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)
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)
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.
Sharing in case you and others are interested to learn about this other project and participating in testing and giving feedback. RHo (WMF) (talk) 22:01, 19 August 2026 (UTC)
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)
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.
---
i. E.g. contents of clipboard metadata and the absence of a reference within a defined amount of new textPPelberg (WMF) (talk) 23:03, 18 August 2026 (UTC)
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)
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)
@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)
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.
Having our cake and eating it would be nice, but I do tend towards constructive edits over using articles as a sandbox. Certes (talk) 21:46, 19 August 2026 (UTC)
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)
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)
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)
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)
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)
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.
Thank you! Will take a look Gnomingstuff (talk) 22:43, 19 August 2026 (UTC)
You bet and thank you! PPelberg (WMF) (talk) 22:49, 19 August 2026 (UTC)
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)
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)
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)
@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...
Great spots and noted. We'll investigate whether there are things we could do to exclude these two category of issues you're describing. PPelberg (WMF) (talk) 23:35, 20 August 2026 (UTC)
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)
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)
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?
Asked as another way: if we could do this all over again, what would you imagine the "ideal" process to be?PPelberg (WMF) (talk) 23:08, 20 August 2026 (UTC)
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)
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)
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)
Seconding all of these Gnomingstuff (talk) 06:14, 22 August 2026 (UTC)
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)
@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)
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.
In the meantime, thank you all for this helpful feedback. PPelberg (WMF) (talk) 18:25, 26 August 2026 (UTC)
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)
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)
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.
Does anyone see issues with this proposed question? Are there any revisions? BilledMammal (talk) 07:42, 21 August 2026 (UTC)
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)
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)
yeah, I think this may be premature for now, but worth revisiting if there are any disasters Kowal2701 (talk, contribs) 18:24, 22 August 2026 (UTC)
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)
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)
The whitelist system works well for AWB/JWB. Certes (talk) 21:13, 27 August 2026 (UTC)
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.
Some abuse/vandalism prevention tools by definition cannot be opt in. Alaexis¿question? 20:18, 21 August 2026 (UTC)
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)
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)
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)
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)
I think it's only suggesting permissions for LLM tools that would potentially be more prone to abuse, not for any and all in testing. ChompyTheGogoat (talk) 07:13, 28 August 2026 (UTC)
There isn't any limiting language in the comment, so I (and most people, probably) would think it would apply to all LLM tools. MetalBreaksAndBends (One for all) 23:42, 28 August 2026 (UTC)
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)
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)
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)
Do you mean a full rfc for each tool or an RFC for this proposal? MetalBreaksAndBends (One for all) 06:25, 29 August 2026 (UTC)
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)
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)
Yes, absolutely. Ymblanter (talk) 08:10, 23 August 2026 (UTC)
Absolutely agreed on all of this Gnomingstuff (talk) 19:01, 23 August 2026 (UTC)
+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)
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)
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)
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)
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)
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)
So me and the other board members repeating the same things that the 3 board members have already said
if only there was something they could do instead of repeating themselves! ah well Gnomingstuff (talk) 03:07, 20 August 2026 (UTC)
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)
"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)
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)
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.
Pay careful attention to the section titled The Lie: “There are no union-avoidance law firms involved”. --Guy Macon (talk) 09:17, 20 August 2026 (UTC)
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)
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)
Wow, and that comes from a community appointed trustee... Ita140188 (talk) 09:54, 20 August 2026 (UTC)
With a background in communications ironically ~ In solidarity 🦝 Shushugah(talk) 17:08, 21 August 2026 (UTC)
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)
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)
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)
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)
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)
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)
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 will work 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)
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)
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)
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)
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)
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)
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)
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)
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)
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.
Also, there’s a similar discussion happening on the proposal Talk page in case you want to follow along there. SPerry-WMF (talk) 21:22, 1 September 2026 (UTC)
@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)
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)
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)
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)
@SPerry-WMF, when you were looking at wish "size", how small was "small"? Might there be room for "extra small" wishes? In solidarity, asilvering (talk) 20:31, 4 September 2026 (UTC)
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)
Wikimedia Foundation Bulletin 2026 Issue 16
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on August 15. Please help translate.
Future of Community Wishlist
Highlights
Simplifying account creation: The Special:CreateAccount page has been simplified as part of ongoing work to modernize the account creation experience. Multiple account creation experiments show that a simpler form helps newcomers complete registration.
Movement Ecosystem strategy: Deadline to provide feedback on the first version of the proposal are extended until Sep 30 to allow more time for community feedback and discussion.
New format for the Community Wishlist: You can read the proposed ideas on Meta. This new process plans to improve how wishes are triaged, voted on, and prioritized in a way that is transparent and balanced across project families and language editions. Please let us know what you think will work well or if there are ways to make this proposal stronger. This consultation is open for two weeks.
Improving page performance: In order to improve page performance, images now load when they are viewed. This means images that are lower down within an article will not load if a reader never scrolls to that part of the page, which may affect some image-related metrics.
Android Reading list updates: Some of the recent Android releases include updates to the Saved feature. This first round of changes on the Android app include redesigning the "Saved" tab to include an "All articles" view, and remove the user-facing default "Saved" reading list.
Reading list on desktop: Reading lists has been released on Chinese, Bengali, Czech, and Vietnamese Wikipedias. The feature is now available for logged-in users on those wikis.
Event Registration tool: The Worklist feature for the Event Registration tool is now live on all Wikimedia wikis. With Worklist, event organizers can add the articles their event will focus on directly to the event page. The Worklist also powers Event Pathways which notifies other editors of the upcoming or ongoing event when they edit an article featured in the event’s Worklist.
Call for Projects and Mentors for Outreachy: Wikimedia is participating in Round 33 of the Outreachy program that runs from December 2026 through March 2027. The deadline to submit projects on Phabricator is Sept 4 at 4pm UTC and the project list will be finalized by Sep 11.
Tech News: The latest highlights from Tech News week 34 and 35 include that a new Wikipedia in Bole has been created. See also the 58 community submitted tasks that were resolved over the last two weeks.
UwER Conference: In December, the Wikimedia Portugal and Wikimedia Foundation will be hosting a first-of-its-kind convening for users with extended rights. Applications to attend opened August 13 and will close on September 4.
Don't Blink: The latest developments from around the world about protecting the Wikimedia model, its people and its values.
Legal footer update: The Foundation had updated the Legal and Safety Contact Information on 300+ content wikis. The project adds a link to a Foundation-managed central page where people can find contact information to report illegal issues and serve official legal notices. This helps to resolve gaps if community-managed contact pages are missing or incomplete.
AffCom: The Affiliations Committee is extending the pause on new affiliate recognition until the affiliate recognition and funding model is further clarified.
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!
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)
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)
Just out of curiosity (and if you don't mind me asking), what makes you unsure that this union is good for editors? Some1 (talk) 02:31, 4 September 2026 (UTC)
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)
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)
I feel like every decent job should support the mental health of their workers, especially anything that deals with the public in any sense. Clovermoss🍀(talk) 04:20, 4 September 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
Has there ever been an example of unpaid volunteers unionizing?
In most jurisdictions labor laws (including the National Labor Relations Act in the United States) explicitly deny union eligibility to anyone who does not receive or anticipate economic compensation as not being a statutory employee.
In 2015 Reddit found that while unpaid volunteers cannot form a union, they certainly can go on strike
When management of The Trevor Project attempted to silence unpaid volunteers and only allow paid union members to voice their concerns and frustrations, the union, Friends of Trevor United stood with the unpaid volunteers.
Many volunteer fire departments are operated by unpaid volunteers who cannot form traditional labor unions, Instead, many of them form Volunteer Firefighter Associations, who in many cases operate exactly like unions negotiating response protocols and equipment standards. Many firefighter's unions opposed this.
I think that our newly formed union -- AFTER reaching a labor agreement -- should form a "Friends of WWU" group that can present proposals and take not-binding advisory votes on them.
I don't think the WWU should support or oppose anything having do do with the relationship between the WMF and the volunteers prior to negotiating a contract. Best to make the official word "we don't comment on issues like this." --Guy Macon (talk) 06:23, 4 September 2026 (UTC)
Love this question! Within the scope of US legislation National Labor Relations Act, this would not be possible. (Frequently NLRB challenges hinge on whether interns are...volunteer or working, in cases of academia, reality tv shows and other cases)
..but on other hand, loss of wages etc.. is not a principle concern of volunteer associations/unions. This is a topic that has come up frequently in different discussions and there is definitely appetite for it. I personally would like to explore this topic more after Wikipedia:WikiProject_Organized_Labour/2026_Online_Campaign is over. There are currently 788 editors registered from at least 12 language groups which would also bring us the cross-wiki legitimacy that enwiki is often criticized for (while being the most numeric). ~ In solidarity 🦝 Shushugah(talk) 10:29, 4 September 2026 (UTC)
It was mentioned above that the foundation decided a Global Council could not happen. The WMF gets to decide no such thing. The WMF may (depending on the question above) decline to recognise an editors' organisation. However, it certainly can't stop one existing, making demands, and in the worst case backing up those demands with various forms of action. Certes (talk) 11:03, 4 September 2026 (UTC)
This gives a lot of credence to the idea that fulfilling a labor activist role play fantasy has been a major factor in this whole saga. Thebiguglyalien (talk) 13:27, 5 September 2026 (UTC)
One person's one comment gives a "lot" of credence to your theory about what's a "major" factor in a "saga" involving thousands... riiight... Levivich (talk) 13:37, 5 September 2026 (UTC)
Thebiguglyalien, would you be so kind as to let me know what part of the post you replied to you are describing as "fulfilling a labor activist role play fantasy"? Thanks! --Guy Macon (talk) 15:37, 5 September 2026 (UTC)
Miscellaneous
Wikipedia App Central Notice Campaign
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.
As always, questions and thoughts are welcome, and we'll update this thread (or follow-up) if we plan any significant changes. NNawaz-WMF (talk) 14:50, 19 August 2026 (UTC)
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)
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)
Hi, Amal!
I wonder whether they were asking about how to search for a category, when they don't know what the name of the category is. WhatamIdoing (talk) 15:40, 27 August 2026 (UTC)
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)
If you could give the apps team a list of the most important features to add as soon as possible, what would be at the top of your list? WhatamIdoing (talk) 15:41, 27 August 2026 (UTC)
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)
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)
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)
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)
@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.
I suppose my comment here won't change anything, but I wanted to put it out there. David10244 (talk) 01:26, 30 August 2026 (UTC)
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)
Not sure where to put this
Found this while cleanig deprecated parameters. Akeel Inham has had a "will be draftified" tag since last year? Does draftify have a massive backlog, or was this just missed? EmergentAnarchy (talk) 16:34, 22 August 2026 (UTC)
This was apparently tagged as a result of a massive RFC (shortcut: WP:LUGSTUBS2) three years ago. I have barely begun to read through the RFC but it appears that this article meets the criteria for draftification. It's not clear to me why this hasn't been moved to draft space yet. If there's a reason this was spared, and it's not just an oversight or a result of a large backlog, then I would expect that to be clearly documented. Pinging the RFC closer @HJ Mitchell, who might have some insight into what happened and should happen here. —Myceteae🍄🟫 (talk) 17:11, 22 August 2026 (UTC)
What happened is that a lot of editors voted for someone else to do the work, and then got mad that other WP:VOLUNTEERS didn't instantly do their bidding. Voting for someone else to do work that I refuse to do myself has been one of the more unfortunate trends over the last few years. (For clarity: the OP is not one of these people. The OP is only asking about a confusing message on an article.)
Then it turned out that a lot of these articles either shouldn't be moved to the draftspace at all, because they're notable athletes, and nearly all of the rest shouldn't be moved to the draftspace because they should just be redirected to a team roster. More than 95% of the original list has already been handled; just 54 tagged articles remain in the mainspace today. Most of them are in South Asian countries. Wikipedia talk:WikiProject Cricket is the place to post if you want something useful done about this one. WhatamIdoing (talk) 15:58, 27 August 2026 (UTC)
Thanks. I figured it had most likely fallen through the cracks. I couldn't find a suitable redirect target so I've moved it to Draft:Akeel Inham. I'll drop a note at WP:CRICKET and WP:SRILANKA in case someone wants to work on it. —Myceteae🍄🟫 (talk) 22:54, 27 August 2026 (UTC)
Following Myceteae's request at WT:CRIC, I've restored Akeel Inham from draft, as it should be redirected to List of Burgher Recreation Club cricketers, which I will create. Inham is a notable player, having made some 65 top-class appearances to date, but when the article will ever acquire significant coverage is anyone's guess, so a redirect is the sensible option at present.
I've copied a list of the 54 tagged articles. I'm familiar with Lugnuts' stubs, and I expect to find that all of these are like Inham. I can virtually guarantee they are all notable players, but there won't be any SIGCOV. So, like Inham, they all need to be redirected to a club list. There's a win for CRIC in this as we need lists of all top-class players by club, and we're a long way behind in our Sri Lankan coverage.
I should add that I will do all this in my own time, as and when I feel like doing it. If anyone thinks I will instantly do their bidding (see above), they will be, shall we say, told otherwise. Thanks, Jack (talk) 19:36, 3 September 2026 (UTC)
Calendar dating
I see a lot of dating using the religious AD and BC while others use the modern secular BCE and CE. As this platform is used by more than Christian readers, I propose standardized CE and BCE throughout. ~2026-46089-12 (talk) 05:47, 23 August 2026 (UTC)
See WP:ERA. Wikipedia is built by people from all over the world, and with many different backgrounds. Therefore, standards for certain issues (BC/BCE, formats of dates, citation style, color/colour, and probably more) are not imposed on everyone. Johnuniq (talk) 06:21, 23 August 2026 (UTC)
@~2026-46089-12 That's fine as a standard, but it's not high priority to change all existing articles. David10244 (talk) 01:29, 30 August 2026 (UTC)
No, it's not "fine as a standard", whatever that is supposed to mean, and it is against the WP:ERA policy to change any article without consensus. Changing all articles is no priority at all. Johnbod (talk) 00:57, 6 September 2026 (UTC)
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)
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)
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)
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)
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)
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)
The lack of filter options is a major drag. I found some stuff to do via WP:Backlog which seems to be entirely based on templates, but at least allows for (some) filtering. Long is the way (talk) 20:35, 26 August 2026 (UTC)
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).
And if you have further ideas for how the Growth team can better support new editors, I'm always eager to hear feedback and ideas at Wikipedia talk:Growth Team features. - KStoller-WMF (talk) 20:54, 26 August 2026 (UTC)
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)
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)
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)
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)
@ChompyTheGogoat - Thanks, I appreciate the additional thoughts on onboarding, navigation, and ways to better support newer editors! I’ve shared the Newcomer Task comparison stats in my response here. KStoller-WMF (talk) 21:42, 28 August 2026 (UTC)
Not for tasks. A "how to edit Wikipedia" the very first time someone goes to edit. ChompyTheGogoat (talk) 08:07, 27 August 2026 (UTC)
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)
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)
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)
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)
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.
Teahouse folks probably have some good ideas about which problems they see most often. WhatamIdoing (talk) 04:31, 29 August 2026 (UTC)
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)
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)
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)
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)
@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)
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)
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)
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)
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)
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)
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)
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)
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)
See my comments below re: comparison between new editors who utilize the tool vs all new editors, which are definitely a mixed bag. ChompyTheGogoat (talk) 07:17, 28 August 2026 (UTC)
@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)
If you know a way to identify when an edit adds a link from metadata, then Wikipedia:Request a query should be able to give you the numbers. (Maybe compare all edits with a byte size of +4?) WhatamIdoing (talk) 04:47, 29 August 2026 (UTC)
@Chipmunkdavis As I understand it, the Add a Link structured task is a newcomer task. In the recent VP discussion, there was discussion of the original testing (mw:Growth/Personalized first day/Structured tasks/Add a link/Experiment analysis, December 2021) and other data. Initial testing compared newcomers who had the Add a Link task turned on to those who did not. Further analysis looks at edits with the Newcomer task and Suggested: add links tags in edit summaries. I'm not involved in this work and had not followed this previously. This is my understanding per recent discussions; please correct me if I have gotten something wrong. —Myceteae🍄🟫 (talk) 18:14, 29 August 2026 (UTC)
Yes, there have been a massive number in the last week alone, just from a single user Special:Contributions/Mathworkofpast. You can just take a look at how many of their recent contributions are link additions which have been reverted. Elestrophe (talk) 06:22, 28 August 2026 (UTC)
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)
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.
This is just one person. Multiply by a thousand and you have an idea of the cleanup burden. Gnomingstuff (talk) 17:37, 28 August 2026 (UTC)
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)
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)
Why are you assuming that those edits haven't already been checked (and probably checked repeatedly) by the RecentChanges patrollers? WhatamIdoing (talk) 04:15, 29 August 2026 (UTC)
Because they clearly haven’t, or else they would have gotten fixed? Gnomingstuff (talk) 19:15, 30 August 2026 (UTC)
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)
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)
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)
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)
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)
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)
@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)
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)
There are some overall stats at Special:NewcomerTasksInfo. The Revise Tone tasks seem to be quite a small proportion. Andrew🐉(talk) 09:58, 29 August 2026 (UTC)
Edit conflict - see below. ChompyTheGogoat (talk) 09:58, 29 August 2026 (UTC)
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)
18,000 articles are tagged with {{Promotional}}. How many of those are you personally willing to add a level-of-work parameter to?
That's just one of many templates. I believe that we've only added a requirement for an explanatory parameter in one instance ({{Cleanup}}), and until last month, more than a decade after we "required" it, Category:Cleanup tagged articles without a reason field had hundreds (previously thousands) of articles in it. WhatamIdoing (talk) 16:46, 29 August 2026 (UTC)
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)
You could ask the Twinkle folks if they would build something to support that. WhatamIdoing (talk) 06:09, 6 September 2026 (UTC)
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)
@ChompyTheGogoat, I've been trying to explain that copy-editing is not "easy" to Growth to no avail for years. I continue to wish that community configuration allowed us to set the difficulty of individual tasks. In solidarity, asilvering (talk) 16:49, 29 August 2026 (UTC)
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)
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)
I wonder if the "2 minutes" estimate is meant to discourage full rewrites/to encourage making one improvement and then moving on. WhatamIdoing (talk) 06:11, 6 September 2026 (UTC)
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)
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)
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)
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)
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)
Fully agree with the above and other comments here. As they are set up, they aren't helping anyone. Johnbod (talk) 02:53, 27 August 2026 (UTC)
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)
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)
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)
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)
That's not what it sounds like to me. My read is that it automatically flags edits for patrol based on this internal automated scoring system. Is there some other function of it I'm missing? ChompyTheGogoat (talk) 04:08, 29 August 2026 (UTC)
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)
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)
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)
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)
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)
Just a note on this, the feature as a whole is several years old. Which means there have been several years for stuff like Special:Contributions/Aritonoko to accumulate. Gnomingstuff (talk) 18:17, 28 August 2026 (UTC)
People who earn a checkuser block aren't really evidence of a problem in editing software. WhatamIdoing (talk) 20:45, 28 August 2026 (UTC)
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)
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)
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)
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)
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)
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)
Do you have a link to that information? ChompyTheGogoat (talk) 05:04, 29 August 2026 (UTC)
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)
Also, from the Revise Tone experiment the changes in constructive edit rates did not meet the threshold for statistical significance. ChompyTheGogoat (talk) 10:07, 29 August 2026 (UTC)
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)
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)
@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.
Does that feel like the right direction to you? And are there other approaches or ideas you think we should be considering? KStoller-WMF (talk) 21:31, 28 August 2026 (UTC)
@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)
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
Here's an early prototype if you want to test out the idea. Do you think something like that could be more promising than providing suggestions based on ORES topics? KStoller-WMF (talk) 22:04, 28 August 2026 (UTC)
@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)
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)
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)
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)
I'm going to ask a newcomer which likes using the feature for their opinion. 16dvnk (talk) 14:12, 5 September 2026 (UTC)
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)
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)
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)
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)
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)
@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)
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)
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)
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)
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)
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)
Is it possible that some PendingChanges type of monitor list shows a subset these edits Well, this shows Special:RecentChanges filtered by edits that are tagged with newcomer task, which one can patrol at will. It's possible to filter further by type of task. Cheers, SunloungerFrog (talk) 14:32, 1 September 2026 (UTC)
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)
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)
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)
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)
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)
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)
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)
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.
What edits would you make to Help:Introduction to cover things that you think are missing in that? Cheers, SunloungerFrog (talk) 10:13, 6 September 2026 (UTC)
BTW just a heads up, the WP:JCW compilation now reports whether or not publications and publishers are open access ones. It's not perfect, sometimes there are classes like (delayed open access being the category given to the article, but the infobox just says open-access = yes, so the bot picks one which might not be accurate. Most publishers should be unflagged because the publisher a mix of open and closed access journals, while most publications should probably be flagged as hybrid open access, since most will support a pay-to-make-it-free option.
Things should get considerably more accurate after the next dump, but if you have feedback, please let me know at WT:JCW#WP:JCW update - Open access! Headbomb {t · c · p · b} 11:54, 31 August 2026 (UTC)
Tamzin marked this page as historical in 2015 because it hadn't been edited since 2012. I just came across it yesterday and added an entry, but I was reverted because the page had been marked as historical. Per {{Historical}}, I should seek broader input at a forum like this one in order to revive discussion there. – MrPersonHumanGuy(talk) 17:57, 2 September 2026 (UTC)
Historical is right. It may have once made sense to maintain this page, but even that is dubious (it was created by somebody who is now perma-banned by the WMF). There's certainly no value in it now. RoySmith(talk) 18:20, 2 September 2026 (UTC)
I'd call that pretty-much-unmaintainable. Leave it historical. --SarekOfVulcan (talk) 18:51, 2 September 2026 (UTC)
The text in {{historical}} is terrible and should be changed. Going to the village pump is such a useless suggestion. FaviFake (talk) 23:10, 2 September 2026 (UTC)
No, the wording the fine. It is saying that historical pages should be left alone unless there is at least some discussion at a central noticeboard suggesting that adjusting them is worthwhile. The last substantive edit to the page in question was in June 2010. Johnuniq (talk) 00:15, 3 September 2026 (UTC)
@MrPersonHumanGuy, since you added an entry, and are opening discussion here, you presumably see some purpose in reviving this tracking. What is that? And do you have any suggestions how it could/would be updated sufficiently comprehensively to be used for that purpose, without being a burden on closers or other editors. It seems to have died out of disinterest, so a natural question is: why the interest now? Martinp (talk) 16:43, 3 September 2026 (UTC)
Asides from the fact that the page has been marked as historical since 2015, I personally didn't see why it should be left outdated for good. If new entries shouldn't be added to it anymore, it should be deleted. If anyone wants the page back, they can ask for it back, but they should be encouraged to explain why they want it back. – MrPersonHumanGuy(talk) 17:01, 3 September 2026 (UTC)
I personally would not be upset if it were deleted, but sometimes people find value in seeing how things used to be done, hence the historical tag. RoySmith(talk) 17:15, 3 September 2026 (UTC)
It seems to me no action is needed. One of many historical pages that are kept around, duly marked as historical, with editing it (as you experienced) discouraged. If you wish, you can take it to MFD to discuss deletion, but I suspect you'll get a number of reactions along the lines of "what's the problem? why bother?". Martinp (talk) 11:47, 5 September 2026 (UTC)
Marking pages as historical and keeping them help preserve institutional memory. It's often useful to remember what initiatives didn't work out, and to preserve the discussions that were part of the initiatives, for future understanding. isaacl (talk) 16:07, 5 September 2026 (UTC)
I just read the lead again, where it says Currently this covers DRVs between 16 August 2008 and 18 January 2009, which means that, when I added a recent example of an overturned speedy deletion, that outlier had made that sentence inaccurate. – MrPersonHumanGuy(talk) 16:15, 5 September 2026 (UTC)
Yes, and? Ledes can be changed - and maybe a minor tweak would be appropriate since there were a few later additions, but since there's no point to reviving it there's also little point to changing the description. You don't appear to have any argument for why it should be kept up to date. If it's been untouched for over a decade that's a pretty solid indication that no one finds it useful. ChompyTheGogoat (talk) 07:15, 6 September 2026 (UTC)
I've boldly removed the lists. If nothing should be added to them anymore, they shouldn't remain in the current revision. The lede can stay because it describes how things used to work, but not the part that says Feel free to add your own overturned speedy deletions if they're not listed here. which could've encouraged other contributors to violate the page's historical status as well. – MrPersonHumanGuy(talk) 10:34, 6 September 2026 (UTC)