Wikipedia:Village pump (idea lab)

There should be a banner (at least) about age verification laws, why they are bad, why they would harm free software, why digital wallets will force everyone to have Android or iOS, why some variants (like the New York one) would even ban root access to your own computer! Gugalcrom123 (talk) 17:16, 10 March 2026 (UTC)

I personally am not a fan of age-verification software either, but I don't understand what that has to do with Wikipedia? Sentimental Dork (talk) 19:37, 10 March 2026 (UTC)

They might be what we need to raise awareness. Gugalcrom123 (talk) 19:42, 10 March 2026 (UTC)

If it was directly restricting access to Wikipedia, I would agree. But Wikipedia doesn't take sides on issues or promote causes, no matter how just. Thebiguglyalien (talk) 21:15, 10 March 2026 (UTC)

True. But we do provide factual, neutral, non-advocacy information in articles such as Age verification system, and the better those articles are, and the more they rely on the WP:BESTSOURCES, the better Wikipedia's will understand the subject. I suggest that anyone interested in this find some very good sources and improve the related articles. WhatamIdoing (talk) 03:31, 11 March 2026 (UTC)

It might be genuinely banning free software like GNU/Linux, which Wikipedia runs on. For example, requiring that all OSes have circumvention-proof ID checks kills it. Gugalcrom123 (talk) 14:15, 11 March 2026 (UTC)

Wikipedia has taken sides and promoted causes in similar situations in the past, most notably Stop Online Piracy Act#Wikipedia blackout CauliflowerMoon (talk) 04:12, 13 March 2026 (UTC)

The difference is that was an existential threat to Wikipedia. Age verification, while pointless, moronic, ill-conceived, etc..., isn't. Headbomb {t · c · p · b} 04:33, 13 March 2026 (UTC)

Maybe not now, but age verification laws could affect Wikipedia and other Wikimedia projects (especially the Commons) one day. Some1 (talk) 00:15, 17 March 2026 (UTC)

That hasn’t happened yet. When (not if) it happens, then we can protest it. Dronebogus (talk) 19:08, 22 March 2026 (UTC)

Should we protest it though? Age verification (identity verification, basically) will cut down on like 99% of the sockpuppetry cases. (Granted, the project will probably lose most of its non-socking editors...) Some1 (talk) 02:28, 5 April 2026 (UTC)

It will also ban doing your computing with libre software like GNU/Linux. Gugalcrom123 (talk) 07:40, 5 April 2026 (UTC)

I agree Cayley-Dicksonconstruction (talk) 19:47, 24 April 2026 (UTC)

@Gugalcrom123 I doubt that anything will, or can ever, ban "root" access to your own computer. And nothing can require everyone to have either Android or iOS. Even if such things are proposed, they won't be implemented. And Wikipedia is not the place to raise those alarms, IMO. David10244 (talk) 02:24, 19 March 2026 (UTC)

Naturally, old hardware is replaced with new hardware. Increasingly, people are less interested in building a machine and prefer to buy pre-built ones. These often come with soldered components that make it impossible to replace/upgrade them. Recently, the "old" computers at my work from 2016 needed to be replaced due to a hardware limitation that wasn't compatible with the switch to Windows 11. Nintendo has made rooting the Switch 2 challenging, and bans people from trying in ways that make it effectively bricked. Companies are increasingly looking towards "renting" people devices, rather then selling it to them. All the pieces are there for proprietary hardware that can only work with proprietary software, that is shut down if changes are made by the user. Computers that can run older versions of software might simply die of old age (I recently had a laptop I kept alive since 2010 die of old age, I suspect something on the motherboard shorted out). If the government(s) makes laws about what that proprietary software needs to do, and passes mandates on what features new computer hardware needs to have, there is little we can do to work around that. GeogSage ^{(⚔Chat?⚔)} 03:09, 25 March 2026 (UTC)

It can happen if the state requires all OSes to have certain circumvention-proof age verifications like New York requested (but not California). Of course, to make that it would be required to disallow root access. See the satirical view at https://lists.debian.org/debian-devel/2026/03/msg00110.html but which will probably be real if NY's law passes. Gugalcrom123 (talk) 06:48, 27 March 2026 (UTC)

I'll point out that many Linux distros based on the Android operating system routinely seek to make it nearly impossible to obtain root access to one's own machine (rooting). GrinningIodize (talk) 20:31, 13 April 2026 (UTC)

It is true. They also aim to store data on one's device, but that the user cannot access manually, only the designated app can. To me, this is outrageous, and "age verification" via "digital wallets" depends on it, and on the "attestation" that this antifeature is provided. Gugalcrom123 (talk) 10:30, 14 April 2026 (UTC)

Agreed. GrinningIodize (talk) 17:18, 14 April 2026 (UTC)

Wikimedia has been fighting against age verification on Wikipedia, see: where it lost, but Wikipedia is not required to implement it at this point. Graeme Bartlett (talk) 07:20, 27 March 2026 (UTC)

From that link I understand that the UK's Ofcom which classes all large user-to-user websites as Category 1 under the Online Safety Act 2023 may make an exception for Wikipedia. Wikipedia would seem to have an interest in persuading the UK to make an exception, and maybe doing the same for other jurisdictions (countries and US states).

PS please vote on my page move proposal at Age verification system

Imakesapage (talk) 08:06, 5 April 2026 (UTC)

• No - Wikipedia is not a place to protest. Blueboar (talk) 12:23, 14 April 2026 (UTC)

  nope ~2026-25074-70 (talk) 15:00, 24 April 2026 (UTC)

As many of you probably know, a lot of biographical articles have birth or death dates listed but the sourcing is very poor or nonexistent. I've generally leant on the side of caution when it came to not adding these uncited birth or death dates to given name/surname pages, due to the risk of violating WP:BLP. However, earlier today, temporary account User:~2026-14944-70 reverted two edits I made, which were in turn reverting the same temporary account which had tried to "normalize" these pages by adding the very uncited birth dates that I wanted to avoid.

Two questions: Should we list people's birth or death dates in lists, given name pages, surname pages, disambiguation pages, or so forth, even if they're not cited in the article about said person? And should we even allow uncited birth or death dates in articles to begin with? Duckmather (talk) 17:36, 7 April 2026 (UTC)

WP:CIRCULAR would seem to appply, especially to BLP information, which is to say that editors can't simply say, "Well, it's cited at that article..." Though in theory it should be easy enough to copy a pertinent citation from the article in question. DonIago (talk) 17:43, 7 April 2026 (UTC)

This is what I do; if I can't find a source in the article, then, great, I can't verify it so I don't get to add it to the SIA. The spirit behind WP:BLPDOB, to a certain extent, applies here to, imo. Dab pages I'm a little unsure about; I think I'd like to have sourced DOBs on all of them, but they are meant to just be navigational pages, more akin to redirects than anything else. GreenLipstickLesbian💌🧸 05:34, 10 April 2026 (UTC)

I've explained this at Talk:Witkoff (surname)#Alignment of index with targets, but when dealing with navigation pages (DABs, indices, lists of lists etc. etc.) The navigation page aligns to the target. So if the target opens with "For Bar (born YYYY) is a Bizian Bazer" that is what the navigation page will read, or if the first sentence is more circumlocutory it will be pulled from the short description. The references are not included on the navigation pages because they should be sourced at the target.

A citation need not follow every word. "Foo^[1] Bar^[1] (born YYYY)^[1] is a Bizian^[1] Bazer^[1]" is unnecessary. In fact, leads do not need to have refs at all, Donald Trump for example does not, and infoboxes should not normally have them either, short descriptions never.

Essentially one of two things is true. Either the information is cited in the target, very often it will be in the body, in which case it will likely be appropriate both there and on any navigation pages that need to direct to it, or it is not cited on the target in which case it should be removed from the target, and then subsequently all navigation pages pointing there.

The pages in Category:Unreferenced BLPs may be a bit of an edge case. One could argue that those pages should not have any information, and so no navigation pages should point there. Or one could argue navigation pages simply are aids to finding pages based on the information those pages have.

As a practical matter these navigational aids usually exist, so as of the time of this writing, John Davis (pitcher, born 1963) has an entry at John Davis.

The basic standard is MOS:DABPEOPLE, though if no dates, nationality, or professional information is present at the target there may be some exceptions that try to structure themselves around what is known. ~2026-14944-70 (talk) 20:15, 7 April 2026 (UTC)

The basic standard is that this kind of page shouldn't contain information that is unnecessary for deciding which link to click on. This:

Witkoff is a surname. Notable people with the surname include:

• Alex Witkoff (born c. 1992), American businessman
• Steve Witkoff (born 1957), American real estate developer
• Zach Witkoff (born 1993), American businessman

is not the goal. Nobody is going to think "Oh, obviously I'm looking for the American businessman who was born 6–18 months before the other American businessman in this list". It's not about what is or could be cited. It's about what the Wikipedia convention is for this type of page, and the Wikipedia convention uses birth years to differentiate between people only when there is no realistic alternative. WhatamIdoing (talk) 23:29, 7 April 2026 (UTC)

That's not what MOS:DABPEOPLE says, it says "For people, include their birth and death years (when known), and only enough descriptive information that the reader can distinguish between different people with the same name" (emphasis in the original text). You could argue that "businessman" is not helpful here, but more likely it is simply not "enough", so maybe other adjectives are in order. ~2026-14944-70 (talk) 03:18, 8 April 2026 (UTC)

