Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for 10 days.

« Archives, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72

Edit request spam

We have this phenomenon that I call "edit request spam", though there might be a better name. Is it discussed anywhere? It seems to trip up experienced editors. Here are examples from Template talk:Source check:

• Special:Diff/1302369938/1302815150
• Special:Diff/1315839583/1316124486
• Special:Diff/1251775942/1287960886

It's a common phenomenon. You could say it's good faith editors making a mistake but I don't think so, it happens far too frequently, and almost always involves an IP or red account without history. Why do they do it? It's the perfect spam/troll. It demands attention from experienced editors, who must then take action and sign their name to what is a joke on you.

What are ways to deal with this? My immediate reaction is "revert", but some editors inexplicably continue to take them seriously. Even if you assume good faith, they should probably be deleted anyway because they are empty requests with no purpose. At the very least this should be documented somewhere so we can link to WP:EDITREQUESTSPAM or something when reverting. -- GreenC 17:23, 10 October 2025 (UTC)

it happens far too frequently - In a world of eight billion people? You're seeing the minuscule fraction who think Wikipedia talk pages are social media. Of course they should be removed, not archived. ―Mandruss ☎ IMO. 17:27, 10 October 2025 (UTC)

We have WP:NOTFORUM for this. These aren't the best examples, though; two of them seem like test edits, and the third is an actual request to change the article. Gnomingstuff (talk) 19:35, 11 October 2025 (UTC)

I think a bigger problem is that some edit requests that don't strictly comport with the format but are abundantly clear in their intent are resolved as malformed and not directly addressed. That's probably another idea for another day. Bremps... 00:59, 12 October 2025 (UTC)

To address the discussion itself, I don't think we need anything more than ordinary archiving or reversion. Bremps... 01:00, 12 October 2025 (UTC)

I wish there were a way to prevent empty edit requests from being posted. WhatamIdoing (talk) 06:48, 12 October 2025 (UTC)

It's possible an edit filter could do that, although it couldn't catch everything that is semantically empty but not objectively empty most empty ones I see are either literally empty or just contain the example diff text. Thryduulf (talk) 09:11, 12 October 2025 (UTC)

I suspect that most blank edit requests are coming from the editing window, in which case it'd make more sense to build it into the MediaWiki software. WhatamIdoing (talk) 19:25, 23 October 2025 (UTC)

I think it is, although maybe a better solution would be to something informative. I'll take a look if no-one else gets there first. All the best: Rich Farmbrough 17:01, 3 November 2025 (UTC).

I think different editors having their own opinions and responses to this is a good status quo. Aaron Liu (talk) 01:19, 14 October 2025 (UTC)

It might be worth creating a standard reply template. All the best: Rich Farmbrough 17:01, 3 November 2025 (UTC).

Integrate quizzes in declines and warnings

Good-faith new users often interact with experienced editors mostly via templated warnings, declines, or draftication notices. Ideally, we would personalised these messages more, but there's insufficient capacity for that. I don't think these type of notices are that effective in teaching new editors how we do stuff.

What if we were to include an optional quiz as part of these notices. This could for instance test somebody's understanding of the text of the notice, and show where there understanding might not be there yet. For instance, for GNG, we might ask 3 questions where they assess if a source counts towards notability. For copyright violations, we can e.g. ask them a question about what to do if the source doesn't explicitly have a copyright notice.

I think this might have the potential to teach more newbies how Wikipedia works, and hopefully leads to fewer reverts or even blocks. Curious to hear what others think. Is there already a way to A/B test changes like this? —Femke 🐦 (talk) 16:37, 15 October 2025 (UTC)

It may work, but the problem is that if you ask those questions of two experienced Wikipedians you are likely to get seven different answers. Phil Bridger (talk) 16:51, 15 October 2025 (UTC)

A good quiz would likely directly get examples from the relevant policies or other simple examples where we do agree. It's about teaching the basics, not the complicated stuff. —Femke 🐦 (talk) 17:04, 15 October 2025 (UTC)

That assumes we even agree about what's directly in the policies. 😉 There are a decent number of things I think people have snuck into various policies to give them an easier time arguing against things than they'd have actually discussing whether the sources are reliable and so on. Anomie⚔ 17:49, 15 October 2025 (UTC)

That's certainly possible yes. But i imagine the very basics of our PAGs we would be teaching are pretty stable. —Femke 🐦 (talk) 18:04, 15 October 2025 (UTC)

It could also produce a bit of useful inspection of policies and their interpretation, and maybe even some useful clarification. · · · Peter Southwood ^(talk): 08:47, 27 October 2025 (UTC)

The suggestion that we should quiz editors implies that we should take action against them if they answer the quiz incorrectly? But doesn't that presume that they would continue to make the same kinds of edits that led to them being warned, which may not be a valid assumption? DonIago (talk) 16:56, 15 October 2025 (UTC)

Perhaps it could be arranged a bit like the DYK section of the main page. A declined AfC on the basis of poor sourcing could be accompanied by a friendly "Did you know: in 1832 the Wikipedia community decided that the Daily Mail is as reliable as a chocolate teapot and anyone attempting to use it as a source would be ridiculed mercilessly?" (only replaced with accurate and less facetious text, of course). Or copyright template warnings could come with "Did you know: copyright extends not just to copy-pasting blocks of text, but also to close paraphrasing?" (probably accompanied by appropriate links to help-pages and policies). Elemimele (talk) 17:04, 15 October 2025 (UTC)

I'd support this over issuing quizzes. DonIago (talk) 17:15, 15 October 2025 (UTC)

Some of our notices are a big block of shouty text. Too much bolding, linking etc to convey the message. Designing them better with a highlighted example might make sense. Examples are always good didactically. If we try this too, can we already A/B test this? —Femke 🐦 (talk) 18:00, 15 October 2025 (UTC)

The idea is that this is to make it easier to learn stuff. In the first instance. If this works, we might consider putting is as part the unblock process, where it forms the first step for quizzable 'offenses' (copyvio etc). But that's a question for later. —Femke 🐦 (talk) 17:07, 15 October 2025 (UTC)

I think you need to clarify your idea of how this process would work, because there's a big difference between giving a new editor a non-required quiz after they've received one warning, and giving a non-new editor a required quiz as a condition of their being unblocked. In your OP you specified "newbies", and I think it may fall afoul of WP:AGF to require new users to have to pass quizzes to resume editing; at worst you're effectively blocking them for a single offense. DonIago (talk) 17:17, 15 October 2025 (UTC)

The idea is that this is optional. They get a warning. As part of that warning is a shiny button saying 'test your knowledge'. When they make a mistake, they get a two-sentene explanation of how the policy works in that example. If they prefer to instead just click there link and read the relevant policy, that's fine too.

If this works, we might want to include something in the unblock process as well, where it might not be optional. But it needs to be thoroughly tested before any of that could happen in an optional system. —Femke 🐦 (talk) 17:56, 15 October 2025 (UTC)

Sorry, I somehow lost track of this. Also, sorry if I missed your original stipulation that this would be optional, as that makes this more of a fun learning tool rather than anything else, which obviously changes the scope of it. I'm open to the possibility of this, though it might be more complicated than we anticipate to come up with quizzes with unambiguously right answers. Still, I don't have any objection to pursuing it, though I agree with you that there's going to need to be some thorough testing involved. Even a question as ostensibly simple as, "Does statement X need to be accompanied by a citation?" is the kind of question that different readers may interpret in ways that could lead to conflicting responses. DonIago (talk) 03:03, 27 October 2025 (UTC)