Disagree here. Disambiguation pages are not Perl golf. Including more info helps the reader find the relevant article faster, and birth / death years are a standard piece of info to include to help clarify which person is being referred to. It's also harmless to include slightly more info in the name of consistency. Including birth years isn't writing an essay, it's a tiny amount of characters that's a genuine aid in navigation. SnowFire (talk) 03:20, 8 April 2026 (UTC)

Really? How much faster does an approximate birth date help you decide between these particular entries? It can be helpful to have something like First Earl of Whatever b. 1620, Second Earl of Whatever b. 1642, etc. but I don't think that's true for BLPs. WhatamIdoing (talk) 23:23, 9 April 2026 (UTC)

I think it's quite useful, especially with common jobs like authors. PARAKANYAA (talk) 01:48, 10 April 2026 (UTC)

+1, same use case. If I'm reading a book review published in the 80s, then the author is more likely to be the anthropologist born in the 30s or 40s than the one born in the 70s. GreenLipstickLesbian💌🧸 01:56, 10 April 2026 (UTC)

Does it help you in the case listed here? Do you find yourself saying "Oh, obviously I'm looking for the slightly older/younger American businessman"? WhatamIdoing (talk) 01:15, 11 April 2026 (UTC)

Nope, but that's because I'm not looking for the American businessman. But if I was looking through a newspaper, and saw an early 2000s article about a businessman called "Witcoff" doing something, then I'd know to mentally filter out both Messrs. Alex and Zach Witkoff. GreenLipstickLesbian💌🧸 08:27, 11 April 2026 (UTC)

@~2026-14944-70 Pretty much ignoring the actual post here, I do want to quickly re-iterate WP:BLPREMOVE. If somebody removes information, citing a good faith BLP objection, then it's up to you (or the editor wishing to re-instate the material) to adequately source it. BLPREMOVE applies to every content space, including navigational ones. So I think Please adjust the targets, assuming any adjustment is needed, before adjusting navigation pages is in the wrong order, considering BLPREMOVE; you (or the other editor) get to source the disputed information, not alter another page before coming back to remove the disputed information from this one. GreenLipstickLesbian💌🧸 08:31, 11 April 2026 (UTC)

User:GreenLipstickLesbian MOS:DABNOLINK is unambiguous "References should not appear on disambiguation pages. Dab pages are not articles; instead, incorporate the references into the target articles". If you believe that should be changed in the case of MOS:DABPEOPLE then take it up at WT:DAB. Maybe use the John Davis (pitcher, born 1963) example where until recently there were no sources even at the target, though admittedly the BLPPROD saw the issue fixed once applied.

Leads do not require sources either, even Donald Trump doesn't have them and I have trouble believing that one is uncontroversial. Same goes for infoboxes, and short descriptions should never have them which is where a good portion of the time scripts pull the appropriate information from to navigational pages. Sometimes they are even transcluded though an RFC said not to do that so then have to be subst'd latter when noticed during other maintenance.

If you want to require leads, infoboxes, and short descriptions to have references then that is fine. But as of present they do not. ~2026-14944-70 (talk) 14:00, 11 April 2026 (UTC)

Infobox content isn't exempt from the WP:BLP requirement for sourcing. Where on earth did you get that idea? It is of course permissible to duplicate content in an infobox that is already given and cited in the article body, as with ledes, or short descriptions. AndyTheGrump (talk) 15:22, 11 April 2026 (UTC)

User:AndyTheGrump yes that is correct. MOS:INFOBOXREF just says the sources does not need to be inline. If you read the above, I already explained that one of two things is true. Either the information is sourced in the body, in which case it can be in the lead, infobox, and short description, or it isn't sourced in the body in which case it should be removed. ~2026-14944-70 (talk) 16:48, 11 April 2026 (UTC)

@~2026-14944-70 And if somebody removed a DOB (or, anything information, really) from the lead, infobox, or SD, with a good faith BLP objection, then I'd still expect the reverting editor to check that the material was, actually, cited elsewhere in the article before reverting it back in. GreenLipstickLesbian💌🧸 18:56, 11 April 2026 (UTC)

User:GreenLipstickLesbian as would I. The present situation is weird because the OP believes that the sourcing is adequate for the information to be included in the biography article, but inadequate for the information to be included in any navigation pages pointing to the article, which makes no sense to me and has no basis in policy or any workflows I am aware of, hence my one of two things is true remark earlier.

They also seem to be saying, though this is not entirely clear, that the lack of inline citation in the lead, infobox, or short descriptions of the biography means that while they can be included there, they cannot be mentioned elsewhere. That makes no sense to me either, and to refer again back to the obvious example, Donald Trump has no such inline citations, yet Donald Trump (disambiguation) has that information nonetheless.

What I was taught some years ago is that navigation pages, and even embedded lists, are simply reflections made by the pages to which they direct. So for example, and this does happen every so often, when someone changes the nationality description of someone to say Barian when the article states Fooian, they should be reverted unless and until the article itself changes, if that means waiting 30 days for an RFC to expire then so be it.

Possibly there have been editing disputes on the targeted pages, however checking for ongoing disputes is not a normal part of the workflow, nor should it be. Even as I write this the dates remain live on the linked pages; if that changes any navigational pages pointing at them will be adjusted accordingly. Very limited reasons to discuss things except on the talk pages of the targeted articles. Very rarely when the list of nationalities, occupations etc. is long, people will dispute a little as to the wording of the entry on the navigation page itself. But in my view even that is needless and any dispute should simply result in the verbatim reuse of the linked article's short description, though there is no formal policy to that effect. ~2026-14944-70 (talk) 19:31, 11 April 2026 (UTC)

We shouldn't have citations on disamb pages. So I don't think citations should go there. Disambs aren't articles, they're navigational tools, so I think it being cited in the article is enough. PARAKANYAA (talk) 21:03, 7 April 2026 (UTC)

And the general rule of thumb has been: If it needs a citation, it really doesn't belong on a disambiguation page. WhatamIdoing (talk) 01:16, 11 April 2026 (UTC)

I think you've made your preference clear for other reasons, but no. If we were being hyper-sticklers, anything other than the article title requires a reference, which would be silly on a navigational page. There's no difference between a birth date vs. an occupation vs. what something is. If the birth / death is cited in the other article, just like the occupation, it's fine. SnowFire (talk) 02:01, 14 April 2026 (UTC)

Why do you say that "anything other than the article title requires a reference"? Where is such a requirement written down? It's not in Wikipedia:Verifiability, which requires inline citations for four kinds of material (and therefore not for anything else). WhatamIdoing (talk) 00:48, 18 April 2026 (UTC)

For clarity, Wikipedia:Disambiguation#References says "Do not include references in disambiguation pages". The obvious way to comply with this prohibition on inline citations, and WP:V's requirement for inline citations for four kinds of material – and that having the citations in the linked article is not sufficient ("When material that needs an inline citation appears in two or more articles, an inline citation is needed in each") – is to not have those four kinds of material on the dab page. Thus: "Alex Witkoff, American businessman" and not "Alex Witkoff, American businessman whose father is a Trump crony" – even though the latter is cited in the linked article. WhatamIdoing (talk) 00:55, 18 April 2026 (UTC)

That is simply sophistry. Nowhere does the string "Trump Crony" appear on that page so it would never be copied across to begin with. It is also not a standard DABPEOPLE type of distinguisher so would be improper for other reasons. Negative descriptors of people of the type Fooian Criminal, Fooian murderer, and even Fooian serial killer do in fact appear on navigation pages, and unlike your example would in fact be libel per se if false. However, since they are true and often used in the linked pages short descriptions and introductory sentences they get copied across anyway. ~2026-14944-70 (talk) 01:45, 18 April 2026 (UTC)

"Libel per se if false" isn't one of the four types of information that's required to have an inline citation. WhatamIdoing (talk) 04:13, 18 April 2026 (UTC)

More sophistry, since the string "Trump Crony" isn't either. ~2026-14944-70 (talk) 13:58, 18 April 2026 (UTC)

Did you mean that 'the string "Trump Crony" isn't' required to have an inline citation? I'd put that in the category of contentious matter about a WP:BLP, which is required to have an inline citation. WhatamIdoing (talk) 00:18, 22 April 2026 (UTC)

And other people would doubtless place "serial killer" in the category of descriptors requiring an inline citation, your point is? ~2026-14944-70 (talk) 02:22, 22 April 2026 (UTC)

My point is that even Wikipedia:Disambiguation pages have to comply with Wikipedia:Biographies of living persons, so when a page shouldn't contain a citation, it also shouldn't contain contentious matter about BLPs. If "serial killer" is actually contentious in a given case, then a different description should be use on the dab page. (Mind the gap between 'widely accepted unpleasant fact' and 'contentious'. Only the latter requires an inline citation.) WhatamIdoing (talk) 05:18, 22 April 2026 (UTC)

So you are saying if a descriptor on a DAB regarding a BLP has been challenged it can never be readded, is that correct? ~2026-14944-70 (talk) 05:24, 22 April 2026 (UTC)

Mind the gap between 'widely accepted unpleasant fact' and 'contentious'. There is not always a gap. I can't remember who it was now, but a while back there was a huge discussion (and RfC?) related to the description of a North American person who had a notable sports career and had also been convicted of a serious sex crime (I think rape) in a high-profile case. It was "widely accepted unpleasant fact" that he had been convicted of rape, however it was highly contentions whether he should be described as a "(former) sportsperson", "(former) sportsperson and rapist", "rapist and (former) sportsperson" or "rapist". Thryduulf (talk) 09:46, 22 April 2026 (UTC)

• (de-indent) No, anything can be contested. If someone linked the article on Alex Witkoff, the guy into cryptocurrency, but incorrectly disambiguated the article with "Welsh hamlet" or "Canadian businessman" or "mathematical concept", people would be well within their rights to contest it and demand the inaccurate summary's removal as unreferenced. If two editors disagree on reality, the one with the reference wins, which would be the person finding a reference saying he's actually an American businessman. So yes, everything has to be referenced. It just that, for reasons of sanity, that reference doesn't have to live on the disambiguation page itself, and can be in the linked article, whether it be "what is this article about" or "what is the subject's birthdate". SnowFire (talk) 20:02, 20 April 2026 (UTC)

  Everything does not have to be cited. The rule in WP:V is that inline citations are required (albeit with no WP:DEADLINE) if the claim is Wikipedia:Likely to be challenged (or already has been, since the likelihood in that case is 100%). There's a big gap between "anything can be contested" and "some things are WP:LIKELY to be contested". WhatamIdoing (talk) 00:17, 22 April 2026 (UTC)

I know that using LLM's for content creation is banned. However, inspired by the thread above, which implies that vandalism is a big problem and often lingers in articles without being fixed, I propose that using AI to review edits by unregistered users might be a good idea. I think any general purpose AI would be quite capable of dividing edits into 'probably not vandalism', 'very likely vandalism' and 'not sure', it could create a list for review by human editors who would be responsible for responding to it. Imakesapage (talk) 02:04, 12 April 2026 (UTC)

We do already have an AI that reviews edits by newer editors for vandalism. It's Cluebot NG. Some tools also do use AI to review edits, such as Wikishield. 45dogs (they/them) (talk page) (contributions) 02:11, 12 April 2026 (UTC)

We already are technically using an AI called ORES to detect likely vandalism in the way you describe on recent changes (though it's not generative), plus there are bots that use much more advanced AI as said above. Feeglgeef (talk) 02:13, 12 April 2026 (UTC)

I think any general purpose AI would be quite capable of dividing edits into 'probably not vandalism', 'very likely vandalism' and 'not sure'. How reliably, though? 'Citation needed' (both for any new proposals, and for anything we are currently using), as they say around here. AndyTheGrump (talk) 02:16, 12 April 2026 (UTC)

It wouldn't have to be super-reliable, as it would only be bringing edits to human attention. I will give some thought as to how to provide a 'citation', maybe you could help with suggestions. Imakesapage (talk) 02:26, 12 April 2026 (UTC)

My suggestion is that any proposals to use AI should be accompanied by evidence that it actually works. AndyTheGrump (talk) 02:28, 12 April 2026 (UTC)

This is not a proposal, just an idea :) Anyway I will look for a way to test it. Imakesapage (talk) 02:38, 12 April 2026 (UTC)