I don't think that's the intention. I see it as a way to identify areas for improvement in editors (particularly, those who are genuinely trying to help but don't know much about our policies), not a punishment. Rosaece ♡ talk ♡ contribs 12:28, 16 October 2025 (UTC)

This puts me in mind of Template:Coiq, which used to be in fairly widespread use on the unblock queue. —Cryptic 17:51, 15 October 2025 (UTC)

Unlike that one I agree with the others here that the quiz should not have any consequences. Aaron Liu (talk) 23:09, 5 November 2025 (UTC)

Well, for copyright specifically, I often make a follow up comment to give the editor a link to the WMF student training module on plagiarism. Unclear success rate, given that people don't tell me if they've done it, but at least it makes me feel better if I have to AN/I them later. I certainly don't think it would be a bad idea to include links to the other modules in standard warning templates. They're not half bad, and they already exist. GreenLipstickLesbian💌🦋 18:12, 15 October 2025 (UTC)

I think this is a great idea.

Quizzes can be optional and voluntary too. For example, a quiz about core content policies.

Completing quizzes can be rewarded with barnstars delivered by a bot. Bogazicili (talk) 18:37, 15 October 2025 (UTC)

I think this is a great idea. Currently warnings describe what an editor has done wrong, but most of them don't really explain why it's wrong. Encouraging editors to learn from their mistakes is a good form of editor retention. Rosaece ♡ talk ♡ contribs 12:35, 16 October 2025 (UTC)

This reminds me of Help:Introduction to policies and guidelines/neutrality quiz, which could be a good start for this project! Chaotic Enby (talk · contribs) 09:26, 17 October 2025 (UTC)

And User:Tony1/Redundancy exercises: removing fluff from your writing. If we force editors to take quizzes, they would probably use AI, however. Children Will Listen (🐄 talk, 🫘 contribs) 03:13, 27 October 2025 (UTC)

There's also the existing MCQs from Wikipedia:The Wikipedia Adventure, which I think are the best format, though the questions should probably be different and less simplistic. See for example Wikipedia:TWA/4/NPOV. Aaron Liu (talk) 23:10, 5 November 2025 (UTC)

In principle I like it a lot. I think it is worth a try, and suggest go ahead and provide a few samples for us to consider. I also suggest a database/list of appropriate questions connected with specific editing errors as a way to workshop it. · · · Peter Southwood ^(talk): 05:58, 23 October 2025 (UTC)

@Femke, if you start this project, please keep me posted. I'm really curious of how it would be implemented. Thanks! Trizek_(WMF) (talk) 19:43, 27 October 2025 (UTC)

An alternative is not to use templates. Or at least not shiny icon laden box surrounded templates. Newsers oftn assume these are automatically generated and pay not attention. All the best: Rich Farmbrough 13:47, 2 November 2025 (UTC).

Another thing that would be lovely to test if we can do A/B testing is making those notes seem like they are handwritten and less formal. Would that make people pay more attention? —Femke 🐦 (talk) 13:49, 2 November 2025 (UTC)

A/B testing to improve new editor retention is absolutely something I'd like to see more of on-wiki, so I can only second this! Chaotic Enby (talk · contribs) 03:12, 4 November 2025 (UTC)

Add a bot/policy that bans AI edits from non-extended confirmed users

I saw this thread yesterday and I wanted to chime in this idea I had, but I waited to long to act on it and now it's archived. So I guess I'll have to make a new thread.

It's clear that lots of new editors struggle making good content with AI assistance, and something has to be done. WP:G15 is already a good start, but I think restrictions can be extended further. Extended confirmation on Wikipedia is already somewhat of a benchmark to qualify editors to edit contentious articles, and I think the same criteria would do well to stop the worst AI slop from infecting mainspace. As for how this would be implemented, I'm not sure - a policy would allow human intervention, but a bot designed like ClueBot NG might automate the process if someone knows how to build one. Koopinator (talk) 10:50, 18 October 2025 (UTC)

I do t see a practical way to enforce that. I also dont think that peoples skill level with AI can transfer to an assessment of their skill level in wikipedia. —TheDJ (talk • contribs) 11:31, 18 October 2025 (UTC)

Regarding enforcement, I would suggest:

1. Looking at whatever process ClueBot uses to detect and evaluate new edits, and add a "extended confirmed/non-ec" clause.

1.1. I will admit I'm not entirely sure of how this would work on a technical level, which is why I posted this idea in the idea lab.

2. Look to word frequency as in User:Gnomingstuff/AI experiment to distinguish AI from non-AI edits. Koopinator (talk) 15:32, 18 October 2025 (UTC)

please don't use this in any kind of blocking enforcement capacity, it is not remotely ready for anything like that Gnomingstuff (talk) 17:41, 20 October 2025 (UTC)

A person's willingness to use AI on Wikipedia is an immediate and absolute WP:NOTHERE, in my opinion. TooManyFingers (talk) 05:50, 4 November 2025 (UTC)

Too sweeping an opinion in my opinion. First you would have to be talking about specifically using unsupervised AI to write articles. Secondly I think it would be "insistance" rather than "willingness". And thirdly it could well be a WP:CIR or user education issue rather than a NOTHERE one. All the best: Rich Farmbrough 18:03, 6 November 2025 (UTC).

Do you have any evidence that extended confirmed users create any better edits with AI than users who are not extended confirmed? Phil Bridger (talk) 14:33, 18 October 2025 (UTC)

I would say it's a reasonable inference. Here's what I can say:

• We can expect that extended-confirmed users are more likely to be familiar with Wikipedia's policies and guidelines, by virtue of having been here longer.
  • This expectation is, in part, substantiated by that most vandalism comes from IP editors.
• Some anecdotal evidence:
  • [1] LLM edit with no sources, survived for almost 2 months. Was created by an editor who was neither confirmed nor extended confirmed.
  • [2] Personal project by yours truly, AI assistance was used, careful review of text-source integrity of every sentence as I constructed the page in my sandbox over the course of 59 days before airing it.
• I admit none of this is hard evidence.

I do feel LLM has its place on the site (otherwise I wouldn't have used ChatGPT assistance in constructing a page), but if it's allowed, the barrier for usage really should be heightened. Wikipedia's content translation tool is also restricted to extended-confirmed users.

Koopinator (talk) 15:25, 18 October 2025 (UTC)

The issue is raising the bar to prevent bots from editing Wikipedia using LLMs. LDW5432 (talk) 19:57, 27 October 2025 (UTC)

LLM detection for text is very hard and has far, far too many false positives, especially for non-native speakers and certain wavelengths of autism. Aaron Liu (talk) 16:41, 18 October 2025 (UTC)

^ This is my experience. Also, a lot of edits are too brief for the already-dodgy AI "detectors" to be reliable for.

@Koopinator, you've made around 2,000 mainspace edits in the last ~2 years. Here's a complete list of all your edits that the visual editor could detect as being more than a handful of words added.[3] It's 78 edits (4% of your edits) – less than once a week on average. And I'd guess that half of your content additions are too short to have any chance of using an anti-AI tool on, so the anti-AI tool would check your edits two or three times a month. Why build something, if it could only be useful so rarely? WhatamIdoing (talk) 00:58, 19 October 2025 (UTC)

Well, how would that tool's frequency scale across the entire Wikipedia community? I'd imagine it'd be used at least a little bit more often then. (or, I imagine, multiple orders of magnitude) Koopinator (talk) 05:55, 19 October 2025 (UTC)

For brand-new editors, it might capture something on the order of half of mainspace edits. High-volume editors are much more likely to edit without adding any content, so it'd be much less useful for that group. WhatamIdoing (talk) 19:54, 23 October 2025 (UTC)

We could at least use a flagging system for vandalism review. LDW5432 (talk) 14:05, 6 November 2025 (UTC)

It should be possible to detect low hanging fruit AI text, based on certain common features. Raw AI inference cut and pasted from a chat bot is going to be easier to detect. I agree that the type of user doing this probably has no reputation at stake, doesn't care very much, more likely to be newbie and/or a non-native speaker from another Wiki. I don't know about policy, but a bot that sends a talk page notice, or flags the edit summary with a "[possible ai]" tag. No one is already working on this? -- GreenC 17:10, 18 October 2025 (UTC)

mw:Edit check/Tone Check uses a Small language model to detect promotionalism. (See tagged edits.) I'd guess that it would be possible to add an AI detector to that, though the volume involved would mean the WMF would need to host their own or pay for a corporate license and address the privacy problems.

mw:Edit check/Paste Check is probably more efficient, though, as anyone copying from a chatbot is going to be pasting it into the article, and detecting a big paste is easier than checking the words that were pasted in. WhatamIdoing (talk) 01:04, 19 October 2025 (UTC)

I think AI edits should be mandatory for everyone to disclose, both in articles and talk pages. There could be a box where you check it if your content comes from AI or is mostly AI, similar to how you can check minor edits. Bogazicili (talk) 18:40, 21 October 2025 (UTC)

Having a UI element like that would work towards legitimizing LLM use in creating text for Wikipedia. Merko (talk) 00:41, 22 October 2025 (UTC)

I agree: Either it will allow the material to be posted and thus legitimize LLM use, or it won't allow the material to be posted and cause people to tell lies so they can get it posted. WhatamIdoing (talk) 02:18, 22 October 2025 (UTC)

Do we currently have a policy on LLM usage? This one seems failed Wikipedia:Large language model policy

My position is that if it's not banned, it should be declared. Bogazicili (talk) 10:45, 23 October 2025 (UTC)

I thought the failed policy proposal was supposed to require people to declare it. WhatamIdoing (talk) 20:00, 23 October 2025 (UTC)

Almost 2 years ago. Merko (talk) 22:09, 23 October 2025 (UTC)

LLM-generated content is a cancer on Wikipedia, and it will only get worse. "AI detectors" have many false positives, as do checks made by editors themselves, but just because we can't reliably detect something today doesn't mean we shouldn't implement a policy against it. I support mandating the disclosure of LLM-generated contributions by all users. We don't treat WP:GNG differently on articles created by extended-confirmed users or others, we shouldn't do it here either. Merko (talk) 22:21, 21 October 2025 (UTC)

If you think original content generated by a program is a negative to that extent, then I don't think requiring disclosure is the appropriate approach, since that would only be a prelude to removal. We should skip straight to requiring editors not to use programs to generate original content. isaacl (talk) 04:38, 22 October 2025 (UTC)

Wikipedia should first address LLM content from anonymous IPs. LDW5432 (talk) 19:56, 27 October 2025 (UTC)

IP editing actually isn't that much of a problem here -- in my experience almost all AI text I find came from someone with a registered account. Off the top of my head I'd say less than 10% of it comes from IPs.

This may change with temporary accounts in a few days though, who knows. Gnomingstuff (talk) 20:56, 30 October 2025 (UTC)

I came here to propose pretty much the same thing (policy, not bot). Having a blanket rule would be hugely helpful in dealing with editors, since it can get very tedious explaining why each AI edit they claim to have checked is in fact problematic. I might even go so far as to propose a separate user right (or pseudo-right?) called something like LLM user, for editors who can demonstrate they are sufficiently competent with content policies and have a legitimate use case. I don't think such a right should convey any actual abilities, but users found to be using LLMs without it could then be much more easily censured and guided towards other forms of editing. Applying exactly the same system but tying it to extended confirmation seems like it minimizes potential rule creep, but it's a blunter filter which might not be as effective, since I'm sure there are plenty of extended confirmed users who lack the requisite understanding of policy. lp0 on fire () 21:03, 10 November 2025 (UTC)

Full ISBN formatting.

Wikipedia has over 40,000 articles with {{ISBN|1234567123456}} where 1234567123456 is any string of 13 digits. All of these can be properly formatted with changing it to {{ISBN|{{Format ISBN|1234567123456}}}} and letting Anomiebot (Anomie, Anomiebot) at it. But using AWB and Anomiebot to do all of that seems a *very* heavy load. Note, there are some hyphenated formatting for the ISBN that still indicate it hasn't been properly formatted, but 13 numbers in a row is a way to start. What would be a good place to start, full bot?Naraht (talk) 15:09, 20 October 2025 (UTC)

Doing {{ISBN|1234567123456}} → {{ISBN|{{Format ISBN|1234567123456}}}} just so AnomieBOT can subst the {{Format ISBN}} would be silly. If we really care about the formatting in the wikitext, better to have a bot directly correct it. If we only care about the output for readers, why not have {{ISBN}} do it internally instead of editing all the pages? Anomie⚔ 15:22, 20 October 2025 (UTC)

Not disagreeing with you. Having the output for readers regenerated each time seems very expensive. A full bot directly changing these seems to be superior. Glad to have you here for the discussion, you seem the one would would understand it best.Naraht (talk) 16:53, 20 October 2025 (UTC)

WP:Don't worry about performance. If it's too expensive, we'll find out because it runs into parser limits of some sort. But it seems unlikely that it will. Anomie⚔ 17:03, 20 October 2025 (UTC)

So it seems that the correct place to discuss this is Wikipedia talk:ISBN.Naraht (talk) 18:10, 20 October 2025 (UTC)

There was a related RFC in October 2023. -- LCU ActivelyDisinterested «@» °∆t° 19:41, 20 October 2025 (UTC)

Falls under WP:BIKESHED in my view. — Qwerfjkltalk 20:31, 21 October 2025 (UTC)

I formatted all the ISBNs back when the 13 digit format was coming into being. I'd happily do it again if requested. All the best: Rich Farmbrough 13:48, 2 November 2025 (UTC).

Can we consider changing the license of codepages (such as MediaWiki:Common.js) from GFDL to GPL (or another appropriate software license)?

As one who is in the more technical side of things on Wikipedia, GFDL does not appear to be a suitable language for programming code, nor does CC BY-SA.

According to this page, we may be able to relicense CC BY-SA code under GPL 3, since CC BY-SA content is compatible with GPL 3, but not the other way around. It also allows for the use of several alternatively licensed programs on wiki such as MIT and Apache. The only problem I see is use is limited to noncommercial use, but that might be solved with the Lesser GPL.

I think this would be helpful especially for user scripts, templates, modules, and other wikitext that describe programs rather than articles. Aasim (話す（はなす）) 16:04, 25 October 2025 (UTC)

I'm honestly surprised that we haven't had a discussion like this yet.
Is this change needed? The only software license compatible with CC BY-SA is GPL, so I'd assume people would be incorporating our code under GPL.

use is limited to noncommercial use

No, that's CC BY-SA-NC, not CC BY-SA. And anyhow, you cannot use a CC BY-SA work under solely Lesser GPL terms, because the latter is not a compatible license. Aaron Liu (talk) 16:37, 25 October 2025 (UTC)

I was talking about the GPL. All the way at the bottom it states that one cannot use GPL in proprietary code (oh wait I mixed up proprietary with commercial). Okay that seems consistent with CC BY-SA which requires that any modifications be also released under CC BY-SA. Aasim (話す（はなす）) 16:42, 25 October 2025 (UTC)

There's little benefit, and considerable drawbacks. Anyone wanting to reuse our javascript under the GPLv3 can already do so; anyone wanting to reuse post-migration changes to our javascript under CC-BY-SA-4.0 would be unable to. The latter includes, in particular, other-language Wikipedias and other Wikimedia projects. —Cryptic 17:03, 25 October 2025 (UTC)

I was wondering if it would require a Wikimedia-wide RfC, since we would not be able to unilaterally change the license on just one wiki (WMF could pull the WP:CONEXEMPT card and refuse to make these changes).

The reason I was discussing this goes back to this thread where Enby and L235 licensed the unblock wizard under MIT rather than CC BY-SA. I was under the impression that MIT might be inherently compatible with CC BY-SA, as all it requires is that the same copyright notice be published on all source copies of the work. A lot of code useful to Wikimedia projects is on GitHub, GitLab, etc. under variety of different licenses (WP:UV and earlier WP:RW are both Apache licensed, and they had to specifically license for use under CC BY-SA for use on Wikimedia). This licensing mess with code can be avoided if we either (a) allowed users to import code in a similar manner that we allow them to upload files under a compatible license (and display that license prominently on the code page), or (b) chose a license so that no matter which code was imported it could be relicensed under that license. Aasim (話す（はなす）) 18:47, 25 October 2025 (UTC)

The reason for requiring all uploads to have specific licenses is so that any reusers know they only have to deal with those licences. Your proposal B would break this goal. Proposal A is already possible. isaacl (talk) 18:53, 25 October 2025 (UTC)

I don't know if it is possible with code pages and templates right now. Currently what it says is "Text is available under the Creative Commons Attribution-ShareAlike 4.0 License; additional terms may apply" which if displayed at the bottom of code pages would imply code pages are also licensed as such (which I presume they are). I have posted stuff with an MIT license header on Wikipedia for example (see User:Awesome Aasim/rcpatrol.js and User:Awesome Aasim/CatMan.js) following what I saw with RedWarn. The only way to use off wiki scripts that are licensed under a different free license other than CC BY-SA would be to post them on wiki and use them under the CC BY-SA.

IMHO the GFDL makes less sense for code pages than GPL though (we have deprecated GFDL for most media files already).

We could also change the footer in user, template, module, and MediaWiki space to say "Content licensed under CC BY-SA unless otherwise noted" (as on Fandom wikis). Aasim (話す（はなす）) 19:39, 25 October 2025 (UTC)

We don't prevent contributors from dual licensing their work under both MIT and CC BY-SA. If you mean upload someone else's code, then if the licence permits the work to be shared under CC BY-SA it can be done. As I said, the whole point is to allow easy reuse by knowing everything is licensed the same way. Adding more complexity in figuring out licensing makes it harder for reusers, not easier. isaacl (talk) 20:44, 25 October 2025 (UTC)

An RFC would not be sufficient. You'd have to get WMF Legal to agree to this. WhatamIdoing (talk) 07:26, 28 October 2025 (UTC)

How do we contact WMF to get them onboard? LDW5432 (talk) 14:02, 6 November 2025 (UTC)

I think we would need to express consensus in a venue like Wikipedia:Village pump (WMF) or maybe even in a place like m:Wikimedia Forum. The reason I have raised in idea lab is I don't have a concrete proposal, just an idea. Aasim (話す（はなす）) 15:51, 6 November 2025 (UTC)

If it's a single author, or just a few people who're still active, they could probably agree to multi-license the code under the GPL or other licenses in addition to the standard GFDL and CC BY-SA licenses applied to all text content. There's also the fact that CC BY-SA 4.0 is one-way compatible with GPL 3. If there are many contributors, though, as for something like MediaWiki:Common.js, getting that agreement may be difficult. Anomie⚔ 17:15, 25 October 2025 (UTC)

I feel like the one-way compatibility is effectively a multi-license. Aaron Liu (talk) 19:43, 25 October 2025 (UTC)

By its nature, Javascript/Lua/wikitext code on Wikipedia is inherently available, which makes one of the motivations for using a software-specific licence less compelling. In theory there could be a different licence for pages hosting code, but it might be unduly confusing to less technically oriented contributers. Specifically regarding GPL, the question is whether or not it's desirable to require any incorporated libraries also be GPL. Mandating that code must be GPL-licensed would open up the possibility of using GPL-licensed libraries, but remove the possibility of using code that is not GPL compatible. isaacl (talk) 17:39, 25 October 2025 (UTC)

Maybe there is a more easily understandable default software license that is appropriate for code pages and user scripts. Or a cheat sheet showing which software licenses are compatible with CC BY-SA (I have not found any such page yet).

On another note I noticed Wikifunctions' code implementations is by default licensed under Apache 2.0. Aasim (話す（はなす）) 16:46, 30 October 2025 (UTC)

I feel like you're not trying to engage with the discussion about the purpose for licences. Concerns specific to compiled software aren't relevant to the interpreted code that is placed on Wikipedia pages. For reusers, fewer licences to deal with is better than more. I feel this follows a pattern for some of your proposals: they exhibit a partial understanding of the overall context, and your followup discussion fails to acknowledge explanations of this context. (Note Creative Commons maintains the list of licences it has evaluated to be compatible with specific versions of its licences. It's a short list.) isaacl (talk) 17:52, 30 October 2025 (UTC)

Maybe I am doing a terrible job at explaining myself.

With interpreted code, one can copy the software by copying the source code. I don't really understand the whole Concerns specific to compiled software then, as software licenses are often applied to the source code as well. If one has a proprietary program, and they reverse engineer and redistribute the source code, that source code is still infringing. One can change all of the variable names and it would still be infringing.

Anyway it probably would not be worth wasting community time on something that would need a Wikimedia wide RfC. Aasim (話す（はなす）) 21:50, 30 October 2025 (UTC)

Isaacl is saying that the building and distribution concerns mentioned over using CC-BY for code don't apply to our code exactly because of what you say about our interpreted code. (Unsure about the modifiability part. And then the patent thing is still there, but probably not a concern.) Aaron Liu (talk) 23:09, 30 October 2025 (UTC)

If you're going to propose a change with the reasoning that GFDL does not appear to be a suitable language for programming code, nor does CC BY-SA, then you need to understand why that's the case. That's why I said your proposal isn't taking into account the overall context. Licences written for compiled software not only cover the human-readable source code, but the resulting work products, and have corresponding conditions. It would be more effective if you would investigate the context more fully before persisting in arguing for your proposals. (As I recall, I'm not the first person to say something to the same effect about your proposals.) isaacl (talk) 23:57, 30 October 2025 (UTC)

I mean, finding the context of things to bake ideas in is what the idea lab is for. This wasn't one of the VPR threads of yore. Aaron Liu (talk) 00:03, 31 October 2025 (UTC)

Once context is revealed, then it would be more effective to investigate further to understand that context, rather than persisting in arguing without taking that context into account. Otherwise, it feels like responses are pointless, since the proposer isn't considering them fully. isaacl (talk) 00:12, 31 October 2025 (UTC)

Okay this is the recommendation according to Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation and Tips on Using the GNU FDL - GNU Project - Free Software Foundation:

• We can use GPL on any kind of work as long as we are clear as to what constitutes "source code" for that work (i.e. for a wiki the source code could be defined as what appears inside of the wikitext editor when one clicks the "Edit source" button)
• GFDL (the current license in addition to the CC BY-SA) is suitable for reference works (like us); any scripts needed to render the document should also be licensed under GFDL (but can be dual licensed under GPL). But otherwise, it is recommended to use GPL.

This means that we probably have a default license that we can propose for user scripts (GPL) and gadgets (such as MediaWiki:Gadget-Twinkle.js), as well as some Lua functions that don't directly render text (such as Module:Yesno).

I see the primary benefit of adopting GPL as permitting users to import scripts from a variety of sources whose license is also compatible with GPL (such as MIT, Apache 2.0, etc.) without having to worry if the license is compatible with CC BY-SA. CC BY-SA only lists a few licenses compatible with CC BY-SA, and only derivative works. Perhaps CreativeCommons' website is not up to date with all known compatible licenses.

I also did find this table on a GitHub-managed website. It's a lot of information, but it may be relevant if we discuss this in the WMF Village Pump (or even in a Wikimedia-wide RfC). Aasim (話す（はなす）) 01:34, 31 October 2025 (UTC)

I asked you on your talk page to present a concrete example of a problem you are facing that would be helped by your proposal. Are you trying to reuse Javascript code, CSS, wikitext template markup, or Scribunto Lua code that is under GPL? Given that everyone who submits code to English Wikipedia pages has released it under CC BY-SA, there's no issue with reusing any of it in other English Wikipedia edits. The thread to which you linked regarding Chaotic Enby's script was not a problem precisely because all code submitted to Wikipedia has a known licence.

As Aaron Liu states, the Creative Commons list is the definitive list of licences that are compatible with their licences. It's written right in the licence itself; I recommend that you read it. If you aren't interested in discussing why Wikipedia, by design, requires all contributions have specific licences, nor understanding what compatibility means (editors cannot upload GPL code and re-licence it as CC BY-SA, as the GPL licence is more restrictive), then this discussion isn't going to progress. isaacl (talk) 03:26, 31 October 2025 (UTC)

I asked you on your talk page to present a concrete example of a problem you are facing that would be helped by your proposal. Okay, it is the use of MIT and Apache and similarly licensed content from external repositories on Wikipedia.

I do believe MIT license is compatible with CC BY-SA (and in fact have imported MIT content myself), as all it requires is that the copyright notice be posted crediting the authors (which probably can be done by linking to a copy of the license). However, if it is not, then:

• If we need to use code from the over 50% of GitHub repositories that use the MIT license, we cannot.
• If a script author wanted to expand and port their own version of an MIT licensed library that is bundled with MediaWiki (such as OOUI), they cannot.

On the other hand, there are other libraries licensed under a GPL compatible license (such as Material Symbols & Icons - Google Fonts) that, again, if Apache 2.0 is not compatible with CC BY-SA, cannot be put directly into any Wikipedia scripts.

Another example: p5.js (licensed under LGPLv2.1).

This problem can be solved with external loading, but loading external scripts can expose a user to cross site tracking, especially if the code is hosted off of Wikimedia. Also I believe if someone wants to host on Wikimedia, they need access to Wikimedia Cloud Services (WMCS).

All of these examples are known to be compatible with GPL (and thus could be used in Wikipedia scripts only if Wikipedia licensed code under a different license from the rest of the site). Aasim (話す（はなす）) 04:24, 31 October 2025 (UTC)

And if you want to know where I imported this MIT content from: Fandom (specifically Fandom Dev Wiki which has the note "Community content is available under CC-BY-SA unless otherwise noted." at the bottom of nearly every page). Aasim (話す（はなす）) 04:27, 31 October 2025 (UTC)

There are different versions of the MIT licence; to which are you referring? Regarding the variants that require that the MIT notice be preserved: CC BY-SA doesn't ensure this will happen. So the CC BY-SA licence alone is insufficient to meet the conditions for re-distributing the code under the MIT licence; the MIT licence needs to be kept for the applicable code. Is it possible to discuss a specific code example? Is it something that can be recreated independently?

Lesser GPL is problematic, since it would require the entire derived work incorporating it to be lesser GPL. To maintain separation, it would be better to serve lesser GPL-licensed Javascript libraries from a MediaWiki server for use by MediaWiki projects. This would make the library unmodifiable by website users, so licensing for derived works wouldn't be an issue. However I don't know the Foundation's policy on acceptable licences for software it serves. isaacl (talk) 04:58, 31 October 2025 (UTC)

How are fewer licenses better than more? Someone reusing a dual-licensed work only has to follow one of the licenses, not both. jlwoodwa (talk) 23:35, 30 October 2025 (UTC)

I apologize for being imprecise. Knowing that Wikipedia content is uniformly available for re-use under a specific set of licences is better than having some pages available under some licences, while other pages are available under another. isaacl (talk) 23:45, 30 October 2025 (UTC)

And if you mean an "or" dual license, we effectively already do that because of CC's compatibility with GPL. Aaron Liu (talk) 23:55, 30 October 2025 (UTC)

https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/ Aaron Liu (talk) 23:09, 30 October 2025 (UTC)

I've already checked this page out and it seems very incomplete. It only discusses other CC licenses and two non-CC licenses, Free Art License and GPLv3. Aasim (話す（はなす）) 01:35, 31 October 2025 (UTC)

Because these are the only ones known to be compatible. Anyone can submit a license to CC for compatibility review, and this process has existed for 11 years with no other license approved. Aaron Liu (talk) 02:21, 31 October 2025 (UTC)

Now that I've seen your reply above: The list is the licenses that CC BY-SA is compatible with, not the licenses that are compatible with CC BY-SA. Aaron Liu (talk) 02:33, 31 October 2025 (UTC)

Renaming indefinite blocks

This isn't the first time I've thought about how we could improve our blocking system (courtesy ping to Chaotic Enby who has been helping me with the unblock wizard). But I don't think the name of indefinite block really gets across to the average person that you aren't permanently banned. Obviously we don't want to never indef people à la Larry Sanger, but I do think it's probably better if we rename indefs to something like conditional block to make it clearer that you basically need to stop doing whatever it is that got you blocked to come back. I'm not sure if there'd need to be an additional "infinite" category when we already have arbcom blocks/community bans, but please let me know if I'm missing something obvious here. Clovermoss🍀 (talk) 12:50, 26 October 2025 (UTC)

I think conditional block may be confused with Wikipedia:Partial blocks and/or a WP:TBAN. No comments on the proposal itself though. ~/Bunnypranav:<ping> 12:56, 26 October 2025 (UTC)

Oh, sockpuppetry is probably the big exception to why getting rid of infinite blocks entirely wouldn't work (even if the master gets unblocked the socks wouldn't). So keep indefinite as an option but encourage a new category of conditional in block templates etc? Because I really do think this phrasing change would be a gamechanger. Clovermoss🍀 (talk) 12:56, 26 October 2025 (UTC)

Regarding conditional blocks, we already have WP:CONDUNBLOCK as a process, so that could work for blocks where a conditional unblock has been suggested (or similar situations such as username softblocks), but might be confusing for cases where there isn't a straightforward unblock condition the user can agree to.

I agree with the general spirit of making it clearer that indefinite blocks can be appealed, but the issue is that these blocks often exist on a spectrum of how feasible they are to appeal, and not all of them are as simple as "agreeing to not do the same thing again". Since there isn't a clear-cut distinction between these, we need to find a word that invites blocked users to work on learning from their block and ultimately appeal instead of giving up, but doesn't give false hopes to users in tougher cases, where a successful appeal might be months or years down the line. Chaotic Enby (talk · contribs) 13:09, 26 October 2025 (UTC)

Any ideas for how to go about doing that? I don't see expanding conditional unblocks as nessecarily being in conflict with the current process but I do want whatever we're coming up with to be practical yet helpful. Clovermoss🍀 (talk) 13:17, 26 October 2025 (UTC)

I would tend to agree with Thryduulf's suggestion of making "indefinite is not infinite" more prominent. It is true that these two words are quite similar-looking, which might lead to some confusion otherwise. Chaotic Enby (talk · contribs) 13:39, 26 October 2025 (UTC)

It's stated clearly in every block template that someone can appeal. If people see the word indefinite and stop reading the unblock template after that word, that's their problem. There will always be someone who finds something confusing or unclear. I'm not sure a change in terminology would fix any problems here. voorts (talk/contributions) 21:04, 27 October 2025 (UTC)

Might be too far in the other direction, but maybe "appealable block" or "fixable block" or "curable block" to distance from partial blocks/tbans, and differentiate from blocks like sockpuppetry/community bans/timeouts after appeals have become tendentious. Tazerdadog (talk) 13:21, 26 October 2025 (UTC)

All blocks are appealable, so that doesn't work. Partial blocks, tbans and at least some full blocks of finite length are also fixable/curable so I don't think that terminology is helpful either. Rather than changing the terminology, I think we need to make Indefinite does not mean "infinite" or "permanent" (from WP:INDEF) a lot more prominent. Thryduulf (talk) 13:27, 26 October 2025 (UTC)

The most practical way of doing that would be editing what's said in the Twinkle block templates. I think that would be a good idea and possibly easier to accomplish then renaming what the type of block is called. I wasn't expecting the idea to be controversial as it was. Clovermoss🍀 (talk) 22:50, 26 October 2025 (UTC)

Are we engaging in a euphemism treadmill here? I seem to recall that "indefinite" and "no expiry set" are already intended as an improvement over "infinite". Anomie⚔ 13:31, 26 October 2025 (UTC)

I don't think it's euphemism treadmilling to be clearer to people who are not experienced Wikipedians what their block actually means. Clovermoss🍀 (talk) 13:33, 26 October 2025 (UTC)

Well we could call brief blocks: “Time out”…

longer blocks: “Sent to your room” or “Grounded”…

and permanent blocks: “F*€k off and Die”

But that may come off as a bit childish. Blueboar (talk) 13:43, 26 October 2025 (UTC)

It may be treadmilling if we keep trying to come up with more "clear" language as newer people, only familiar with the latest language, become experienced and decide that the language they're used to isn't "clear" enough for even-newer people. Anomie⚔ 14:01, 26 October 2025 (UTC)

If you asked me 7 years ago what an indefinite block was, I would not have told you the Wikipedia definition of the term. Clovermoss🍀 (talk) 14:10, 26 October 2025 (UTC)

In this case, "7 years ago" does put you in the "only familiar with the latest language" group, as "indefinite" replaced "infinite" well before that.

I do see how 7-years-ago-you might not interpret "indefinite block" as "block of indefinite duration", instead struggling to make sense of it as meaning something like "block that is vague or uncertain" or "block designating an unspecified or identified target". Until you encountered terminology like "temporary block" or "36-hour block" that should have pointed you in the right direction, or clicked a link like the one to Wikipedia:Blocking policy#Indefinite blocks in {{uw-block|indef=yes}} or the like that explains it directly. Anomie⚔ 14:27, 26 October 2025 (UTC)

My argument is that if you have to explain to someone that something does not mean what you think it does (indefinite is not a commonly used word and most people are going to assume they're blocked forever when hearing it), that's not ideal. I don't think we should give up trying to change things just because we've changed them before and have the survivorship bias of eventually learning what it means. Clovermoss🍀 (talk) 14:50, 26 October 2025 (UTC)

🤷 "People are too dumb to know what 'indefinite' means, or to look it up, or to read the links explaining it" isn't a claim that's worth arguing over. Anomie⚔ 14:54, 26 October 2025 (UTC)

Yeah, Wikipedians tend to be pretty great at givings words definitions that have little to nothing to do with their IRL definitions (see: WP:R3 "Recently created, implausible typos", our speedy deletion criteria for normal typos) - indefinite, however, means the same thing. I mean, there's no shame in not knowing a word, especially if you joined Wikipedia at a young age and perhaps had never come across it before, but this is one that I think most people should know how to look up in a dictionary. GreenLipstickLesbian💌🦋 18:42, 26 October 2025 (UTC)

Why would you look up something you are fairly sure what it means? I suspect the common understanding of indefinite for new people is infinite. Which is why we had to make that WP:INDEF. If most people are thrown by it, even if they are in the wrong, it is not ideal and creates unnecessary misunderstandings. 4.7.212.46 (talk) 19:00, 31 October 2025 (UTC)

Oh, no, you wouldn't - grew up in an immigrant house, and was literally just ranting this morning about how monocultural people seem so loathe to look past their own idiolect. But, well, at least for "indefinite", the word is used the same way IRL as it is on Wikipedia - it means that something will stay in a condition until some factor changes. Yes, people will still misunderstand it - but many people also believe that something becomes their "own work" when they copy it or screenshot it - which is why we have Wikipedia:OWN WORK. Is that because we've chosen words that create 'unnecessary misunderstandings'? There's a point where, no matter how simple or monosyllabic the words are, you can't stop misunderstandings.

In this case, I actually don't suspect that "indefinite"="infinite" is a common misunderstanding, and nor do I suspect that most people are "thrown" by it. What I suspect that people get freaked out by the actual act of being blocked. And I'm not opposed to making that message clearer, but I don't see how. Adding more words? well, panicked people won't read more words - speaking as somebody with anxiety, the longer you make the block message, the less accessible it would be to me. (YMMV). Similarly, the longer and more complex a sentence is, the harder it is to read in your second language - for a simple example, I can pick up any dictionary and go "標準時"? Oh, that just means "time zone" - but replace it with "ある国家または広い地域が共通で使う地方時をいう" in a sentence, and now you've got to learn multiple grammar points and other words, then successfully push them together.

Again, I don't think our block messages are that great - the second line "If you believe that there are good reasons for being unblocked" is the major sticking point for me, though. What on earth does that mean, "good reason"? An unfair block? Well, let's say the block was fair. So, there's no good reason - so okay, time to leave forever. Ditto "appeal", the word everybody is using in this conversation as if it's the least bit applicable, but, IRL, you only appeal a decision if it is flawed. But what if the choice to block wasn't flawed, I (as the blocked user) really did create a sock account, or add content cited to unsuitable sources? Then what's the point of appealing? There's none. In wiki speak, reversing a block often just means undoing it, I think, but not in the vast majority of contexts. Removing a word because it's long and could possibly be confused with "infinite", and replacing it with a shorter Wiki-word that makes no sense to outside word... I'm not on board with that. I will save you from an even longer message, but I've had this "this word makes no sense in this context" response to all the alternatives. I mean, I don't know how to make the block message more clear. "You have been blocked [for OO time/indefinitely]. If you understand why you were blocked and promise not to break the rules again, you may ask to be unblocked. If you believe the block was unfair, you may appeal and your case will be reviewed by an uninvolved administrator" works for me, but would that work for other people? I don't know. GreenLipstickLesbian💌🦋 19:54, 31 October 2025 (UTC)

Instead of trying to rename indef blocks, how about adding a big "Appeal" button in MediaWiki:Blockedtext that takes them to the unblock wizard? Many people have no idea how to add the unblock template and e.g. resort to legal threats instead. Children Will Listen (🐄 talk, 🫘 contribs) 15:01, 26 October 2025 (UTC)

If many people are resorting to legal threats because they don't understand what an indef block is, then it sounds like they don't have the temperament to edit here in any case and blocking them was a good idea. DonIago (talk) 17:36, 26 October 2025 (UTC)

I don't think legal threats are at all the majority that will be benefitted. I'd reckon they just leave. Aaron Liu (talk) 13:01, 28 October 2025 (UTC)

Perhaps split indefs into 2 categories based on the actions needed to lift the block? a "quick-fixes block" for username issues, newbies who missed a memo on their first dozen edits, or veterans who need a rolled up newspaper, versus "introspection needed block" for when the community is at the end of it's rope, bigger issues, or where a simple acknowledgement of what went wrong and promise not to repeat it no longer suffices. Tazerdadog (talk) 14:37, 26 October 2025 (UTC)

That could be a good start, and formalize what is already the case to some extent, although some blocks are on a continuum between the two. If a block for a minor issue (say, a username softblock, or a block to get a user to communicate on their talk page) leads to more serious issues being discovered, would the user be "reblocked"? Clarifying the situation (and new expectations) to the user would certainly be helpful either way, but the software block itself shouldn't have to be changed.

This does move the parameters of the block beyond the mere technical and towards the social (see Wikipedia:Blocks and bans, with community-consensus blocks being considered de facto CBANs due to their appeal requirements). However, this is already the case to some extent with the idea that blocks don't apply to an account but to a person, and this could serve to build a framework that could unify, alongside bans, the "social" aspect of blocking that a software block enforces, and sort them out in a more understandable way. Chaotic Enby (talk · contribs) 14:50, 26 October 2025 (UTC)

• Is it really so common to think that "indefinite" means "infinite" or "permanent"? "Indefinite" simply means "not for a definite period". I would have thought that anyone thinking it means something else would not understand English well enough to be writing an English encyclopedia anyway. Phil Bridger (talk) 17:20, 26 October 2025 (UTC)

  Maybe it's just because I follow Wikipedia-related hashtags online but yes, this perception is absurdly common. Clovermoss🍀 (talk) 18:16, 26 October 2025 (UTC)

  I too would agree it is common and even more so with editors for who English is not their first language. —TheDJ (talk • contribs) 14:48, 27 October 2025 (UTC)

  I'd say people use it often enough as a euphemism for "permanent", as in "postponed indefinitely". I shortcut the definition in my mind to "without end" from "without any current plans for an end, although an end may be possible in the future". I know what it actually means, but I also know how people use it. If someone says "You're banned for the foreseeable future", it's easy to take that to mean you'll never be allowed back again, even if that's not what it literally means. 207.11.240.38 (talk) 15:46, 28 October 2025 (UTC)

  But the notices do also present options for appealing blocks, which to me undercuts the idea that they're for the foreseeable future, unless one considers the possibility of a successful appeal to be unforeseeable? Now I'm mildly curious as to how many blocks get overturned on their first (sincere) appeal. DonIago (talk) 16:12, 28 October 2025 (UTC)

  Yes its exceedingly common. No, it is not a reason someone should not edit English Wikipedia? Seriously? 4.7.212.46 (talk) 19:16, 31 October 2025 (UTC)

• All of the suggested new names are less clear than the original name. The blocks for a dozen socks with abusive usernames are not particularly well described as "conditional", and making two categories of indefinite blocks is a massive complication with little demonstrated benefit (if any). —Kusma (talk) 17:32, 26 October 2025 (UTC)

  I think people can disagree on whether we should try this but I do believe that more people understanding that blocks aren't nessecarily in place for eternity has huge benefits with little drawbacks. Clovermoss🍀 (talk) 18:20, 26 October 2025 (UTC)

My initial thoughts on the different types of bans that are enforced with indefinite blocks:

• conditional bans have a very specific, easy to verify condition for unblocking. A username change is an example.
• behavioural bans are made due to behaviour that is counter to English Wikipedia policy. The blocked user needs to convince the enacting authority that they can behave appropriately if unblocked.
• site bans are made when the user is no longer welcome to participate in the community, due to a lack of trust that they will be able to behave appropriately

An advantage to focusing on the type of ban rather than the technical mechanism used to block a user is that it should lessen ambiguity. Today sometimes users propose a community indefinite block, not understanding that this has the same effect as proposing a site ban. Using categories based on the difficulty of appeal would make the consequences of enacting a ban more evident. isaacl (talk) 17:41, 26 October 2025 (UTC)

The blocked user needs to convince the enacting authority that they can behave appropriately if unblocked

Isn't that true for all blocks though? The main difference is which authority - cbans go to the community, arb bans go to arbcom, blocks by a single admin go to any random admin; the actual trust/welcomeness factor may not be all that relevant. For example, the blocks of editors like ClemRutter, while the actual editor is welcomed by many, are ultimately CIR blocks that aren't going to be undone again, likely ever. Creating a system that puts him in a lesser category than "idiot ten year old who made a bunch of socks, came back at age 13 and is trying to be a productive editor" just creates ambiguity, confusion, and false hope - putting him in a greater category is just going to cause needless offense and pain. (second is also real example, not linking because I had to forward that one to an OS, neither of us seemed to think a block was called for despite the ban evasion) GreenLipstickLesbian💌🦋 18:25, 26 October 2025 (UTC)

When you are saying that some editors aren't ever going to get unblocked, I was under the impression you mean that there are some bans where the banned user isn't ever going to convince the enacting authority that they can behave appropriately. Thus, I don't think it is true for all bans. An indefinite block is the tool for enforcing a restriction, not the actual restriction itself. I think the best way to communicate the route to return to editing is to explain the restriction and the reason for it, rather than focusing on the tool enforcing the restriction, which can cover multiple situations. isaacl (talk) 00:52, 27 October 2025 (UTC)

I was under the impression you mean that there are some bans where the banned user isn't ever going to convince the enacting authority that they can behave appropriately.: Aside from self-disclosed pedophiles, criminals, etc, I'm of the mind that most bans involving on-wiki conduct are reversible given time and reflection. For example, Wonderfool, who deleted the Main Page twice here and several times on Wiktionary, was recently unblocked (now editing as Vealhurl). If Willy on Wheels somehow comes back and requests a convincing unblock, I'm sure the community would agree. Children Will Listen (🐄 talk, 🫘 contribs) 01:04, 27 October 2025 (UTC)

Yes, I also think that focussing on the reason for block or ban & discussing it with the editor is far more important than deciding what we're going to call any given rose, if you want to get the editor back.

To clarify the first point, no I do mean that it's easier to appeal certain bans than certain blocks or quasi-bans. I was disagreeing with your categorization system, specifically where you only applied the idea of "convincing the authority" to one type of block. GreenLipstickLesbian💌🦋 01:11, 27 October 2025 (UTC)

Conditional bans with a very clear condition don't need convincing. Site bans are ones where there is no foreseeable path to return to editing. Thus with this categorization, convincing the enacting authority plays no role with these two categories. (To clarify, what is currently called a site ban would end up being split across the behavioural ban and "never coming back" site ban categories.)

I think it would better to tell people they are banned for specific reasons, with pointers to how they might be unbanned for cases where that is feasible. "Block" should only be used afterwards to describe how they are technically limited from editing. isaacl (talk) 01:27, 27 October 2025 (UTC)

What benefits do you see formalizing such as system as having? GreenLipstickLesbian💌🦋 06:05, 27 October 2025 (UTC)

I apologize for being confused. In each statement I made I discussed how it would be better to focus on the restriction rather than the technical tool being used, and how this would clarify the route to being unbanned. You agreed that it would be better to focus on the reason for the ban. Perhaps you can let me know where additional clarification would help? isaacl (talk) 16:21, 27 October 2025 (UTC)

Oh, yeah, and I'm still mostly stuck back on the entire idea of dividing the blocks into categories like 'banned for behaviour' or 'banned for behaviour, but in a way that annoyed the community' or 'banned for technical reasons' - I think there's too many edge cases to actually formalize that (even username blocks can require some degree of convincing,), and the actual line between 'blocked for violating a particular policy' and 'annoying one too many people' is very subjective indeed. We already do tell blocked editors that they need to work on the issues for which they were blocked. We already do mostly focus on the actual reason for the ban far more than the technical side of things, at least from my perspective of watching the unblocks queue like a puma for the better part of a year & looking through historical blocks, so it's not a new idea. The issue is getting said user to actually understand what part of a very abstract set of rules they broke, why it's important, and how they can avoid doing so again - and I just don't see how creating a somewhat arbitrary classification of blocks system could help with that? GreenLipstickLesbian💌🦋 16:46, 27 October 2025 (UTC)

You stated that we shouldn't give editors false hope about being unbanned. I think a lot of the arguing today over whether someone said "support indefinite block" means they supported a site ban is because people want an option where someone is banned from all editing but is given a path to return. But because we don't distinguish between different kinds of site bans, there is no option for this distinction. I think breaking down site bans into "bye for now" and "goodbye" bans would provide this distinction and help with the false hope problem. I appreciate this is more work to figure out, but the only way to avoid giving false hope is to do the work. In my view, it's not a question of the community being annoyed, but if it does not feel there a path to trust the editor again, whether due to repeated poor behaviour, or sufficiently egregious behaviour. I think conditional bans would just provide a simple descriptor for bans where admins say "any admin who verifies this condition has been met can unban". isaacl (talk) 17:11, 27 October 2025 (UTC)

Alright, I think I see where you're coming from now - I can maybe see where you're getting at by saying that there could be benefits to creating two sites of site bans, the problem is that this would require the community taking such an option, and form an admin to be OK unilaterally lifting any form of block that had community consensus. After all, in cases with any degree of subjectivity (POV pushing, source-text integrity issues, promotional editing, close paraphrasing), who is to say that the condition has been met? In this hypothetical world, is the guy who promotes his video game, gets told off by an admin, takes to to AN/I only to find himself boomerang condition-banned OK to be unblocked when he agrees not to edit about his video game anymore? What if his example edit is making an edit to an article about a competitor? I'd argue that's still promotional, many other editors wouldn't. How about an edit to the article on a record label associated with the composer he hired? Nothing to do with the video game, of course - but there's a valid argument that this is promotional, and a valid argument that it isn't. An admin might, quite reasonably, think the condition to unban has been met - but oopsie, the community didn't agree. From their POV, is it worth jeopardizing their adminship on behalf of a new editor with NOTHERE/SPA tendencies? On the over end of the spectrum - let's just say that the community conditionally bans an experienced editor for making personal attacks or creepy comments to other editors. The editor has a lot of friends, so the closer did a little bartending and said that it was a conditional ban until the other editor agrees not to make any more personal attacks. Let's say they make an unblock appeal six hours later, agreeing not to make such attacks again- does that mean an individual admin friend , who didn't participate in the AN/I thread, can lift the ban, credibly claiming that they verified the unban conditions had been met? In my second example, there's a much greater incentive to risk adminship & hide behind the shield of "verification" (after all, you get your friend back) than there is the first example, which I'd argue is the type of incidental cban that occurs more often that neither you or I is entirely comfortable with. GreenLipstickLesbian💌🦋 17:32, 27 October 2025 (UTC)

My thoughts on categorizing bans weren't about changing the appeal process (just as I don't believe the initial post was about changing process), just better documenting the intent of the community. There is no change to who has authority to lift an editing restriction: it remains within the authority of who enacted the restriction, or within the scope of the governing policy (such as restrictions imposed as arbitration enforcement). So a community-imposed editing restriction has to be appealed to the community. isaacl (talk) 17:51, 27 October 2025 (UTC)

But you can't change one without the other? Any change to how blocks are categorized will impact appeals, just because the type of block is what most people with little to no familiarity with the underlying situation are going to look at. Formalize a category of conditional bans that can be undone the moment some criteria is met? Well, okay, who decides that? The community? You can't legislate community response. Any individual admin? Same issue, most people (especially our admins) are reluctant to go against community consensus (high risk) to unblock somebody who was a poor enough editor to get blocked (low reward). Somebody else? No matter which way you cut it, you're creating (whether intentionally or not) a new appeal system - and one that's a lot more confusing to non-Wikipedians (the average people) than it is to top AN/I and project space posters.

Also ditto Thryduulf - my brand new non-OS example of a "this is technically one kind of block, but the actual edits made it much more complicated" is Misterjamesveitch - softblocked to prevent impersonation of James Veitch (comedian). The AGF explanation for his edits is that it was actually him, but if he hadn't verified his identity that would have had to have turned into a hardblock for serious misconduct. GreenLipstickLesbian💌🦋 18:20, 27 October 2025 (UTC)

We can add categories to articles without changing the process for writing articles. Categorizing types of site bans is for our convenience. It doesn't dictate process. We already have restrictions where the admin says that any admin can lift it if a given condition is met. The categories aren't inventing new types of restrictions. isaacl (talk) 18:28, 27 October 2025 (UTC)

And I'm arguing that the actual act of introducing labels would impact the process - also, categories absolutely can impact the writing process. That's why we have categories for stuff like ENGVAR or dates. Yes, they are meant to be descriptors, but "I spent years switching all the spellings in this article to American because the categories told me I could" is a totally valid excuse to avoid being sanctioned, even if the only reason the article is in the category is because of subtle vandalism. Conversely, categories that have no impact are going to have no impact period - I don't see how trying to classify blocks is going to make solving the issue which lead to the block any different, which is what actually matters, and not hundreds of editor hours wasted over what exactly to categorize something as.

Also, the idea that we have "restrictions where the admin says that any admin can lift it if a given condition is met" is fictitious, ultimately. When an admin says that any other admin can lift a block once a condition is met, it means that they won't raise an objection or they themselves would unblock in such a case- they can't actually dictate that other admins not unblock. But we don't have a formal restriction system in place, and, given that admins are all fallible volunteers with minimal oversight, can never have one. GreenLipstickLesbian💌🦋 18:45, 27 October 2025 (UTC)

We have the option to do either: we could change the process and have categories that reflect the changes, or we could not change the process, and define categories as we please to reflect current process. I'm looking at the latter, not the former. I was just laying out some initial thoughts on how, within the current process, bans could be categorized, rather than renaming a tool used to enforce many kinds of bans, with the goal of enabling the community to distinguish between site bans that aren't likely to get lifted versus those where there is a path to lifting the ban. So to me a discussion about how the process can be changed is a different discussion. It might be a fruitful one, but not one I'm trying to address with my thoughts. isaacl (talk) 01:14, 28 October 2025 (UTC)

And I suppose where I'm at is that I don't think it's possible to change the process of blocking and the process of appealing - they're simply too dependent on each other. Change what you call a ban, and the appeals process changes to match, even if you don't mean it to. The actual act of labeling impacts it. So, at least from my perspective, you can't talk about one but not the other. GreenLipstickLesbian💌🦋 18:24, 28 October 2025 (UTC)

There are also blocks that are not clearly one or the other. For example editors who engage in promotional editing with a promotional username - especially when you need the context of the edits to see that the username is promotional.

More than one of my Oversight blocks have been of minors significantly oversharing while engaging in self promotion - sometimes they even spam their self-promotional material. While requests for unblock following oversight blocks are handled by arbcom rather than any random admin, the block log will typically just say "oversight block" and I'm sure the same applies to normal blocks too. Thryduulf (talk) 17:52, 27 October 2025 (UTC)

The examples you raise are, using current terminology, site bans which the enacting authority is willing to lift in favour of a topic ban. Unless otherwise stated, the enacting authority is the one who evaluates the response of the banned user. Within the categorization framework I raised, they are behavioural bans that the enacting authority is willing to lift in favour of a topic ban. isaacl (talk) 17:59, 27 October 2025 (UTC)

• I don't consider this a problem and am perfectly happy with the current situation; however, if we need to make it exceedingly clear to those who may think that indefinite means perpetual, I propose calling indefinite blocks "blocks without a fixed duration". Everything else that's been proposed so far is liable to introduce even more confusion, in my opinion. Salvio ^giuliano 18:49, 26 October 2025 (UTC)
• I agree with others stating that most of the ideas presented thus far seem like a step backwards with respect to the intended purpose. To be honest, I think "indefinite" is so well suited to this kind of situation that I've started using it in similar contexts outside of Wikipedia, to no confusion as far as I am aware. _signed, Rosguill ^talk 22:53, 26 October 2025 (UTC)
• I think what is getting at here, is that we have a single block "period" that encompasses two very different situations. What we call "indefinite" blocks are called "infinite blocks" in the database, so it is entirely reasonable for people who are blocked for a "curable" reason to believe that they have been banned forever. Realistically, there are a lot of indefinitely blocked accounts that we have zero reason to think will ever be unblocked. At the same time, we also have a lot of accounts that are indefinitely blocked because they need to assure the community that they understand the reason for their block and will not repeat the behaviour that resulted in the block. Quite honestly, I don't actually see any benefit in time-limited blocks. Our blocking policy says that we shouldn't be giving "cool-down" blocks, but that is exactly what a 24 or 36 hour block is. Arbcom stopped giving out time-limited blocks way back in 2009, and has since that time made unblocks conditional on behavioural change.
  I can't see any reason why "conditional block" would be confused with "partial block". Risker (talk) 23:05, 26 October 2025 (UTC)

  Respectfully, I don't think the average person has the slightest clue what blocks are recorded as in the database; I don't see how that could be a source of confusion. GreenLipstickLesbian💌🦋 23:11, 26 October 2025 (UTC)

  The average person doesn't get blocked, either indefinitely or infinitely. I hold our administrators in high enough esteem that they can differentiate between making a block that can be cured by the account and one that cannot. Even if that opinion isn't a widely-held one, I think that all our dropdowns should not use the term "infinite" anywhere, or should be a separate alternative to indefinite/conditional. Risker (talk) 23:37, 26 October 2025 (UTC)

  Changing the dropdowns seems fine. However, this conversation started out with a claim that editors who got blocked were confused by the term "indefinite" (see OP:But I don't think the name of indefinite block really gets across to the average person that you aren't permanently banned, emphasis own); I don't see how changing the admin interface has much, if anything, to do with that?GreenLipstickLesbian💌🦋 23:49, 26 October 2025 (UTC)

  It's an idea lab, that means that we should iterate on the idea. There is no such thing as an idea that is fully formed on its first legs. Let's work on looking at the idea and talk about how we can improve on the idea, not just have knee-jerk reactions that something won't work. Some of the ways we can do that might start with "why did we choose these terms in the first place? when did we do that?" We've come up with lots of good ideas over the years, and improved on old ideas. Back in the day, there was no such thing as community bans, or blocks longer than a certain specific time, or admins handing out blocks longer than a month or so. It is good that we have given the space for people to come up with these ideas and helped them to develop them, and to figure out how to shut down experiments that haven't really worked. Please be charitable. The Wikipedia of 2025 is massively different than the one of 2002, or 2010, or 2015, and a lot of those positive changes have started out as seeds like this. Risker (talk) 00:16, 27 October 2025 (UTC)

  I'm not trying to shut you down? You said that you thought the database could cause people who were blocked to think they were blocked forever, the OP was also talking about confusion for average editors, but when I asked you about that, you started saying that the average person didn't get blocked? I'm trying to follow your train of thought and see where you're going with this by asking you for clarification? GreenLipstickLesbian💌🦋 00:21, 27 October 2025 (UTC)

  Technically, people are blocked forever (with a duration of infinite) until someone decides to lift their block. The MediaWiki source code does not have any expectations on whether someone would come along and unblock a user. The problem here is a social one; most normal people don't seem to understand that they are able to appeal their indefinite blocks instead of engaging in sockpuppetry and/or making legal threats. The first thing most users see is Template:Blocked text, and the next is a Template:Uw-block placed on their talk page. Non-admins can't see what the dropdowns say, nor would most users worry about what's in their block log, so all changes, if any, must be made to these two templates. Children Will Listen (🐄 talk, 🫘 contribs) 00:34, 27 October 2025 (UTC)

  ...and, a quick look at CAT:RFU reveals that most new editors have the impulse to use LLMs to generate their unblock requests, which get declined almost instantly, leaving the users frustrated and unsure of what to do next. Keep in mind that most people use AI-powered tools daily, especially in the Global South, where people may not be confident in their ability to write in English on their own (even though many are actually pretty good at it.) A good first step would be to add clear instructions in the Unblock Wizard (do people even use that?) or elsewhere to refrain from using LLMs. Children Will Listen (🐄 talk, 🫘 contribs) 00:53, 27 October 2025 (UTC)

  The unblock wizard is more of an idea than something that has actually been implemented at this time. Chaotic Enby created it after a discussion I started here expressing a desire for it because I've cared for a long time about how blocked users don't nessecarily understand the template/what they can do to get unblocked very well and I was inspired by the edit request wizard to see if we could maybe do something different. But an RfC needs to happen before it can be used in the way I envisioned. Clovermoss🍀 (talk) 09:23, 27 October 2025 (UTC)

  The only dropdown I see that has "infinite" as an option comes from MediaWiki:ipboptions, of which Special:Diff/880298592 indicates it's that way because we can't have two options with the same label and says it still shows up as "indefinite" in the logs. Are there others? Anomie⚔ 00:08, 27 October 2025 (UTC)

  So...it appears that "infinite" was added with no discussion, as a result of some sort of OOUI change? Why not simply change the dropdown back to indefinite then? There is no discussion that indicates why the word "infinite" was selected. Risker (talk) 00:16, 27 October 2025 (UTC)

  "indefinite" is already at the start of the list. To have an indef option at the end too, some other name was needed. As to why "infinite", I have no idea. Anomie⚔ 00:19, 27 October 2025 (UTC)

• We should be wary of introducing a second set of vocabulary. The names of blocks currently reflect their direct practical impact on the blocked user: partial, X-hour/day/month, indefinite. Naming blocks after the reason blocks were given, or the expected unblock path, or similar may make the jargon even more jargony. CMD (talk) 06:28, 27 October 2025 (UTC)
• My view: If an editor thinks "indefinite" means "forever", they need to improve their vocabulary. "Indefinite" is the clearest way to say it—it literally means "not definite". See dictionary entry for "indefinite". Sure, clarify the PAGs as necessary. ―Mandruss ☎ 2¢ IMO. 06:46, 27 October 2025 (UTC)

  Except a not definite block is forever unless you successfully appeal it and a lot of people have no idea that you can, whether it's because the word isn't used that often, they assume it's something like "inflammable", or they don't understand the concept of a block being "indefinite" because other websites just permanently ban people and there isn't a block expiration time like there is for the other blocks. I hate to bring Larry Sanger up because I don't think his "9 theses" are practical and they're out of touch at best but stuff like "get rid of indefs" is one of those ideas people have been talking about elsewhere online. I've seen so many people discuss how they basically did stupid teenage things and don't have the secret arcane knowledge of Tamzin's essay because they think it means "game over forever". Given that Sanger describes that the practice as Wikipedia’s draconian practice of indefinite blocking—typically, permanent bans—is unjust. This is no small problem. Nearly half of the blocks in a two-week period were indefinite. This drives away many good editors. Permanent blocks are too often used to enforce ideological conformity and protect petty fiefdoms rather than to serve any legitimate purpose, he seems to think that too. I press x to seriously doubt that admins hand out indefs for "ideological conformity", but the fact the average person's reaction to that statement is not the Wikipedia line of "but it's not technically an infinite block even though it is until you appeal successfully" is a problem worth remedying imo. I'm going to refrain from commenting further because I don't want to bludgeon, but it took me awhile to figure out "how do I express what I'm trying to say here?". Clovermoss🍀 (talk) 09:44, 27 October 2025 (UTC)

  Haven't read this whole thread, but FWIW, I think the best way to bring policy in line with practice (the practice that's reflected in my mildly heretical essay) is to make it explicit that WP:CLEANSTART is allowed five years after an indefinite block, provided that the block was not to enforce a community or ArbCom sanction, and was not a block that no reasonable admin would lift without community consensus; and that post-block cleanstarts on shorter timeframes may be tolerated on a case-by-case basis if there is no continuation of the underlying disruptive behavior, but that this is not something anyone should rely on. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 09:56, 27 October 2025 (UTC)

  ...and if we could trust the indef'd editor to correctly apply all of those provisional criteria to their own situation, they'd probably not be the kind of editor who got indef'd in the first place. WhatamIdoing (talk) 07:44, 28 October 2025 (UTC)

  I repeat: Sure, clarify the PAGs as necessary. But don't mess with a widely-recognized, perfectly good word. ―Mandruss ☎ 2¢ IMO. 10:55, 27 October 2025 (UTC)

  I have to wonder whether any amount of renaming blocks would really make a difference to that sort of misconception, considering studies have also shown that many people also don't realize that it's possible for them to edit Wikipedia in the first place. Anomie⚔ 13:33, 27 October 2025 (UTC)

  I believe that editors should spend about as much time finding ways to simplify editing as we spend finding ways to complicate it. I'd estimate that this ratio is traditionally about 1-to-10. ―Mandruss ☎ 2¢ IMO. 14:35, 27 October 2025 (UTC)

• I wonder about the truthiness of statements like 'blocks drive people away'. Accounts are blocked. Wikimedia doesn't have the tools to block people. People come back with new accounts or as unregistered IPs or both. There is currently no way to stop them. If they are 'good' editors determined to edit Wikipedia and stay out of trouble they are likely have a de facto cleanstart of their own making. Sean.hoyland (talk) 10:51, 27 October 2025 (UTC)
• For the standard "indef, not appealable for 1 year" sorts of blocks I think the current terminology is perfectly fine. I do think we should probably split off "indef immediate appeal" blocks for username issues or newbies doing something dumb from "true" indefs though. Loki (talk) 18:47, 2 November 2025 (UTC)

Perhaps instead of looking at the name used within discussions among editors, we should look at the templates posted to blocked users, and work on clarifying their messages. The name of the technical tool used to enforce the imposed editing restriction doesn't matter, as long as the message clearly explains the reason for the restriction, and the path to have the restriction removed. isaacl (talk) 17:18, 27 October 2025 (UTC)

+1. The same issues also apply for definite but long blocks (months to years). We'd prefer the editor to clean up their act instead of waiting out the block, no matter whether the block has definite or indefinite duration. —Kusma (talk) 17:59, 27 October 2025 (UTC)

+2 This is the best return on effort we are going to get. Tazerdadog (talk) 18:38, 27 October 2025 (UTC)

+3. A blocked editor who has sufficient competence with the English language to constructively edit the English Wikipedia should always be able to clearly understand why they were blocked. They can disagree that that should be something people are blocked for, and they can disagree that what they were saying/doing was an example of that reason for being blocked, but they should always understand what the reason given means. Thryduulf (talk) 19:11, 27 October 2025 (UTC)

There is Wikipedia:Unblock wizard, which I recently discovered as it was mentioned in the nomination statements of one of the current RfAs. It's a pretty cool idea, and while I think there is room for improvement in its current form, it could make the process of appealing indefinite blocks much less daunting than it might currently be. Maybe something like this (User:Mz7/sandbox/uw-blockindef-wizard):

You have been blocked indefinitely from editing to prevent further vandalism.

If you believe that there are good reasons for being unblocked, please review Wikipedia's guide to appealing blocks, then use the "request an unblock" button below.

---

Request an unblock

Mz7 (talk) 04:27, 29 October 2025 (UTC)

How about something like "You have been blocked from editing for [reason]. This block does not have an expiry date set, but if you believe that there are good reasons for being unblocked you may appeal. If you do wish to appeal, please review..."? Thryduulf (talk) 11:09, 29 October 2025 (UTC)

Speaking as an American, I prefer "does not have a set expiration date. If you believe...". Otherwise, while I still think it's a little silly that people misconstrue "indefinite" as "infinite", this wording probably is more easily understood. DonIago (talk) 14:21, 29 October 2025 (UTC)

I agree. Aaron Liu (talk) 14:37, 29 October 2025 (UTC)

I'm fine with DonIago's suggestion, which reads fine in British English. Thryduulf (talk) 15:39, 29 October 2025 (UTC)

I see where you two are going, but those sentences both rate as much more difficult on a bunch of the online grade level/text difficulty checkers I measured them against when compared w/ "You have been blocked indefinitely". Also, the new versions may register as easier in difficulty than they are. Most people learn what expiration means in the context of foot products remaining good to eat, while indefinite pretty much just has the one meaning. Again, I do get why people might confuse it, but indefinite was ranked as a elementary school level word, so you should really know what it means by the time you're twelve, or you should know how to look it up in a dictionary. It's a lot easier than other words we expect people to know, like 'citation', 'plagiarism', and 'consensus', all of which got ranked as college-level. GreenLipstickLesbian💌🦋 16:41, 29 October 2025 (UTC)

I'm admittedly surprised to hear that those alternatives would be considered much more difficult to parse. Is there perhaps a middle ground? "Indefinite" may be ranked as an elementary school level word (and as I've expressed, I personally don't see how it's all that ambiguous), but it's clearly tripping up a number of people, so it seems worth considering options that may trip up fewer people. DonIago (talk) 18:09, 29 October 2025 (UTC)

learn what expiration means in the context of foot products remaining good to eat

That should be enough to understand what an expiration of a block means. And "indefinite" is probably way more obscure than any of "expire"'s meanings (in fact it seems more a middle-school word to me).

know how to look it up in a dictionary

The concern is that scanning eyes will mistake the word as "infinite" far more easily than "expiration". Aaron Liu (talk) 18:31, 29 October 2025 (UTC)

I'm also surprised that these are regarded as more confusing, although I also don't regard "indefinite" as problematic it's clear that some people do. If "expiry date" or "expiration date" are problematic, would "end date" be better? Thryduulf (talk) 18:34, 29 October 2025 (UTC)

Wikipedia:Readability tools tend to over-focus on the number of syllables in a word or the number of words in a sentence without regard to whether the words are familiar or make sense in context. (Different systems have different metrics.)

If you just split the middle into two sentences:

You have been blocked from editing for [a reason]. This block does not have a set expiration date. If you believe that there are good reasons for being unblocked, you may appeal. If you do wish to appeal, please review...

then that will make a big difference to some of the tools, though not so much to the reality. Expiration, with four syllables, will be rated as difficult by several tools, and you could change it to end, but unless you're expecting a younger child to be reading this, it probably won't make any actual difference.

Alternatively, just try a different reading tool. They're wildly inconsistent, with different tools producing a range of "correct" ratings that can differ by 10 years of education or more for the same text. If you don't like the answer you got with the first tool, then pick a different one until you get the answer you want. Wikipedia:Readability tools links to about 10, if you want to try them out. WhatamIdoing (talk) 00:16, 30 October 2025 (UTC)

I find the split to make a pretty big difference. Aaron Liu (talk) 02:49, 4 November 2025 (UTC)

I'll throw in the idea I had, how about "Appeal only block" or "Appeal required block". It gets the info you want right out front, that they can appeal, and that its the only way to remove the block. HypnoticCringer (talk) 02:39, 29 October 2025 (UTC)

• Indefinite blocks are logical name for blocks of indefinite duration. We could call them permanent blocks, but indefinite works better than any other suggestion I've heard so far. If we want a change to the system I would rather look at the blocking of IP addresses when we hard block accounts. I think such IP blocks are permanent and it would probably make sense and greatly reduce collateral damage to make these "intelligent blocks" either a fixed duration or O/S dependent. ϢereSpielChequers 20:24, 31 October 2025 (UTC)

  I think such IP blocks are permanent: Nope, underlying IP addresses are autoblocked for a duration of 24 hours, regardless of the block duration you apply on the account. That's why sockpuppetry is so common. Children Will Listen (🐄 talk, 🫘 contribs) 20:27, 31 October 2025 (UTC)

TL:DR. I got tagged...As a former user who deleted the main page (not sorry about that), I always thought "indef" wasn't quite right. "long-term block" would always make more sense Vealhurl (talk) 16:07, 1 November 2025 (UTC)

"Long-term" wouldn't make more sense; an indef can be quite brief, if the editor appeals successfully. Schazjmd (talk) 16:29, 1 November 2025 (UTC)

How about "Open-ended block"? All the best: Rich Farmbrough 13:54, 2 November 2025 (UTC).

One of the better options, though I'm a little concerned it might seem overly euphemistic. Aaron Liu (talk) 15:40, 2 November 2025 (UTC)

Clearer might be "Blocked until successful appeal" but too wordy. Schazjmd (talk) 16:29, 2 November 2025 (UTC)

I still like my original suggestion of conditional block. Simple yet concise. However, if nothing about the name of the block itself is changed, I agree that making the Twinkle templates as clear as possible is a good idea. Clovermoss🍀 (talk) 17:06, 2 November 2025 (UTC)

Yes but indefinite is clearer and also includes asking for clemency. Appeals are for mistaken blocks, after 6 months you can promise to obey the rules as per the standard offer and in most cases that will get you unblocked. ϢereSpielChequers 17:25, 2 November 2025 (UTC)

• How about "until removed" for MediaWiki:Infiniteblock? Again this does not mean that the block will be removed, it just means that the block will go on until an administrator or the community decides to revoke that block, which could literally mean never. But it could also be less bitey to newcomers and other users who did not realize that their editing was harmful and give them a second chance at productive editing. Aasim (話す（はなす）) 20:47, 5 November 2025 (UTC)

  In fact this wording could work for page protections and similar as well. Aasim (話す（はなす）) 20:49, 5 November 2025 (UTC)

  I think this is very clear! @GreenLipstickLesbian Thoughts? Aaron Liu (talk) 23:07, 5 November 2025 (UTC)

  Well, my first thought is that, in the contexts its currently used, it sounds a bit tautological - all blocks remain until they are removed, it's just whether or not the removal is automatic (time limited blocks) or not. So I personally don't find it any clearer. I'd be curious to know what others think, though.

  For contenxt, the regular-editor part of the site that such a change would impact is, I believe, MediaWiki:Blockedtext - and the sentence would become "This block will expire on: until removed". GreenLipstickLesbian💌🦋 04:48, 6 November 2025 (UTC)

  Maybe it could be reworded to "This block is not time-limited." or "This block is not timed to expire."? Chaotic Enby (talk · contribs) 09:46, 6 November 2025 (UTC)

  I think "until removed" implies required manual action while "for <duration >" implies automatic expiration. Aaron Liu (talk) 13:46, 6 November 2025 (UTC)

  A long time ago blockedtext looked like this. Incidentally this was also when MediaWiki:Infiniteblock was changed from the default "infinite" to "never", then to "no expiry set".

  Right now {{blocked text}} (the template used for all block related messages) is configured to not display the block expiry if the block is indefinite. This means the only thing that this will right now affect is Special:BlockList and not the blockedtext system message (for now). Aasim (話す（はなす）) 16:10, 6 November 2025 (UTC)

  I agree that all blocks remain until removed, and so this doesn't add any additional descriptiveness. I don't agree that most people will interpret this to implicitly exclude automatic removal. isaacl (talk) 16:35, 6 November 2025 (UTC)

Enumerated type lists in templates?

Would it make sense to enable enumerated type as a parameter type in Wikipedia templates? An example of usage would be to standardize on a set of colors and layouts for templates under a particular topic category. I'm suggesting a usage something like: 'object_type=plutino', resulting in a particular template layout, with object_type including {planet, giant_planet, ice_planet, dwarf_planet, plutino, asteroid, comet, ...}. The benefit would be ease of template management across a potentially broad series of articles. Thanks. Praemonitus (talk) 19:38, 26 October 2025 (UTC)

Are you imagining this as part of TemplateData? Templates themselves don't really have "parameter types"; for instance, numbers are passed around as strings. jlwoodwa (talk) 20:26, 26 October 2025 (UTC)

And in TemplateData I think suggested values are already enough. Aaron Liu (talk) 13:05, 28 October 2025 (UTC)

I'm not sure what you mean by "enable". MediaWiki doesn't support typed parameters in templates, though as alluded to by Jlwoodwa, VisualEditor's template editing mechanism does overlay some typechecking for templates that provide that information through TemplateData. Your example sounds like you are thinking of treating one parameter as a selector to choose different behaviour. You're free to do that in templates you create. It's a tradeoff, though: you may be able to reuse code with a template that serves multiple purposes (using helper templates or by implementing it in Lua), possibly saving maintenance costs, but it adds complexity, adding maintenance costs. isaacl (talk) 01:05, 27 October 2025 (UTC)

My 2 cents, as I spend time on many wikis: it is a recurring topic, mainly about infoboxes. A parameter can turn a generic infobox into a specialized one. Wikidata-based infoboxes can even hide the parameters that aren't relevant to the object type. While the work on the content of the infobox, through a generic infobox, can save maintenance burden, I already read discussions that highlighted the increase in complexity. Also, if each parameter calls its own style, it can multiply styles and hence increase maintenance (not counting the amount of conversations about styling, i.e. choosing the "right" color) and, potentially, confuse the reading experience. Trizek_(WMF) (talk) 19:01, 27 October 2025 (UTC)

In a limited-use case (e.g., choosing infobox colors), you could just program the template to ignore any input that doesn't match the approved values. WhatamIdoing (talk) 07:47, 28 October 2025 (UTC)

One of the issues is the "Monkey mayor issue". You think all mayors are humans, but Hartlepool elected a monkey. Rome had a horse as co-emperor. One party in a UK lawsuit was (depending on your perspective) either a rock or a god. More pedestrianly there are a slew of exception labelling values, n/a (with at least two meanings), none, unknown, "see list" etc. etc. What is the RGB value of infra-red? (See also, Impossible color.) All the best: Rich Farmbrough 14:06, 2 November 2025 (UTC).

Of course you can write template code or Lua code to do what you describe. And indeed Template:Infobox baseball biography (for example) does that. It's important to remember that information should never be given only by a visual style or colour. All the best: Rich Farmbrough 14:47, 2 November 2025 (UTC).

Sending a user a copy of their speedily-deleted page

Just a thought:

After a page is deleted, the page creator (and/or other major contributors?) gets a copy of the deleted article sent to them. This way, they could see what the offending bit was and resubmit it down the line.

It's kind of like draftifying but for pages that qualify for CSD in both article and draftspace.

This wouldn't work in all situations. For example:

• Pages that are libelous (or other major BLP violations)
• Pages that are illegal for WMF to have in their servers (such as CSAM)
• Pure spam/vandalism
• Pages that break arbitration remedies
• Blank pages

The page Biz by the Water is an Australian sports broadcast article that is currently being CSD A7-ed for not indicating notability. The author would be sent the page, fix it, then resubmit.

Obviously kinks would need to be worked out, like how would the page be sent to the user (talk pages won't work)? Worth a thought.

Could help with editor retention. Not sure. EatingCarBatteries _{(contributions, talk)} 05:52, 28 October 2025 (UTC)

You can request a WP:REFUND for (almost) any deleted page. WhatamIdoing (talk) 07:49, 28 October 2025 (UTC)

Also, they could just contest the speedy with a request to move the page to their sandbox for improvements. — xaosflux ^Talk 09:00, 28 October 2025 (UTC)

You assume the user is on-wiki between the time the speedy is nom'd and the deletion takes place. In my experience this is often not the case. In fact when I was patrolling the CSD queue (many years ago) I found that most were deleted before I had the chance to make an informed decision. I believe (based on a sample of speedy deleted items I reviewed) that admins were deleting without more than a cursory check at best. No doubt things are much better now. All the best: Rich Farmbrough 14:12, 2 November 2025 (UTC).

How would we send it to them without it being publicly published ? Email ? some sort of sandbox environment ? —TheDJ (talk • contribs) 09:07, 28 October 2025 (UTC)

Email is the normal non-public way to send refunds. Sometimes people do their creative writing or homework in a Wikipedia page, and so may have a reason to want pages. Another possible way is to find an archived or mirrored copy that exists outside Wikipedia and point the user to it. Sandboxes are unlikely to be archived. Graeme Bartlett (talk) 00:02, 1 November 2025 (UTC)

Publicize WP:RSP ratings

In the articles about Wikipedia's potential sources, such as The New York Times, mention the RSP rating in some fashion; e.g. "Wikipedia considers the Times a generally reliable source."

If it's permitted to link from mainspace to WP space, the article could even link to the RSP rating.

If this were placed in a separate section with a standard heading (similar to See also), that would make the information that much easier to find in the article. I know, many editors dislike one-sentence sections, and there's probably a guideline discouraging it. I think an IAR exception would be justified in this case.

If a citation |work= parameter linked to the article (I believe it should), a reader could see what we think of the source. That would support verifiability and improve transparency. ―Mandruss ☎ 2¢ IMO. 13:27, 28 October 2025 (UTC) Edited per discussion 23:47, 30 October 2025 (UTC)

I doubt this will gain acceptance (whether Wikipedia considers something a reliable source or not really isn't relevant to the topic in the majority of cases), but it'll be interesting to see how many bad policy and guideline references people use when opposing it. Anomie⚔ 15:01, 28 October 2025 (UTC)

Alternatively, create a new CS1 citation parameter that produces an icon in the rendered citation, indicating its RSP rating. Green check mark, etc. That would be ideal, but it would require more work for both Trappist and general editors. ―Mandruss ☎ 2¢ IMO. 15:09, 28 October 2025 (UTC)

That idea sounds like something better suited to a user script than a CS1 parameter. In fact, I'd be a little surprised if such a script doesn't already exist, as it seems like something people doing FA reviews and new article patrolling would find really helpful. Anomie⚔ 15:14, 28 October 2025 (UTC)

A script run by a roaming bot. ―Mandruss ☎ 2¢ IMO. 15:16, 28 October 2025 (UTC)

There is a user script somewhere, someone mentioned it to me the other day. Katzrockso (talk) 00:35, 1 November 2025 (UTC)

I'm leaning towards opposing this on the basis that "generally reliable"/"generally unreliable"/"deprecated" are Wikipedia jargon that most of our readers will misunderstand. _signed, Rosguill ^talk 15:21, 28 October 2025 (UTC)

I don't think it's in the encyclopedia's interest to shield readers from understanding of Wikipedia content policy. If they "misunderstand", it's because they haven't been educated. Readers aren't stupid, for the most part. ―Mandruss ☎ 2¢ IMO. 16:34, 28 October 2025 (UTC)

It’s not about readers being stupid, my concern is that it’s not possible to explain the nuances of how we treat this in practice while holding to WP:DUE. Anecdotally, RS tend to only discuss RSP when they’re talking about Wikipedia; I am skeptical that RS coverage of NYTimes, for example, is ever going to center Wikipedia’s assessment of it as a source. _signed, Rosguill ^talk 16:56, 28 October 2025 (UTC)

I agree with Rosguill.

Also, who says that readers actually want to spend any part of their life "being educated" about Wikipedia's content policy? Most people are just looking for a quick fact: What's the website for this company? What's the name of that actor in that film? WhatamIdoing (talk) 17:02, 28 October 2025 (UTC)

I admit that I am a little wary of RSP ratings, because folks treat them as a binary yes/no when WP:RSCONTEXT is still a guideline. The New York Times for example would not be a reliable source for medical claims. Even the most fake of sources are reliable sources for their own claims (although WP:DUE is then often a problem). Jo-Jo Eumerus (talk) 16:49, 28 October 2025 (UTC)

As a side note, I invite you all to Wikipedia:Requests for comment/Restructuring RSP.

In line with what Jo-Jo Eumerus says here, several of us have explicitly opposed a "cheat sheet" or "quick look up" that would give only the name of the source and its general category (this suggestion would have a link to further information, but we fear that most editors would only look for the color coding and not care about the details. For example, we've got one "GUNREL" and one "deprecated" news source whose explanatory text says that their sports coverage is okay – but you won't notice that, if you just look for the colored icon and believe that it applies to everything). No source is reliable for everything, and any source can be reliable for something. WhatamIdoing (talk) 17:05, 28 October 2025 (UTC)

I have contemplated writing a user script to indicate a media outlet's status from @Headbomb's WP:UPSD or RSP. (Just an idea at this stage. I haven't thought about how to implement it yet.) Due to the current PEIS issues, if I see an unfamiliar source mentioned in a discussion I am more likely to look for an article describing it than try to load the whole RSP. I agree that RS assessments generally shouldn't be included in articles as they could introduce more confusion or misunderstanding among non-insiders. ClaudineChionh (she/her · talk · email · global) 22:29, 28 October 2025 (UTC)

Have you looked at m:Meta:Cite Unseen? (Pinging @SuperGrey) WhatamIdoing (talk) 00:23, 30 October 2025 (UTC)

Of course, it's become indispensable for identifying problematic references just by glancing at a reference list, but it doesn't (AFAIK) tell me anything about a source when I'm reading an article about that source. ClaudineChionh (she/her · talk · email · global) 09:57, 30 October 2025 (UTC)

Usually, by the time I'm looking at a Wikipedia article about a source, I want to know about the source, rather than about which discrete pigeonhole an RFC shoved the source in. We have many sources at RSP that are "generally reliable, except for X" or "generally unreliable, except for Y", and several sources that have to be divided up (e.g., there are three separate rows in RSP for Fox News – politics and talk shows aren't reliable, but ordinary, non-political news may be okay). WhatamIdoing (talk) 00:45, 1 November 2025 (UTC)

This sounds a lot like navel gazing. Wikipedia doesn't consider a source to be reliable or unreliable, they may be a consensus of editors that a source is unreliable or reliable for the purposes of Wikipedia. Although discussions tend to use the former wording, the actual meaning is always the latter. That some editors on Wikipedia considers a sources as more or less usable when writing articles doesn't seem like something that should be included in an article about the source. -- LCU ActivelyDisinterested «@» °∆t° 21:03, 30 October 2025 (UTC)

I think we're past inclusion in the articles. As the proposer, I am. ―Mandruss ☎ 2¢ IMO. 22:41, 30 October 2025 (UTC)

If you don't want people to respond to that part of your proposal anymore, I suggest striking it. jlwoodwa (talk) 23:41, 30 October 2025 (UTC)

that part of your proposal That's the entire proposal, but I am striking it. ―Mandruss ☎ 2¢ IMO. 23:47, 30 October 2025 (UTC)

• Consider putting the rating on the talk page instead? If we did that, then I bet some helpful person could make a script, so opting-in editors would see deprecated sources highlighted in %_colour, generally reliable ones in %_colour, and the ones in between in %_colour (hopefully user-configurable and thus colour-blindness friendly). Would be helpful for me to glance at an article's reflist and see that.—S Marshall T/C 22:40, 5 November 2025 (UTC)
• There are at least 3 citation highlighter scripts. The one I made is User:Novem Linguae/Scripts/CiteHighlighter. This allows one to easily see a source's RSP rating in the article. It also pulls data from some more obscure sources, such as WikiProject reliable sources lists. Hope this helps someone. –Novem Linguae (talk) 22:48, 5 November 2025 (UTC)
• If Wikipedia's decision to report a source at RSP is itself commented on by reliable sources (e.g. Anti-Defamation League#Wikipedia determination of unreliability on the Israeli–Palestinian conflict), it does make sense. Otherwise, there isn't a reason to report on Wikipedia's decision in particular, and material for the benefit of editors can go on the talk page like S Marshall suggests. Chaotic Enby (talk · contribs) 09:51, 6 November 2025 (UTC)

Non-technical summary section or page for technical topics

TLDR (or non technical summary :P):

So many math pages (and other technical ones) are only readable by people in the field, when the concepts are valuable and searched for by quite a few people. Could we make them more readable with a new type of section that is standardly implemented or different types of page (i.e. toggle between non-technical and technical)? Otherwise/additionally, could we have some initiative to copy-edit them to be more readable?

Explaination:

As it stands, when I was younger and using wikipedia, up till now, when I look up more technical topics (such as in math or computer science) I am met with an absolute mish-mash of word salad and formulae.

This does most of the time serve formally as a definition, but unless I have prior knowledge of the topic helps me about as much as a dancing chihuahua in a raincoat (or less, for at least the chihuahua is entertaining, whereas this simply leaves me slightly befuddled and frusturated before I go on to search for a more useful explaination elsewhere).

Advancing from a standpoint of clarity, simplicity, and usefulness, I would propose that a new section be commonly implemented across some of the more trafficked technical pages (or ones useful for many people). Alternatively, we could have pages which have two different parts, a non-technical part and a formal part.

An example: scope, which 'in short' as it currently stands defines itself as 'the part of a program where the name binding is valid,' and meanders through about 4 paragraphs of text which is all formally (blah blah blah) important for it's definition and usage (and yes completely understandable to many programmers). However, for those who are more new to the topic, it means hot sh- I mean... for beginners in code looking to understand scope it also doesn't help much. Those 4 paragraphs practically can be condensed into: "Scope determines where a variable (like x = 1) can be accessed in your code. It's usually determined by where you define the variable. If you define a variable in a function, usually it's scope is only within said function; if you define it in the file, it can be accessed in that file etc." Which I hope my fellow devs can agree is a more effective definition practically. In fact, all this boondoggling of the formal definition would just confuse me - it's not just useless, it's anti-helpful!

Another (more minimal) formulation of this idea could be that: many practically useful ideas that were once technically developed (such as baysian statistics) are locked behind 'intellectual paywalls' or gatekept (unknowingly). Taking the concept and expressing it as it matters practically disseminates the knowledge more effectively, and helps people develop their understanding of the world. There could be some initiative to translate important, useful or fun technical concepts for a wider audience.

Yes, I can be bold and do this myself, in fact I probably will. However, it seems a useful thing for wikipedia to do in general. The most interesting contents of human knowledge are usually (if they have formulae) on this site incomprehensible to anyone outside of the field. We should make them accessible!

"An idiot admires complexity, a genius admires simplicity." At least I just want to verbalise a problem I've had (perhaps my own simple mindedness): that it seems many technical pages are correct in definition but are incorrect in transmission. Briefly noting I'm new to excuse me from any mistakes if I have made them here :)

- Julius Chandler (talk) 12:05, 30 October 2025 (UTC)

Hello Julius Chandler. Our current guidelines already say that the article's lead should be understandable to a wide audience, per WP:EXPLAINLEAD. But we often fail to comply with that guideline. So instead of giving two different leads, these overly complicated leads need to be rewritten to be understandable to an interested layperson. There's a project to rewrite the WP:Understandability guideline, where I'm looking for one more person to give feedback during the workshop phase before launching Wp:request for comment asking people whether they prefer the old or new version of the guideline. If you have time, feedback on the workshop text would be welcome on its talk page.

When you encounter an article with an overly complicated lead and you don't have the ability to simplify it, feel free to tag it with {{Technical}}. —Femke 🐦 (talk) 14:22, 30 October 2025 (UTC)

That makes sense. See my comments on the talk page and someone feel free to archive this. Also any interested editors in making technical concepts from mathematics and other fields should really get together and do some initiative if only to rewrite the 80/20 articles (if you get what I mean a la views/ease to rewrite). I'm not really sure how that works on here though. Julius Chandler (talk) 16:43, 30 October 2025 (UTC)

Thanks Julius Chandler! There's a couple of ways to organise people. One effective way is to organise a contest (which has lost on my to-do list), as gamifying stuff is the best way to really get momentum on Wikipedia. My idea was to make it a contest where people work in pairs (one layperson, one expert) to tackle our most-read articles across all technical topics. If you like that idea, and have the bandwidth to organise, I'd be happy to help set this up (feel free to leave me a message on my talk page). Other ways is to see if you can get people at WP:WikiProject Mathematics interested in a project by posting on that Wikiproject's talk page. —Femke 🐦 (talk) 16:52, 30 October 2025 (UTC)

WPMATH has tried to do this in the past. What they mostly need is people who are both willing and able to do the work.

The table in Wikipedia:Readability tools#Build a balanced article might be a useful explanation about how to meet the needs of different groups of readers in the same article. It uses Abstract algebra as one of the examples. WhatamIdoing (talk) 00:54, 1 November 2025 (UTC)

Sometimes the simple English wikipedia does a better job. I would agree, our maths articles are generally incomprehensible. I asked a mathematician about this, and her comment was "that's because they're not written by mathematicians, they're written by grad students who want to show off", which is possibly a rather harsh generalisation. The difficulty is that if you try to edit maths articles, you encounter the arguments "we are not a textbook", "anyone who knows anything about the subject will understand", and "your edit that squares have four corners is wrong because in a Hoffmannian semi-polar set of isobaric coordinates the tertiary quadrilateral apex disappears to negative infinity". My feeling is that articles that can only be understood by someone who already knows exactly what they are trying to say, are utterly pointless. There is a fundamental difference between a textbook and an encyclopedia, but it's a bit subtle, and lost on hard-core maths article editors - who tend to turn the articles into extreme secondary reviews with little context or background. I don't know the solution. Elemimele (talk) 17:34, 4 November 2025 (UTC)

Perhaps we can amend WP:NOTTEXTBOOK to say that sometimes the textbook explanation is the only one that allows compliance with our WP:Understandability guideline. (That exact wording might not find consensus, but I'm sure we can workshop something sensible). —Femke 🐦 (talk) 17:38, 4 November 2025 (UTC)

NOTTEXTBOOK says:

• Textbooks and annotated texts: the purpose of Wikipedia is to summarize accepted knowledge, not to teach subject matter. Articles should not read like textbooks, with leading questions and systematic problem solutions as examples...

Of course, Wikipedia:Nobody reads the directions, but perhaps a beefier description of what is desirable would help. WhatamIdoing (talk) 20:21, 4 November 2025 (UTC)

Perhaps we need guidance somewhere on what a technical article ought to contain. I think Integral is an example of a good article (although it failed its last GA assessment). Euclidean vector is another good one. These articles both give an overview, they give a historical context, and they describe why the thing (integral; vector) is actually useful - what its relevance is, in the world. Sequence is a contrast; it's not a good article. It gets bogged down in quite complicated nomenclature far too early, it has no historical context, it doesn't say why sequences are interesting, and it does things back-to-front (there's a section on definition by recursion before the main section on formal definition) - it basically just spirals into a a hole of ever-more-complicated nomenclature and then peters out into a long list of one-sentence links between the concept of sequences and other articles in maths, links that will mean nothing to anyone who doesn't already know that the link exists (e.g. "A metric space is compact exactly when it is sequentially compact.", which is offered with no further explanation or context). I feel that some sort of (flexible) template guideline would help: who is the expected audience (is this a record of the current state of theory for fellow mathematicians, a bit like I'd see (as a biologist) a review article; or is it a summary of the field aimed at an intelligent amateur?); what parts should it contain (overview, historical context, relevance/application, definition, further information about how it works, summary of its interaction with related concepts). This might help people work out what's missing from less-good technical articles. Otherwise, people can only look at the GA criteria, which don't actually make technical articles good. You can satisfy all the requirements of a GA article and still have an incomprehensible turgid text that doesn't help readers. The other thing that would help would be to formalise team-editing: to turn a technical article into a good technical article you need someone who understands the technical stuff really well (to get it right) and someone who doesn't (to make sure the result is understandable). Elemimele (talk) 17:08, 5 November 2025 (UTC)

Affine space is another really good example of a bad article. Someone's tried really hard to explain what an affine space actually is (good) but there's nothing to explain why they're called "affine" (bad: encyclopedias ought to include this non-mathematical information too), there's nothing to explain why anyone would find affine spaces useful (bad: we're supposed to say why a concept is relevant to the world), there's no summary of the history of the usage of affine spaces, the development of the concept (bad: this is also encyclopedia-stuff), and again it spirals into an unstructured heap of barely-connected concepts (very bad). Elemimele (talk) 17:25, 5 November 2025 (UTC)

Femke (and whatamidoing), agreed.

I think a beefier (or more concise) definition is required here. I might try to draft up a new or slightly edited version of that guideline.

I would appreciate ideas or suggestions. See my longer response to elemimele for more. Julius Chandler (talk) 18:03, 5 November 2025 (UTC)

Elemimele, you say that the description of 'grads trying to sound smart' is harsh, but to be frank, it is in my opinion a correct diagnosis, or one approximating it.

Indeed, the "not a textbook" guideline seems to be one quoted often at people trying to make math articles anything other than a heaped mess of hot s- equations.

However, I would not give up hope. In fact, the current guidelines if you read them, simply say we shouldnt provide content to work through, ask leading questions... etc.

That does not preclude attempts from turning what are mostly just lists of barely comprehensible words, even to their authors (and sometimes not even, I see them copying in lines from somewhere that are just wrong, without understanding 🫠) into actually readable content. In fact, if it did, I would propose removing that guideline.

As it stands, I would still suggest an edit to them, as Femke suggests. I may draft one up in the next few days or after some more feedback.

Of course, Chesterton's fence here, there are good reasons we don't want to be a textbook. However, it needs to be made clear that

1. Simplicity and ease of understanding, especially in earlier section, is necessary
2. An encyclopedia is supposed to help people understand a topic, and develop *joined up thinking* which can't happen if you expect the average Joe to understand that the polar coordinates of my embedded covariance normalisation are simply intuitively the same as the eigenvector of the set of all the times I sneezed.
3. I would remove/revise the rule about not asking leading questions. Certainly we don't want to pretentiously act like a textbook, get people to walk through exercises etc. However, some small rhetorical questions should be fine. Or rather:
4. Emphasise that a conversational, professional, clear tone is preferable to an academic who has recently graduated and while hopped up on something decided to go on a "Eulers top hits 100" writing spree to prove to all the journals that rejected them they are indeed, the next coming of Gauss.

Julius Chandler (talk) 17:56, 5 November 2025 (UTC)

Editors usually dislike rhetorical questions, and they really hate SEO-related questions (like section headings saying ==Who wrote this song?==).

NOTTEXTBOOK could get another obvious 'negative' ("questions or problem sets for students at the end of the page"), but adding some 'positive' ("Do add examples and explanations in plain English") might also help. Maybe Wikipedia:Wikipedia is not a textbook (a redirect) should be turned into an explanation? WhatamIdoing (talk) 20:07, 5 November 2025 (UTC)

As an aside, we do already have more accessible versions of some articles, such as Introduction to the mathematics of general relativity (vs Mathematics of general relativity). Chaotic Enby (talk · contribs) 09:48, 6 November 2025 (UTC)

Article wizard should impose a process

I looked today for the first time at the article wizard. It seems to be no more than a set of warnings to ignore and click through, followed by free-form editing. That's not a wizard, it's just a slow-motion nag screen. A real wizard forces you to make appropriate choices in an appropriate order, and a real wizard would be nice to have on Wikipedia. In my opinion, probably the best thing it could do is disallow writing any text until you have cited several reliable sources, and then only allow you to type "under" the sources you've specified, so that you are required to attribute every word you type to one of your sources, and no freestanding sentences are possible. (With, of course, an "add new source" button easily accessible.)

The concept of writing an article "backwards" is often mentioned as a problem. The point of my suggestion is that the function of the article wizard ought to be to force people to write "forwards" - not to give warnings and advice and then turn them loose to do whatever. TooManyFingers (talk) 05:56, 1 November 2025 (UTC)

Sounds like good UI design. Well-designed wizards etc. can make various types of errors impossible, including the ones stated above. ―Mandruss ☎ 2¢ IMO. 06:00, 1 November 2025 (UTC)

A wizard that is giving blank pages to end users is not ideal. I would like one where you have sections per-arranged in a template and this template would also include a place to paste a reference. LDW5432 (talk) 03:46, 4 November 2025 (UTC)

@TooManyFingers, it looks like you've never tried to write an article. Were you looking at the Wikipedia:Article wizard because you wanted to start Your first article? WhatamIdoing (talk) 04:12, 4 November 2025 (UTC)

No, I was looking at it to think of ways it could be made even more useful than it currently is, by actually compelling some good habits rather than just recommending them during the "click through and ignore" preliminary messages. (Of course I know no one ought to click through and ignore, but it's clear to both of us that that frequently happens.) TooManyFingers (talk) 05:20, 4 November 2025 (UTC)

Well, not to put too fine a point on it, but maybe you should create a couple of articles before you decide which the advice is helpful. WhatamIdoing (talk) 06:27, 4 November 2025 (UTC)

I think headings are barely even a concern. If someone gets them wrong, they're easy to change. IMO, forcing people to adhere to their source material - or else be shut out of writing until they specify the sources - could be extremely helpful.

If I see an article with no headings, I can often give it some semi-reasonable headings in just a few minutes of very light work (depending on its length and complexity of course). But an article that isn't written according to its sources is a discouraging, time-consuming, conflict-filled mess to sort out. TooManyFingers (talk) 05:39, 4 November 2025 (UTC)

A-Class Reviews hub concept.

Hello! A few new page reviewers and I have come up with an idea to revive the A-Class review process, which are currently only held at some WikiProjects, most notably WikiProject Military history. The idea is to create a page or project, that includes a noticeboard for requests to be submitted directly without needing to go to a WikiProject that may not have one, and a feed that provides up-to-date listings on currently active A-Class Reviews or those that have been requested at a WikiProject.

I have created an essay for the concept: Wikipedia:A-Class Reviews/Hub. This will take quite a bit of work, beyond what I can do alone or with a handful of editors. Please let me know your thoughts and if you want to help, please do! Thanks!

(Disclaimer: I did not come up with this idea myself. Credit to @Squawk7700, @HurricaneZeta, @Hekatlys and @MCE89. {If I've missed anybody I apologise.) 11WB (talk) 14:59, 1 November 2025 (UTC)

Thanks for the ping. With the disclaimer that I have no experience with the A-Class assessment process, I don't necessarily mind the idea of having a centralised place to list all open A-Class reviews. While it would probably be entirely or almost entirely made up of MILHIST reviews, I don't think it would hurt to have a page that explains the A-Class assessment process and links to open A-Class reviews, including any that happen to be open at other Wikiprojects. I'm a lot less convinced that there should be a centralised place to request A-Class reviews outside of Wikiprojects thoughs, especially when there is already a perennial shortage of reviewers at GAN/FAC/PR. MCE89 (talk) 15:51, 1 November 2025 (UTC)

I agree. Just to want to add, this post isn't to gather a consensus on this concept. The page will need to be in a functional state, so that a formal RfC can be opened at WT:ASSESS. 11WB (talk) 15:55, 1 November 2025 (UTC)

I think this could open the A-Class status up to more articles, as of now almost all A-Class articles are from MILHIST. Z E T A³ 15:54, 1 November 2025 (UTC)

If the GA, FA, and PR processes were running smoothly, I might support something like this. As it is, PR often goes ignored, GA is backlogged at an absurd level, and FA is only getting by because it throws out nominations that don't attract reviewer interest. Expanding a fourth process will make all four less efficient. Thebiguglyalien (talk) 🛸 02:22, 2 November 2025 (UTC)

I'm not in the know regarding how the other article reviews are running. I waited about two months for a recent GA review, which isn't too long. I don't know what the usual wait time for an FA review is. I would hope that something like this hub idea would promote activity with both A-Class reviews and peer reviews. This discussion isn't to gather consensus, instead it's just to get some feedback and maybe some help! 11WB (talk) 05:55, 2 November 2025 (UTC)

Why do you think that an idea (A-class articles) that has been rejected by most of the community as not worth bothering with would be a good thing to do? WhatamIdoing (talk) 04:13, 4 November 2025 (UTC)

Thank you for your question! It is definitely a shame that A-Class reviews are not more prevalent on the project. My reasoning is based on how they improve the article respectively. A GA review is excellent as a fellow editor, not necessarily with experience in the subject, can suggest improvements to prose, formatting, images, check references to make sure information that's in the article text matches the source. These are all important. The difference with A-Class is they focus on the actual information itself, which is why they take place at the WikiProjects, so editors with background knowledge or maybe even a degree in the subject can assist in improving the veracity and depth of the actual information rather than just how it is written. Then an FA does both of these things with even higher boundaries. A-Class Reviews I personally think definitely have a reason to exist, it's unfortunate that so few WikiProjects offer them. 11WB (talk) 04:50, 4 November 2025 (UTC)

Maybe those groups of editors think there are better uses for their limited time. WhatamIdoing (talk) 06:12, 4 November 2025 (UTC)

An idea like this was discussed a few years ago. The admin who started the discussion for abolishing A-Class said that building a process for it is preferable to just doing away with it entirely. That discussion did take place two years ago, so I would be interested to know @MSGJ's thoughts on this now. 11WB (talk) 07:11, 4 November 2025 (UTC)

Encouraging new editors on the main page

We have a huge editor recruitment problem, and I'd like for us to add some form of invitation to edit on the main page. I've put this together as a starting point:

Get involved!

Every article you read on Wikipedia is written and maintained by hobbyists, and anyone can help!

• Learn to edit with the Introduction to Wikipedia
• Read a detailed guide at Contributing to Wikipedia
• Ask questions about editing at the Teahouse
• Practice editing in the Sandbox

What would be a good way to approach this, and what else might be added to something like this? This is just an example to demonstrate what I'm talking about, I would love to hear other people's ideas. Thebiguglyalien (talk) 🛸 02:49, 3 November 2025 (UTC)

Looking at old main page versions, the language used there is more personal:

Visit the help page and experiment in the sandbox to learn how you can edit any article right now.

than it is now:

the free encyclopedia that anyone can edit.

Maybe this line could be changed to

the free encyclopedia that you can edit right now.

? sapphaline (talk) 14:18, 3 November 2025 (UTC)

Someone's trying to get Wikipedia:Articles for improvement back on the Main Page. Maybe these this idea should be combined with that. WhatamIdoing (talk) 04:15, 4 November 2025 (UTC)

I like it a lot, but where would it go? Kowal2701 (talk) 09:25, 4 November 2025 (UTC)

See Wikipedia:Village pump (idea lab)/Archive 72#h-Final round of suggestions for This Week's Article for Improvement before WP:VPP-20251011020400 (pinging @Bremps). WhatamIdoing (talk) 16:36, 4 November 2025 (UTC)

AI citation-checking bot

Please note: this is not a proposal for AI editing of Wikipedia articles, but rather for AI annotation via templates to aid human reviewers.

Wikipedia has always had the priniciple of supporting material in articles citations to reliable sources. But do those sources actually check the content cited? It's asy to put citations into articles, but does anybody check them. This problem has also recently been exacerbated by the introduction of AI editing that generates pseudo-articles with bogus citations.

This is an ideal opportunity for the use of LLM technology. Here's the idea:

• a bot reads a Wikipedia articles, and retrieves all the cited sources that are fetchable at that moment
• point by point, it compares each paragraph/sentence in the article with the cited sources. If it's all fine, it just marks the article with a review template that states that the article has been auto-reviewed, and when.
• If any material is either unsupported by the cited material or contradicted by it, it surrounds that material with some variation of {{citation needed span}}, with parameters that specify when it was auto-reviewed and what's wrong with it. Maybe from a small range of choices: "source disagrees", "source does not support", and with a free-text comment. Perhaps it also puts in a short checksum (say 6 hex digits) of the enclosed content, so that changes to that content are easily detectable in later scans. The article is also marked by an invisible template in the same way as above. It could also generate "source unavailable" annotations, or edit URLs if sources get moved.

And that's it for the automation. Now comes the human part. Once articles have been marked, they will automatically be put into categories by the template, marking them for human review. Human editors can then confitm whether the bot is right, by removing the bot metadata from the template, turning it into a human review, or by removing or amending the material, in the normal Wikipedia fashion.

So this is bot-annotation, not bot-editing: the bot should never make any changes to actual article text other than adding the templates. We can set the threshold for false positives quite high, so it should generate very few of them. And we can also make the bot respect human annotation: if it flags something as bogus, and a human editor disagrees and removes its annotation, the bot won't keep on making the same warning over and over again.

All this fits entirely within the existing Wikipedia ecosystem of bots, templates and categories.

Running this bot on millions of pages may work out quite expensive, but that's what grant funding is for. Even if it only costs $0.01 per article, that's still $70,000 to scan the whole encyclopdia - but the gains in reliability and authenticity should be well worth the cost. Whether this is a small amount of money or a large amount of money depends entirely which end of the telescope you are looking down.

Some extra comments:

• Wikipedia Library access could provide access to references which are behind paywalls
• Also, while it's at it, it can also check that the given citation template actually matches the content of the cited source - author, title, publication date, etc.
• Writing the bot is the easy part

— The Anome (talk) 16:39, 3 November 2025 (UTC)

This is the holy grail, right? And if it can verify existing, why not also find sources for uncited material. People are working on this later idea right now. With human in the loop. But I think your idea makes sense, it only requires test cases to see how well it works in practice. If the false positive rate is low enough that editors trust it. — GreenC 17:01, 3 November 2025 (UTC)

I think putting sources for uncited material into articles would be dangerous. The bot should only flag, never edit. What it might perhaps do is to add suggested source recommendations to talk pages to allow human editors to review those sources themselves. There should always be a human in the loop, or it just becomes encyclopedia-slop, and that's all too easy to generate these days. — The Anome (talk) 17:05, 3 November 2025 (UTC)

The Anome, "with human in the loop" is confirmed, what I said right. Nobody is advocating for fully automated AI anything, that's obviously a bad idea. — GreenC 21:38, 3 November 2025 (UTC)

@GreenC I've had bad experiences with the latter. There are facts that I know are true due to first-hand experience, but when I've asked an LLM to find me reliable sources so that I can add them to Wikipedia, it confidently feeds me a bunch of links to websites that don't actually verify the statement. --Ahecht (TALK
PAGE) 19:14, 3 November 2025 (UTC)

No you can't do it that way. There are other techniques though that can work. — GreenC 21:44, 3 November 2025 (UTC)

I am not confident in the ability of llms to handle verifying citations as citation use lies further from being a close paraphrase towards uses that require actual textual understanding. There would need to be a pretty convincing display to support editing articles directly, even if it is just adding a template. Marking this for human review risks creating a whole new backlog as long as the encyclopaedia, plus an explicitly bot template implicitly suggests to readers that llms are involved in the editing process. The way I've envisioned such a tool being most useful is something similar to WP:EARWIG, where a report can be generated on request for easy review, perhaps in two neat columns. This would help with things like GAN spotchecking. CMD (talk) 17:16, 3 November 2025 (UTC)

You might be right: perhaps report generation is the right way to go, rather than direct editing of articles. But I think it should be a within-wiki process (perhaps on the talk page?) rather than an outside-wiki process. Putting it on talk pages would also mean that it could perhaps be flagged for the attention of relevant WikiProjects. — The Anome (talk) 17:28, 3 November 2025 (UTC)

The talkpage might work for short articles the way some bots post there, but it would be unworkable for longer articles. If you intend it to be something that can be updated to take into account human review (eg. noting that source X actually does support text Y) I could see how it might function on an onwiki subpage that can be updated, but that brings its own set of additional coding complications that a one-off post would not have. CMD (talk) 17:45, 3 November 2025 (UTC)

In early stages, you'd probably want to run it on a single ==Section== of an article at a time. Nobody's going to actually check hundreds of sources to see whether the AI got it right. WhatamIdoing (talk) 04:18, 4 November 2025 (UTC)

Given my experience with LLMs, I am not confident in their ability to understand and interpret sources well enough to have any use for this sort of project.

Recently Acrobat has incorporated a LLM that will summarize key points of a pdf document. I tried it on some reports from work and the results were less than inspiring. It did not understand what the most important parts of the document were, did not know the meaning of phrases, at times giving them the opposite of what they were saying, and was generally worthless in summarizing the document. ~ ONUnicorn^{(Talk|Contribs)}problem solving 17:46, 3 November 2025 (UTC)

Based on my understanding of LLM function and architecture, I don’t think there’s any reason to believe that they are suited to directly do the operation proposed by Anomie; perhaps as part of a larger piece of software that incorporates LLM functionality alongside small language model heuristics, it could work. But as a general rule, LLMs don’t verify things, they extrapolate guesses. _signed, Rosguill ^talk 17:50, 3 November 2025 (UTC)

No. The sheer number of hallucinated references/references that do not support the content they are cited for in LLM-generated articles is convincing proof that LLMs cannot ensure source-to-text accuracy. The systems have no concept of "correct" and "incorrect", only "likely" and "not likely".

Besides, a similar verification idea has been rejected before; see WP:PADEMELONS. SuperPianoMan9167 (talk) 20:54, 3 November 2025 (UTC)

I find merit in the idea of a bot which can identify and tag articles for bias by looking for emotional language. Then a human can review it and stop hallucinations. LDW5432 (talk) 03:41, 4 November 2025 (UTC)

@LDW5432 assuming it wouldn't be too much of a stretch for me to interpret you saying emotional language above to mean "non-neutral language," I wonder if you might find value in the editcheck-tone tag.

In essence, this tag gets appended to edits a small language model trained on 20,000 Wikipedia edits thinks are adding non-neutral language to Wikipedia articles. You can |see it in action in Special:RecentChanges here and learn more about the Tone Check, the broader feature behind it here: wp:Edit check/Tone Check. PPelberg (WMF) (talk) 22:56, 7 November 2025 (UTC)

As mentioned above, LLMs are really bad at facts. It's not what they do. The law of pademelons shows that LLMs can very easily conflate similar things, to a greater extent than a careful human editor. Cremastra (talk · contribs) 15:47, 5 November 2025 (UTC)

I think, based on my recent real-world experience on other projects, LLMs might well do much better at verifying specific claims as they relate specific documents, rather than verifying it against their rather nebulous knowledge of the world. Using 'thinking' and asking them to explain their rationale for their decision, and then running a separate checker pass on verifying that explanation before coming to a final conculsion, should have very much better results than 'true or not?'. This because where they really excel is as language transformers, not as oracles. I've got API accounts on a variety of LLMs, and doing the Python coding isn't really hard - pehaps I should do some experiments, and see how well this works compared to human review, before people jump to conclusions about how well it would work. — The Anome (talk) 21:55, 3 November 2025 (UTC)

I think something like this is a good idea but I'm not super convinced by the specific implementation above.

In particular I don't want a bot adding {cn} tags to the actual article itself. If the point of this is to do bot-annotation not bot-editing, a {cn} tag is absolutely bot-editing. It's taken widely to mean that the content that is tagged is dubious, and for good reason. (Also I'd like to point out here that if we were going to do this the actual template we'd want to use is {failed verification}.)

Ideally we'd put this information into a separate list somewhere so a human can check it before any editing to the article actually happens. If that's not practical, the tag we'd actually want is a custom tag that says something like [a bot reviewed this claim and thinks it failed verification], though obviously shorter than that. Loki (talk) 22:53, 3 November 2025 (UTC)

@LokiTheLiar: could you please say a bit more about what you can "see" this list looking like and being used for? Asked another way: what information can you imagine being available within this list? How/when would it get updated? Where could you imagine this list living? Who is looking at this list and what action(s) are they taking on each item within it? PPelberg (WMF) (talk) 22:59, 7 November 2025 (UTC)

While I'm not sure how I originally imagined this looking, right now I think a table like Ca did below for their experiment works well. Maybe with fields along the lines of claim, sources, verified?, explanation. Available to any editor, auto-updated by bot, on some sort of Wikipedia/ namespace page maybe linked from Template:Failed verification like Category:All articles with failed verification currently is. Loki (talk) 23:31, 7 November 2025 (UTC)

Verifying specific claims is definitely something that would be interesting, and, while I'm not certain that this will work out, I do believe that it is absolutely worth a shot to try to develop it. "Is X sentence supported by Y text" is a much more specific task than "write a Wikipedia article about Z", and one for which LLMs could potentially be used (and even, if needed, fine-tuned). It will take some time before we have something that is ready (and trusted enough) to be run at the scale of the encyclopedia, and it might not turn out to be reliable enough to be worthwhile, but it might just work, and I would be glad to help with this project if you want to go forward! Chaotic Enby (talk · contribs) 03:31, 4 November 2025 (UTC)

Yes. It's the specific nature of the problem that is interesting here, and makes it more plausible that this might actually work, by avolding treating the LLM as an oracle. Thanks for the offer of help, I'll see what I can do. — The Anome (talk) 03:39, 4 November 2025 (UTC)

I was unaware of this discussion whe I vibecoded today a python script that pulls the text of a list of Wikipedia articles, inputs it into the chatgpt model of your choice (I used gpt-5 mini), looks for 1 factual inaccuracy, and spits out the results into a wikitext table. With an n of 4, I found no issues, including one article where it didn't find anything, 2 articles where it found clear in inaccuracies, and 1 article where it found something that while supported by a source may be incorrect based on the weighting of other sources. Because I wrote it to use the OpenAI API, I didn't run it too widely though my back of envelope calculations suggests it could be run fairly economically (especially if I adjusted the prompt to cut down on the verbosity of the output (which is the most costly part). Best, Barkeep49 (talk) 03:52, 4 November 2025 (UTC)

There is someone in the Village pump who posted something similar: Wikipedia:Village pump (idea lab)#c-86.33.69.28-20251015115200-Pilot project for GPT-5 powered article bias analysis WikiTool LDW5432 (talk) 03:58, 4 November 2025 (UTC)

I am much less comfortable with using LLMs to measure bias, as it is less likely that they will correctly weigh dozens of RS, and they might just as well flag words that carry some emotional weight without checking whether sources justify them. Especially since sentiment analysis is a much more common task and one which the model is likely to mix up with bias analysis. Plus, it's much harder to get an AI to search for, retrieve and synthesize many sources vs to read one given source they get as input. Chaotic Enby (talk · contribs) 04:04, 4 November 2025 (UTC)

In addition to what CE said, the biggest issue with using LLMs for bias analysis is that what sounds neutral to an outside observer and what is actually demanded by our WP:NPOV policy can be wildly different.

So for instance, the last sentence of the first paragraph of Zionism:

Zionists wanted to create a Jewish state in Palestine with as much land, as many Jews, and as few Palestinian Arabs as possible.

is not neutral-sounding at all, but because the NPOV policy is about reflecting the balance of sources and not some kind of view-from-nowhere, it's not only in compliance with NPOV but NPOV basically forces us to say it like that. The number of scholarly sources that support that statement is more than I've seen for any other claim on the whole wiki, so there's really no way we could even hedge it.

And especially in articles in contentious topic areas we have tons of cases like this, where high quality scholarly sources agree on something that doesn't sound particularly neutral in a lay political context. Loki (talk) 04:18, 4 November 2025 (UTC)

You don't even have to look at contentious topics. "There is no such thing as ghosts", which is not "neutral" to the billions of people worldwide who believe in ghosts.

I spent several years at Breast cancer awareness helping editors grasp the difference between what reliable sources said on the subject and what the popular opinion is. After all, neutral is what the best sources say, and while all significant viewpoints need to be represented, those viewpoints are best supported by scholarly sources instead of fundraising/promotional sources. (With Komen's near collapse a few years back, the pressure of Pinktober has decreased.)

Towards the end of every October, I check Poisoned candy myths, because we sometimes have people who are just sure that it's "not neutral" to plainly state that no child has ever died by because a stranger gave poisoned candy to trick-or-treaters. And almost every December, there's someone complaining that Santa Claus is not neutral, since it (gently!) says that Santa is "legendary" instead of "real". Most of them are afraid that their children will read the Wikipedia article and discover the facts (but kids who are capable of understanding that article are old enough that believing in Santa would be an age-inappropriate belief). WhatamIdoing (talk) 04:46, 4 November 2025 (UTC)

• As others have said, you cannot just ask an LLM for fact checks or reliable sources that are new (as in, external to Wikipedia's current text) using a pretrained model with its existing knowledge base and a limited tool ability to web search or call the Wikipedia API. It will provide the same old ones (from Wikipedia) or it will hallucinate new ones that don't exist. But what you can do and it works reasonably well is download a bunch of PDFs or web pages and upload them and tell the LLM to read them all and provide you with verbatim quotes and page numbers and authors and dates for everything alongside whatever new generated text it makes - a report, or summary, or fact checks or tasks, in a constrained mode. Then you can check those with non-LLM code or by hand to eliminate hallucinations. Some will even highlight the PDF to show and make checking easier, YMMV. You can also give a document to an LLM, along with a statement, and ask it if the document supports the statement, and to provide verbatim proof. This produces fewer hallucinations and they are caught. I think having a bot to do this is a good idea. It could leave messages on a talk page or in its own set of user pages or in an interface. It would speed up improvement of thinly patrolled and maintained articles and it's a way to use LLMs for good without actually generating the article text itself, which does not work well and shouldn't be done. Andre🚐 05:14, 4 November 2025 (UTC)
• Nope doesn't work that way. Even when given sources, AI "summaries" usually introduce their own interpretations of the material -- which frequently follow the same contours as the usual WP:AISIGNS slop, just in this case put in someone else's mouth.

Here's an example from Grokipedia (choosing it because we know unambiguously it's AI text, because it really likes to claim it "fact-checks" everything, and also to dunk on Grok) This sentence from their "Woman article" -- Toni Morrison's Beloved (1987), drawing on the historical trauma of slavery, earned the Pulitzer Prize in 1988 and contributed to her 1993 Nobel Prize in Literature, emphasizing African American experiences through nonlinear storytelling -- is cited to this Reddit poll. Nothing after "Toni Morrison's Beloved" appears in that thread. Gnomingstuff (talk) 07:34, 4 November 2025 (UTC)

• That is exactly what AI is incapable of doing: checking sources. Don't believe me. Pick a big topic on Crockipedia. Go through the "sources" at the bottom in the form of raw URL links. Start counting how many are inaccurate or utter fabrications. Have fun with it. We need to keep AI as far away from WP as possible as its enshitification of the internet proceeds apace. Carrite (talk) 08:47, 4 November 2025 (UTC)

On the contrary, the motivation behind this is to avoid exactly the sort of errors found on Grokipedia. This is a bug detector, not an article generator. I've been experimenting with the following procedure:

1. Select an article using 'Random article'
2. Get Claude to perform a review of that article, giving it the article's wikitext as an input (Claude, and I imagine other LLM agents, has been blocked from accessing Wikipedia directly.)
3. Based on that, tell it to perform a set of web searches to find sources to confirm or deny any factual errors it thinks it may have found. (It incorrectly 'believes' that it cannot access the web unless actually told to.) It is forbidden to use Wikipedia as a source. I may later add more stringent criteria on sources.
4. Based on the output of those seatches, perform a review of the claims based on the evidence it has found
5. Finally, based on that, select the single correction out of the remaining errors that it is most confident about.

This multi-stage systematic approach has worked very well. Among other things, it has successfully made Claude detect and correct its own initially mistaken error reports, on finding that the sources actually back the article, leaving only valid reports of minor typographical errors. I've hand-reviewed all the remaining error reports, and every one of them has been accurate.

This should work as well with any other LLM, and it would probably make sense to use different LLMs to perform reviews to eliminate common-mode errors. — The Anome (talk) 10:45, 6 November 2025 (UTC)

This sounds promising, but I think it would be better if the prompt also included the full text of all of the available sources. Then you could ask it to verify each claim based off the citation and output chunks of the source which verify the claim. That would massively speed up the manual process of verification, but still leave it to humans to make the final evaluation. Hopefully including the sources would reduce the hallucinations as it would only be working with the prompt. SmartSE (talk) 13:41, 6 November 2025 (UTC)

This is an interesting process. You should create a flowchart for it. LDW5432 (talk) 13:57, 6 November 2025 (UTC)

• I tried something similar to this in Recent Change patrolling (User:Ca/Automated RCP) using GPT5-nano to surprisingly low error rates. I think this idea has potential. Ca ^{talk to me!} 05:27, 7 November 2025 (UTC)

I wonder if it's possible to compare the reliability of such a process to human reliability. AIs are error-prone, but more error prone than human reviewers? I am not so sure, especially when dealing with long articles where humans get tired/overwhelmed/eyes-glazing-over after a while. Granted, my personal idea of using AI would be to compare each claim to its reference, not the entire article as a whole. That denies us several benefits of whole-article comparisons but might (or might not) produce fewer hallucination errors. Jo-Jo Eumerus (talk) 08:20, 7 November 2025 (UTC)

When it comes to the field of medicine, especially but not only radiology, AI is being used rolled out to the "real world" quite tangibly including GPTs and other LLMs, not just image analysis models. (citation for this claim) So assuming we do not consider the accuracy of Wikipedia to be more vital than the accuracy of medicine being practiced on humans, I'm confident LLMs can be used to increase the accuracy of human editors who are trying their best to add good citations. JezzaHehn (talk) 01:13, 11 November 2025 (UTC)

I'm not sure this claim really makes sense (even though I'm fairly positive about this idea in general).

By analogy, computers have been used to do math in all fields including medicine for a long time, and have been highly reliable at that since the 50s. However, despite this fact, computers have never been useful at writing encyclopedia articles.

Just because an LLM is good at one thing doesn't mean it's good at some totally different thing. We're not doing medical scans here, so proof that AI is good at medical scans isn't very relevant. Loki (talk) 01:35, 11 November 2025 (UTC)

I agree that some type of LLM add-on will increase neutrality on Wikipedia. And if a human can review what the LLM does then even better. LDW5432 (talk) 01:44, 11 November 2025 (UTC)

Neutrality policy for genocide

Should Wikipedia have a neutrality policy that gives more specific guidance on how to describe genocide or alleged genocide? If so, what should it say? (A new WP:GENOCIDE was proposed on Talk:Gaza genocide, where many comparisons have been made to other genocide articles. I am not expressing an opinion on this question, just moving the conversation here.) -- Beland (talk) 01:43, 4 November 2025 (UTC)

To clarify (and based on comments so far), this is not necessarily a suggestion that Wikipedia should come up with its own definition of genocide and just use that (but advocate for that if you want). It could instead be a guide that points editors to common definitions used in the field, documents technicalities and sensitivities of various terminology, helps identify expert sources, and helps editors apply NPOV and other policies to statements. On the reader side, we have some of this information in List of genocides and Genocide definitions. We could also make this broader than just genocide to include other violent or otherwise sensitive types of event, add some words to Wikipedia:Manual of Style/Words to watch, or abandon this whole idea because instruction creep or some other reason. -- Beland (talk) 09:27, 4 November 2025 (UTC)

A serious question: why create a guideline for this particular label and not others? What purpose would it achieve given that guidelines are superseded by policies that are usually diligently applied to contested labels? M.Bitton (talk) 01:54, 4 November 2025 (UTC)

Would you prefer to see genocide, or some broader list of labels added to MOS:LABEL? Or if we're creating a new page, would you prefer it to cover a broader scope, like violence or government acts or something else? -- Beland (talk) 02:04, 4 November 2025 (UTC)

Oppose using a different standard for genocide than other events would itself be a form of bias, in favor of those who argue that genocide is exceptional rather than a recurrent theme in history. (t · c) buidhe 01:56, 4 November 2025 (UTC)

One option is to write up guidance that maintains the current policy, but just explains in more detail how it applies to genocide. Another option would be to write an explanatory extension with a broader scope - I think some editors suggested violent acts in general. Genocide and murder, for example, have technical legal definitions which make them different from mass killing and individual killing; it might help editors to have an explanation of the special considerations around those terms for that reason. -- Beland (talk) 02:06, 4 November 2025 (UTC)

From my conversations with genocide scholars, the legal definition(s) of genocide are highly criticized for a number of reasons. I don't know if enshrining these into Wikipedia policy is a good idea (and indeed, as buidhe notes may itself violate NPOV). Katzrockso (talk) 02:11, 4 November 2025 (UTC)

It sounds like you're thinking the guidance would be "if it's not legally considered a genocide, Wikipedia can't say it's a genocide". That doesn't have to be the case. Given this concern, what would you advise editors on how to use the word "genocide" in Wikipedia's voice? -- Beland (talk) 02:15, 4 November 2025 (UTC)

No different than the advice for editors on any other topic - through consensus-building and the weighted balance of reliable sources. That this topic area needs a specific guideline is not clear to me at all. Katzrockso (talk) 04:16, 4 November 2025 (UTC)

Pointing to my own comment below as to what a guideline could do to help: we don't want a guideline telling us what is and isn't genocide, but one telling us how best to assess and weigh reliable sources in this area. Chaotic Enby (talk · contribs) 04:20, 4 November 2025 (UTC)

Yes, it would be a form of bias to pick and choose between the many definitions of genocide used in academic research. Relatively few genocide scholars besides the lawyers actually use the UN Convention definition. (t · c) buidhe 05:58, 4 November 2025 (UTC)

It's also possible to write a guideline that's biased in favor of those who argue genocide is not exceptional, depending on the wording, no? If you were going to advise editors on how to use the word "genocide" in Wikipedia's voice, given this concern, what would you say? -- Beland (talk) 02:52, 4 November 2025 (UTC)

It should be treated the same as any other text, write what most of the scholarly sources say. (t · c) buidhe 05:59, 4 November 2025 (UTC)

Support Emotionally charged words like "massacre" and "genocide" should have a NPOV guideline for the project. The resulting policies should be added to WP:WORDS and other relevant sections. LDW5432 (talk) 03:18, 4 November 2025 (UTC)

I would oppose having one specifying on a single term and giving our own definition of the term (which might not follow what reliable sources use), although a wider guideline about emotionally charged words would absolutely be helpful. I don't think it should be part of Wikipedia:Manual of Style/Words to watch as these aren't words that should be avoided (and we don't want to introduce bias by toning down languages), but it could be a separate guideline cross-linked from there.

As for the content of the guideline, it shouldn't write our own definition for these terms, but give indication as to how we should best follow reliable sources. For example, how much weight should be given to experts vs media vs governments, what level of consensus (affirmative consensus vs silent consensus) is enough for these labels, when to attribute claims vs use wikivoice, or whether we should have separate guidelines for titles and prose (cf. Tamil genocide for an example where the title uses "genocide" but the prose clarifies it as a specific framing rather than a consensus). Chaotic Enby (talk · contribs) 03:26, 4 November 2025 (UTC)

I agree with this take. There are cases where having a literal flowchart can be useful (see WP:DEATHS) but I don't think this is one of them. Instead we should have a more general guideline about what kinds and numbers of sources we need to have to justify charged terms. Loki (talk) 04:22, 4 November 2025 (UTC)

As I questioned above (funny that you replied to me there as I was writing my comment here), what necessitates an extended guideline for this topic that isn't already covered by our existing policies and guidelines? All of the things you describe seem to be adequately covered by our existing guidelines, from what I have seen. At best, what you describe here seems to warrant an essay or a page on Wikipedia:WikiProject Genocide, not a guideline. Katzrockso (talk) 04:22, 4 November 2025 (UTC)

While I agree that it would proceed from our existing guidelines, there have been recurrent discussions about how exactly they should be applied to represent sources about possible genocides, and it could be good to have some reference points to avoid circling around the same arguments again and again. Chaotic Enby (talk · contribs) 04:28, 4 November 2025 (UTC)

I agree that it would be useful to have somewhere to collect common thinking on the topic to avoid repetitive discussions, but this is when an essay is warranted, not a new guideline. Katzrockso (talk) 04:32, 4 November 2025 (UTC)

The thing with essays is that they don't carry the weight of community consensus (anyone can write one), so it might not be especially helpful. Chaotic Enby (talk · contribs) 04:33, 4 November 2025 (UTC)

Community consensus on the application of our existing can be established through the discussions on each particular page in question, there is still no compelling reason for a new guideline on this topic area. How particular guidelines and policies are applied within particular topic areas is typically covered by essays (I only see topic specific guidelines for at WP:LGL for naming conventions - largely to the extent that these are formalized other non-Wikipedia guidelines, notability and style), which don't "carry the weight of community consensus", but still fulfill the rationale you provided for having a guideline. I worry about instruction creep and the fact that this seems like it might be the first content guideline that applies to a contentious topic area. Katzrockso (talk) 04:48, 4 November 2025 (UTC)

Good information can be helpful no matter what tag is at the top of the page. For example, I suspect that many editors would benefit from a handy summary of the difference between various legal definitions of genocide vs current scholarly understandings. WhatamIdoing (talk) 04:54, 4 November 2025 (UTC)

I see both of your arguments, and agree that a guideline might be too heavy-handed for this, although I'm still worried that an essay might be ignored as, well, "just an essay" even if it carries broad community consensus. Instruction creep is definitely something to be careful of, so I'm absolutely open to non-guideline alternatives. Chaotic Enby (talk · contribs) 05:01, 4 November 2025 (UTC)

So don't call it "an essay". Call it "an information page". Or consider {{Wikipedia how to}}, with the opening lines saying that the page tells "how to" handle disputes over this term. Make a custom tag with {{notice}}. Or put WP:NOTAG on it. WhatamIdoing (talk) 06:18, 4 November 2025 (UTC)

It's also possible for an essay to become a guideline if it's widely supported and followed. Just getting something out there that can be iterated may be more productive than arguing too long about what might be said in an abstract way. -- Beland (talk) 07:34, 4 November 2025 (UTC)

Yes, I started writing something earlier about how I'd rather see specifically what we are talking about in order to evaluate whether or not it should be a guideline. It's very difficult to support such an abstract idea of a guideline, for me. Katzrockso (talk) 09:52, 4 November 2025 (UTC)

Truthfully I felt we are really too close to this conflict and that everyone has their own biases in determining whether or not the Gaza War is a genocide. While the discussion on that talk page has raised examples of sources pushing back terms to describe the Armenian genocide and similar massacres/genocides, other scholarly content accessing these events are also made decades after the event, and with sufficient distance to discuss the event objectively. Right now, I felt there's really too much emotions across all parties (and potentially some antisemitic/anti-Israel/Islamophobic bias) to really properly access the conflict, especially since this is part of a broader contentious topic.--ZKang123 (talk · contribs) 04:03, 4 November 2025 (UTC)

Oppose. I don't think it has been established that a guideline is necessary here vs the already existing guidelines and policies on this topic that address this adequately. Katzrockso (talk) 04:28, 4 November 2025 (UTC)

Oppose as its not really a good idea to treat genocide different from similar words like massacre, etc. Instead, what we should be doing is not trying to rush to name such events in Wikivoice until many years have passed and we can then judge what the academic consensus is, assuming their is one. It is the same approach to how we handle scientific topics (For example, we do not assert COVID-19 was zootrophic but instead say the scientific consensus is that it was zootrophic and did not have a lab origin). Masem (t) 04:49, 4 November 2025 (UTC)

Comment - I am not opposed, but I expect the discussion over how to formulate the policy will be heavily weighed upon by the question of whether the Gaza genocide will make the cut. Additionally, I worry that the definition which comes out of this will be such that it is effectively impossible to call a genocide in Wikivoice until decades after the fact. There seems to be a group of editors (Jimbo included) which believe that the opinions of directly implicated governments and affiliated NGOs should weigh strongly against the designation. Such a policy would be very corrosive to our ability to describe objective reality. StereoFolic (talk) 05:04, 4 November 2025 (UTC)

As you point out, I suspect that any such discussion will simply be the relitigation of every previous genocide discussion combined and multiplied. I am not sure how productive such a discussion could be or whether meaningful consensus could result it. Katzrockso (talk) 05:06, 4 November 2025 (UTC)

Yes I worry about this too. There might be a push to adhere to strict rules, for example confining it to genocides that have been litigated at the ICJ or warrants issues for genocide at the ICC or other tribunals, which would ignore extensive studies into genocides of native Americans for example, just because the predated certain international conventions. Or there might be an appeal to constrict such calls to events that enough time has passed for consensus maybe putting into question something like the Yazidi genocide. If there is to be a consensus it will never be just custom made to exclude this one event, it will inevitably lead to more genocide denial down the line. Tashmetu (talk) 08:35, 4 November 2025 (UTC)

One way to resolve these worries would be to propose text you do want to see, and make some enlightened arguments. I think if a guideline has to cover all genocides and alleged genocides, it becomes difficult to argue for an unfair rule to favor a preferred outcome for a partisan fight without that becoming somewhat transparent as a tactic if as it fails to fit less controversial cases. Or if the drafting process goes off the rails and produces something unacceptable, there's always the option to vote against making it a guideline. -- Beland (talk) 08:53, 4 November 2025 (UTC)

@Beland: What would it cover that WP:LABEL and other guidelines already don't? Let me give a somewhat related example, there has been a liberal use of dictator being added to a lot of BLPs and otherwise without discussion, sources or the weighing thereof. But that is perfectly countered by extant guidelines like LABEL which I have argued for and used in discussion. Would we then need a separate WP:DICTATOR guideline, I think not.

But to add, I think both the genocide proposal and the dictator example given by me can be covered in use cases (for when and how to voice these) at the extant guideline pages. Gotitbro (talk) 06:35, 4 November 2025 (UTC)

Are you voting for adding "genocide" and "dictator" as examples at MOS:LABEL, then? -- Beland (talk) 07:36, 4 November 2025 (UTC)

I think "dictator" is a good example of a value-laden label, but I disagree that "genocide" functions in the same way. Whether or not someone is a dictator is not typically the subject of significant scholarly analysis (there are exceptions here and there, especially in the historical literature), but whether or not an event is a genocide is. This makes "genocide" distinct in that while it may have value-laden implications, the actual usage of the term in Wikipedia should be governed by e.g. our other content guidelines that emphasize WP:RS. Another important distinction is that genocide refers to "events", while MOS:LABEL examples refer to people/groups. Part of the justification for MOS:LABEL is WP:BLP, which doesn't apply here for an event (genocide). Katzrockso (talk) 07:38, 4 November 2025 (UTC)

Well, there are governments being accused of genocide, which are made of living people, some of whom have international criminal warrants issued against them, and some of whom are aghast what has been happening.

But it's true that events are just a different class of thing than people which may require different advice. For example, whether to describe an event as a death, killing, murder, manslaughter has to take into account whether the cause of death was indisputably another person, and whether a specific legal category has been assigned to the killing through a conviction. Labeling an shooting as a terrorist attack or militant action or liberation attempt may have similar considerations to labeling someone a terrorist. Is this transportation event a collision or an accident?

I can actually brainstorm a fair number of event-related words and phrases to watch: direct action, sabotage, protest, activism, eco-terrorism; civil war, rebellion, insurgency, terrorism, resistance; strike, supply disruption, work stoppage, lockout; occupation, liberation, invasion, annexation, reunification, restoration; coup, revolution, liberation, regime change, change in power; parade, protest, demonstration, riot, uprising, insurrection, rebellion.

There are also more people-related words we don't cover, but which are sensitive: refugee, asylum seeker, alien, immigrant; homeless, unhoused person; "discovery" of the Americas.

We could just expect editors to educate each other about the technical considerations and connotations and cultural sensitivities around various words and otherwise expect them to follow sources or common sense, or try to document terminology for sensitive events for reference and to guide discussions toward faster and more predictable consensus. We could also scope such an expansion broadly - whatever we can think of that's been the subject of e.g. a page move dispute or lede RFC - or narrowly, just for words where there's a burning need to ensure they are treated consistently across many articles, either because we are being inconsistent or we are just arguing too much and codifying where we always land would save time.

-- Beland (talk) 08:34, 4 November 2025 (UTC)

While yes, governments are made up of people and warrants have been issued for arrests, the application of the term "genocide" to events doesn't have such a direct implication on people in a way that is relevant to Wikipedia. From the basis of determining that any particular event is a genocide, I don't believe we have gone to attach these labels to individual people, but still keep the type of attribution requested by MOS:LABELS.

WRT the event-related words to watch, This is good pushback, I think many of those words could broadly construed as sensitive and value laden labels that are subject to the same sorts of disputes as the ones in MOS:LABELS, so parts of my argument aren't quite as strong there. I do think that genocide, ironically, is unique in its position that its extension is uniquely studied in academia - other than maybe terrorism, I can't think of any large body of academic research that consistently studies whether or not any particular event constitutes a type of event or not. In this case, genocide is if anything the one category of event that does not need a specific guideline to govern its use per MOS:LABELS or anything similar, imo. Katzrockso (talk) 09:38, 4 November 2025 (UTC)

LABEL is broad enough to cover insances beyond bios/orgs to including events. The reason MOS:TERRORISM to it for example. These to me are close enough to not warrant a separate adjudication.

@Beland: "Are you voting for adding "genocide" and "dictator" as examples at MOS:LABEL, then?" Yes. And if it is not considered bloaty most of the rest of the examples given by you above. Gotitbro (talk) 10:49, 4 November 2025 (UTC)

Oppose: We should primarily go with what the reliable genocide scholars say regarding each case, and follow the official standards in this world, not develop our own standards that go against them, especially as this can easily be abused to lessen said standards so much that we do not recognise serious crimes against humanity. David A (talk) 08:29, 4 November 2025 (UTC)

Do you think it would be helpful to have a WP:GENOCIDE that documents various genocide definitions that should be referenced by articles? And maybe gives some advice about where to look for reliable genocide scholars or how to figure out which are and aren't reliable? Do editors need advice on how to evaluate statements made by scholars and what sort of sources to discount from "scholarly consensus" or to report with attribution (like governments involved in a conflict)? -- Beland (talk) 08:47, 4 November 2025 (UTC)

That seems much more reasonable, yes. David A (talk) 08:49, 4 November 2025 (UTC)

OK, that's certainly well within the scope of what I'm asking people to propose. -- Beland (talk) 08:55, 4 November 2025 (UTC)

My next question was going to be, what are the major definitions we should be highlighting? Then I thought, oh, maybe we could just link to Genocide definitions...but there are so many definitions there! It sounds like the 1948 Genocide Convention is almost universally used for legal purposes. Do scholars tend to only reference that, or are there other common definitions used in the academic literature? Or in other reliable sources, for that matter? -- Beland (talk) 09:00, 4 November 2025 (UTC)

I am not a genocide scholar, so I am not sufficiently well-informed to be of much help for you in that regard. My apologies. David A (talk) 09:04, 4 November 2025 (UTC)

Ah, OK, perhaps some experts will chime in.

List of genocides may be a good anchor; that list is scoped to only include events "recognized in significant scholarship as genocides". Perhaps if it isn't on that list, it shouldn't be described in wikivoice as a genocide. That's partly just a matter of synchronization, but it could also serve as a public documentation of what our threshold for that is, with sources that can be used for easy comparison.

That list article also has a good summary of definitional controversies. It seems we now think of ethnic cleansing and politicide as distinct atrocities from genocide, and I'm not sure how "forced pregnancy, marriage, and divorce" is treated in modern times. The article also says: "The academic social science approach does not require proof of intent, and social scientists often define genocide more broadly." I find that a bit mysterious and it may help editors to clarify that, and help readers to explain how that relates to inclusion on the list.

-- Beland (talk) 09:15, 4 November 2025 (UTC)

See my comment below on how it may be described outside of the legal definition. I was active in crafting the new inclusion criteria for that article. I would just clarify that while The academic social science approach does not require proof of intent most definitions from this area still have intention, and treat it with some primacy. -- Cdjp1 (talk) 09:25, 4 November 2025 (UTC)

Spurred by your comments, I've tweaked List of genocides a bit as the cited source was actually closer to what you're saying. -- Beland (talk) 09:42, 4 November 2025 (UTC)

While the legal definition is engaged with regularly and thoroughly in the literature, it is also highly contentious, as the majority tend to view it as too restrictive (due in part to the political climate it was developed under), though a minority also view it as too broad. These views have existed since prior to the adoption of the Convention, and are not just "humanities and social science scholars" but are also expressed, again regularly, by legal scholars in literature. There are a couple of definitions (more aptly called frameworks, in my opinion) that scholars will gravitate towards, and these definitions come from the more prominent individuals in the field. But there is no singular standard alternative used instead of the legal definition. -- Cdjp1 (talk) 09:19, 4 November 2025 (UTC)

Are those frameworks listed on Genocide definitions? -- Beland (talk) 09:43, 4 November 2025 (UTC)

Yes, there has long been a discussion around how Lemkin expended every last bit of him political capitol to get the UN to adopt a definition of genocide that gutted its meaning. Katzrockso (talk) 09:45, 4 November 2025 (UTC)

Comment - While I support the notion in theory, and have been mulling over the idea of starting one myself for a few years now (I do have a draft), I have not pushed forward with it as it seems as though we would ultimately end up in OR territory with it. If we do start working on an essay (with the view of it eventually becoming a guideline or policy) I will engage with the matter, but for now, I can not make a vote either way to it existing. -- Cdjp1 (talk) 09:14, 4 November 2025 (UTC)

OR because we'd be coming up with our own definition of genocide? That's not the sort of thing we really do; as David A and I were talking about above, I would expect it to be more about looking at existing definitions of genocide and helping editors navigate them and apply NPOV and other policies to them. -- Beland (talk) 09:18, 4 November 2025 (UTC)

I understand that isn't what we (should or otherwise) do, as I said though, when I try to play out pushing and developing such an essay, I ultimately end up seeing us discussing the matter in ways I consider to be within OR territory. This view could (and hopefully) be ultimately wrong, but is the reason why I have not pushed forward on it. -- Cdjp1 (talk) 09:23, 4 November 2025 (UTC)

Editors seem to be pretty good at yelling "original research!" and deleting as needed, so I expect we'd be able to distinguish between that and making better editorial decisions, which actually still requires some thinking and occasional guidance. I think we're at the point of working on this now...it seems better to be concrete and vanquish fears about what might happen by going ahead and not doing the wrong thing or demonstrating we can recover from it. So I'd welcome a draft even if we decide it's not a direction we want to go in. -- Beland (talk) 09:34, 4 November 2025 (UTC)

There were suggestions of making up our definition/analysis of genocide in the other thread, I believe VPP suggested something like this. Katzrockso (talk) 09:40, 4 November 2025 (UTC)

@Very Polite Person:, I think this is referring to you. Are you interested in a guideline that says "if reliable sources say X, Y, and Z have happened, it can be called a genocide in Wikivoice", or something that references existing legal and academic definitions and helps editors look for reliable sources that reference those (and maybe documenting considerations and sensitivities around terminology, etc.)? -- Beland (talk) 09:50, 4 November 2025 (UTC)

Yes, this was in reference to Very Polite Person from this comment in particular and I hope I didn't mispresent their position (which is legitimate even if I disagree with it). Thanks for tagging them into this discussion. Katzrockso (talk) 09:55, 4 November 2025 (UTC)

This topic is contentious and argued enough that at least an essay with some centralized guidance and summaries of previous discussions and community consensus would be useful. Not as a tool for winning arguments or forcing specific practices, but as a shortcut to common understanding. ~2025-31078-40 (talk) 12:23, 4 November 2025 (UTC)

Support - My vision for such a centralized policy page would be a place to explain the synthesis of various Wikipedia policies related to covering the topic of genocide on Wikipedia. It should explicitly not be trying to define genocide. Instead, it should focus on addressing commonly raised issues. For example, it can explain that Wikipedia policy does NOT require that the ICJ declare that an action is genocide in order for Wikipedia to use Wikivoice to refer to it as genocide. It should clarify that genocide studies is an academic field and that the opinions of scholars in that field should be given more weight (per NPOV) than government officials asserting denial. It should explain that Wikipedia is not limited to only using the legal definition of genocide, and instead it is up to reliable sources to use the word, which we can then attribute. It should explain that Wikipedians should refrain from original research and avoid synthesis of facts to conclude genocide or lack thereof (and that talk pages should not be filled with such material of Wikipedians soapboxing their own assessment of events, such as "the low/high number of deaths means that it [is] [is not] genocide!"). These are just a few suggestions, but the general theme is that it should not be trying to (1) authoritively define genocide or (2) declare certain events as genocides. JasonMacker (talk) 15:03, 4 November 2025 (UTC)

Those seem like good ideas. David A (talk) 15:21, 4 November 2025 (UTC)

i agree with this. it could also address "it's a war not a genocide" and "not enough people have been killed to count as a genocide" Rainsage (talk) 23:15, 4 November 2025 (UTC)

Wikipedia:Genocide is draft live with my notes inspired from that talk on Gaza genocide. Any of you are free to adopt and edit as needed. — Very Polite Person (talk/contribs) 16:51, 4 November 2025 (UTC)

It seems to me the root of the matter is that some folks don't understand that current enwiki consensus/practice is usually to weigh academic consensus higher than government and news sources. This can cause a lot of confusion and even indignance in topics where there are a lot of news and government sources saying X, and a lot of academic sources saying Y, and then we write our articles from the Y POV. The same thing happens constantly in WP:FRINGE topics such as COVID-19 lab leak theory. Perhaps the fix is as simple as strengthening the "academic consensus is always superior to other types of sources" wording in the various policies such as WP:NPOV, WP:RS, WP:FRINGE, etc. It is currently a bit weak, with only a sentence here and there (WP:SOURCETYPES, WP:BESTSOURCES). I say "academic consensus" instead of "academic sources" because we need to be careful not to elevate junk academic sources such as single studies (WP:SINGLESTUDY). What we're really interested in is review articles, textbooks, and policy statements from respected international organizations that summarize the academic consensus. WP:MEDRS does a great job of this for sciences. For humanities topics, we'd probably need to add to the list books by experts in the field. –Novem Linguae (talk) 03:40, 5 November 2025 (UTC)

Agree with this, I’m surprised WP:BESTSOURCES doesn’t explicitly say scholarship Kowal2701 (talk) 12:49, 5 November 2025 (UTC)

There are lots of topics that do not get academic coverage, so that might be why. Katzrockso (talk) 13:43, 6 November 2025 (UTC)

Wikipedia:Genocide

@Katzrockso: and @Beland: I have put my idea and notes here: Wikipedia:Genocide. Please feel free to run with that as needed. — Very Polite Person (talk/contribs) 16:49, 4 November 2025 (UTC)

Thanks for tagging me, I will take a look. Katzrockso (talk) 03:42, 5 November 2025 (UTC)

I'm interested as well. LDW5432 (talk) 17:09, 5 November 2025 (UTC)

!Voting on sanctions at ANI

Interested to hear what people think about this, I know there's been lots of discussion on reforming WP:ANI (like here and here) but I can't see that this has been suggested before from the archives. I think that when !voting on sanctions at ANI that are to be imposed by the consensus of the community, people who are involved in the underlying dispute should preface their !votes with something indicating that they're involved (like {{nacmt}}). This could be limited to the underlying dispute preceding escalation to ANI and historical disputes with that editor, or could be broadened to meet WP:INVOLVED (ie. disputes in the topic area). Reasoning is the same as at INVOLVED, involved [editors] may be, or appear to be, incapable of making objective decisions in disputes to which they have been a party or about which they have strong feelings; having some identifier makes it easier for newcomers to the report to analyse the discussion.

Imo the benefits of this is that it would encourage transparency and honesty, make it easier for newcomers to the report, and hopefully would make ANI fairer and slightly more functional (at the very least make it appear fairer, moreso to the reported editor). Whether closers ought to weigh involved !votes less or the same as uninvolved, idk. Downside is that it takes admin time to 'enforce' and could derail reports with people back-and-forth arguing about whether they're involved (maybe it could be written somewhere that this should be discussed on user talk pages instead). Thanks for reading Kowal2701 (talk) 19:05, 4 November 2025 (UTC)

First thought: I don't think we need a bunch of little discussion templates for this. I don't think we should make this "a rule". But I think that it would be an okay thing to model and to encourage, particularly in longer, more vote-like threads.

Second thought: It's sometimes difficult to decide whether you're involved or uninvolved. We see editors sometimes saying that they're "semi-involved", and there's the difficult case of an editor whose views are clear but who hasn't technically been involved in this specific dispute. For example, I had a userbox on my User: page for years that said I dislike comma splices. If Alice and Bob have a dispute at ANI about a comma splice, then am I "involved"? We might normally say that I'm not involved, but if someone's closing a contentious RFC, there is a preference for people who have never expressed an opinion on the subject, because we want people who are uninvolved. WhatamIdoing (talk) 21:41, 5 November 2025 (UTC)

As another unclear case, I was actively involved with an RFC about a topic, arguing strongly for one option, and have expressed similar views in related discussions, but did not participate in a second RFC about the same topic shortly afterwards (I wasn't aware of it). The closure of the second RFC was brought to ANI for review - am I involved or not? Thryduulf (talk) 21:50, 5 November 2025 (UTC)

Yeah it's probably better as a norm, that way people can do it at their own discretion, but idk how we'd encourage it without jotting something down in an essay/guideline like Wikipedia:ANI advice. WP:CBAN does say Discussions may be organized via a template to distinguish comments by involved and uninvolved editors, and to allow the subject editor to post a response, though I've never seen that done, maybe advice along these lines could be added there? Kowal2701 (talk) 17:03, 6 November 2025 (UTC)

For community discussion of cbans, it would be nice to recruit uninvolved participants the same way we do for rfcs with WP:FRS. User:Bluethricecreamman (Talk·Contribs) 20:32, 10 November 2025 (UTC)

Sounds like a great idea Kowal2701 (talk) 21:08, 10 November 2025 (UTC)

Wikipedia:Banning policy#Community bans and restrictions says in part the community may impose a time-limited or indefinite topic ban, interaction ban, site ban, or other editing restriction(s) via a consensus of editors who are not involved in the underlying dispute (emphasis added). !votes on sanctions from involved editors shouldn't really be considered at all according to this. I agree with WhatamIdoing that disclosure probably shouldn't be "a rule" but if you notice it I wouldn't have a problem with mentioning it briefly, as we typically do with WP:SPAs. Ultimately though I think it's up to the closer to weigh consensus appropriately, especially in cases where an editor's involvement may be marginal. —Rutebega (talk) 21:55, 5 November 2025 (UTC)

This makes me think about the role of reputation. You don't really want editors to be posting "This editor has previously supported ____ in many other discussions", because that kind of comment promotes drama, and yet if I were closing a dispute, I'd probably take the person's reputation into account, if I happened to know it. WhatamIdoing (talk) 00:15, 6 November 2025 (UTC)

I'm surprised at that, I've seen very clearly involved editors even make CBAN proposals, and haven't gotten the impression their !votes aren't weighed. Yeah, little notes like WP:INVOLVED for unambiguous cases would probably be okay and hopefully uncontroversial, and help the closer out.

I was going to add to the OP that admin !votes should be weighed more heavily than those of non-admins. While we tend to stress consensus is based on quality of argument, I'm sure things like reputation and social capital contribute to weight. Like how WP:NHC says (bold mine) If the discussion shows that some people think one policy is controlling, and some another, the closer is expected to close by judging which view has the predominant number of responsible Wikipedians supporting it, not personally select which is the better policy. ("predominant number" seems to encourage vote-counting?) Kowal2701 (talk) 17:16, 6 November 2025 (UTC)

If there was no vote-counting of last resort, 50% more of our disputes would result in no consensus.

Otherwise, there are decisions that could never be made at all, because there is no written rule saying that Image A belongs in the infobox and Image B in the first section or vice versa, or that editors should prefer to merge or split content that could equally be one long article or three shorter ones.
— User:WhatamIdoing 23:56, 11 June 2025 (UTC)

Aaron Liu (talk) 12:56, 10 November 2025 (UTC)

It's not really "their !votes aren't weighed" at all. It's more like "Of course this notorious WP:CPUSHer would say that, so I'll count that less (but not zero)". Consider a CTOP subject such as a geopolitical dispute. We know that some editors occasionally try to 'win' by getting editors who disagree with them kicked out of the community. If one of them turns up at ANI claiming that their opponent hates kittens, etc., then you need to take the context of their relationship and their POVs into account. WhatamIdoing (talk) 20:22, 10 November 2025 (UTC)

This is a great idea. Most are unaware that "involved" !votes should be ignored, and those "involved" very often influence others with their arguments - you can't simply ignore them. In the real world it is sometimes called jury tampering or vote tampering, to use legal terminology, maybe call it !tampering in the same way it is a !vote -- GreenC 16:51, 8 November 2025 (UTC)

Please, let's not extend the programming logic negation (!) jargon to more words. It's already opaque to those unfamiliar with programming or the reason why it's being added in front of "vote". It doesn't provide any additional concision (almost every instance in this section, for example, could be replaced with "comment"). Additionally, putting a negation in front would, by analogy with "!vote", convey the meaning that "this is an opinion expressed in the form of tampering but is not actually tampering". Assuming for the sake of argument that tampering is an apt word, I don't think negating it helps. isaacl (talk) 17:41, 8 November 2025 (UTC)

Subreferencing with templates

The m:SUBREF syntax <ref name=foo details="bar" /> does not support templates, unlike the original <ref extends=foo>bar</ref> proposal. This makes it more difficult to have standard rendering of, e.g., quotations, in subreferences, much less proper metadata. There should be some way to use a template within a subreference. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:29, 8 November 2025 (UTC)

As this appears to be a more technical issue with the subreference syntax itself, and it isn't available on English Wikipedia yet, I invite you to ask this question at meta:Talk:WMDE Technical Wishes/Sub-referencing instead, as there isn't much we can't do about it here. Chaotic Enby (talk · contribs) 21:23, 10 November 2025 (UTC)

References

WP:TOOBIG and "justify reading material"

At WP:TOOBIG, it states that at over 9,000 words, an article, "Probably should be divided or trimmed, though the scope of a topic can sometimes justify the added reading material." Many editors believe the scope of an article fits this "added reading material". Recent examples include Washington Monument and Wilmington massacre, although more examples can be produced if requested.

Long articles are discouraging for the average reader, who are more likely to be interested in an overview of the topic and not specific details. It also makes it hard for the reader to navigate the article, especially on mobile, and to find the most important information on a topic. Long articles can usually be spun out, have information summarised more effectively, or have excess detail removed. Articles with large scopes such as Philosophy, Earth, and Bacteria are able to keep their word count below 8,000.

I would like to change the phrasing of this sentence so that the guidelines makes it clearer that articles under 9,000 are encouraged and that very few articles can justify an extended length. One phrasing I thought of was, "> 9,000 words: Probably should be divided or trimmed. While the scope of a topic can sometimes justify the added reading material, these are rare exceptions." I am open to alternate wording, and hope to bring this as a formal proposal in a couple of days or weeks. Thoughts? Feel free to ping me. Z1720 (talk) 15:29, 8 November 2025 (UTC)

these are rare exceptions - How rare is it? Would be interesting to see stats for those categories (6k, 8k, 9k, 15k). -- GreenC 16:38, 8 November 2025 (UTC)

@GreenC: This might be difficult to determine. Looking at Wikipedia:FABYLE, Taylor Swift was 6483 words when it passed its FAC, Mitt Romney at 11,105, Lady Gaga at 6883, India at 7732 at the end of its 2011 FAR, and Sonic the Hedgehog at 9488. Beyoncé was at 9241 words after I did a copyedit to (among other things) reduce the size of the article: I think if I did another copyedit I would be able to get it down to under 9,000. I think attempts to spin out content and remove excess detail should be attempted before proposing that the article's scope can justify a larger article. Z1720 (talk) 17:01, 8 November 2025 (UTC)

wikiget -w "Washington Monument" -p | wc -w = 10,899 words .. this is plain text no markup (calls API:TextExtracts). Only need run this command on 7 million articles, sort the results into categories by size. In all the years, nobody has yet made a report of largest articles by word count? -- GreenC 18:25, 8 November 2025 (UTC)

@GreenC, in a sample from last year, about 0.5% of articles have more than 9K words, and about 0.1% have more than 15K words. WhatamIdoing (talk) 19:42, 10 November 2025 (UTC)

Eh, I would oppose, I think this guideline is already too restrictive and I don't feel the need to make it stricter. "Long articles are discouraging for the average reader, who are more likely to be interested in an overview of the topic and not specific details" don't agree with that. Spinning out can be impossible because sometimes there is no notable subtopic to spin out. There are quite a few topics where >9000 words is justified. PARAKANYAA (talk) 19:38, 8 November 2025 (UTC)

Yeah, I agree- I know this isn't the way we envision our articles being read, but I think most people read the first paragraph/lead and then, if they

need more, use the TOC to navigate to the section they're interested in. The size of an article is much more relevant when it comes to loading articles, which actually doesn't have all that much to do with word count. As an example, my laptop would rather die than edit United States at the 2024 Summer Olympics ever again, but that's at only 4k words. It's fine with the 9-10k word biographies. GreenLipstickLesbian💌🦋 20:13, 8 November 2025 (UTC)

@GreenLipstickLesbian: I agree with your description on how readers read the articles, but come to a different conclusion: larger articles will produce larger TOCs, making navigation harder for our readers. By shortening the articles, we help our readers find the information that they are looking for. Spinning out articles helps readers go down the wiki-rabbit hole and make them more likely to read the lead of the new article. Larger articles make it harder to load on slow connections, less appealing to readers, and less likely that readers will read editor work. Reducing word count will also help with other loading issues: a smaller article has less space for images and less likely that templates will be necessary to help explain prose. Z1720 (talk) 02:29, 9 November 2025 (UTC)

Yeah, definately different conclusions. I find that I'm more likely to read something if everything is on the same page; going down wiki-rabbit holes (while something I very much enjoy doing!) is frustrating to me when I'm looking for a specific piece of information. It's often why I !vote "merge" at AfD. Even if everything was integrated very well across multiple articles, then I think we'd still be have the same issues wrt to the length of the TOC - but I'd lose my ability to CTRL+F. Similarly, spin offs tend to have viewer viewers & fewer page watchers, meaning serious issues are much more likely to slip under the radar. Tobacco smoke, for example, is an arguably standalone topic - it got deleted through WP:CP/N, but for 10 years we had a very highly viewed article where an editor used some very old papers to propose a somewhat... outdated view on tobacco smoke, cancer, and cigarette companies - the type of view that would have been removed instantly if you'd added it to the main cigarette, tobacco, or tobacco smoking articles.

While it's true that on first glance, a longer article has more room for reasonable tables, images, ect, I wonder how true that actually is? Many articles, even the smaller ones, lend themselves to a lot of images and very little text. Similarly, and maybe this isn't so true at the FAC/GA level, but many editors I've encountered see to have no issue adding massive sections of images to tiny articles. And, again, some of the worst offenders I've come across in terms of page load times have been articles like the Olympics one I linked about - over 300,000 bytes for just 4k words and 4 images. I'd rather have a maximum byte-size rule than a strict wordcount; something that would apply to all articles equally. I think we could trust editors to determine how to split that between prose and non-prose content. GreenLipstickLesbian💌🦋 03:20, 9 November 2025 (UTC)

We do have a maximum byte-size rule. It's around two million, and strictly enforced in software. WhatamIdoing (talk) 19:40, 10 November 2025 (UTC)

Given the pain my laptop goes through when loading articles at 10% of that total.... goodness gracious. GreenLipstickLesbian💌🦋 23:59, 10 November 2025 (UTC)

In re sometimes there is no notable subtopic to spin out: Maybe Wikipedia:Notability needs to have an explicit sentence authorizing the article about a subtopic that is the result of an article split. The point would be to stop all the wrangling, not to make unwanted or inappropriate content exempt from deletion or re-merging. I think this would be particularly helpful for splits resulting in a list, because WP:LISTN is a section that editors have wildly different interpretations of. WhatamIdoing (talk) 19:39, 10 November 2025 (UTC)

I don't see any use to that. PARAKANYAA (talk) 01:31, 11 November 2025 (UTC)

What sometimes happens now is:

• A: This article is much, much too big! Let's WP:SPLIT it.
• B: Good idea. The last section is just a list, so how about we split that off into a List of X?
• C: Sounds good. I'll do that now.
• D: Mwa ha ha, I'm taking the List of X off to AFD, because nobody already cited SIGCOV IRS in the List of X to prove that organizing information about X in the form of a List of X is separately notable from X itself! Wikipedia should not have such unimportant unencyclopedic unwanted content, no matter what the Wikipedia:Editing policy says to the contrary!

WhatamIdoing (talk) 18:17, 11 November 2025 (UTC)

A better change may be to provide more relevant advice. "divided or trimmed" doesn't really work, division gives the impression of cutting in half or thirds etc. which is not really what we look for at all. Trimming is fine on the margins but doesn't do more than that. What we really want is for subtopics to be spun out, we want an article to be summarised, rather than divided. CMD (talk) 03:13, 9 November 2025 (UTC)

@Chipmunkdavis: Your proposal would probably require rewording the whole table, which I am open to considering. Here's how that might be phrased:

Some useful guidelines for article length:

Readable prose	What to do
> 15,000 words	Almost certainly should be reduced in size. Sections that are notable should be spun out, overly detailed information removed, and information summarised more effectively.
> 9,000 words	Almost certainly too large. Although the scope of a topic can sometimes justify the added text, these are rare exceptions. Consider summarising text more effectively and removing overly detailed or less important information.
> 8,000 words	Might be too large: the likelihood goes up with size. Consider summarising the text more effectively to reduce the word count before adding new text.
< 6,000 words	The article is within the target length. Summarising information more effectively will help with readability, although this might not be a high priority.
< 150 words	The article is probably missing key aspects of the topic. Consider expanding the text to add important details that will allow the reader to better understand the topic.

Thoughts are welcome. Z1720 (talk) 03:42, 9 November 2025 (UTC)

• Overly long articles are a problem; but I am concerned with arbitrary limits applied equally to 7 million articles. It works better with soft wording, and the option for each article to decide its own local consensus. The guideline is a starting point for discussion, not a hammer looking for nails. -- GreenC 06:36, 9 November 2025 (UTC)
  • @GreenC: Several editors state that an article's scope justifies a longer length when the article has unnecessary detail or phrases that could be summarised more effectively. This change is trying to encourage editors to copyedit the article first before making that statement about the scope. Z1720 (talk) 15:18, 9 November 2025 (UTC)
    • unnecessary detail .. what goes into an article can be controversial. Is it unnecessary? It should follow the wiki method of editing. BTW I edited Washington Monument a few months ago, reducing detail in one section by completely rewriting it. Nobody objected because it was a clear improvement. There was no need for a guideline about word count. Don't want this guideline to force changes that are controversial, it's a recipe for dispute. Thus the wording could be softer not hard line ("certainly too large"). -- GreenC 17:12, 9 November 2025 (UTC)

• @GreenC: What would you propose replacing the word "certainly" with? Z1720 (talk) 19:15, 9 November 2025 (UTC)

I wonder whether we need to give practical advice about how to trim an article (e.g., "check whether it's a WP:PROSELINE, make a WP:SUMMARY of a section..."). WhatamIdoing (talk) 20:12, 10 November 2025 (UTC)

@WhatamIdoing: I have thought about writing an essay about this, but haven't gotten around to it. Z1720 (talk) 22:45, 10 November 2025 (UTC)

Or maybe start by expanding Wikipedia:Article size#Trimming or content removal. WhatamIdoing (talk) 23:39, 10 November 2025 (UTC)

• I'm not certain that the change will have the intended effect. The heart of the matter is what, if any, circumstances justify going above 9000 words. A considerable percentage of articles could contain more than that much material. To minimize argumentation over whether a specific article should constitute an exception I'd think we need to lay out potential rationales as well. Vanamonde93 (talk) 18:32, 11 November 2025 (UTC)

Consistent display of coordinates

When reading articles about geographic locations in desktop mode, I am slightly annoyed if the coordinates are not available in a convenient and predictable spot near the article title. This forces me to hunt for the coordinates in the infobox or article body. It also means that the article will not be correctly geotagged.

For some examples of articles that have this issue, due to using {{coord}} with |display=inline alone, see Yerevan, Matera, Duluth, Minnesota, San Luis Potosí (city), and Shivneri Fort. Also note, for example, that Shivneri Fort will not show up when viewing Special:Nearby#/coord/19.199,73.8595.

Conversely, when browsing on mobile, coordinates added using |display=title alone aren't visible at all. For some examples of articles with this issue, see Islandmagee, Ostia (Rome), and Matthias Church.

To avoid both of these problems, I would tentatively propose that |display=inline,title should be preferred in most^* articles about settlements or geographic features. It seems that it would be possible to use a bot or semi-automated script to enforce this rule.

Perhaps my proposal is already the accepted approach and the articles above have just unintentionally deviated from it, but I'm not sure. MOS:COORDS doesn't really seem to address this issue and I couldn't find any other relevant guideline. This issue has probably been discussed before; links to past threads would be appreciated.

* There are obviously cases where |display=inline is appropriate. For example, the article Extreme points of the United Kingdom discusses several different points and it would be wrong to geotag the entire topic to any specific one. There are likely other edge cases I haven't thought of. I'm only referring to how to format the "main coordinates" in articles about uniquely identifiable locations: villages, mountains, buildings, etc. ~2025-32085-07 (talk) 23:36, 9 November 2025 (UTC)

Hello. In my opinion, the title is a goofy spot for coords and we should list them only in the infobox alongside all the related metadata about a place. It's a weird historical artifact and anachronism that the coords get such special placement and their special page placement has been a constant headache for years with different views and different skins, as you note. Is there a reason coords are so special that they can't be put in the infobox? The coords seem as relevant to Pittsburgh as its population. --MZMcBride (talk) 20:47, 10 November 2025 (UTC)