So here's a problem: Vandalism detection is usually easy for a human. But if you give all the easy cases to a tool, and pass the uncertain ones along to the human, then the human gets worse at the job and has less fun doing it. A few rounds of classic poop vandalism is a quick and easy win for the humans, and doing the easy ones helps the humans hold on to the definition of vandalism. If the self-chosen vandal fighter instead has their feed full of POV pushing or simple broken wikitext, then it's a lot harder to figure out. It's not what they want to be working on. And over time – slowly, imperceptibly – they'll start calling all of that "vandalism" too. (It made Wikipedia worse, so that's basically vandalism, right?) And the next thing you know, their functional definition of vandalism is so far out of step with the community's rules that they're getting yelled at and even blocked. WhatamIdoing (talk) 06:54, 13 April 2026 (UTC)

My suggestion is to not to let the LLM perform any edits itself, so a vandal fighter could simply look at the 'probably vandalism' ones and revert any necessary. POV pushing and broken wikitext etc still need to be dealt with, right? These might go under 'not sure' for people with more time or whatever to look at. Imakesapage (talk) 08:37, 13 April 2026 (UTC)

If we could have the LLM flag improper claims of vandalism, and suggest a more accurate description, that might help.

I suggest this article, if you can read it: https://www.theatlantic.com/magazine/2026/04/self-driving-car-technology-tesla-crash/686054/ (For eligible editors: It's in Wikipedia:The Wikipedia Library if you search for "My self-driving car crash" in the box at the top of the page.) WhatamIdoing (talk) 18:50, 13 April 2026 (UTC)

I've experimented with this a while ago with (see User:Ca/Automated RCP), and while it didn't do too bad, I decided it wasn't worth the price. But local models have advanced significantly since then, so it might be worth trying it again. Ca ^{talk to me!} 00:23, 20 April 2026 (UTC)

From my experience with this, it's really really complex. LLMs are incredibly expensive, which practically forces you to use local models. The issue is that this is both slow and local models really really struggle with understanding wikimarkup and Wikipedia policies. When I played around with it, I saw many false positives for clearly good edits, such as the addition of templates being flagged as gibberish, or removing unsourced sections being flagged as disruptive. – LuniZunie_(talk) 18:15, 22 April 2026 (UTC)

Whenever I read an article about a new thing, especially geopolitical events, there's always cities, districts, villages etc. that I don't recognise. It would be helpful if the page preview for links to pages of geographic locations contained a map of the general area with that place highlighted, for example hovering over the link of a state/city would show you where the state/city is in the country. Right now the page previews contain images of the place, but a map would be more informative. Shyamm537 (talk) 15:48, 15 April 2026 (UTC)

That definitely sounds like a neat idea! mw:Page Previews is the feature that enables these, it could be good to look into this. Since they're implementing audio pronunciation snippets for Wiktionary, a map could have some potential for a future implementation too! Chaotic Enby (talk · contribs) 16:58, 15 April 2026 (UTC)

Thanks! I went through mw:Page Previews and it led me to mw:Extension:Popups and mw:Extension:PageImages, and I can see two ways to go about this. In the ?action=info page 1. either change the Page Image field with a map (if one is available) or 2. add a field called Map and set the API call to show the Map field if one is available. I haven't familiarised myself with the Extension documentation yet, so I might be missing some nuances within scenario 2 here. Shyamm537 (talk) 06:46, 16 April 2026 (UTC)

One issue is there is a subgroup of users that find maps useful for orientation and another subgroup who like photos of a place (probably more common e.g. SatNav drivers that rely on verbal prompts next turning). Both take up space in previews. It might need to be a user adjusted preference if Page Image field substitution used. Another issue is default scaling of maps may be poor for at a glance orientation of the user. ChaseKiwi (talk) 13:20, 16 April 2026 (UTC)

That (your first point) is very true. I am totally lost without a map, but many people I know never even look at them. I'm at a loss to explain how anyone can have an opinion about a place without even knowing where it is or what it is near but many such people certainly exist. Phil Bridger (talk) 14:14, 16 April 2026 (UTC)

Map reading is not the same skill as comprehending English or images which are more vital for the wikipedia project...see Zyszkowska, W (2017). "Levels and properties of map perception" (PDF). Polish Cartographical Review. doi:10.1515/pcr-2017-0002. ChaseKiwi (talk) 14:57, 16 April 2026 (UTC)

Map reading as a skill is different from seeing where a city/district/county exists inside a country/state. Page previews offer a small summary about the page, and as such a photo of a place would hold substantially less information than a map showing you where the place is. Map scaling, as you pointed out, is definitely an issue that would need to be tackled. Shyamm537 (talk) 02:36, 17 April 2026 (UTC)

I think personalisation would be useful, but I guess it also matters on what the context is. Suppose you're reading about a war or an election and you see names of cities and districts thrown around that either don't exist anymore or you're simply not aware of. In this case a map would be more useful than when, say, you're reading about a city and a building is referenced somewhere. Shyamm537 (talk) 02:30, 17 April 2026 (UTC)

Currently, G15 is mostly about deleting pages where the primary content came from an LLM but it was hidden. I propose an extension to G15 that permits the deletion of any articles that:

• (a) Had a disclosure of LLM usage in its article body when it was created, and would obviously fail Wikipedia:NEWLLM
• (b) Have a disclosure of LLM usage in the edit summary of the edit that led to the article's creation, and obviously would fail Wikipedia:NEWLLM

An example of where this might apply is this AfD discussion, which contains several articles that are obviously in violation of the present LLM policies and have an LLM disclosure in their initial edit summaries. GrinningIodize (talk) 12:53, 21 April 2026 (UTC)

Does that meet the requirements at the top of Wikipedia talk:Speedy deletion? Phil Bridger (talk) 13:52, 21 April 2026 (UTC)

Yes, I believe so.

The process is objective (only pages which have a disclosure of LLM usage in the initial edit), uncontestable (there are very few gray areas), frequent because we already have several examples of pages that would be deleted under these rules, and nonredundant (if I thought that another rule applied better here, I would have already used it). GrinningIodize (talk) 16:10, 21 April 2026 (UTC)

In the past, some proposals to expand G15 (such as adding oaicite markers) were rejected on the grounds that, while they were indisputably evidence of AI, they were not evidence of unreviewed AI, and the editor could have simply overlooked them. As WP:NEWLLM has since been enacted, and AI-generated articles are now prohibited in general, it makes sense to reconsider these as a collection (including, but not limited to, the explicit disclosure you mentioned above). Chaotic Enby (talk · contribs) 14:38, 21 April 2026 (UTC)

Possibly, if the article was created after NEWLLM was enacted and the current revision of the article is sufficiently problematic that it needs major work (we don't want to penalise the good, human work that has resulted in a good article just because it was initially created by AI). However, I'm not sure that leaves anything that doesn't already meet G15?

I'll leave a note about this discussion at Wikipedia talk:Speedy deletion if nobody has beaten me to it. Thryduulf (talk) 15:11, 21 April 2026 (UTC)

Missionary linguistics appears to have been written with large portions of unreviewed LLM content and the current revision is still tainted, to the point where it would need a full rewrite to be acceptable. GrinningIodize (talk) 16:12, 21 April 2026 (UTC)

But that was written before the new LLM guideline, unless I'm much mistaken? -- asilvering (talk) 16:53, 21 April 2026 (UTC)

Yes, but that doesn't matter, because we're not penalizing anyone, we're just cleaning stuff up to meet the new policies. GrinningIodize (talk) 16:55, 21 April 2026 (UTC)

Thryduulf said, Possibly, if the article was created after NEWLLM was enacted and the current revision of the article is sufficiently problematic that it needs major work (we don't want to penalise the good, human work that has resulted in a good article just because it was initially created by AI). However, I'm not sure that leaves anything that doesn't already meet G15? I, too, would like to see some examples that meet these conditions. -- asilvering (talk) 16:58, 21 April 2026 (UTC)

The article that I linked does not appear to meet G15 and has very little human text in it. It wasn't created after NEWLLM, but once again, that doesn't really matter. GrinningIodize (talk) 17:04, 21 April 2026 (UTC)

Please see WP:AINB for examples of the huge mountain of LLM-generated article content that was created before WP:NEWLLM that requires cleanup. Most does not meet G15, and some still won’t under any potential expansion. I₂Overcome ^talk 17:05, 21 April 2026 (UTC)

I'm not asking about content that was created before NEWLLM, and neither was Thryduulf. -- asilvering (talk) 20:10, 21 April 2026 (UTC)

It sounded to me like you were both implying that only content created after NEWLLM was enacted could be speedy-deleted under any new WP:G15 criteria. G15 does not have a "recently created" requirement, and I see no reason why any changes could not be applied to older articles. In any case, there are plenty of examples of LLM articles created after NEWLLM that don’t meet the G15 criteria too that can be found at WP:AINB. In general, most LLM-generated articles, even ones with serious issues, do not meet G15. I₂Overcome ^talk 20:37, 21 April 2026 (UTC)

(edit conflict) We don't typically apply policies retroactively, so unless someone presents some very good evidence of a need to do so in this case I would strongly oppose any new or expanded speedy deletion criterion for LLM-written material that predates the policy's adoption (March 2026). Thryduulf (talk) 20:41, 21 April 2026 (UTC)

Do you have any examples of other CSD modifications that explicitly couldn't be used on pages predating a related policy's enactment? GrinningIodize (talk) 20:51, 21 April 2026 (UTC)

WP:NEWLLM for article creation dates back to December 2025. It was only expanded in March 2026 to cover all content additions, but that shouldn't "reset the clock". Chaotic Enby (talk · contribs) 20:51, 21 April 2026 (UTC)

Interesting! I didn't know that. GrinningIodize (talk) 20:54, 21 April 2026 (UTC)

Can the guideline itself be applied to article content that was generated by an LLM before March 2026? In other words, is WP:NEWLLM an acceptable reason for tagging, reverting, stubifying, PRODing, or AfDing AI-written articles from before March (or December)? Because that is how it’s being applied by editors at WikiProject AI cleanup. I₂Overcome ^talk 20:55, 21 April 2026 (UTC)

I would argue yes. Consensus is that LLM-generated content doesn't belong here with a couple of small exceptions, and that consensus should be followed regardless of context. GrinningIodize (talk) 21:00, 21 April 2026 (UTC)

What do you mean by a collection? GrinningIodize (talk) 16:27, 21 April 2026 (UTC)

Considering all the unambiguous criteria for AI-generated articles as a whole, rather than discussing them one by one. That wouldn't include more nuanced WP:AISIGNS like redlinks in "See also" mentioned below, but would definitely include disclosed AI-generated articles as well as AI-exclusive artifacts such as oaicite. Chaotic Enby (talk · contribs) 17:52, 21 April 2026 (UTC)

I see now, thanks. GrinningIodize (talk) 18:37, 21 April 2026 (UTC)

I think redlinks in See also and nonexistent categories should also be added to G15. It is highly unlikely that any human editor would make those mistakes. I₂Overcome ^talk 16:53, 21 April 2026 (UTC)

I disagree. Plenty of humans, including me, often make mistakes like that, and it's always possible that a page or category got deleted later on. GrinningIodize (talk) 16:56, 21 April 2026 (UTC)

That’s a good point. It would have to be combined with other AISIGNS, which would not really be objective. I₂Overcome ^talk 17:12, 21 April 2026 (UTC)

Regarding objectivity, see WP:AINB#Resonance of the Soul: Flowers and Harmonics for a good example of where editors experienced with AI detection disagree about whether something was or wasn't written by an LLM. Thryduulf (talk) 18:20, 21 April 2026 (UTC)

I'm still of the opinion that stubification is usually sufficient for newly-created AI articles. What do we gain by deleting them? The issue is the presence of the AI text, not the presence of the article. LLMs are actually pretty good at digging up obscure sources so I'd rather see a one-sentence stub with 10 references, 3 of which are good, than no article at all. If, after removing the LLM text, there is truly no content left, you will often be able to delete under A3, A7, or A9. So the benefit of expanding G15 here seems small. Also, pragmatically-speaking, this change might encourage people to lie about LLM use, which makes things harder for everyone. -- LWG ^{talk (VOPOV)} 15:51, 21 April 2026 (UTC)

By deleting them, we gain the aspect of being written for humans, by humans, which is what separates us from competitors like Grokipedia. If people lie about LLM usage, then we will ban people who are clearly using LLMs, same as sockpuppetry or any other potentially-secretive infraction. GrinningIodize (talk) 16:07, 21 April 2026 (UTC)

By deleting them, we gain the aspect of being written for humans, by humans I agree that maintaining our human-written status is critical, but how does speedy deletion achieve that goal more effectively than simply editing the article to remove all LLM content (leaving behind sources), and then deleting or keeping what remains based on the normal criteria? I agree that people who deliberately lie to other editors to evade accountability for their editing practices are WP:NOTHERE and should be blocked, but it's not trivial to identify these people and I have WP:BEANS-adjacent concerns about certain types of AI policy pages. -- LWG ^{talk (VOPOV)} 17:06, 21 April 2026 (UTC)

Rewriting the article from scratch has been our main strategy for years now, and it's incredibly ineffective, as evidenced by my other comments. What would take 2 days to delete might take a year to rewrite. As for not stuffing beans up one's nose with policy pages, that would be better discussed in another topic. GrinningIodize (talk) 17:15, 21 April 2026 (UTC)

If we're being pragmatic, WP:SOCKDELETE has a reason: the goal isn't to punish the sockpuppet, but to take away the reward for violating policy. Thebiguglyalien (talk) 22:36, 24 April 2026 (UTC)

You might have a point about possibly encouraging people to lie about their AI use. However, the ones that know it is prohibited are already doing that anyway.

I don’t see what good a one-sentence stub is to an encyclopedia. We are not a dictionary. Also, if only 3/10 refs are good, why keep the 7 that are bad? I₂Overcome ^talk 17:28, 21 April 2026 (UTC)

Agreed. GrinningIodize (talk) 17:31, 21 April 2026 (UTC)

I don’t see what good a one-sentence stub is to an encyclopedia. Not much, but I don't see that it does much harm either.

if only 3/10 refs are good, why keep the 7 that are bad? Because it saves me the time of checking them to find out which 3 are good. When someone is ready to actually write a non-stub article, they can examine the sources and keep/discard as appropriate.

The point I'm trying to make is that once the LLM text is removed, which post-WP:NOLLM can be boldly done by anyone, there isn't a need to speedy delete anymore. So it feels like we don't gain much by expanding G15. -- LWG ^{talk (VOPOV)} 18:33, 21 April 2026 (UTC)

But in many cases, there is no usable article to be had after removing LLM-generated text. GrinningIodize (talk) 18:36, 21 April 2026 (UTC)

If that is objectively true then in most cases it can be speedily deleted under an existing criterion (e.g. no content). If it is not objectively true then speedy deletion isn't appropriate under any criterion. Thryduulf (talk) 18:39, 21 April 2026 (UTC)

But if it has no content because said content was removed in an edit (as it would be here), wouldn't the LLM-generated content have to be restored instead? GrinningIodize (talk) 19:58, 21 April 2026 (UTC)

No, why would it? If you remove all infringing content and nothing remains, we delete. See eg G12. -- asilvering (talk) 20:12, 21 April 2026 (UTC)

I think the main difference here is that the revisions we could have G12-ed are eligible for CSD. Revisions ineligible for G15 (or another criterion) are ineligible for CSD, and thus render the page ineligible. Blanking a page and tagging it for A3/A7 is more akin to how you can't BLAR a page to draftspace, then R2 it, imo. And like how, even though UPE is banned, we don't G11 the non-G11 eligible promotional creations, or even blank the infringing promotion then A7/A3. GreenLipstickLesbian💌🧸 20:17, 21 April 2026 (UTC)

Wikipedia:ALPHABETTISPAGHETTI comes to mind when reading your comment. GrinningIodize (talk) 20:57, 21 April 2026 (UTC)

Anyone having difficulty understanding GreenLipstickLesbian's comment becuase of the abbreviations just try prefixing them with "WP:" and linking them: WP:G12 WP:CSD WP:G15 WP:A3 WP:A7 WP:BLAR WP:R2 WP:UPE WP:G11. Phil Bridger (talk) 08:45, 22 April 2026 (UTC)

Thanks! GrinningIodize (talk) 12:00, 22 April 2026 (UTC)

You mentioned G12, but how is that relevant here? LLM usage is not unambiguous copyright infringement; people are still debating about that. GrinningIodize (talk) 20:53, 21 April 2026 (UTC)

People are debating whether LLM text is inherently copyright infringement due to the sourcing of their training data, but they are definitely capable of producing unambiguous copyright infringement, for example when they are asked to write an article based on sources and their output quotes large portions of the sources verbatim or nearly verbatim. -- LWG ^{talk (VOPOV)} 15:30, 22 April 2026 (UTC)

True. GrinningIodize (talk) 17:48, 22 April 2026 (UTC)

What Thryduulf said: axe the LLM text, then check what remains against A3, A7, or A9. -- LWG ^{talk (VOPOV)} 18:53, 21 April 2026 (UTC)

Even if there is usable content left, and it doesn't meet CSD, that doesn't mean the article is suitable. Cleaned up AI articles still end up at AfD for other issues, especially notability. It seems to me that having to deal with these LLM generated articles is a waste of editor time. It takes seconds to LLM generate an article--then, after however long it takes to spot it, tag it, and clean it up, they end up at AfD, which can take a week or more. StartOkayStop (talk) 22:58, 22 April 2026 (UTC)

The problem is that stubification usually requires the reviewing editor to check each source and claim one by one, which the editor creating the article has not done. This shifts the burden towards reviewing volunteers and creates a major asymmetry of effort, which is why WP:AINB currently has so much of a backlog. Chaotic Enby (talk · contribs) 17:55, 21 April 2026 (UTC)

stubification usually requires the reviewing editor to check each source and claim one by one If the text is known to be LLM-generated, that kind of detailed review is optional - it's a valid choice to just axe it. For example, it took me just a few minutes to clean up this article, and I feel like I was being generous in the extent to which I tried to find salvageable content in the sources. -- LWG ^{talk (VOPOV)} 18:48, 21 April 2026 (UTC)

I agree with LWG here. Most content issues unrelated to notability (outside of libel, slander, BLP issues, WP:CHILDPROTECT and other issues that involve people) are resolvable by stubification. There is no reason to expand a speedy deletion criteria and delete notable topics because the first version was WP:IMPERFECT. Katzrockso (talk) 14:36, 22 April 2026 (UTC)

Notified: Wikipedia:WikiProject AI Cleanup/Noticeboard. GrinningIodize (talk) 16:26, 21 April 2026 (UTC)

I have some doubts about how frequently this occurs. Phil Bridger (talk) 17:55, 21 April 2026 (UTC)

So, some users in the past disclosed a use of AI, as a token of transparency and proof of good intentions, even if it was not actually required to do so, and the idea is to punish such users? Cambalachero (talk) 14:16, 22 April 2026 (UTC)

I don't think it should be seen as a punishment, although I can see how it might be interpreted as such. However, the given example, Model specification (artificial intelligence), was written after WP:NEWLLM was expanded and three whole months after it was passed for new articles. Being transparent as to the fact that you're breaking policies and guidelines shouldn't give you a free pass to break them. Chaotic Enby (talk · contribs) 14:24, 22 April 2026 (UTC)

Fully agreed. GrinningIodize (talk) 14:26, 22 April 2026 (UTC)

But the proposal is not about users doing that now, but when policies allowed it. Retroactive enforcement of new policies is usually the source of lots of disputes and acrimony. Cambalachero (talk) 14:37, 22 April 2026 (UTC)

The proposal doesn't seem to specify that anywhere, and, as all the examples were from a time where policies didn't allow it, I'm not sure why it should be interpreted as retroactive. Chaotic Enby (talk · contribs) 14:41, 22 April 2026 (UTC)

My intent was for it to be retroactive. GrinningIodize (talk) 14:47, 22 April 2026 (UTC)

Thanks! I thought your clarification above regarding this was a suggestion separate from the original proposal, but that makes sense too. Are there pre-December 2025 cases of such issues that would make it necessary to have a retroactive policy? Chaotic Enby (talk · contribs) 14:50, 22 April 2026 (UTC)

I am not aware of any at the moment, but I consider those to be just as bad as ones created in violation of the policies at that time, because it would still be going against consensus. GrinningIodize (talk) 14:52, 22 April 2026 (UTC)

So, some users in the past disclosed a use of AI, as a token of transparency and proof of good intentions, even if it was not actually required to do so, and the idea is to punish such users? I don't actually think this G15 expansion is a good idea, but I cannot possibly emphasize enough that reversion of "your" edits/deletion of "your" articles is not a punishment. It's a foundational principle of what we do here. The moment you click "publish" you are releasing your content into a world where it can and should be mercilessly refactored whenever doing so would improve the wiki, or removed if its presence doesn't improve the wiki. -- LWG ^{talk (VOPOV)} 15:38, 22 April 2026 (UTC)

Yes, that's the written idea, but not the way it actually works in real life. That's the disadvantage of a human-written encyclopedia: that it has human editors, humans have feelings, and if you push them too hard in the name of arcane regulations, they would simply pack and leave. There's Wikipedia:Please do not bite the newcomers precisely because of that. Cambalachero (talk) 16:05, 22 April 2026 (UTC)

That's fair, and I agree with your core point that this policy might disincentivize people from being transparent about their editing practices. I also agree that we should be gentle in explaining expectations and give grace to new editors who are still learning the ropes, but not to the extent that we allow bad content to stay online just because the person who put it online meant well. -- LWG ^{talk (VOPOV)} 16:45, 22 April 2026 (UTC)

WP:BITE is not an excuse to never make any edits ever because it might hurt someone's feelings. Especially in this situation, given that the operative word is "newcomers," and someone who's been around long enough to do something "in the past" is, by definition, not a newcomer anymore. If they're even around anymore at all. Gnomingstuff (talk) 17:21, 22 April 2026 (UTC)

We need to stop thinking of removing material that does not belong on WP as some sort of “punishment”. It is called “editing” and is part of what editors are supposed to do. Blueboar (talk) 23:15, 22 April 2026 (UTC)

I concur. GrinningIodize (talk) 23:19, 22 April 2026 (UTC)

My comment above hasn't attracted a reply yet. Could someone please link to these "frequent" articles that have disclosures of LLM use, because I haven't seen any yet, although I'm perfectly prepared to believe that they exist. Phil Bridger (talk) 20:20, 22 April 2026 (UTC)

State AI laws in the United States is a good example. I nominated nearly a dozen others for deletion as well, but someone took it upon themselves to rewrite those, I presume for the purpose of making my proposal seem less fit. GrinningIodize (talk) 20:23, 22 April 2026 (UTC)

More for the purpose of putting my money where my mouth is on my claim that stubification is an easy way to deal with these. It's always annoying when people say "existing processes handle this AI problem fine" without lifting a finger to actually help, so I wanted to make sure I wasn't doing that. -- LWG ^{talk (VOPOV)} 20:35, 22 April 2026 (UTC)

I see; sorry about making that false presumption. GrinningIodize (talk) 20:47, 22 April 2026 (UTC)

OK, I can see one example, but I'm not convinced that this happens frequently enough to justify adding it to a speedy deletion criterion. Remember that we can delete such articles now, just not speedily. Phil Bridger (talk) 22:04, 23 April 2026 (UTC)

Well, that's your opinion. GrinningIodize (talk) 22:57, 23 April 2026 (UTC)

It's an opinion that I share. Remember that WP:NEWCSD point 3 is "Frequent", unless something happens so frequently that it is actually a frequent occurrence at the relevant XFD then it's not suitable for speedy deletion. Without a track record at XFD it's also very difficult to demonstrate the proposal meets point 2 (uncontestable). Thryduulf (talk) 23:10, 23 April 2026 (UTC)

You don't need to delete these if the article topic is notable. Just stubify them. SuperPianoMan9167 (talk) 23:46, 23 April 2026 (UTC)

Even if they do get stubified, it's likely for many of the subconscious biases of the LLM to still leak through, whereas a deletion would force editors to start from a clean slate. GrinningIodize (talk) 12:44, 24 April 2026 (UTC)

That's also a concern for me, and I did my best to avoid it while stubifying that recent slate of articles. Let me know any feedback for how I could have done better. I think it's analogous to stubifying an article whose first draft was purely promotional WP:UPE content. It might be better to WP:TNT delete in some cases, but that seems like the kind of judgement call that is firmly outside of speedy deletion territory. -- LWG ^{talk (VOPOV)} 15:06, 24 April 2026 (UTC)

Got it. GrinningIodize (talk) 15:07, 24 April 2026 (UTC)

Regarding stubbifing, based on what I've seen, I think people are more likely to create articles out of redlinks than to improve one-sentence stubs. InfernoHues (talk) 15:51, 24 April 2026 (UTC)

Agreed. GrinningIodize (talk) 15:53, 24 April 2026 (UTC)

I'm doubtful about this, but it seems like something that we could find an answer for, rather than just guessing based on each individual's own limited experience. WhatamIdoing (talk) 20:10, 24 April 2026 (UTC)

Help:Guided tours are a very powerful functionality that can allow for easy onboarding of newcomers, or help out more experienced users get a hold of tools/workflows with steep learning curves. However, they are sadly quite underutilized. I've recently worked on one to help administrator election clerks set up SecurePoll, and I would love to hear out your ideas for more functionalities that tours could help with! Chaotic Enby (talk · contribs) 23:26, 24 April 2026 (UTC)

• @Chaotic Enby: I like this suggestion. I boldly quoted you on meta:Talk:Wikimedia Foundation Annual Plan/2026-2027#Guided tours, and added some of my own comments there. ↠Pine (✉) 04:09, 25 April 2026 (UTC)

• I'd like to see something like this that helps familiarise new users with some of our policies and guidelines. Many new users aren't familiar with the existence of our policies & guidelines, let alone how to find them, so bumping up against them is an unfortunately common (and often discouraging) occurrence. I'm not sure how this could be done exactly, but guided tours seems like it could be helpful to direct users in the right direction. --Grnrchst (talk) 17:13, 26 April 2026 (UTC)

  One thing we've heard from newcomers in the past is that almost all of the policies and guideline pages look the same. If you don't remember the name, you're stuck. There's no fallback to help your memory or communication, like "Um, I think I was looking at a page with a grumpy cat on it?" or "It was a weird shade of green". WhatamIdoing (talk) 01:48, 29 April 2026 (UTC)

  Solution: put a different memorable animal on each page, like we've done at Wikipedia:Please do not bite the newcomers. Chaotic Enby (talk · contribs) 01:53, 29 April 2026 (UTC)

  A la O'Reilly Books? "Please get out your copy of the cricket book, and we'll both turn to page 123, where it says..." WhatamIdoing (talk) 02:02, 29 April 2026 (UTC)

  Made me think of the dragon book, which was used in a course I took in the early 1980s. Donald Albury 13:02, 29 April 2026 (UTC)

See mw:Article guidance – maybe this could be developed further to broader scope/application and it could be sth like that is already planned but I'm not sure about it...could also be a broad goal about helpful guidance at point needed/useful or nothing 'official'. Two other or related ways for this is some editor assistant tool as proposed here which can provide links and maybe help if you ask things in natural language and videos – see c:Category:Instructional videos on using Wikipedia. Prototyperspective (talk) 14:49, 29 April 2026 (UTC)

These all look very interesting, although a bit separate in functionality from guided tours, as the first one is another extension intended specifically for article creation and the second one is some kind of chatbot, which might not be as well-received by the community. Guided tours are more flexible (as they can be directly written on-wiki without requiring developer work, since the extension already exists) and can provide interface-level guidance, so they are in some way complementary with what you suggest. Chaotic Enby (talk · contribs) 15:14, 29 April 2026 (UTC)

Yes, Article guidance currently is just about article creation but again maybe that could be expanded. The context was that the extension you linked seems not use much by both people providing tools and especially users and has been developed it seems around 2013 while the article guidance is used by many users and has been developed just recently. So to me it seemed like expanding that is probably the more feasible approach for optimal results. Maybe one could ask about the differences between the two at the article guidance talk page where maybe it could be clarified if the guided tours extension could be used or why not. Prototyperspective (talk) 11:53, 30 April 2026 (UTC)

I'm very confused as these two extensions seem to have very different purposes and functionalities, so using one over the other doesn't seem especially meaningful? For example, the SecurePoll setup tours aren't something that could have been done with the Article guidance extension, as the goal is to guide users through navigating an existing interface rather than have them answer a series of questions. Noting that the latter extension is also currently experimental, and hasn't been fully deployed yet, so expanding it would be a bit premature (although it's good to plan it in advance!) Chaotic Enby (talk · contribs) 14:34, 30 April 2026 (UTC)

Guides tours are interactive tours of a part of Wikipedia. They are meant to complement help pages, by showing users directly how to do something in a step-by-step way overlaps with Article guidance … provides tailored, community-adjustable guidance throughout the creation process [in this context also other processes and pages] and I don't see why it couldn't be adapted for SecurePoll setup; also things like SecurePoll setup seemed like an example, not some particular thing you were asking about. Prototyperspective (talk) 16:10, 30 April 2026 (UTC)

The intent is similar, but the actual execution is different, as Article guidance provides a standalone window while Guided tours show up as an overlay. Both are helpful in different use cases – to go back to my SecurePoll example (which I'm referring to as it's the one I've developed recently, so it helps to have a concrete example), the setup requires the clerk to use Special:SecurePoll/create, while article creation is more flexible and a separate window can be used to send preload data (which I don't think is feasible with SecurePoll). In general, Article guidance is still experimental and more tailored to the specific task of article creation, and doesn't yet have options to be adapted by the community for other tasks. Chaotic Enby (talk · contribs) 16:42, 30 April 2026 (UTC)

Due to recurring issues with original research in categorization of fictional elements by in-universe attributes, I have opened Wikipedia_talk:Overcategorization#Fictional_elements?. I suspect that there is enough precedent to establish one, but I don't know exactly what it would entail. –LaundryPizza03 (dc̄) 14:46, 25 April 2026 (UTC)

The topic as framed is already in-universe, not strictly being about fictional elements :) DMacks (talk) 15:42, 25 April 2026 (UTC)

Would it be possible to make a bot thingy for the sole purpose of removing double space? Wikipedian12512(alt) (talk) 11:55, 27 April 2026 (UTC)

It would be possible for someone to create such a bot, but it wouldn't be approved. See WP:COSMETICBOT. Anomie⚔ 12:31, 27 April 2026 (UTC)

Also see MOS:DOUBLESPACE, which implies that they should be just left alone. Graham87 (talk) 06:26, 28 April 2026 (UTC)

I'm talking more about accidental double spaces in between words. I've had to correct that occasionally. Wikipedian12512(alt) (talk) 11:49, 28 April 2026 (UTC)

Such double spaces do not show in reading mode, and so do no harm. Its OK to correct them when performing more substantive edits, but editing an article solely to reduce double spaces is unnecessary, and may be considered a form of gaming the system to increase edit counts. Donald Albury 15:37, 28 April 2026 (UTC)

Thanks! Wikipedian12512(alt) (talk) 21:25, 28 April 2026 (UTC)

While we're all here: I've heard that the double-space actually is visible, but only to the small number of people who use the Wikipedia app. WhatamIdoing (talk) 01:50, 29 April 2026 (UTC)

Sounds like a bug in the app then... Anomie⚔ 02:03, 29 April 2026 (UTC)

WP:GAME doesn't appear to be an intuitive rule to me, and there are many cases where it restricts a possible way to avoid large reverts. For example, segmented edits are better for controversial topics, as they allow people to easily revert a particular problem caused by a good faith editor. So here's my question: couldn't we remove GAME and support the separation of controversial changes and other, trivial changes? Or we could have editors decide whether to link two changes, and have them count as one for the edit count. Heck, we could even make a system that only counts one edit per page per day or something for the edit count (I feel that this might be preferable to just having a warning templates if someone breaks GAME). Wikipedian12512(alt) (talk) 21:38, 28 April 2026 (UTC)

Making several edits to allow for specific reverts wouldn't fall under "gaming the system" in my opinion. The matter is more suited for something like making 10 dummy edits adding one character to a sandbox, rather than making several substantial content edits on the same article. This is one of the reasons why having Wikipedia not being a legal system is useful, as a rigid rule on "don't make multiple edits in a row on the same page" would indeed be much less practical. Chaotic Enby (talk · contribs) 21:48, 28 April 2026 (UTC)

And, as someone often guilty of changing my mind and adding more to one of my comments, I'd be the first one affected by this! Chaotic Enby (talk · contribs) 21:48, 28 April 2026 (UTC)

Yes, I agree that the flexability is important, but a system that I think would work better is one where you can add many dummy edits to a sandbox, but only the first counts. Maybe one every hour per article in the main space, and one per day in the non main space? (These are all per page, different things on different pages are treated seperately, and this isn’t saying you can’t go back and add another tweak, just that the second one doesn’t count for edit counts if it’s too soon.) Wikipedian12512 (talk) 00:11, 29 April 2026 (UTC)

That could be a good idea! In that case, the edit count requirement should be decreased accordingly as not every edit from legitimate editors will count anymore. Given the recent technical changes to autoconfirmed, this is absolutely something that can be taken into consideration! Chaotic Enby (talk · contribs) 00:22, 29 April 2026 (UTC)

Thanks :)! Wikipedian12512 (talk) 00:47, 29 April 2026 (UTC)

My guess would be that the auto confirmed should stay the same, as the 10 edit req is kinda just to make sure someone doesn’t just make the account, wait a bit, then vandalize. Plus, with the linking bot suggestions, it shouldn’t be too hard for anyone. (If necessary, I think seven is a good number, but ten is also quite practical.)

Extended confirmed might need a much larger decrease, as the bot suggestions stop after a while and people start to find their “groove,” hitting things that they really like, therefore lowering their range and leading to doing a lot of work on the same article. My guess would be that 350-400 would be the ideal new range for that.

Anything else needing an edit count should be lowered by 20-40%.

(I’m probably getting ahead of myself here.)

Wikipedian12512 (talk) 00:55, 29 April 2026 (UTC)

• Note the OP presumably means WP:Gaming the system (WP:GAME) rather than Wikipedia:WikiProject Ghost towns (WP:GTS). Please check the shortcut goes where you think it does before posting - in this case the link target enough of a non sequitur to make it clear that there is an error and there is sufficient context for experienced editors like me to work out the intended meaning. However when the target is more plausibly relevant, there is less context and/or the reader is less familiar with the English Wikipedia a mistake like this could cause serious confusion and miscommunication. Thryduulf (talk) 01:05, 29 April 2026 (UTC)

  Sorry. Every single time, I mix those up.

  Note to anyone confused: I meant Wikipedia:Gaming the system. I’ll be changing this now. Thanks! Wikipedian12512 (talk) 01:11, 29 April 2026 (UTC)

  And, please, everyone, check that the WP:UPPERCASE actually says what you think it says. Our rumor mill/telephone game is not a reliable source for what pages like WP:QUO or WP:NOTNEWS actually say. WhatamIdoing (talk) 01:59, 29 April 2026 (UTC)

  …What? Wikipedian12512 (talk) 02:27, 29 April 2026 (UTC)

  Am I missing context? Wikipedian12512 (talk) 02:27, 29 April 2026 (UTC)

Apparently continued at Wikipedia:Village pump (policy) § Proposal: Changing WP:GAME. Graham87 (talk) 07:16, 30 April 2026 (UTC)

The WMF has recently changed Autoconfirmed to apply from the date the first edit was made, not the date the account was first created.

I'm opening this discussion because there was some discussion in that AN thread about additional changes to autoconfirmed or extended confirmed, with the intent to get a list of changes that the community might want to see made to these rights. These possible changes would then be taken to a multi-part RfC.

How they are presented in the RfC depends on the proposed change. Configuration changes (changing the seniority or number of edits required for autoconfirmed or extended confirmed) are simple to implement and only require a consensus to be formed and a request made through the process listed at meta:Requesting wiki configuration changes, and would be listed in the RfC as being there to determine whether the required consensus exists.

Proposals for changes that are not simple to implement, such as changing extended confirmed to be from the date the first edit was made, not the date the account was first created, would be listed in the RfC as going into an open letter if there is a consensus for them, which would request that the WMF consider implementing them.

Changes to discuss in the RfC could include:

Configuration changes

1. Change AC to require 7/14/30 days of seniority, not 4
2. Change AC to require 25/50/100 edits, not 10
3. Change ECR to require 60/90/180/365 days of seniority, not 30
4. Change ECR to require 750/1000/2000 edits, not 500

Other changes:

1. Change AC to require 7 days with edits, not 7 days seniority
2. Change ECR to apply from the date the first edit was made, not the date the account was first created
3. Change ECR to apply from the date the account received autoconfirmed, not the date the account was first created
4. Change ECR to require 30 days with edits, not 30 days seniority
5. Change ECR to count only the first 10/25/50 edits on any day

Please proposal additional ones. BilledMammal (talk) 06:29, 30 April 2026 (UTC)

I think other changes 1, 4, and 5 are too complicated to explain to new editors, but I wanted to include them here to allow for discussion on them.

Regarding configuration change 3, ECR period, according to statistics from Sean.hoyland, most accounts already take more than a year to obtain it, so extending the period is not likely to be disruptive.

BilledMammal (talk) 06:29, 30 April 2026 (UTC)

One easily overlooked effect of increasing the requirements is that we would get more requests for manual granting of these permissions, so more work for admins. Phil Bridger (talk) 08:10, 30 April 2026 (UTC)

I'm not sure how sensitive the number of requests for manual EC grants is to the requirements. Most requests seem to be related to either the content translation tool, alternative accounts, restoration of the grant after it was revoked or the occasional "the rules don't apply to me because..." claims (which can presumably be declined at leisure). It's not obvious to me how or the extent to which requirements changes would impact those sets. Sean.hoyland (talk) 13:18, 30 April 2026 (UTC)

I note that changing ECR to count from first edit would be simple to implement, just swap APCOND_AGE for APCOND_AGE_FROM_EDIT in the configuration. Some wikis already do this. Anomie⚔ 11:58, 30 April 2026 (UTC)

I have to wonder what the purpose of all these proposed changes is. I find it hard to believe that the sort of vandals that make sleeper accounts would be significantly inconvenienced by the change from "age from creation" to "age from first edit" or by modest increases in the thresholds. Similarly, the "days with edits" might make it easier for vandal fighters to catch obvious patterns (if they have the bandwidth to watch), but other than that I don't see it being much barrier to persistent vandals either. On the other hand, legitimate new editors are probably much more likely to be affected. Anomie⚔ 11:58, 30 April 2026 (UTC)

What would be the effects on legitimate new editors in your view? I should clarify that I don't see EC as a barrier for vandals. Vandals can just be reverted (or they won't be able to edit EC protected pages anyway). The EC grant is interesting for me because I think it is effectively our only enforceable restriction for contentious topic areas, and there are interesting statistical relationships between grant acquisition rates and outcomes for accounts (e.g. ). It's possible that the EC requirements could be one of the few dials we can turn to regulate disruption in contentious topic areas. Sean.hoyland (talk) 13:50, 30 April 2026 (UTC)

Having said that, when it comes to contentious topic areas, with their complicated feedback loops, I have very little confidence in our ability to predict the effects of actions. Things done in good faith to improve things may not have the intended effect and may make things worse e.g. AE seems like a good idea in theory, but in a polarized environment with the additional issue of an inability to establish whether accounts are in good standing, the system becomes weaponized and a cause of conflict. Similarly, changing the EC requirements might have the opposite of the intended effect by filtering out the semi-disinterested parties (who can't be bothered to acquire EC) and concentrating the dedicated partisans willing to put in the effort. One contentious topic area, for example, is currently under attack by organized, probably paid, ban/block/lock evading actors, and I doubt that changing the EC requirements would significantly impact these kinds of actors, although it would extract more pre-EC work from them, which probably benefits the project. Sean.hoyland (talk) 15:04, 30 April 2026 (UTC)

Change ECR to require 50 edits, not 500. The current bar is already absurdly high and makes XC protected articles considerably worse. LordCollaboration (talk) 14:03, 30 April 2026 (UTC)

Any time-based limits are moot to me, since you don't need experience to go and do something else for a bit.

ECR involves articles with the most potential for disruption, so I absolutely think #4 in config changes is my preference (1k edits). There are plenty of editors with 500 edits at ANI or Teahouse who still don't know how to find reliable sources properly - especially when it comes to contentious topics.

The difference between the amount of editors who manually ask for EC vs. the potential save in disruption from otherwise-well meaning editors (or not-so-well meaning ones) is going to be pretty significant IMO.

AC editors can still work on any non-ECR article, so this won't impact new editors that much, it's just raising the bar on our definition of an experienced editor.

I also think #4 on the second section is best (within that section) as it has the least potential for exploitation, #5 would be great but I don't know if that's technically possible? Overall, I prefer #4 at the top. Blue-Sonnet 14:07, 30 April 2026 (UTC)

If you look at the Days and Unique Dates columns in https://gamingcheck.toolforge.org/recent_grants_table with the Verbose option switched on, it's clear that account age and active editing days are very different kinds of time that would presumably have different effects in requirements. Sean.hoyland (talk) 14:18, 30 April 2026 (UTC)

Would it be possible for autoconfirmed to require mainspace edits? Or at the very least non-userspace/draftspace edits, so that somebody can't get 10 edits to their own article draft and then be able to create it in mainspace. ScalarFactor (talk) 17:00, 30 April 2026 (UTC)

I don't think any criteria can give us what we want. The idea of the "confirmed" status is to give us some idea that the user is not just here to vandalise, and "extended confirmed" to show us that the user is experienced and has some idea of policy/guidelines. These are very difficult to automate. For exanple a user with 50 edits could know policy/guidelines inside out, but a user with 5000 could know nothing about them. Phil Bridger (talk) 22:08, 30 April 2026 (UTC)

I think a big part of that problem is that "we" don't agree on what "we" want in the first place. You (and I) think of autoconfirmed as a low bar to stop the simplest drive-by vandalism by people who've effectively never edited before. Dennis Brown, just below, wants it to be something much stronger for many different purposes. Anomie⚔ 01:53, 1 May 2026 (UTC)

• I personally think AC should be 50 edit + 30 days. Some may argue this is a high bar, but I would argue that for one the largest and heavily trafficked websites on the planet, it is a reasonable limit that allows new users to edit most articles, and protects sensitive articles. This isn't just about vandalism, it also protects against sockpuppetry/meatpuppetry, and even from innocent "bad edits" from users that are too new to understand how things work here. 50 edits is also enough to establish patterns for bad acting accounts, to see if they are gaming the system, if they are essentially SPAs, and if they are actually WP:HERE to build an encyclopedia. I don't think we need to limit it to $x number over $y days, or only count mainspace edits, just keep it simple. 50/30 makes it easy to understand, easy to determine someone's motivation, and is based on the reality that it takes a month for a good faith editor to have a clue about things like WP:BRD, how to use talk pages, etc. If anything, it would prevent new, good faith editors, from getting into trouble on sensitive pages simply due to a lack of experience, and improve the experience for all editors. Dennis Brown - 2¢ 23:41, 30 April 2026 (UTC)

Recently, Vector 2022 has been showing the donate button in bold to logged out users, making it more prominent than "Create account".

In a discussion at the Fundraising Hub, Toadspike, Barkeep49, and Chaotic Enby have proposed unbolding it but the WMF doesn't seem receptive. However, it should be possible for us to do that ourselves, by editing MediaWiki:Vector-2022.css.

I want to start a discussion on doing so here, to see what the general opinion of the community is, and if the community is supportive then possibly open an RfC if the WMF isn't willing to act. BilledMammal (talk) 07:04, 30 April 2026 (UTC)

Yep, I think giving the "Donate" button more prominence than the "create account" button really gets our priorities backwards. We are in great need of more editors. We are not really in need of more donations. Toadspike [Talk] 08:43, 30 April 2026 (UTC)

Would bolding Create account put a thumb on that scale? CMD (talk) 09:35, 30 April 2026 (UTC)

Agree but maybe it's styled bold because the button is there temporary, unlike the create account button. On a related note, I think it needs open source developers / technical contributors too and this is essentially never highlighted (I've suggested occasional campaigns/banners above IT-related articles). Prototyperspective (talk) 11:58, 30 April 2026 (UTC)

I don't love the message bolding Donate and not create an account sends. I have consistently pushed for "editing" to be a meaningful part of the "donation" process because a semi-regular editor provides far more value to the project than someone throwing money equivalent to a few cups of coffee at the foundation once a year. However, I'm not sure I agree that We are not really in need of more donations. First I don't agree because I don't see myself as part of the WMF so their need for donations is not something that includes me in a "we" situation. But I also don't agree because, for the first time since I became an active participant in these kinds of discussions, I think the WMF does need donations. Even for those who think all the Foundation should do is keep servers running and defend us legally, the costs of maintaining the project have risen dramatically in the last year, with AI scrapers placing real strain on our servers and the political and legal climates in numerous places causing increase stain there. And, for me, I want the foundation also developing the mediawiki software and think its done a better, though still highly imperfect, job of orienting that development towards community desires and needs. Together, I think the WMF's objective needs are greater and it's doing a better job of spending the money it does raise. So I am troubled by the decreased number of donors in last year's fundraising drive both from a financial standpoint and because of what it means for our readership (with readership being something I care about a huge amount). I suggest instead of finding ways to unbold "Donate" we should go the opposite direction, leaving that bold, and instead using our abilities to also bold "Create an account". Best, Barkeep49 (talk) 14:50, 30 April 2026 (UTC)

Co-signing the above, and I'd like to draw on because of what it means for our readership a bit more. AI isn't just a threat to our server capacity. It's preventing readers of our information from being readers of Wikipedia. And that's where we get both editors and donations from. We are going to start needing both, much more than usual. -- asilvering (talk) 15:20, 30 April 2026 (UTC)

Seconding Barkeep once again on this. The only worry I'm having with this is that bolding conveys relative importance as well as absolute importance – if everything is bolded, we're giving the reader more or less the same impression as if nothing is, although the buttons will be (on aggregate) slightly more visible. Bolding the Donate and Create account buttons but not the Log in button could be another option, although I'm afraid it might look a little odd. But yes, we do need both more editors and more donors in the grand scheme of things. Chaotic Enby (talk · contribs) 16:55, 30 April 2026 (UTC)

Hi all - A major area of the Wikimedia Foundation’s 2026-2027 annual plan is around deepening contributor engagement, where we’re trying to double the number of retained editors over the next two years. That’s a huge goal, but it’s the right one; our entire mission depends on growing the number of volunteers who create and improve Wikipedia content. It’s also one that has been strongly recommended by editors on the Product and Technology Advisory Council (PTAC). Foundation teams are spending a lot of time thinking about what are the most effective entry points to do that, including things like lowering the barriers to entry for newcomers through structured editing. If you have any thoughts about this, we’d love your feedback on the annual plan talk page. KStineRowe (WMF) (talk) 20:59, 30 April 2026 (UTC)

cc @KStineRowe (WMF)'s point, I remember talking about this exact thing with @OVasileva (WMF) about this a while back after Toadspike mentioned it on the Fundraising Hub page. TLDR, I think the current status quo of donate having more prominence than creating a account is temporary? and the plan is to double down on bringing account creation to the forefront in the next year to my understanding. Sohom (talk) 21:16, 30 April 2026 (UTC)

For those who don't speak WMF, "next year" refers to the next Fiscal Year which starts in July. But future promises does nothing in my mind to diminish actions we might want to take as a community now. Best, Barkeep49 (talk) 21:22, 30 April 2026 (UTC)

@Barkeep49 Yes and no. They are working on some of it this year. For example, mw:Readers/Reader Experience/Reading lists trials (one of the features that WMF thinks might get a lot of folks to create accounts) are ongoing right now. But again you are right that most of the work appears to be scheduled for the next year. Sohom (talk) 21:33, 30 April 2026 (UTC)

Also cc @SToyofuku-WMF who was more directly involved in the experiment per the List_of_experiments_in_Product_and_Technology. Sohom (talk) 21:36, 30 April 2026 (UTC)

Reading lists are a project because the WMF sees a large number of people who create accounts and whose only desired role is to be a reader. The WMF wants to make Wikipedia more useful for them. This is great. I support such work. I take our readers seriously and delivering value to users keeps them coming here as opposed to relying on AI slop; it's an example of why I want to see the WMF able to continue to fundraise successfully. That, however, is different from getting people to be an editor which is what I am focused on in this discussion. The good news is that bolding the "Create an account" serves both kinds of registered accounts. Best, Barkeep49 (talk) 21:44, 30 April 2026 (UTC)

On the linked page it does say that it may encourage more users to become editors. Personally I think this is unlikely, though I agree that improving the reader experience is still a worthwhile goal.  novov talk edits 12:53, 1 May 2026 (UTC)

Thanks all - we're pretty open to discussing turning off the donor button bolding and exploring the idea of bolding the account creation button, but these decisions fall across a few different teams/timezones, and some key people are at an offsite. Would it be ok with you if we paused this discussion and followed up with you all next week? KStineRowe (WMF) (talk) 14:50, 1 May 2026 (UTC)

Sounds great, thanks a lot for the feedback! Chaotic Enby (talk · contribs) 15:07, 1 May 2026 (UTC)

That definitely works! Sohom (talk) 15:32, 1 May 2026 (UTC)

What are the reasons that make this current temporary status quo (which might add confusion to readers about our priorities) necessary, and would it be possible to make these changes sooner instead of waiting a fiscal year? I'm worried that, while "temporary" at first, it might stay here as a fait accompli and be much harder to change moving forward. Chaotic Enby (talk · contribs) 21:53, 30 April 2026 (UTC)

Noting that it was Some1 not me who raised the bolding issue. It got misattributed to me. Best, Barkeep49 (talk) 14:26, 30 April 2026 (UTC)

Thanks for the ping Barkeep49, but I believe it was Toadspike who raised the bolding issue, not me . I haven't commented on the new Donate button yet, but since I'm here, I'll just give my 2 cents and say that bolding the Donate link makes it look tacky. My preference would be to not bold any of those three top-right corner links (donate, create an account, log in), unless data shows that bolding those links will increase the number of donations/user account creations, etc. Some1 (talk) 22:39, 30 April 2026 (UTC)

But the WMF seems perfectly prepared to "look tacky" as long as the money keeps rolling in. Phil Bridger (talk) 18:32, 1 May 2026 (UTC)

Would we really need an RfC for this? It’ll just get speedily closed in favour and stir up animosity Kowal2701 (talk, contribs) 16:23, 30 April 2026 (UTC)

I think if the community wants Iadmins to start a fight with the WMF then it should be really clear that they truly have community support. Speaking as an interface admin myself I definitely would not be willing to do this without an RfC. * Pppery * _{it has begun...} 17:29, 30 April 2026 (UTC)

Same here (although, being WP:INVOLVED, I shouldn't be the one to do this either way). If there isn't a clear message from the community showing overwhelming consensus, we shouldn't be doing this. And, if there is, our primary goal should be convincing the WMF instead of circumventing them. Chaotic Enby (talk · contribs) 17:46, 30 April 2026 (UTC)

Ditto from me, I'm happy to talk with WMF folks on behalf of the community, I'm not going to be taking any controversial WP:IADMIN actions without strong community consensus. Sohom (talk) 21:25, 30 April 2026 (UTC)

On a different front from the IA points raised by Pppery and CE, as this thread shows in the discussion so far even when there's agreement on the problem (bolding the Donate button by itself is bad), there may be disagreement on the solution and so finding consensus can be useful. Best, Barkeep49 (talk) 17:55, 30 April 2026 (UTC)

Imho the only button that should be bolded is "Edit", as it was before Monobook.-- sapphaline (talk) 19:44, 30 April 2026 (UTC)

The Wikipedia mobile site and app currently provide no information about an article’s assessment level (FA, GA, etc). Neither the article pages themselves nor the corresponding talk pages show it. A little icon on either of those pages (or just making some of the standard talk page templates visible) would be helpful. Philroc (talk) 18:19, 30 April 2026 (UTC)

The talk pages do show it, at least on web on my phone. The assessment templates are hidden behind a button saying "Learn more about this page". It would be good for them to be visible without having to press a button. CheeseAndJamSamdwich (talk) 19:01, 30 April 2026 (UTC)

Similar discussion occurred at Wikipedia:Village pump (proposals)/Archive 174#Move good/featured article topicons next to article name. There is apparently an issue (though I don't know if it applies to skins added since 2020) that prevents GA/FA topicons from appearing on mobile (apologies if I'm totally wrong about this now). As stated, most of this information can be found on the "Learn more about this page" when looking at a talk page if you really need it. I was certain more discussion was had at length about assessments being visible on mobile in the past but I can't find it now. -- Reconrabbit 17:58, 1 May 2026 (UTC)