Wikipedia:Village pump (policy)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

The policy section of the village pump is intended for discussions about already-proposed policies and guidelines, as well as changes to existing ones. Discussions often begin on other pages and are subsequently moved or referenced here to ensure greater visibility and broader participation.

See the list of frequently rejected or ignored proposals. Discussions are automatically archived after 7 days of inactivity. To keep this page's size accessible, discussions with more than about 100 comments should be split to a separate page.

RfC: Permitting or prohibiting AI in creating/formatting Wikitext

Since I clarified that the original discussion was not an RfC and was also getting off-topic (sorry, Gurkubondinn), here we are. The discussion yielded an unclear result, so I figured I would just move ahead with a clearer RfC. Hopefully consensus will be clearer. Courtesy-tagging original discussion participants: @Gnomingstuff @SuperPianoMan9167 @Katzrockso @NicheSports @LWG @Fermiboson @Thryduulf @InfernoHues @Chipmunkdavis

Should WP:NOLLM be updated to explicitly permit or explicitly prohibit the use of AI/LLMs to create/format Wikitext (hereafter referred to as "WT")?

Option 1 — No change to NOLLM.

Option 2 - Add some form of explicit exception to PERMIT the use of AI to format WT, with the caveat that the user is responsible for ensuring it is non-disruptive and publishes without error.

Option 3 — Add some form of explicit prohibition to PREVENT the use of AI to format WT.

This RfC also invites discussion as to the wording of an exception or prohibition — MWFwiki (talk) 22:12, 19 September 2026 (UTC)

Note: This isn't an WP:RFC. Merely putting the letters "RfC" in a section heading does not create an RFC. The purpose of the RFC process is to advertise the discussion to uninvolved editors. If you don't follow the process outlined at WP:RFC, then that advertising never happens, and it's not an RFC. I have removed the misleading "RfC" label from the section heading. WhatamIdoing (talk) 19:09, 20 September 2026 (UTC)
Resolved. — MWFwiki (talk) 21:13, 20 September 2026 (UTC)
Option 2 or Option 3 — I feel we should go with option 2 or 3, as I don't care for the current ambiguity and I fail to see how a clearer guideline in either direction could cause issues. If it does? We can always gain consensus to change it back. — MWFwiki (talk) 22:12, 19 September 2026 (UTC)
Bad RFC. Sigh. This is just a broader version of the citation RFC that just closed. -- LWG talk (VOPOV) 22:18, 19 September 2026 (UTC)
Per the the closer's commentary: "Nevertheless, the discussion did not establish consensus on whether WP:NOLLM currently prohibits all LLM-assisted citation formatting or whether accurate, carefully checked citations should attract sanctions. While this RfC rejected adding a written exemption, it should not be read as resolving either of those questions" — I would argue that, at least in-part, this is one of the questions this RfC seeks to resolve, as citations are WT. It also asks if explicit prohibition is not the best course of action. — MWFwiki (talk) 22:22, 19 September 2026 (UTC)
I guess if we need another whole RFC to determine that no consensus for change 5 days ago means consensus for status quo now, then Option 1. I still wish we could just have a couple scoops of ambiguity tolerance in our morning cereal and not open RFCs every time we think of an edge case. Options 2 and 3 will both cause problems and have little to no benefit. -- LWG talk (VOPOV) 22:32, 19 September 2026 (UTC)
Please do not ping me to a discussion I have been active in less than 24 hours ago and whose existence I am clearly aware of. Gnomingstuff (talk) 23:30, 19 September 2026 (UTC)
Why would I assume you to be "clearly aware" of an RfC on a different page and in a RfC you have never been "active in"? Regardless, I'm happy to respect your preferences moving-forward. — MWFwiki (talk) 23:45, 19 September 2026 (UTC)
Nevertheless, Option 1. The simpler the guideline, the better, and frankly "Don't use AI" would be an improvement on what we have now, because it would put an end to the endless attempts to undermine the guideline at any possible perceived weak point. Gnomingstuff (talk) 23:32, 19 September 2026 (UTC)
"'Don't use AI' would be an improvement on what we have now[...]" — unless I'm misunderstanding you, then don't you mean option "3"?  — MWFwiki (talk) 01:12, 20 September 2026 (UTC)
How does adding more clauses to the existing guideline make it simpler? —ClaudineChionh (she/her · talk · email) 01:21, 20 September 2026 (UTC)
It makes the guideline technically "more complicated" as one is adding text to it, but it makes the enforcement practices easier (it codifies that the only use of LLMs are in the explicit exceptions) and takes-away an oft-used excuse that individuals like to seemingly use when confronted over AI use. It doesn't need to be overly-verbose. "LLM-use to produce or format wikitext is prohibited." — MWFwiki (talk) 01:26, 20 September 2026 (UTC)
I mean option 1. I'm not actually proposing to rewrite the guideline, as much as I think it would improve matters. Gnomingstuff (talk) 06:43, 20 September 2026 (UTC)
I think "re-write" is a strong term. The prohibition could be a small blurb, "LLM-use to produce or format wikitext is prohibited."  — MWFwiki (talk) 18:15, 20 September 2026 (UTC)
Option outcome of Wikipedia:Village pump (policy)#RfC: AI use for generating citations within articles, lest everyone repeat the same points made there and in subsequent discussion again. CMD (talk) 23:36, 19 September 2026 (UTC)
Option 1 per Gnomingstuff and the previous rfc. —Leaf.Sheap ⇖ /.°°.\ ⇗ (They•Them) 00:05, 20 September 2026 (UTC)
Option 1 - per Katzrockso in the original discussion linked. InfernoHues (talk) 00:34, 20 September 2026 (UTC)
Option 1 – The stalwarts at AINB are overworked and burnt out. They don't need their time consumed by endless relitigation of previous RFCs. —ClaudineChionh (she/her · talk · email) 01:20, 20 September 2026 (UTC)
Option 1. No change. We don't need to incentivize people to do it wrong (as explicitly allowing it would entail) - but if you do it right no one will ever notice! This is not an issue! PARAKANYAA (talk) 01:30, 20 September 2026 (UTC)
Maybe we can add after the bit on LLMPRV on a new line

Editing Wikipedia is often challenging at first; newcomers may find help pages and this brief summary of policies and guidelines useful.

Kowal2701 (talk, contribs) 08:25, 20 September 2026 (UTC)
I'm gonna boldly add this along with Editors generally should not edit a Wikipedia edition whose language they are not proficient in (see Meta:List of Wikipedias for all existing language editions). as I think I'd do it anyway regardless of the result of this RfC (been meaning to do something similar ). Anyone should feel free to revert and discuss at WT:NOLLM Kowal2701 (talk, contribs) 12:18, 20 September 2026 (UTC)
FWIW option 1, this'd get wikilawyered about a hell of a lot and lead to AINB cases getting bogged down even more than they already do, for otherwise minimal benefit Kowal2701 (talk, contribs) 12:50, 20 September 2026 (UTC)
Option 1 > Option 2. Per Kowal and LWG and in support of our slop-fighters. I would very strongly prefer a nuanced guideline but having read some of the AINBs, I can see the hardship that would create. I would like to see the guideline improved so that the slop fighters don’t need to use essays at AINB but will leave that for another discussion. Dw31415 (talk) 04:04, 17 October 2026 (UTC)
Option 1 - per Claudine, Gnoming, and everything else that's been said in all of the other discussions. ‑‑gurkubondinn 08:33, 20 September 2026 (UTC)
Option 2 per my comments above and in the previous RFC. Policies and guidelines should mean what they say and say what they mean. Thryduulf (talk) 10:09, 20 September 2026 (UTC)
Option 1 - Is the current guideline perfect? No… but… we have been over this again and again. It reflects current consensus. My suggestion is that we give it time… we need to see it in action and chart its flaws. After (say) 6 months to a year we will better know what needs to be amended. Blueboar (talk) 12:16, 20 September 2026 (UTC)
Option 3 or option 1, and it would be nice and further Wikipedia's unique approach to AI to not allow AI posts on talk pages or in discussions. Randy Kryn (talk) 12:22, 20 September 2026 (UTC)
it would be nice and further Wikipedia's unique approach to AI to not allow AI posts on talk pages or in discussions Just FYI this is already more-or-less the case. -- LWG talk (VOPOV) 17:07, 20 September 2026 (UTC)
Option 1 per LWG above and at the original discussion NicheSports (talk) 13:55, 20 September 2026 (UTC)
Option 3, the less AI the better. It may start with formatting, then... As they say First They Came for formatting, and we did not speak... Yesterday, all my dreams... (talk) 15:31, 20 September 2026 (UTC)
Option 1 or 2. Using an LLM to format wikitext is already allowed per the guideline:

Editors are permitted to use LLMs to suggest corrections to their own writing, and to incorporate them after human review. This is limited to spelling, punctuation, capitalisation, grammar, and other simple mistakes.

We could tweak this to call out formatting specifically but I don't feel strongly either way. Anne drew (talk · contribs) 19:07, 20 September 2026 (UTC)
option 1 not required. I also agree with other editors that this will only result in more wikilawyering. -- LCU ActivelyDisinterested «@» °∆t° 20:09, 20 September 2026 (UTC)
Option 1 to avoid more wikilawyering. A carveout for wikitext formatting may be used by editors arguing (or being advised by LLMs to argue) that large content additions inside, say, templates would be acceptable as only "wikitext" was edited, and more generally encourage editors to rely on AI to make such changes. Minor formatting (e.g. consistently italicizing genus/species names) already falls under basic copyediting and shouldn't be an issue. Chaotic Enby (in solidarity · talk · contribs) 20:27, 20 September 2026 (UTC)
Option 1 as per Chaotic Enby. * Pppery * it has begun... 21:28, 20 September 2026 (UTC)
Option 1 – Does not make sense for consensus to go a different way here than it did for the citations RfC. Also little to no benefit. Every sentence added to WP:NOLLM enables more wriggling/wikilawyering and has WP:BEANS issues. Editors who are capable of using LLMs to format wikitext are already not being sanctioned, because nobody can tell that they are doing it due to the results of formatting wikitext with and without an LLM are indistinguishable when done correctly. –Maltazarian ᚾparleyinvestigateᛅ 10:11, 21 September 2026 (UTC)
Option 1. Honestly, if I were to write a "nutshell" for NOLLM, it would be something to the effect of "If anyone can actually tell that you're using an LLM, you're using one in a way you shouldn't be." If a human editor really is carefully checking over the LLM output, and changing it as needed, the final result will be indistinguishable from something they wrote themself. (Why they wasted time with the intermediate step is a separate question, but in the end I don't care how the sausage got made.) If anyone is able to tell that an LLM was used to generate something, then whoever generated it is doing it wrong. So, if someone uses it to generate an infobox, and actually carefully double checks that the output is correct, how would I know the difference between that and them doing it themself? Seraphimblade Talk to me 12:17, 21 September 2026 (UTC)
The issue is that this isn't want the policy says and as has been noted several times, this view is not universal. There are editors who do care about how the sausage is made and believe that any use of an LLM, detectable or otherwise, is prohibited. Thryduulf (talk) 12:23, 21 September 2026 (UTC)
Thryduulf, in the end, what practical difference does that make? If something looks like you wrote it, it's not like I'm going to stand over your shoulder and watch what you do on your own machine. And realistically, if someone wrote a bunch of fake citations up completely by hand, that in itself would be a problem too. Seraphimblade Talk to me 16:46, 21 September 2026 (UTC)
I completely agree with you that if you can't tell it shouldn't matter. My point is only that (a) not everybody does agree with this (as I understand it, they see it as a point of principle) and (b) the policy does not currently say that. The latter means that those who disagree with us can (and per other comments in this discussion, do) point to the policy and say it backs their viewpoint. If there is a community consensus in favour of the view you and I hold then the policy should say that. Thryduulf (talk) 17:06, 21 September 2026 (UTC)
French Wikipedia recently changed their AI policy to prohibit LLMs, except for copyediting and when the content is PAG-compliant (with lots of caution stressed). We can see how their experience with that goes ig, but yeah for some it'd be a non-starter Kowal2701 (talk, contribs) 18:38, 21 September 2026 (UTC)
If a human editor really is carefully checking over the LLM output, and changing it as needed, the final result will be indistinguishable from something they wrote themself.
This. While I don't think this should be added to the NOLLM page (as per others, "wikilawyering"), if someone decides to use AI to help with their edits but review its suggestions before publishing, then the end result would not look like a LLM wholesale wrote it (and thus should not warrant a user warning). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:48, 26 September 2026 (UTC)
Option 1: Editors should use their best judgement as to whether they should use AI to format (but not add content) wikitext, although this should be strongly discouraged for new editors who are not familiar with many of Wikipedia's policies. If we want this change then I suggest adding "formatting of wikitext" into point 1 of NOLLM (ie copyediting), while making sure the changes it has made has been adequately/reasonably reviewed (through using the "Show changes" button before publishing). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:28, 26 September 2026 (UTC)
Option 2, even though I sense that we are at an impasse of insincerity. I agree with MWFwiki and Thryllduff that polities should mean what they say. The desirable solution is to minimize, carefully review, and assign editors full responsibility for Wikitext formatting that is LLM-assisted. We should explicitly carve out non-disruptive formatting from either the policy altogether (my preference) or from enforcement by banning (a reasonable fallback). I'll share process comments below.--12:56, 27 September 2026 (UTC) — Preceding unsigned comment added by Carwil (talk • contribs)
Option 1: Wikipedia must not allow AI at all at any stage. I don't want any thing even least questionable.
Clear Judgement:
Research your topic, collect references, write article in your own way, read thoroughly the references before citing them. No use of AI at all. If a person has grammar and language weak, why are so many other editors for? Let them correct the grammar. JyotiTheLightHouse (talk) 20:53, 27 September 2026 (UTC)
Respectfully your proposal is unable to be enforced in this present reality and universe, so there's really no benefit or value beyond moral positioning with no effectiveness in even trying to normalize or popularize it (being honest).
How would anyone know if an editor asked GPT or another tool, "Find me WP:RS academic sources about XYZ, and why they're good for XYZ on Wikipedia," and then building an otherwise normal article about it by hand, with the tool collecting the "material" for them? How can I prevent or detect if you found the last WP:RS you added to an article by hand in Google or at the physical library, versus asking an app? — VPP (t/c) 15:56, 28 September 2026 (UTC)
Also how would you tell if I checked the spelling with a spellchecker that used AI or with a spellchecker that didn't use AI? Especially as I don't know that. Thryduulf (talk) 20:16, 28 September 2026 (UTC)
I suppose we could tell if we had you etch it with a chisel and hammer upon stone with a trusted witness at minimum seeing the livestream. Make sure you also don't engage in folly like asking GPT to "tell me more about XYZ" that you're curious about on the train to work, in case you may edit about XYZ later in the evening - as someone invariably says in one of these, got to keep the contamination more or less at bay.
I just we had actual real standards that were plausible, as the integration of these tools is increasing by the month. — VPP (t/c) 00:42, 29 September 2026 (UTC)
It's very plausible to not use AI. I manage to not use AI every day. Until 2023, billions of people managed this as well. Gnomingstuff (talk) 08:07, 30 September 2026 (UTC)
Sure, but expecting ideological purity doesn't keep us in editors in the real world where these things are increasingly shoved at us without transparency for non-technically savvy people, and does the longevity and ultimate fate of the site outrank any of our ideologies?
We have to deal with the world we live in. This is why I keep asking these "Are we sure we're right?" kind of questions in these. I'm not sure and I suspect we're shooting ourselves in the face possibly. — VPP (t/c) 16:07, 30 September 2026 (UTC)
I see the existential threat of AI to Wikipedia as sort of a reverse Pascal's wager. If LLM capabilities drastically improve in the next few years, Wikipedia will become unnecessary, since people will be able to just ask their LLM for the sorts of information Wikipedia currently provides. At that point the ultimate fate and longevity of Wikipedia doesn't matter: mission accomplished, all humans have access to all published human knowledge, we can all quit editing and go garden or hike or play Candy Crush or whatever floats our respective boats. But if LLM capabilities don't drastically improve in the next few years, the AI bubble will eventually pop, and in that scenario it will be incredibly helpful if we have preserved a repository of human-written and human-curated information for people to turn back to once the AI is gone. -- LWG talk (VOPOV) 17:38, 30 September 2026 (UTC)
Wikipedia will become unnecessary, since people will be able to just ask their LLM for the sorts of information Wikipedia currently provides.
The thing is that LLMs if you investigate their training relies absurdly heavily on us. Our content is the direct baseline feeder system for those. — VPP (t/c) 17:43, 30 September 2026 (UTC)
Brilliant, in that case add "At least our volunteer hours helped make some tech bros rich" to the top right square of the payoff matrix. -- LWG talk (VOPOV) 19:47, 30 September 2026 (UTC)
I know. I don't like it. But it's also the reality we're stuck with, and if the overall consensus is "fuck off LLM", then that's what it is, but every iterative jump on their capabilities as of now is going to drive them to be further integrated all over if loser rich people think it can make them richer. This is going to be argued endlessly here. My only position is that whatever standard we have needs to be realistic versus what is happening in the world, versus what we want to have happening in the world. Ideology is of no value if it can't achieve anything. — VPP (t/c) 20:12, 30 September 2026 (UTC)
this assumes that iterative jumps are inevitable, and there's no reason to think that -- GPT-6 has completely shit the bed in terms of quality/detectability, it's kind of funny how instantaneously it reverted to being obvious Gnomingstuff (talk) 14:51, 1 October 2026 (UTC)
I am pessimistic about many things but optimistic there will always be a demand for human-written content, regardless of how "good" AI becomes. The project has no purpose other than meeting that demand. NicheSports (talk) 17:57, 30 September 2026 (UTC)
(Niche beat me to this) It's also product differentiation, there's the possibility that human writing will have some sort of premium attached to it, and that there'll always be demand for this even if greatly reduced. LLMs also provide their info in a (mostly) contextless environment that's very unnatural, and they'll always hallucinate some of the time. At least w Wikipedia it's content production process is intuitive which makes it easier for readers to treat critically, and it cites its sources anyway. Wikipedia will likely lose the traffic wherein people are just looking up a fact (admittedly most of our total traffic), but retain traffic wherein people actually want to read and learn about a topic (also serendipity, dependent on new features that help people explore the wiki). Kowal2701 (talk, contribs) 18:05, 30 September 2026 (UTC)
Boy was this part of the thread a rollercoaster of emotions. I’d like to think that the level of care that the average committed editor puts into their work here, combined with the unique qualitative difference in information conveyance our work produces would earn us some street cred in an increasingly cold, output-/payoff-centric world. But I think that we end up spending far more time still fighting amongst ourselves about how to protect ourselves from irrelevancy (a discussion that, from what I can tell, has been taking place for the better half of the past two decades) than we do actually considering the problems that need addressing here and now to ensure that we don’t ultimately make ourselves irrelevant by stubbornly clinging to a societal framework (both on- and off-wiki) that no longer functions, because that society (off-wiki) no longer exists.
TLDR: I’m sorry this was egregiously long but I need to get the point across that we’ve run out of time to keep getting into the same old fights. It’s time we realize that if we fade into irrelevancy, it will be because we tore each other apart over particularist notions of how we’d fight the final battle, instead of trying to unite behind a cohesive vision of what we actually want this community to be in advance of it.
Best to all,
CSGinger14 (talk) 10:16, 18 October 2026 (UTC)
Option 1 or option 3. There should be a clear line drawn between asking an LLM to suggest minor corrections or stylistic improvements for the human editor to review (which is fine), and asking an LLM to reformat or rephrase text (which in some cases may open up the possibility that the LLM may introduce errors or hallucinations). My understanding of NOLLM is that it currently permits the former and does not permit the latter, which I think is appropriate. I would not object to rephrasing the guideline in such a way as to make it clearer that AI cannot be used to reformat, rephrase or add references to human-written text. Dionysodorus (talk | contribs) 01:01, 29 September 2026 (UTC)
Option 1: Why is this RfC necessary? It's become clear that LLMs can't be trusted for anything, even for minor stuff. Lazman321 (talk) 16:02, 29 September 2026 (UTC)
The RFC is necessary because not everybody shares your opinion. Thryduulf (talk) 18:14, 29 September 2026 (UTC)
Do you think we can trust the hallucinating LLMs with formatting wikitext? Lazman321 (talk) 20:11, 29 September 2026 (UTC)
Exactly how much are we assuming AI hallucinates exactly, these days? Which model, which vendor, which thinking level, commercial or free? — VPP (t/c) 20:23, 29 September 2026 (UTC)
All LLMs hallucinate. All of them. The only reason I'm not voting option 3 is because I'm concerned with how we'd be able to enforce it. Regardless, you're better off formatting wikitext manually than having to oversee the output of any LLM. Lazman321 (talk) 20:31, 29 September 2026 (UTC)
"The only reason I'm not voting option 3 is because I'm concerned with how we'd be able to enforce it." - Frankly, this should not be a consideration. Anyone can raise this concern about any proposed policy addition or modification. How we enforce a policy comes after. We adapt to our needs. Regardless, enforcement would be simple, in my view: either an editor admits to LLM-use in wikitext formatting or they (the LLM) leave obvious tells. That's a violation. If neither of those situations occur, then it's not a problem because no one knows, anyways. An explicit policy prevents wikilawyering from either way. As I have pointed out, there are those that already believe this is prohibited. This RfC will actually serve as community consensus that this practice is NOT prohibited if it is closed as option 1 (likely) or NC, as many folks have indicated, so.  — MWFwiki (talk) 00:26, 4 October 2026 (UTC)
Do you think we can trust the hallucinating LLMs with formatting wikitext? Yes, if the output is checked by a human and, if necessary, corrected. While every LLM is capable of hallucinating, not everything output by an LLM contains hallucinations. Thryduulf (talk) 22:40, 29 September 2026 (UTC)
Option 2: As much as I hate AI on this site and as a writing aid more broadly, I think this is one instance where it offers some measure of necessary accessibility to editors. My concern is its use by inexperienced ones, who will almost certainly be unable to discern what if any mistakes the system has made before ultimately publishing the contribution. Nevertheless, systems like Wiki markup are a nightmare for people with visual processing disorders.
With that in mind, I'd argue that WP:ACCESSIBILITY takes precedence, though we need to really think about the way this would actually be implemented. Perhaps a caveat stating that such rules only apply to extended-confirmed editors, or some other pre-qualification?
CSGinger14 (talk) 07:21, 30 September 2026 (UTC)
Option 1, failing that 3. It's Wikitext. It shouldn't require LLMs to format properly. XtraJovial (talk • contribs) 10:30, 30 September 2026 (UTC)
Option 1 as the only viable option; LLMs seem to not be particularly good at Wikimarkup to begin with. This is like asking if a shark can swim backwards. (I don't read the passage that Anne Drew points out as allowing use of it for Wikitext; I read that more as allowing it for simple SPaG issues.) —Jéské Couriano v^_^v Look out it's Jimothy! 18:13, 30 September 2026 (UTC)
Option 1. LLM usage in such a context simply causes far more problems than it is worth. 'Caveats' achieve almost nothing, when they are so frequently either not read, or used as an excuse to engage in practices they are supposed to prohibit. AndyTheGrump (talk) 15:03, 1 October 2026 (UTC)
Option 1 as Option 2 nullifies the most obvious and commonly used AI tells (triple `s, markdown, WP:AITABLE, etc). All of these are essentially formatting tells, and any change allowing AI for markup would provide AI users with a very convenient excuse. In fact, I would be fine with Option 3 as a second choice, since we get this excuse too much already. Personally, I would find it very suspicious if someone has enough time to "write" their own content addition, but not to learn WP:VE. Somepinkdude (talk | contribs), in solidarity 20:24, 3 October 2026 (UTC)
Option 2. "with the caveat" is sufficient for me. It's just a tool. Use it responsibly, move on. --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:05, 10 October 2026 (UTC)
I would agree with you, but given recent developments on AI (including rouge agents), I can't really choose option 2. And unfortunately, humans are just that stupid. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 02:18, 10 October 2026 (UTC)
@Hason-LEK-SIN We can of course agree to disagree, but I don't see the rogue agent problem relevant here? AIs are becoming more powerful, which also means they are becoming less error/hallucination-affected, so to me that is actually argument for, not against, the tools becoming useful. Ditto for Deaths linked to chatbots - as in, I don't see the relevance? (on the side note I wonder if Deaths linked to Wikipedia is a valid topic to research... :/). Piotr Konieczny aka Prokonsul Piotrus| reply here 02:50, 10 October 2026 (UTC)
Sorry, that was more of a ( peanut gallery comment), though for the chatbot deaths, it was meant to show "many humans blindly follow what AI says", so explicitly telling people that you can use AI for formatting wikitext may make people blindly copy-paste the AI's output. Then again, there's "the caveat that the user is responsible for ensuring it is non-disruptive and publishes without error.", so perhaps that might satisfy your option. Again, it was more of a passing thought, and I apologise. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 02:56, 10 October 2026 (UTC)
@Hason-LEK-SIN How would you feel about a requirement of the sort I proposed above?
CSGinger14 (talk) 07:45, 10 October 2026 (UTC)
Option 2 While I was generally not in favor of the original LLM ban, I could at least see the position of those who defended it against the risk of hallucinations, etc. However when it comes to wikitext formatting and creation, I don't see how these concerns apply more than any other "traditional" tool. If LLMs are not even allowed for formatting, then I will personally withdraw myself from English Wikipedia fully: I like contributing to the encyclopedia, but to the content, not to the format. Also I disagree with those who say that the current ambiguity is not a blocker for good quality edits/well intentioned contributors; for example, this proposal to automate the creation of infobxes is likely to become blocked because of the lack of clarity of the current policy as to whether it applies to the creation of infoboxes. 7804j (talk) 16:13, 10 October 2026 (UTC)
That proposal to generate infoboxes would likely be blocked regardless of the outcome here, because the proposal went beyond formatting wikicode into using an LLM to extract the information from the articles. -- LWG talk (VOPOV) 23:04, 10 October 2026 (UTC)
Option 1. There are plenty of circumstances where rote automation is fine, just like you'd use WP:AWB or bots. But I also want to avoid Option 2 for WP:BEANS reasons. Thebiguglyalien (talk) 00:51, 11 October 2026 (UTC)
I vote Option 2. If AI is only being used to format code correctly, I fail to see any issue. In fact, I have done it myself several times. CoolDino1 (talk) 19:51, 15 October 2026 (UTC)
Option 2 per my comments here and in previous RFCs/dicussions. In particular, the current state seems undesirable, unenforceable, and unsustainable. I'm willing to wait to see when/if it becomes OBE by the adoption and hundreds of billions advancing the art, but some forward-thinking by WP seems advisable. Also, generally I would prefer this area follow more the norm of WP:Policies and guidelines, especially WP:GUIDELINES, to be about what to do and how to do it and less about banning things and penalties. Finally, I would prefer it based on facts rather than vague fears of AI delusion or idiot users and AINB being overloaded. Can we at least be fact-based, say by looking at empirical examples in AINB of what the efforts actually are like and limit the ban or gate to specific kinds of usage or give guidance on how to use it properly ? e.g. When someone tried to enter a BLP complaint about the article on themself but got rejected because it looked AI why was that even a discussion and what else is wasting AINB time ? In general we should also face realities that AI use is becoming ubiquitous and unavoidable - your life depends on how doctors already use it, cited journals already use it as well as the submitting "authors", businesses seems pushing use everywhere they can, universities are producing policies about it -- can we maybe start seeking suggestions and data a bit more ? Cheers Markbassett (talk) 20:43, 20 October 2026 (UTC)


Discussion regarding wording of a proposed exception or prohibition

Prohibition proposal: "Use of an LLM to produce or format any form of Wikitext is prohibited. For example, this prohibition includes but is not limited to: utilizing an LLM to wikilink, create citations, create infoboxes, etc."

Exception proposal [to become point "3" of NOLLM: "LLMs may be utilized to assist users in generating Wikitext, to a limited extent, and all work must be checked thoroughly before final publication. Such exceptions include basic and simple tasks, such as adding Wikilink bracketing, crafting an infobox, etc. Users are still responsible for 'hallucinated' or otherwise false content and are responsible for ensuring all of their inserted content publishes without error." — MWFwiki (talk) 22:20, 19 September 2026 (UTC)

My issue is that wikitext needs to be clearly defined if not wikilawyered. Is everything we type not technically wikitext too? Katzrockso (talk) 01:08, 20 September 2026 (UTC)
Well, we could call it wiki-markup. But WT is defined at Help:Wikitext. We could just wikilink "WT" to there. Or we could use its definition in the exception. "Text which formats the page." But indeed, your question is yet another reason we need to clarify the guideline, as people can argue "all text is wikitext" or that "all wikitext is text."  — MWFwiki (talk) 01:23, 20 September 2026 (UTC)
Many word processing programs (e.g., Microsoft Word) are now also embedding LLM-based AI functionality, as are email platforms, social media platforms, and so forth. Are we going to get to a point where any kind of application that contains a spellchecker will end up being prohibited because they are accomplishing the task with AI rather than a traditional spelling library? BD2412 T 01:25, 20 September 2026 (UTC)
Well, I would argue that this is already covered (as an exception) under the current wording of NOLLM. Basic copy-editing, spell-checking, etc. If you are asking whether I think a prohibition on the use of an LLM in formatting WT would contradict the current exception, no, I do not. Otherwise, why have explicit exceptions at all?  — MWFwiki (talk) 01:34, 20 September 2026 (UTC)
It's covered if you actually use it for "copy-editing, spell-checking" etc.
E.g., if you copy paste a proquest header (citoid usually does not work with proquest), with the source details (title/publication/date/volume/issue/page/location/author/etc) into an LLM and ask it to format it into wikitext cs1 templates and make no other changes, then check it after. I've tested this out offwiki and it worked basically perfectly and any hypothetical errors would be easy to catch (LLMs tend to make stuff up less when they're working directly with a small amount of text you give them). I see no problems with that basic usage, and there's no way to tell the difference - unlike with generating new prose.
However, explicitly saying it is allowed will make some people who don't know any better use it to generate full citations, which is totally problematic, and to defend themselves against sanction that way. PARAKANYAA (talk) 13:57, 20 September 2026 (UTC)
I was discussing prohibiting (formatting wikitext) in the thread you replied to. Again, if the concern is your last sentence, why have explicit exceptions at all? It's either used well and it's no problem and no one knows... or it causes an issue. Very generally speaking, at least. The current guideline is already overly-ambiguous and ripe for wikilawyering  — MWFwiki (talk) 18:13, 20 September 2026 (UTC)
Because having no exceptions will make people go the opposite way and attack people for mundane, correct uses that are baked into all spellchecking programs. If you use a modern program with a spellchecker you are "using AI" - the problem is letting it rewrite larges swathes of text. PARAKANYAA (talk) 14:01, 21 September 2026 (UTC)
The issue is proving it, short of an admission. LLMs are getting better, slowly, but they are getting "better." A year ago, it was extremely obvious when an LLM was used. I feel those days are waning (though they are not completely gone, to be clear). Regardless, having no exceptions isn't on the table, so I suppose the point is moot. My argument is simply that virtually nowhere else is having clearer, less-ambiguous guidelines an issue. Funnily enough, the way this RfC is heading, its consensus can be used to show that there is no prohibition against formatting wikitext, the community simply does not want to codify it... nevertheless, the consensus is there.  — MWFwiki (talk) 18:49, 21 September 2026 (UTC)
There is no prohibition against formatting wikitext, the community simply does not want to codify it... Precisely this: acceptable types of formatting are already de-facto permitted under the current guideline, so codifying an exception accomplishes nothing except encourage wikilawyering in support of unacceptable types of formatting. If you have to ask which side of the line a particular use case falls on, it probably falls on the prohibited side. In the rare case that someone is asked to stop using LLMs even though they would have used them responsibly, the mild inconvenience to that person is a more than worthwhile cost to pay for the streamlining of the slop cleanup process. It's just like our rule about disclosing conflict of interest: COI editors are required to disclose their COI. Yes, they could theoretically make non-controversial edits to their pages without disclosing, and if their edits really are non-controversial they are unlikely to be sanctioned for it, but the COI guideline doesn't and shouldn't say "you don't have to disclose as long as you only make totally non-controversial edits", nor is it acceptable to waste our time arguing that your particular undisclosed COI editing was fine. -- LWG talk (VOPOV) 20:20, 21 September 2026 (UTC)
Personally, I'm leaning towards codifying a prohibition, but that is neither here nor there. Maybe I'm dumber than I thought, but I just can't wrap my head around not wanting to codify an exception that there is clearly consensus for... while simultaneously arguing (not you) that wikilawyering will be an issue if we clarify the guideline. I understand your COI analogy, but we decide these things independent of each other.  — MWFwiki (talk) 21:02, 21 September 2026 (UTC)
As I've discussed in my essay on addressing problems without creating new specialized rules, it's impractical to codify all guidance. As far as reasonably possible, it's better to lay out general principles to be followed. As I discussed previously, the general guidance is that guidance about content is about what the reader sees: the rendered HTML output. There's no special exception for one type of tool being used to generate the underlying wikitext. Guidance on using wikitext (like how to format lists) explicitly refers to wikitext. isaacl (talk) 22:02, 21 September 2026 (UTC)
this slope is so slippery it has ceased to be a slope and is now just straight oil Gnomingstuff (talk) 03:10, 20 September 2026 (UTC)
Was it ever realistic for anything like a hard ban to be viable? — VPP (t/c) 18:41, 22 September 2026 (UTC)
Reading these evolving discussions I'm more worried over time that we're being ideological rather than realistic. Your examples of AI-native tooling getting embedded into so many products is a perfect example. — VPP (t/c) 18:40, 22 September 2026 (UTC)

Most writing-related guidance on English Wikipedia focuses on the rendered HTML output, rather than the wikitext source, since that's what affects reader experience. Historically, tools have generated wikitext through a deterministic process, whether it is using templates, Visual Editor, or off-wiki tools filling in skeletons based on some data source. With a generative tool, though, the result is produced through a black box that no one explicitly programmed. If there is a consensus that the risk of users not verifying the result is greater that the benefit of using such tools, then it's not clear to me how to carve out a set of allowable uses in a practical way. Although it might be the case that a user is less likely to check the result of a generated infobox than a single verb tense change, I think there is a point where the probability of that user checking a mass set of grammar and spelling changes starts approaching the same level. isaacl (talk) 18:10, 20 September 2026 (UTC)

Process comment: As with the prior RFC on LLM-assisted citations, we have a substantial set of editors !voting to keep the policy as it is (Option 1 here; No on the prior RfC) with the understanding that non-disruptive LLM-assisted Wikitext formatting will not get anyone in trouble. And we have another substantial set of editors arguing to keep the policy as it is with the understanding that any LLM-assisted Wikitext formatting should get editors in trouble. Resolving this tension is what I take to be MWFwiki's purpose in opening the RFC.

To put too fine a point on it, these are statements in this and the prior RFC that are all in the prior camp:

The impasse that we stand in is that some editors believe that no written change (Option 1) means that the policy is effectively Option 2 (in competently executed cases) -- presumably those quoted here -- and others believe that no change means the policy is effectively Option 3. I'm not sure how to get out of this impasse, but do think that we should use this RFC to do so.--Carwil (talk) 13:02, 27 September 2026 (UTC)

Our votes for status quo aren't motivated by a misunderstanding of what the status quo is, they're motivated by the understanding that the status quo includes some useful ambiguity and reasonable restraint in enforcement while leaving no excuse for defending AI text when it is challenged. This status quo is better than what we'll get if we adopt either of the other options proposed here. -- LWG talk (VOPOV) 14:12, 27 September 2026 (UTC)
That's not the issue. The issue is that two groups of people are voting to support the status quo based on different interpretations of what the status quo allows. That is not "useful ambiguity", that is bad policy that allows for inconsistent enforcement and biting of good faith editors. Thryduulf (talk) 14:36, 27 September 2026 (UTC)
I just re-read all the votes and I'm not seeing this "substantial set" of editors with the "status quo is option 3" interpretation? Every single Option 1 voter appears to broadly agree with my position. -- LWG talk (VOPOV) 15:42, 27 September 2026 (UTC)
It seems pretty clear that Gnomingstuff's !vote (plus comments here: Wikipedia_talk:Writing_articles_with_large_language_models#Proposed_reword) is based on reading Option 1 as implying that Option 3 is already in effect; their opinion was seconded as well. Numerous examples in the citation RFC. Ditto this essay.--Carwil (talk) 16:53, 27 September 2026 (UTC)
I can see how you could read it that way, but based on my experience of Gnomingstuff's cleanup activities and comments re sanctions on ANI, I don't there's actually much gulf between our interpretations of the status quo. Gnomingstuff is of course welcome to correct me if I'm wrong. I would argue that WP:YESLLM is broadly consistent with all the Option 1 votes, especially Seraphim's nutshell "If anyone can actually tell that you're using an LLM, you're using one in a way you shouldn't be." That essay also doesn't really address the question posed here (wikicode formatting) except to say that if your "formatting" is introducing new words to the article text, it's not just formatting (which I think we all agree on here). -- LWG talk (VOPOV) 00:12, 28 September 2026 (UTC)
I have no idea what you are talking about re: ANI but my stance is pretty much identical to PARAKANYAA's, with the added point that since there is often a language/competency barrier with people who use AI, we do not need to carve out more exceptions to be misinterpreted (which already happens all the time with people claiming their substantive rewriting is just "copyediting"). Gnomingstuff (talk) 13:58, 28 September 2026 (UTC)
I have no idea what you are talking about re: ANI maybe I'm misremembering the venue but I seem to recall you contributing to discussions of sanctioning LLM-using editors and I can't remember you ever calling for sanctions on an editor who was just using the LLM for non-semantic tasks like formatting wikicode. -- LWG talk (VOPOV) 00:03, 29 September 2026 (UTC)
I don't usually call for sanctions in general unless there's a behavioral issue as well, like if someone is continually lying or sealioning about it Gnomingstuff (talk) 10:17, 29 September 2026 (UTC)
Also see my comment here regarding Gurkubondinn's statements (which I think I shared with you, already, and I apologize if that is the case) which led me to start this RfC. Clearly there are editors that believe option 3 is the status quo (and are supporting option "1" in-support of that status quo). Tagging @Carwil — MWFwiki (talk) 19:45, 28 September 2026 (UTC)
Honestly, I'm really gratified to see that Gnomingstuff might have the same general intuition here, though I walked away from our 9 September conversation with the opposite impression. I really, really get the concern about wiggle room being an invitation to un-monitorable content. But I also think a lot of long-time contributors, myself included, take the letter of prohibitions and the possibility of a ban after many years of contributing as very serious signals. Clarity matters to us. I, for one, am not contributing with the kinds of tricky Wikitext formatting edits that I could do (and did do) before WP:NOLLM was passed (like this one). Let's try and get creative about how to enable this understanding without opening the floodgates for slop. Maybe an autoconfirmed status as stage gate? Maybe a formal limitation on banning that requires actual damage to the content of the encyclopedia?--Carwil (talk) 23:06, 28 September 2026 (UTC)

Let's try and get creative about how to enable this understanding without opening the floodgates for slop. Maybe an autoconfirmed status as stage gate?

See below. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:47, 28 September 2026 (UTC)
a lot of long-time contributors, myself included, take the letter of prohibitions and the possibility of a ban after many years of contributing as very serious signals. Maybe I'm naive, but it's hard for me to imagine anyone in this conversation advocating for a ban of someone who was editing in good faith, doing no damage to the encyclopedia, and willing to follow the discuss part of Bold, Revert Discuss when challenged. -- LWG talk (VOPOV) 23:51, 28 September 2026 (UTC)
Given that people have seriously argued that all AI use is, in and of itself, damaging to the encyclopaedia and that using an AI to edit Wikipedia is evidence of bad faith, I truly can see people advocating for the banning of editors using LLMs. Thryduulf (talk) 00:12, 29 September 2026 (UTC)
Then again the general vibes on AI to a sizable amount of people on the internet (not just people on the encyclopaedia) is "any AI use is bad, just get rid of it already" (keyword: any). Sigh, if only they knew it was not just for LLM chatbots and AI generated media/"slop" (after all, it is other humans that are producing the slop, so, who to blame?). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:17, 29 September 2026 (UTC)
The comment I was referring to was not Gnomingstuff's, but Gurkbondinn's. My point was to support your argument that there were indeed additional users arguing that LLM use is currently prohibited. However, Gnomingstuff similarly indicated they want LLM-use prohibited while simultaneously arguing the guideline should not be changed. It seems obvious to me that the desire is to keep things vague so that the policy may be wielded on a case-by-case basis. I'm fine with that, personally, but I argue that even that must be codified. Something like "generally, any LLM-use, admitted or otherwise, is subject to local consensus if called into question." My contention is that there should be no ambiguity in policy and if there is, the reason for the ambiguity should be explained.  — MWFwiki (talk) 01:57, 29 September 2026 (UTC)
The reason for the ambiguity is that "generally, any LLM-use, admitted or otherwise, is subject to local consensus if called into question." will result in endless time-wasting arguments of the sort WP:YESLLM is trying to preempt, often with one side of the argument itself being walls of LLM text, but maximalist prohibition is not desirable if a lesser prohibition can prevent the slop. If we are going to clarify anything, I would focus on the clause generate or rewrite article content and consider saying something like some uses of LLMs that do not alter the article content (such as converting an existing citation from one format into another, or wrapping an image in wiki code to make it float left on the page) may be permissible, however the editor using the LLM must review the output and ensure that the LLM has not gone beyond its directive and altered the article content in any way while doing these tasks. Such non-semantic uses of LLMs should be totally indistinguishable from a human accomplishing the same task, since there is no stylistic element to tasks like plugging human-specified information into a Cite X template or pulling syntax from Help:Extended image syntax to make an image have a human-specified position on the page. If they are distinguishable as LLM output, then they probably haven't been adequately reviewed. -- LWG talk (VOPOV) 02:43, 29 September 2026 (UTC)
People have overwhelmingly !voted for the status quo, approaching WP:STICK here Kowal2701 (talk, contribs) 06:18, 29 September 2026 (UTC)
Can you please stop putting words in my mouth? If I wanted to !vote something else, then I would have done that. Gnomingstuff (talk) 10:21, 29 September 2026 (UTC)
I didn't indicate you meant to !vote anything else; could you please point-out where I did that? I had asked you earlier, admittedly. When you write things, your words are subject to interpretation.  — MWFwiki (talk) 21:24, 1 October 2026 (UTC)
Sure let's go through this one by one:
  • unless I'm misunderstanding you, then don't you mean option "3"? No, if I meant option 3, then I would have said option 3. There is no possible way to "misunderstand" 1 as 3.
  • It seems obvious to me that the desire is to keep things vague so that the policy may be wielded on a case-by-case basis. I did not say this, nor do I think this (in fact I think the opposite, interpreting things on a "case-by-case basis" results in nothing but sealioning), nor is it a charitable "interpretation" of (really just making-shit-up-about) my words.
  • It seems pretty clear that Gnomingstuff's !vote [...] is based on reading Option 1 as implying that Option 3 is already in effect. No, if I thought Option 3 was already in effect, I would have said that. As for my "comments here: Wikipedia_talk:Writing_articles_with_large_language_models#Proposed_reword", my comments were to tell you to stop vagueposting about unnamed individuals and attributing supposed radical opinions to them.
Gnomingstuff (talk) 17:16, 2 October 2026 (UTC)
People are referencing WP:IAR, it doesn't matter if NOLLM is interpreted as prohibiting using LLMs for formatting in all contexts or only when someone else can tell, the result is the same. This seems like textbook WP:CREEP to me Kowal2701 (talk, contribs) 06:49, 29 September 2026 (UTC)
( peanut gallery comment) Just to make sure everyone is on the same page, AI here refers to LLMs. Technically, AI is used to power other tools on Wikipedia, such as reverting vandalism (ClueBot) or the Editor Suggestions tool (example), but that usually falls under machine learning and aren't usually as problematic as random editors asking LLMs to generate content since they are more refined and controlled. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:08, 27 September 2026 (UTC)
I think the WP:NOLLM page may need to be restructured in a way that says:
  1. If you are a new editor, DON'T.
    • If you are scared that the output you will give will be full of grammatical errors, or if it might not be allowed, be bold and do it it yourself. Someone will visit the page and help you fix it later, or revert it painlessly and tell you about what was wrong. Your human input is more valuable than AI generated content. I swear, I saw the "human input" part on one of our guideline pages before...
  2. Once you have edited Wikipedia for long enough (typically extended-confirmed users), you are allowed to use AI for:
    1. Rough translation of articles to English,
    2. Basic copyediting, or
    3. Any other minor formatting fixes.
    • However, you should always review the output of the LLM before publishing your edits, to ensure that the content is still supported by the works cited (ie the meaning of the text has not changed).
Optionally, I also believes WP:AI needs to be a bit more detailed on how AI could be helpful other than writing articles from scratch (for example, Google AI Overviews), but that's another whole can of worms for another day to ensure that AI is still used "alongside our human knowledge/creativity, and not a replacement". Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:47, 28 September 2026 (UTC)
Option 2 — with a narrow exception. I support explicitly permitting the use of LLMs to assist with Wikitext formatting, provided that the underlying substantive content has been independently written or verified by the editor.
There is an important distinction between using an LLM to generate encyclopedic content and using it as a syntax/formatting tool. For example, converting already-written prose into Wiki markup, formatting an existing citation into a citation template, correcting template/table syntax, or fixing markup errors does not necessarily involve delegating the creation of encyclopedic content to the LLM.
I would therefore support wording along these lines:
Editors may use LLMs to format or transform Wikitext syntax for content they have independently written or verified, provided that they review the output before publication and remain responsible for its accuracy, functionality, sourcing, and compliance with Wikipedia's policies and guidelines. This does not permit using an LLM to generate or substantially rewrite the substantive content of an article.
The key safeguard should be the distinction between formatting/syntax assistance and substantive content generation. An editor should remain responsible for checking every resulting edit, including citations, templates, links, and markup. This would also avoid treating all AI-assisted editing as equivalent when the actual nature of the assistance is quite different. — Preceding unsigned comment added by BasNamRahegaAllaKa (talk • contribs) 05:53, 29 September 2026 (UTC) BasNamRahegaAllaKa (talk) 05:54, 29 September 2026 (UTC)
Struck comment from sockpuppet. -- LCU ActivelyDisinterested «@» °∆t° 22:03, 2 October 2026 (UTC)
I don't think that's the right way of looking at it. To me it appears like the camps are in agreement that if LLM-use can be detected then you are violating the guideline. If it can't be detected, then who cares whether the guideline is to be interpreted as prohibiting or allowing it? Regardless of what the guideline says, for cases of LLM-use that we cannot detect the outcomes will always be the same as if we had chosen Option 2 here. –Maltazarian ᚾparleyinvestigateᛅ 21:03, 29 September 2026 (UTC)
There are actually more than just two camps, very broadly in no particular order:
  1. LLM use should not be permitted at all as a matter of principle, whether we can detect it at all is not relevant. If someone admits to using it that's a violation and should be treated as such, even if we wouldn't have known if they'd said nothing.
  2. LLM use should not be permitted at all, but if we can't detect it then it's not worth worrying about (but don't tell anyone that)
  3. LLM use should ideally not be permitted at all, but if we can't detect it then it's not worth worrying about, and policy should be open about this.
  4. LLM use should not be permitted at all, and it's ok if are inconsistent about how we treat stuff we can't detect and policy should allow this inconsistency.
  5. Only LLM use that is actually problematic should be prohibited and policy should explicitly allow non-problematic uses, whether they are detectable or not.
Thryduulf (talk) 23:07, 2 October 2026 (UTC)
I think I'd see it a lot like the sockpuppetry policy. It is, for example, forbidden to use a sockpuppet to evade a block or ban. We realistically know, though, that if someone got blocked/banned, really did learn from that and changed their ways, and never got up to their old tricks again, chances are very good they'd never be caught (and realistically, that's probably going on as we speak). Nor would catching such an actually reformed sockpuppeteer particularly be a priority. But I would not want the sockpuppetry policy to say that, or to encourage it; it's just the reality of the situation. Seraphimblade Talk to me 23:38, 2 October 2026 (UTC)
That's fair. I disagree on a couple of points, first the sock-puppetry policy does not leave it ambiguous as to whether that is permitted (it makes it clear it is not) even if it isn't usually enforced that way - the LLM policy does not make it clear either way. Secondly I don't think either policy should work that way - we should be explicit that if you aren't causing problems then you won't be blocked on a technicality so that those who do sanction on a point of principle know that this is not the community consensus. My main point above though was that not everybody is on the same page regarding what is desirable. Thryduulf (talk) 01:04, 3 October 2026 (UTC)
On the other hand, if you discovered a sock puppet editing uncomfortably close to their old ways and they dragged you through a long argument where they first denied that they were a sock puppet and forced you to prove that, then argued that their socking should be overlooked because they've changed and forced you to show a bunch of diffs proving they haven't, and then finally argued at length that their sockpuppetry is justified because they disagree with whatever policy led to their original block in the first place, your patience would probably wear thin, and if people who walked in on the tail end of a couple interactions like that proceeded to open multiple RFC saying that policy needs to more clearly state that we should only block sockpuppets who do bad things, that would be understandably frustrating. -- LWG talk (VOPOV) 02:24, 3 October 2026 (UTC)
There are exactly four possible scenarios here, none of which require an ambiguous policy:
  1. Their contemporary editing is unproblematic and it's not clear they are a sockpuppet.
    No need to do anything - nobody benefits from sanctioning unproblematic editing.
  2. Their contemporary editing is problematic and it's not clear they are a sockpuppet.
    Deal with the problematic editing as if they were a new user doing that. Bringing socking into it will not help.
  3. Their contemporary editing is unproblematic and it is clear they are are sockpuppet.
    No need to do anything - nobody benefits from sanctioning unproblematic editing.
  4. Their contemporary editing is problematic and it is clear they are a sockpuppet.
    Deal with them for both the problematic editing and for being a sock.
None of these circumstances requires ambiguous policies, inconsistent enforcement or policies to mean something other than what they say. The project gains no benefits from any of those things in any of those circumstances.
I understand that this will sometimes be frustrating to some editors, but policy does not and should not allow us to sanction editors just because they are frustrating. Thryduulf (talk) 10:20, 3 October 2026 (UTC)
An edit is policy compliant based on what lands in the edit window and is saved. — VPP (t/c) 02:46, 4 October 2026 (UTC)
I have no idea what you are trying to say here, nor how it relates to my comment? Thryduulf (talk) 11:25, 4 October 2026 (UTC)
Sorry - what I meant was you seemed to be getting at. At the end of the day, if what is "saved" is policy compliant, there's almost no possible way to sanction an editor for such an edit based on whatever happened to get that edit created before it reached Wikipedia, if the editor simply chooses to not say "how they work".
It's that implied nebulous thing here that makes me uneasy in so many of these comments. "No AI anywhere in the entire thought process pipeline," and "editors can be stopped if they seem TOO good at the Wikipedia game" or some similar vibes. I don't know what to make of it. — VPP (t/c) 21:01, 4 October 2026 (UTC)
The thing is that editors do sometimes disclose that they used AI at some point in the pipeline. I believe that everything other than what is saved should be completely irrelevant, but some other editors do not and believe that AI use at any point in the pipeline can and should result in sanctions. Thryduulf (talk) 21:11, 4 October 2026 (UTC)
some other editors For the sake of clarity, please name these editors, so they have the opportunity to correct you if that is not actually what they believe, and so any editors you aren't talking about don't have to wonder if you have misunderstood their position. -- LWG talk (VOPOV) 00:36, 10 October 2026 (UTC)
the prohibition is on LLM-generated content, i.e. text produced by an LLM, there's nothing nebulous about that. Because LLMs are typically used habitually, AI cleanup tends to be focussed on a user's contributions within a certain time period rather than just individual edits in isolation. By extension, the focus is sometimes on how the LLM is used, in an effort to understand what we're looking at and ig address the crux of the problem. It's completely fine for people to use LLMs in their workflow for copyediting or research (along w other uses that aren't generating text), we even have an essay giving advice about those things, I'm not aware of anyone who thinks any kind of LLM use should be sanctionable and it seems to me like you're projecting (?) Kowal2701 (talk, contribs) 21:22, 4 October 2026 (UTC)
The only nebulous thing is the subject of whatever you are vagueposting about. Name names. Provide names and diffs of the people who are producing "similar vibes" to editors can be stopped if they seem TOO good at the Wikipedia game or No AI anywhere in the entire thought process pipeline.
Can't do it? That's because "so many of these comments" are not saying this. The only people who have said anything close are Laxman, JyotiTheLightHouse (which is somewhat weird since there is evidence they are contributing AI-generated content themselves), and people who are not participating in this discussion like EEng. See, look how easy it was for me to name names? See how easy it is to not vaguepost? Gnomingstuff (talk) 13:55, 5 October 2026 (UTC)
1 week later and no one has managed to identify these "similar vibes" Gnomingstuff (talk) 05:10, 12 October 2026 (UTC)
Under current policies, #3 still merits a block, for better or worse. Katzrockso (talk) 00:44, 10 October 2026 (UTC)
There was very recently an editor who seemed to have moved on from their previous negative behaviors and had positively contributed tens of thousands of edits that ended up being a sockpuppet and was blocked. Katzrockso (talk) 00:42, 10 October 2026 (UTC)
Honestly my camp would be somewhere between 2 and 3:

LLM use should ideally not be permitted at all, but if we can't detect them (can't tell they used LLMs), then it's not worth worrying about (but don't tell anyone that).

I'm emphasising the underlined point because, as what @Chaotic Enby said, to avoid more wikilawyering (using a portion of the rules in a literal manner that goes against the rule's intended message), noting that a carveout for wikitext formatting may be used by editors arguing [...] that large content additions inside templates would be acceptable as only "wikitext" was edited, and [...] encourage editors to rely on AI to make such changes. Note: quotation edited for emphasis. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 10:51, 3 October 2026 (UTC)
There is currently no agreement about what the rule's intended message is: Some believe the intent is to prohibit all AI use that isn't explicitly allowed, whether detectable or not. Others believe the intent is to prohibit prohibit only problematic AI use, with undetectable uses not being problematic. The current wording allows for people in both groups to claim that their interpretation is the correct one. Enforcement is thus inconsistent.
Separately there is also disagreement about whether explicitly allowing and/or not explicitly prohibiting something will or will not encourage people to wikilawyer about it and/or encourage people to do it. Thryduulf (talk) 11:16, 3 October 2026 (UTC)
While that makes sense in principle, I don't think it should be codified in an actual rule, very much for the reason you underline. People using LLMs are not necessarily the most qualified at realizing whether their LLM use will be detectable (or, more crucially, at spotting the errors their LLM use might introduce), and we don't want to give them false confidence that they can just sneak by.
In a way, all of our rules already operate that way: if you're editing about your company without disclosing it, but it's just fixing a broken template's formatting and no one will catch it, then it's not worrying about. But we don't make an exception for undisclosed paid editing about editing templates or wikitext, as it will only encourage people wanting to fudge company sales numbers in the infobox or add their manager in the "Key people" entry. Chaotic Enby (in solidarity · talk · contribs) 16:45, 3 October 2026 (UTC)
The comment I responded to said that there are editors voting to keep the policy as it is with the understanding that non-disruptive LLM-assisted Wikitext formatting will not get anyone in trouble. And we have another substantial set of editors arguing to keep the policy as it is with the understanding that any LLM-assisted Wikitext formatting should get editors in trouble. What I disputed was that is any difference in practice between the two camps that the comment I'm responding to have presented, not that there are different camps when it comes to how to phrase the guideline or even how the guideline should work, it was only in response to the comment I responded to. –Maltazarian ᚾparleyinvestigateᛅ 10:58, 3 October 2026 (UTC)
There is a very much a difference in practice between "doing this won't get editors in trouble" and "doing this should get editors in trouble" in this case because, as policy stands, an editor admitting to AI use but which is not detectable otherwise will sometimes get into trouble and sometimes won't depending whether the review thinks editors doing that should get into trouble or not. Thryduulf (talk) 11:10, 3 October 2026 (UTC)
But there isn't anything in the wording about whether it is detectable. To use an analogy, if you admit to fraud and no one would've caught it otherwise, you still suffer the consequences for it. The fact that undetected fraud will otherwise go unpunished doesn't matter in that calculation, beyond the fact that <not legal advice>if your goal is to not get caught, it's an odd calculation to confess to fraud that you know no one would've found out about otherwise</not legal advice>. Chaotic Enby (in solidarity · talk · contribs) 16:50, 3 October 2026 (UTC)
Plus, the determining factor in whether someone’s AI use is “detectable” is not always editor competency or advances in technology (GPT-5.6 on have actually kind of faceplanted into really obvious tells compared to predecessors) but whether the handful of people actively doing AI cleanup have gotten around to them yet.
For instance, in the LLM paste log are by now hundreds of people whose AI use is confirmed but “has not been detected” because there is too fucking much of it and only 24 hours in the day. Gnomingstuff (talk) 17:41, 3 October 2026 (UTC)
Which is precisely why I would rather not actually add any wording to the guideline about LLM-use being okay if nobody can tell you're doing it. An exception specifically for editors formatting Wikitext with an LLM with an output identical to what you would have done themselves and who then admit to doing it for some reason (which as I stated below is not something we should sanction regardless of what the guideline says) is going to encourage people to use LLMs more and then wikilawyer about it. –Maltazarian ᚾparleyinvestigateᛅ 22:17, 3 October 2026 (UTC)
I have thought of someone admitting to it out of the blue (I was going to include a clarification about this in my reply to you but I seem to have forgotten to do so), but I don't see it like you do here becaude I view an editor admitting to breaking a policy or guideline with no detectable impact on the Wiki, so no clean-up work and really nothing to actually be "fixed", as a simple case of WP:IAR; last I checked we don't enforce rules merely for the sake of enforcing them. Unless there is actually a problem with the substance edits there is nothing to sanction. –Maltazarian ᚾparleyinvestigateᛅ 22:09, 3 October 2026 (UTC)
There are two problems with this:
1) There is no way to violate WP:NOLLM without having a detectable impact on the Wiki.
2) If someone is unwilling to follow guidelines that they know full well are guidelines, then they probably shouldn't be here as they are demonstrating that they do not care about what people are asking of them. This is uncontroversially true with every other policy and guideline, and yet for some reason people think that the AI guideline is an exception. Gnomingstuff (talk) 21:10, 4 October 2026 (UTC)
1. The whole context of my comment is that there are editors who disagree with you, and that I think it is a disagreement with no practical relevance. You say that NOLLM cannot be violated without a detectable impact on the Wiki, others say that if you got an LLM to format wikitext exactly like you would have yourself then it is a violation to copy and paste that text instead of typing it out yourself.
2. I would argue that I'm treating NOLLM perfectly in line with other guidelines by saying that the purpose of the guideline is more important than the exact wording, and that common sense exceptions exist because of that. That's what it says at the top of every guideline page after all. That does not mean that I advocate for a relaxed view of NOLLM; none of what I have said entails giving any sort of excuse to an editor who has been detected using an LLM, nor more ammunition for wikilawyering. –Maltazarian ᚾparleyinvestigateᛅ 09:56, 5 October 2026 (UTC)
  • Neither exception not prohibition, more in the nature of suggestions for positive usage notes to add to WP:NOLLM.
1) Editors should generally refer to available WP:AIRESOURCES on the relevant topic.
2) Editors may use AI to suggest WP:Wikitext for layout, formatting, links, musical notation, images, tables, and columns. Editors may include suggestions after human review of the resulting page appearance.
3) Editors may use AI in developing edits in areas that is individual to them that are outside of the article space. For example, usage may be done in developing content within a user's own WP:Userpage, shown as illustrative example in wikimedia, and AI assistance may be used in filing a WP:BLPSELF complaint. If it is not content to be viewed by the public reader, concerns about AI results are greatly lessened.
4) Editors may use AI assistance in checking any content for differences from WP policy, guidelines, essays, or individual criteria. Results may be taken as helpful, but are not to be regarded as authoritative or conclusive as the tool or prompting may have led to errors.
5) Editors may show AI outputs in discussions if explicitly allowed by the project, TALK thread originator, or editor of the Userpage. Editors should be careful with the number and size of such posts to avoid [[WP:BLUDGEON|overwhelming] input of other editors, and clooapsing the AI content is a useful step.
Cheers Markbassett (talk) 23:08, 20 October 2026 (UTC)

RfC: Allow autoconfirmed users to archive MfD pages, instead of being bot exclusive.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Can the MfD guidelines be changed to allow autoconfirmed users (or above) to archive non-controversial discussions? 🐴🌀[citation needed] 04:26, 20 September 2026 (UTC)

Reason

I have tried to archive pages by myself, but I might get into a bit of trouble, considering the guidelines mentioning that only bots can do it. I'm making this RfC because if this does get allowed, we wouldn't have closed discussions on the MfD page just sitting there, and would make newer discussions get more !votes, instead of being overshadowed by older closed discussions.

Thanks for cooperating in my RfC. From, 🐴🌀[citation needed] 04:26, 20 September 2026 (UTC)

This RfC is premature. Before starting an RfC, try discussing it at WT:MFD. Axolitl (talk | contribs) 05:20, 20 September 2026 (UTC)
Not to mention that RFC's should start with a neutral statement of the issue and not advocate for one side or the other. Also, this RFC was multi-posted at Wikipedia talk:Miscellany for deletion#RfC: Allow autoconfirmed users to archive MfD pages, instead of being bot exclusive.. This all started at Wikipedia:Administrators' noticeboard#Issue with redirecting an MfD because the user was prevented from completing an MFD closure by an edit filter due to not being extended-confirmed, and then moved to this thread on my talk page. Graham87 (talk) 05:34, 20 September 2026 (UTC)
Yea, I might have accidentally added too much requests on multiple pages. 🐴🌀[citation needed] 06:06, 20 September 2026 (UTC)
I closed the RFC that was opened at WT:MFD per WP:MULTI. Chess enjoyer (talk) 06:31, 20 September 2026 (UTC)
Oh, also, the relevant page is Wikipedia:Miscellany for deletion/Administrator instructions. Graham87 (talk) 10:59, 20 September 2026 (UTC)
"Can the MfD guidelines be changed to allow autoconfirmed users (or above) to archive non-controversial discussions?" is a neutral question. The RFC process does not prohibit the OP from explaining why they're making a proposal, including giving reasons why they think the proposal is desirable. WhatamIdoing (talk) 19:11, 20 September 2026 (UTC)
I'll concede those points. I'm used to reading one-sentence RFC statements with more of the explanation in the initial !vote, but I realise now that that's not the only way. Graham87 (talk) 06:53, 22 September 2026 (UTC)

Responses re MfD pages archives

  • This doesn't seem needed. Let the bot do its job in a predictable fashion. CMD (talk) 06:53, 20 September 2026 (UTC)
  • Allow. Some people are more bothered by visual clutter than others. For the majority of Wikipedians who read fluently (and most of us do; the nature of Wikipedia means most editors are above-averagely literate and comfortable with large amounts of text), this is a non-issue. But decluttering has real benefits for some people, including but not limited to people with specific disabilities. There is no reason to prevent a Wikipedian from manually cleaning up if it helps them.—S Marshall T/C 09:37, 20 September 2026 (UTC)
    • @S Marshall: Closed discussions are already collapsed in show/hide boxes. As an example that works at the time of writing, see the entry for "September 18" in this edit of mine (which was ironically nixed by the archiving bot). Graham87 (talk) 10:12, 20 September 2026 (UTC)
      • I understand that. What I don't understand is why we should stop this volunteer from working in the way he wants to. Is he doing some kind of harm?—S Marshall T/C 13:13, 20 September 2026 (UTC)
        As a collaborative project, though, the preferences of one volunteer shouldn't be imposed upon all others. If a daily archiving cadence fits everyone else's workflow, then it's reasonable to stay with it. The custom CSS provided by OutsideNormality allows for individuals to decide to hide the sections in question. isaacl (talk) 17:21, 20 September 2026 (UTC)
        Indeed. Especially in this sort of case when a volunteer is working in an area they almost certainly don't understand sufficiently. To continue with the construction site analogy I used below, it's like radically reshaping a long-established construction site based on the whims of a rookie employee on their first day on the job. Graham87 (talk) 06:30, 21 September 2026 (UTC)
    • decluttering has real benefits for some people, including but not limited to people with specific disabilities. There is no need to manually archive the page (forcing everyone else to trawl through the archives to find the outcome of a recently closed discussion) when the following CSS I whipped up just now seems to work (although only for Parsoid, and doesn't remove empty section headers):
      section:is([aria-labelledby="Current_discussions"], [aria-labelledby="Old_business"]) section .mw-collapsible {
        display: none;
      }
      
      OutsideNormality (talk) 16:44, 20 September 2026 (UTC)
  • Don't allow/leave it alone. Let the dedicated bot do its job as they have for many years now, since 2010. The XFD pages (and particularly those besides AFD) are not for inexperienced users to peruse and this sort of activity is highly unusual. Universal accessibility is very much essential in a completed building, not so much on a live construction site where only qualified workers tend to go. By this I *don't* mean that our accessibility guidelines shouldn't apply to non-article pages, just that unless we hear a complaint from an experienced Wikipedian who regularly peruses MFD (or if there's a significant minority who are put off by the discussions being live on a page for a little while), we shouldn't change how things are done. And, as I noted at the admins' noticeboard discussion that started this whole thing off, there's abuse filter 174 that stops non-extended-confirmed editors from removing MFD templates in the first place. Graham87 (talk) 10:26, 20 September 2026 (UTC)
    • As a counterexample, if we had an RFC saying "a few regular and experienced Wikipedians have complained that XXX Wikipedia namespace venue is impossible to load because of page size; let's explore solutions to make it easier for those people", I'd have absolutely no problem with that. But that's not what we have here. Graham87 (talk) 10:31, 20 September 2026 (UTC)
  • No - We have a bot that does this. If you would like to propose that the bot act more frequently, that's fine, but it looks like the bot comes by after ... one day? Hard to think of a case where we'd need to move faster than that -- it's not like MfD is particularly busy these days. If the issue is readability of text clutter, that's more the fault of the voluminous instructions at the top of WP:MFD. It should be easy enough to create a custom page or propose to separate the list and the instructions. — Rhododendrites talk \\ 13:40, 20 September 2026 (UTC)
  • Manual archiving imposes a burden on everybody that sees the diff and then goes to verify that the discussions were in fact archived correctly, instead of just being disappeared or having their results on the monthly archive page misrepresented. And there are people who check, because why else would someone do that when there's a bot to do it? And even if there were no Petty Nefarious Plot, there's plenty of room for error. It'd take a very extraordinary situation to be worth ignoring this rule, on the order of dozens of closed discussions from the same day. —Cryptic 00:30, 21 September 2026 (UTC)
  • No Why make onlookers wonder if manual archiving was done correctly? What about time wasted when there is a disagreement about whether manual archiving was appropriate? Let the bot do its job until consensus shows there is a problem. Volunteering is good. Imposing one's ideas on others is not. Johnuniq (talk) 09:25, 21 September 2026 (UTC)
  • No. Don't fix what isn't broken applies to too many proposals these days, this one included.Katzrockso (talk) 02:08, 26 September 2026 (UTC)
  • "Allow, I am in favor of anything that deprecates the rampant, out-of-control, absolute plague on my existence that is archive bots Gnomingstuff (talk) 17:04, 2 October 2026 (UTC)
    • This particular bot archives in only very specialised venues and doesn't even close discussions, therefore making them uneditable (that's what editors, mostly admins do); it just removes them from pages. Also, I know you like undoing problematic edits from talk pages, but miscellany for deletion pages are exceedingly unlikely to be subject to the problems you're targetting. I think that archiving bots are sometimes overused or used too aggressively, but having witnessed many unusual forms of manual archiving over many years, I'd much rather that they existed than contemplate a return to a Wikipedia without them. Graham87 (talk) 12:21, 4 October 2026 (UTC)
  • Comment: It's come to my attention that the filing party has been indefinitely blocked from the Wikipedia namespace for a while now. Pinging the blocking admin, @Star Mississippi: FYI (sorry for yet another ping!), but I doubt that anything more needs to be done here other than letting the discussion be archived naturally as it will be soon. I guess it could be closed early because it is dominating the top of this page and maybe gunking up the RFC system but meh ... Graham87 (talk) 12:24, 18 October 2026 (UTC)
    Thanks @Graham87
    I'm not active enough in MfD to participate but my read of the above is that there's no consensus for the proposed change, independent of their block. Agree that no action is needed here re: block. They were an excited new editor. Star Mississippi 13:58, 18 October 2026 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The status of LLMTALK

I'm increasingly seeing people say outright that AI-generated comments are forbidden in the same way that AI generated article content is. However, WP:LLMTALK really doesn't explicitly say this; it even implies that AI-refined comments are perfectly acceptable so long as they're not wholly generated, whatever "refined" means.

Is there generally consensus that we wholly forbid AI in user communication the same way we forbid it in article content? If so, any proposals as to the wording LLMTALK should take on to clarify this? Athanelar (talk) 10:21, 8 October 2026 (UTC)

Last time there was any substantive discussion on this that I'm aware of, there was a clear consensus that translated comments were allowed and these days that necessarily means there cannot be a complete prohibition on comments with LLM-written content. Thryduulf (talk) 10:52, 8 October 2026 (UTC)
There could still be the same caveat for WP:LLMTRANSLATE, of course. I mean 'complete prohibition' in the way that NOLLM is, I should've clarified. Athanelar (talk) 11:30, 8 October 2026 (UTC)
Agreed, perhaps LLMTRANSLATE should be modified to allow comments that are written by a human in one language, but translated using an AI into another. In solidarity, Gommeh (talk 🎮 sign) 20:00, 11 October 2026 (UTC)
We have discussed this ad nauseam. The consensus is clear: You can not use AI to generate stuff on WP. But you may (in very limited ways) use it to assist you in your human writing and editing. This is what “AI-refined” refers to - you can use AI based tools to help with translations, and to do basic stuff like grammar and spelling checks.
My “rule of thumb”: if you have any question as to whether it is appropriate to use an LLM (or other AI tool) to do something - it is probably not appropriate. Blueboar (talk) 11:04, 8 October 2026 (UTC)
"AI refined" has a lot more wiggle room in it than the caveat given in NOLLM for simple corrections, though. Athanelar (talk) 11:30, 8 October 2026 (UTC)
Again… if you are unsure, don’t use it. It really is that simple. Blueboar (talk) 11:51, 8 October 2026 (UTC)
I'm not asking because I want to use AI. I was part of the discussions that wrote WP:NOLLM. "Rules of thumb" aren't something we can easily point new editors to. Before the wording of NOLLM was changed, those of us doing AI cleanup had more than enough headache arguing about the caveat for "basic copyediting" in that guideline; "AI-refined" is even looser and even more subject to interpretation.
The point is that if the consensus is that we want to forbid people from wholly or partly generating comments except for the same exceptions as NOLLM; why not just make the text say that instead of being vaguer and looser about it? Athanelar (talk) 11:53, 8 October 2026 (UTC)
Practice, as seen in multiple WP:ANI threads, seems to be that use (particularly repeated use) of LLMs on talk pages is often treated as as demonstrating a lack of competence in one of the essentials in a collaborative project: communication. It is also frequently stated that we don't demand perfect grammar or spelling on talk pages, and that we'd much prefer moderately-mangled English to grammatically-perfect botspeak that may or may not be communicating anything the contributor actually intended. This is the point we should be trying to get across, in LLMTALK and elsewhere: the why of limitations on LLM use, not just the what. It clearly isn't possible to define an exact cutoff point where LLM use is prohibited, and rather than attempting the impossible, we'd be better off just explaining what we actually want - which is contributors own input, not something put through an unreliable algorithm. AndyTheGrump (talk) 11:55, 8 October 2026 (UTC)
I have no objection to clarifying why. Indeed a lot of our P&Gs could benefit from that. Blueboar (talk) 12:18, 8 October 2026 (UTC)
we don't wholly forbid AI in article content. Maybe change "refined" to "corrected or translated", and say that it is best practice to disclose when the comment was translated using LLMs? Kowal2701 (talk, contribs) 14:46, 8 October 2026 (UTC)
WP:LLMTALK does not seem to imply that AI-refined comments are perfectly acceptable so long as they're not wholly generated. It states that obviously AI-generated comments can be struck and collapsed. Naturally, less clear cases should not be unilaterally collapsed. This is reflected in the closing statement of the cited RfC. Just above LLMTALK in the same section, there is the sentence Posts that might be considered disruptive in various ways are another borderline case and are usually best left as-is or archived. Here, it is quite clear that an instruction against striking or removing a kind of comment is not by any means an indication that it should be allowed. Kisseran (talk) 18:32, 8 October 2026 (UTC)
The text of the guideline is older than the text of WP:NOLLM and never got updated, so that's why there's a discrepancy.
In practice, if something gets collapsed under HATGPT, it's usually because it's an WP:AITALKSIGNS regurgitation and/or made concurrently with similarly obvious AI text elsewhere. Gnomingstuff (talk) 19:11, 8 October 2026 (UTC)
tbh I only collapse ones that are massive walls of text, easier to leave the others so long as it's clear to a newcomer to the discussion they're AI Kowal2701 (talk, contribs) 19:18, 8 October 2026 (UTC)
I'd like to strengthen WP:AITALK to have the same language as NOLLM, other than on translation which should be handled differently. Translation is fine for reporting issues or responding to conduct concerns but not for long term use, as editors contributing here should be able to communicate using their own words, with fluency not expected of course.
We could also add language about not biting newbies. NicheSports (talk) 17:02, 18 October 2026 (UTC)

I find it a bit hypocritical to complain about users using Super Intelligence to write their posts, when standardized user warning templates are a thing. Cambalachero (talk) 16:06, 8 October 2026 (UTC)

I'd like to take this opportunity to draw more attention to Wikipedia talk:Biographies of living persons/Noticeboard#LLM reports here. ScottishFinnishRadish (talk) 16:28, 8 October 2026 (UTC)
We already ask editors to not BITE the newbies. If a clueless new editor uses an LLM to write a comment at a noticeboard, just politely explain the rule… and ask them to rewrite their comment in their own words. Blueboar (talk) 19:33, 8 October 2026 (UTC)
There is a difference between a new editor and someone who just wants to report a problem. Some of the latter might become editors, but making them jump through unnecessary hoops (like rewriting their report) is biting them and you've significantly reduced the chances of that happening. Thryduulf (talk) 20:01, 8 October 2026 (UTC)
Agreed, if someone's initial edits here is to attempt to use LLM to make a properly formatted report of a problem and the report is otherwise correct, it should be considered wrong to chastise such a person in every circumstance.
They went to the trouble of attempting to do things right, as far as they knew. Thank them, show them the policy, and suggest they do it that way next time. Give them cookies. No one should go on any AI/LLM related screeds there be they pro/con/other. — VPP (t/c) 15:58, 9 October 2026 (UTC)
The problem is that the report is not often otherwise correct. Speaking as someone who sees this regularly at WP:AFC/HD, it's fairly common for a LLM-written noticeboard report to make up policies and guidelines out of whole cloth or misapply existing ones due to an overly-literal interpretation of them. And even when those aren't a thing, the LLM blatantly lies about the content of the draft or related discussions and is blind to declines/rejects. —Jéské Couriano v^_^v Look out it's Jimothy! 15:51, 11 October 2026 (UTC)
LLM-written drafts are not relevant this discussion, we're talking about good-faith reports of problems in existing articles, often (but not exclusively) from the subjects of those articles. The correct thing to do is to:
  1. determine what the reporter sees as a problem
  2. evaluate whether it is actually a problem (whether for the reasons given or not).
If it is actually a problem, then fix it to the best of your ability and thank the reporter for bringing it to our attention.
If it isn't actually a problem, then politely explain to the reporter why it isn't actually a problem.
If you are unable to do this then leave it to someone else who can. Thryduulf (talk) 15:58, 11 October 2026 (UTC)
Exactly. Any policy - any - that can limit how WP:BLP issues are reported to us by the public that says to remove/strike such reports if from LLM are wrong. We can't make a fuss if some random person with a page about themselves here, or a truly random person seeing a BLP problem, reports it because of how they reported it.
Fix the WP:BLP issue first, then link them the page about LLM and send them on their way politely and every responsible level headed editor would be wise to bite their tongue on sharing their views of LLM to that user in that interaction. — VPP (t/c) 15:10, 13 October 2026 (UTC)
I would be interested to see any example of a person in good faith reporting a serious BLP issue and getting scorned by overzealous AI haters. This hypothetical person comes up in nearly every AI policy discussion but I have yet to see this situation actually manifest. The reality is that the average layperson doesn't know enough about our policies and guidelines to report violations of them, and as far as blatant vandalism goes I have yet to see anybody report such a thing using AI, let alone do so and get told off for it.
WP:IAR and WP:BLPKIND always apply, after all. Regardless of what our other policies say, we have plenty enough ability to make exceptions to deal with reports like this. A good example is WP:DOLT. WP:NLT calls for immediate blocks in response to legal threats, but we can still understand there may be material worth acting upon in those threats. A stricter written prohibition against AI generated comments isn't going to mean we suddenly stop checking whether those comments are actually reporting something important. Athanelar (talk) 15:38, 13 October 2026 (UTC)
, which is what drove me to make my post on the talk page. This is not the only time it happened, nor the only editor who has done it. I'm also not trying to call out Bluethricecreamman, who apologized on the talk page. ScottishFinnishRadish (talk) 16:18, 13 October 2026 (UTC)
I appreciate the example. Still, the second part of my point stands; this is no argument against strengthening our wording forbidding AI generated comments, since in any case we make common-sense exceptions where it benefits the encyclopedia. Athanelar (talk) 16:50, 13 October 2026 (UTC)
Yeah the most egregious examples of ai generated talk are such that many of us want to mark it as AI generated. Maybe instead of collapse LLM talk there should be an additional template way to distinguish it, such that its visible and able to reply to but subtly tells folks (esp newbies) we can gell obvious ai and not to use it. And ofc for folks using ai to spam a discussion, we can reserve the option to collapse. User:Bluethricecreamman (Talk·Contribs) 17:01, 13 October 2026 (UTC)
better case for collapsing might be AI-generated comments that are only identifiable as AI in aggregate, and which have problems, but where someone who only sees one comment won't necessarily pick up on it
recent example: the person at ANI who appears to have spammed ~400 AfD comments with Perplexity; the comments are highly unlikely to be reviewed at all, but they're so short that if you're only looking at and/or closing one AfD it might not really raise an eyebrow. Gnomingstuff (talk) 22:09, 14 October 2026 (UTC)
The wording ("can be struck or collapsed") leaves flexibility ("being vaguer and looser") because our policies and guidelines often leave space for nuanced situations. That does not mean anything not covered is "perfectly acceptable". For example, the 3RR policy point does not mean that editors should frolick through reverts up to that number. CMD (talk) 00:42, 12 October 2026 (UTC)
I do agree that as written LLMTALK basically gets very close to wholly prohibiting without being so clear about gray areas, or even saying its actually prohibited. It simply says ai generated comments mah be collapsed. As written, it doesnt actually prohibit such coments nro does it make it clear about edge cases such as refined talk comments.
i think it could use a few more passes atp especially with growing exponential scale of ai problem on wikipediaUser:Bluethricecreamman (Talk·Contribs) 17:07, 13 October 2026 (UTC)
I think 'forbidden' or 'blanket ban' is the general consensus and the general understanding of WP:LLMTALK and WP statements about LLM/AI use in general. Personally I think the focus of 'guidance' should be how and where to use something, and that the current blocking are unsustainable but am inclined to say let time tell. Cheers Markbassett (talk) 23:54, 15 October 2026 (UTC)

RfC: Geographic disambiguation of school article titles in the United States

00:00, 13 October 2026 (UTC)

Background

Recent RMs involving US secondary school articles have produced many different outcomes regarding how their titles should be geographically disuated. Assessment of actual practice in article titles reveals a lack of consistency. The issue has been whether it should be identified by its state, its city or other settlement, or both its city and state.

Recent RMs on the topic:

For more context, see WT:NC(S)#Background and summary from above, which summarizes recent discussion at Wikipedia talk:NC(S) and the discussion at Wikipedia talk:WikiProject Schools/Article advice § Title. There have been four failed proposals for a schools naming convention in the past.

Some editors favor state-based disambiguation. Others favor city-based disambiguation. Always using '(City, State)' regardless of the need for further disambiguation would produce a consistent result but is less concise than state-only or city-only. Other suggestions have included considering whether the US city is the primary topic for its name or whether it is a major city as described at WP:USPLACE.

Existing practice is inconsistent even at GA level; see Wikipedia talk:Naming conventions (schools)#GAs and DYKs. Issac I Navarro (talk) 00:00, 13 October 2026 (UTC)

Question 1 responses

Should the name of the city be included when using geographic disambiguation for primary and secondary schools in the United States?
And yes, as others have said, using "city, state" across the board would make many titles both unnecessarily redundant and unnecessarily long, giving us something like "Salem High School (Salem, Massachusetts)" and "Salem High School (Salem, Ohio)", when in both cases (and as they currently stand) the state alone accomplishes the job of distinguishing between the two. -- JonRidinger (talk) 15:19, 13 October 2026 (UTC)
I believe that the point of this RFC is to declare that, if we have two "Central High Schools", the detail that is necessary to distinguish them is that one is Central High School (Smallville) and the other is Central High School (Neighborton), rather than by saying that one is Central High School (Florida) and the other is Central High School (New York). The "(City, State)" style would only come into play if there were two Central Highs with cities of the same name, e.g., Central High School (Smallville, Iowa) and Central High School (Smallville, Ohio). WhatamIdoing (talk) 17:57, 13 October 2026 (UTC)
As put together at Wikipedia:Naming conventions (schools)/History, there is no consistency or consensus. It seems that for RM in schools are often changed with no policy based.
Furthermore, as I put together at Wikipedia talk:Naming conventions (schools)#GAs and DYKs, you can see the dropdown Of those 12 that use city and sates, there are: that also illustrates this point. Issac I Navarro (talk) 18:02, 13 October 2026 (UTC)
The point of this RFC is to determine which approach we should use. —Myceteae🍄‍🟫 (talk) 18:38, 13 October 2026 (UTC)
Should the style with the state only (with exceptions perhaps for WP:MAJOR cities – I think Cleveland and New York City are the only ones in these examples) be used for US educational institutions across the board, or should secondary (and lower) schools follow a more "localized" style? Ham II (talk) 18:54, 14 October 2026 (UTC)
I think colleges/universities are often different in this regard than elementary, middle and high schools, so that would make sense. They're often more associated with a larger area than just a city or even an entire state. Katzrockso (talk) 19:05, 14 October 2026 (UTC)
The scope of the RFC question is intentionally limited to primary and secondary schools—which is not to say we shouldn't discuss related cases and the extent to which they are or are not similar. I agree with @Katzrockso. Primary and secondary schools are local, often hyperlocal, institutions. Of course it's true that some students attend school in neighboring communities. College and universities have important similarities but I find the justification for a state or even national designation stronger there, depending on the institution. —Myceteae🍄‍🟫 (talk) 22:17, 14 October 2026 (UTC)

Question 2 responses

If yes (to Question 1), should the state also be included by default, or only under certain circumstances? If the state is not always included, when should it be?
No as under WP:CONCISE. Issac I Navarro (talk) 18:23, 14 October 2026 (UTC)
—Myceteae🍄‍🟫 (talk) 19:46, 20 October 2026 (UTC)

Question 3 responses

Should we develop a naming convention covering all school articles?
To anyone saying yes, here. If that page was to be developed, I would love some feedback on that page's talk. I think that page could greatly benefit from others' points of view. Issac I Navarro (talk) 05:14, 13 October 2026 (UTC)
Yes, folks may want to take look at the very rough draft proposal at WP:NC(S). It's somewhere between the brainstorming and draft proposal stage described at WP:PROPOSAL. It is mostly compiled from past failed proposals listed at Wikipedia:Schools § Article titles. It does not reflect any clear consensus. @Issac I Navarro has done a nice job pulling it together and cleaning up some portions. Per WP:MULTI, and for everyone's sanity, let's not start a parallel discussion about US schools or anything else within the scope of this RFC on the draft proposal's talk page—or anywhere else. —Myceteae🍄‍🟫 (talk) 05:32, 13 October 2026 (UTC)

Question 4 responses

Should we develop a naming convention that covers schools, museums, churches, libraries, and similar institutions and buildings?
Jmabel | Talk 06:58, 13 October 2026 (UTC)
Much to consider. If a more comprehensive guideline is developed, it would presumably default to WP:COMMONAME, WP:PRIMARYTOPIC for the common name, and other broad considerations in many cases. So the likes of University of Washington, Holworthy Hall, and Cincinnati and Hamilton County Public Library would not need to be changed. I don't want to digress too much into what exactly such a naming convention might say but it would be critical to define its scope. Another critical question would be whether the disambiguation considerations and outcomes should be the same for each type and, if not, what special rules or factors could be described for, say, libraries as distinct from high schools. —Myceteae🍄‍🟫 (talk) 07:19, 13 October 2026 (UTC)
I agree with Jmabel, point, that seems to make the most senes. Issac I Navarro (talk) 00:57, 14 October 2026 (UTC)
  • Johnbod, why would one country get special handling versus everyone else? — VPP (t/c) 12:32, 13 October 2026 (UTC)
  • To avoid yet more cultural imperialism by guess who. If other countries want their own standard, fine. But a standard devised by and for the US should not be imposed globally, as too often happens here. Johnbod (talk) 13:13, 13 October 2026 (UTC)
    There's no reason region-specific guidance and considerations should not be included in such a guideline. —Myceteae🍄‍🟫 (talk) 15:55, 13 October 2026 (UTC)
    Agreed. I don't believe any country on Earth would feel like we're imposing US standards if we use their specific regional terms. For example, China has a different system of administrative divisions, and none are called "States," but are employed in a similar way to describe places in China. Each country has their own way of doing things, and we can respect that while still having some standard that is roughly consistent globally. GeogSage (⚔Chat?⚔) 03:54, 14 October 2026 (UTC)
    As pointed out in the Article Advice Talk, UK schools use commas instead of parentheses. Issac I Navarro (talk) 04:01, 14 October 2026 (UTC)
    The point is less what symbol goes where in the title as opposed to what level of place goes where in the title. — VPP (t/c) 06:24, 14 October 2026 (UTC)
    To be clear what I mean is that anyone should be fine with if one country's norm is (this, then) vs this, then. THe point is the this and the then, not the other errata. — VPP (t/c) 06:25, 14 October 2026 (UTC)

Discussion (Geographic disambiguation)

Of course, to be clear, if a school is Exaaammmple Skooool High School with its own unique name, there would be no need to add any of the three options being discussed above: (city, state)/(state)/(city) Issac I Navarro (talk) 19:37, 13 October 2026 (UTC)

Date format in citations and references

In recent years I have been using ISO 8601 YYYY-MM-DD format in citation templates that I add to articles since this is unambiguous and is, anyway, converted to whatever default date format that has been set for the page by the date template. This is consistent with Wikipedia:Overview of date formatting guidelines and, anyway, the raw ISO date format is never seen in the article, only seen when editing the article.

However, over the years, I have seen other editors spending time changing the YYYY-MM-DD format to (typically) M, d, yyyy format, sometimes using scripts. I find this somewhat irritating since I spent time to add the citations and in the spirit of universality using the unambiguous ISO date format. Are there any policy restrictions on the citation template "date =" date format?!?
Enquire (talk) 20:53, 13 October 2026 (UTC)

See WP:ENGVAR and List of date formats by country, noting that the US date format is unique in the world. To avoid any ambiguity for international readers, it is probably prreferntial to spell out the month. Kudpung กุดผึ้ง (talk) 22:23, 13 October 2026 (UTC)
Template:Use mdy dates and Template:Use dmy dates automatically convert 2026-10-12 into October 12, 2026 or 12 October 2026, for the reader. So for example, if you look at Kazuo Ueda (linguist) before and after Special:diff/1375822500, it appears the exact same for the reader, except now if I want to copy a reference into another article I have to manually alter the date parameters. 22:40, 13 October 2026 (UTC) 1brianm7 (talk) 22:40, 13 October 2026 (UTC)
MOS:DATEFORMAT is the guideline, not the essay Wikipedia:Overview of date formatting guidelines. MOS:DATEFORMAT says ISO dates are not acceptable for general use and are for "Only in limited situations where brevity is helpful". In my experience, inconsistent date formatting is common in rendered articles, and I believe we generally do not depend on a "default date format that has been set for the page by the date template". I thought templates like {{Use DMY dates}} do not actually convert the displayed dates to that format, but some conversion seems to have been happening in the version before Special:diff/1375822500, and I'm a bit surprised to see that. I do confirm that it seems to be having that effect, although I don't see that effect mentioned in the documentation of that template. The documentation for date templates like {{Use DMY dates}} includes encouragement to run scripts periodically to maintain consistency. Date format within an article is supposed to be basically consistent, so when someone sees clear inconsistency, I think they are justified in taking action. The widely available script converts all of the dates at once with a single click, making it hard to do something like put access dates in a different format than the dates in the body text or use a different date format in some table. MOS:DATETIES suggests that articles about topics that are particularly related to the United States should use Month D, YYYY. —⁠ ⁠BarrelProof (talk) 22:43, 13 October 2026 (UTC)
The templates say "Citation Style 1 and 2 (collectively cs1|2) templates automatically render dates (|date=, |access-date=, |archive-date=, etc.) in the style specified by this template. Because it is allowed by WP:MOSDATES, the cs1|2 templates can automatically format dates in a variety of styles." Its explicitly not a cosmetic edit, but an edit which makes no difference in output for readers is unideal IMO. 1brianm7 (talk) 00:17, 14 October 2026 (UTC)
Thanks for the info. But I now see that the rendering conversion is sometimes not applied – for those who are editing sections of the article and preview the text. There is a warning that editing a section disables the conversion (Help:Citation Style 1#Auto-formatting citation template dates: "Nota bene: CS1/CS2 auto-date formatting does not apply when previewing an article section that does not contain a {{use xxx dates}} template."), which may explain rendered output sometimes looking different. —⁠ ⁠BarrelProof (talk) 00:49, 14 October 2026 (UTC)
Section editing breaks many things (as of last count, I believe all efns, sfns, and named references first declared outside of the section?). I would not aggrieve any editor who, while making an edit to the section, changed 2026-10-12 to 12 October 2026. The benefits of converting away from 2026-10-12 are nonexistent, but the negatives are so minor that, when I see the edit made, I just express confusion to myself as to why anybody bothered with it and then I move on with my life. But on a policy-wide level, I'd be glad to see it prohibited, at least for drive-bys and not when bringing the article to FAC or something. 1brianm7 (talk) 01:51, 14 October 2026 (UTC)
others have point out the problem of iso dates, but I will note we have WP:DATERET that says to not change date formats unless there's good reason. Moving from unaccepted Iso to mdy ir day is a good reason in this case. Masem (t) 22:47, 13 October 2026 (UTC)
MOS:ENGVAR is MoS, a guideline, so pretty much a policy. MOS:DATERET likewise, MOS:DATEFORMAT likewise. List of date formats by country is a Wikipedia article but serves as a very good, clear, overview, and shows the USA in total isolation. Wikipedia:Overview of date formatting guidelines is an essay, typical when users feel our MoS and PAGs are inadequate so they write their own and what we get are many pages saying the same thing - a classic crowd sourced phenomenon. Personally, I have always used the 14 October 2026 in all articles and sources I write and edit and I have never come across any issues - not ever. Kudpung กุดผึ้ง (talk) 02:21, 14 October 2026 (UTC)
Twice here you have said something about how isolated the US is. Are you referring to the all-numeric date format in the U.S. (of which I think there are several minor variations, depending on whether leading zeroes are used or not and whether the year uses two digits or four) or are you referring to the "January 5, 2006" (or "Jan. 5, 2006") format where the name of the month is spelled out using letters? I have certainly seen dates expressed like "January 5, 2006" in many English-language publications outside the United States. Here is one I ran across while doing some editing today. List of date formats by country says that dates are not expressed that way in South Korea, but Korea Times seems to say otherwise. The list article also says that Israel does not use dates like that, but the Haaretz website seems to indicate otherwise. The Toronto Sun also seems to use MDY. —⁠ ⁠BarrelProof (talk) 09:22, 17 October 2026 (UTC)
Our guidelines are very explicit that ISO is acceptable in citations, even without the template being used. 1brianm7 (talk) 07:32, 14 October 2026 (UTC)

Citation archives and reference names

I routinely add ref-name and archives to citations I create as well as to sometimes add them where absent in existing citations. However, from time to time, other editors for some unknown reason deleting either the reference name and/or the archives. This is quite discouraging since, particularly for archives, it takes time to find archives and to add these to the citation. Is there any plausible reason that other editors would delete reference names and/or archives?
Enquire (talk) 21:07, 13 October 2026 (UTC)

Do you have some examples? Have you asked those editors? —ClaudineChionh (she/her · talk · email) 21:09, 13 October 2026 (UTC)
If by archives you mean archive.today, here's the context on that. Gnomingstuff (talk) 21:25, 13 October 2026 (UTC)
I've seen editors remove ref names when a ref is used only once in the article. Whether the name is there or not makes no difference to the reader, in that case, so I just ignore it. If a ref isn't reused, it doesn't need a name. Schazjmd (talk) 21:40, 13 October 2026 (UTC)
Whether it is used only once or multiple times removing a ref name is silly if it already has a name. If a user is showing a pattern of doing so, they should be politely advised that it is borderline disruptive and suggest they find something better to do - because it also generates questions like Enquire's. FWIW, I almost always name my refs as a matter of 20-year habit. Kudpung กุดผึ้ง (talk) 22:39, 13 October 2026 (UTC)
I agree that it's silly but it isn't worth my time to argue with someone about it because it doesn't really matter. Schazjmd (talk) 22:52, 13 October 2026 (UTC)
Like you said: ignore. Unless it's a pattern, in which case that 'pattern' may disclose other patterns on closer examination. Kudpung กุดผึ้ง (talk) 01:30, 14 October 2026 (UTC)

How to handle tendentious resubmission of rejected drafts?

The background lore is at the ANI thread, but I wanted to ask a more general question since I do see this happen a lot based on Special:AbuseFilter/1370. When a draft is tendentiously resubmitted after a rejection or multiple rejections, how should it be handled? In some cases, it can be handled at WP:MfD, if the draft has no chance of acceptance. But other times, a draft is rejected specifically because of tendentious resubmission with no improvement, or for some other reason, even if the draft does at least have a chance at being accepted. In such a case, would it be better to take the submitter to WP:AN or WP:AIV? What about WP:RFPP? guninvalid (talk) 20:37, 14 October 2026 (UTC)

If the draft is about an objectively non-notable subject and/or is so bad that it would not be useful as a starting point for an article without TNT then take it to MfD.
If the submitter is doing this for a draft that could be improved to be acceptable or is tendentiously resubmitting multiple drafts then take them to ANI, or (if you are an admin) consider whether a partial block from draftspace or a NOTHERE or CIR block is appropriate. Note this is not mutually exclusive with MfD.
I'd say AIV is appropriate only if they are doing this to other drafts being actively worked on by other editors. The only time I can think of that page protection would be the right solution would if the draft is in an area covered by ECR (e.g. Israel/Palestine) and multiple non-extended confirmed editors are disrupting a draft being worked on by editors who are extended confirmed. I'd be surprised if that was a common occurrence. Thryduulf (talk) 09:55, 15 October 2026 (UTC)

An attempt to prevent autoconfirmation gaming and other issues

Should requirements to autoconfirmation be changed to prevent gaming, particularly of LTAs? This conversation started here as a result of actions taken by a likely D86 sock. Socks of this behavior edit once to get the day counter going and then make several dummy edits to their userspace (example). I see two ways of counteracting this, which I have listed below. Both methods should increase visibility of socks gaming the system and allow for more reaction time on our end. I am aware of this discussion; a previous attempt to get this implemented was rolled into that discussion at the tail end of it, not allowing much time for it to be discussed. The following proposals also take a different approach to much of what was suggested at that previous discussion: it changes the system instead of just creating a new arbitrary number to reach. This also should not significantly impact new editors. @Finfixer noted that Option 2 below could prevent some new editors who make edit suggestions or participate in discussions from becoming autoconfirmed, but that cannot be a significant amount of editors impacted nor that hard to solve. A reasonably knowledgeable editor should be able to click random article enough times while making minor edits to reach the new requirements. Pinging @Hurricanehink as a conominator and @Wizzito for starting the first discussion.

There may be some nuance possible within the options, but that could be resolved in a later discussion if not implemented here. ✶Quxyz✶ (talk) 23:43, 14 October 2026 (UTC)

Is there any write up of what uses of AI/LLM are unambiguously allowed, or are ungovernable?

I'm curious if anyone's ever made a write up of what sorts of use cases of AI/LLM tools supporting your editing is unambigulously non-governable on-wiki, even if you said: "This is what I done and how." The big LEAD discussion going above, and cracking open yet another giant PDF right after got me thinking to post this.


Examples that I've seen broadly brought up before, more or less:


That second one would have saved me weeks on one project I bet.

If an editor said they do those, is that a no-no? Or a default and automatic yes?

Is there any write up along those lines? — VPP (t/c) 01:29, 16 October 2026 (UTC)

I don't think there is unanimous agreement about anything to do with the intersection of LLMs and Wikipedia. Obviously if what you are doing doesn't involve adding or editing text on Wikipedia then what we do or do not want is irrelevant (as long as you abide by the license and TOU of course). It think most people are OK with using an LLM to find potential sources, as long as nothing is added without a human verifying that every single one is reliable and actually verifies what it claims to. I think at least most of those people will also be OK with adding a list of such sources to a discussion with a note saying something like "here are some potential sources, but I haven't had chance to look at them all yet" (although I don't recall this being explicitly discussed).
LLM-assisted translations are not universally loved but are in accordance with policy at present, ditto spelling and grammar checks. Everything else is at minimum more controversial, see e.g. #The status of LLMTALK for a case that I think should be uncontroversially allowed (despite failing the letter of LLMTALK): non-contributors reporting, in good faith, problems with articles. Thryduulf (talk) 02:17, 16 October 2026 (UTC)
The source hunting has gotten me honestly curious too. For Wikipedia, half of my fun IS that part of the research, that no one on here gets to see. Hours and days of just reading and turning over every stone. For work stuff, that is tedious. Then I discovered with a high end proper commercial model, I can send it on quests to get me ALL the technical information I need from the public internet. Get a list and voila. Least favorite part of work, inverse to here. So now I can spend all my time on the fun side of work more, for the type of stuff I do.
What happens if you or I do just what you said? "Hey all, I used this prompt on this version/level of GPT: [blah blah], and got back these nineteen sources here: [list]."
Is that a WP:NOLLM violation? Even if they are possibly all good sources? What part of the acts that we did were disruptive to the project? — VPP (t/c) 02:25, 16 October 2026 (UTC)
NOLLM is only about article content, so it is not relevant to posting a list of potential sources on a talk or project page (LLMTALK is the relevant guideline). I would have no problem with you posting such a list and agree that isn't disruptive at all, however this is not a universally held view with some editors arguing that any use of an LLM is inherently disruptive and/or that as a matter of principle Wikipedia should be 100% free of LLM-generated content.
Pasting that list into an article would be a NOLLM violation, but as it would also obviously be disruptive for other reasons too that's academic here. Thryduulf (talk) 02:56, 16 October 2026 (UTC)
I think you ought to try to cross check the returned list in some way to see if the sources are sufficient to determine that they provide reliable information, including adequate coverage of all significant viewpoints. For some subjects, this is pretty trivial (for example, verifying the outcome of a sporting event), but for others, more investigation is likely needed. isaacl (talk) 03:17, 16 October 2026 (UTC)
This depends what the goal of these specific citations are. If it is to demonstrate notability then what they need to contain is very different to if they are to verify specific facts or provide information on a particular aspect of a topic. Posting a list of sources with a note saying "these might be useful but I haven't checked" is always OK (checking them yourself is better but not required), especially if you intend to come back later or you can't properly evaluate them (paywalled, in a language you don't speak, too technical for your understanding, you don't know the reliability, etc, etc). For an LLM-generated list I'd say the absolute minimum verification is that the sources exist.
Sources are never required to provide [...] adequate coverage of all significant viewpoints. We don't require our sources to be neutral or comprehensive, and which viewpoints are and are not significant is based on what coverage of them exists (volume and nature). Thryduulf (talk) 04:31, 16 October 2026 (UTC)
Yes, as I said, for some circumstances, it's trivial to evaluate that you have enough sources.
I agree an editor might not find enough sources to comprehensively cover the specific information being added to an article. But an editor must make a determination that they've seen enough information from enough sources so they can evaluate the overall reliability of the content being added. In other words, they shouldn't assume a list they've been given or found somewhere, from whatever provenance, is enough, without performing some due diligence. isaacl (talk) 05:14, 16 October 2026 (UTC)
If the person is adding content to an article, the sources they use must support at least all the content they added. The totality of sources is only relevant to determine whether that information is DUE if that might be challenged (some material is unambiguously due, e.g. if the person is a professional sports player then what team(s) they played professionally for).
However, what I was discussing above was specifically of adding a list of potential sources to a talk page or other discussion. Thryduulf (talk) 13:03, 16 October 2026 (UTC)
We should that expect those creating such a list would do a minimum of Due Diligence before posting it… to at least check to see that the potential sources actually exist, and that they are at least potentially relevant to the topic of the article. Again, the important step is what happens AFTER you do the LLM query. Blueboar (talk) 14:38, 16 October 2026 (UTC)
It is my continued experience at AfC and AfD that when told their current sources don't support notability, a newer editor will very often respond with "What about these?" and dump a list of anywhere from 3-10 new sources that are very often obviously inappropriate (plain CORPTRIV, blatantly not independent, the sort of thing you can tell from first click even); maybe even doing the same again if some poor sap gives a detailed response to that batch of sources. I can only assume (at least in many cases) this is the product of someone asking an LLM to spit out a list of suitable sources and never actually checking them, so I have to agree that the problems with LLM generated text can extend even to what might seem on the surface to be an unproblematic use like providing a list of sources in a discussion. Athanelar (talk) 07:01, 20 October 2026 (UTC)
To elaborate a bit, the main problem with LLM-generated text on Wikipedia (my ideological gripes aside) is the way that it shifts responsibility away from the person producing the text and instead multiplies exponentially the burden on those reviewing it. This is just another form of that. Having an LLM spit out a list of sources and forcing other people to review them takes no effort on the part of the person doing it and all the effort on those on the receiving end. And often those on the receiving end have no choice but to engage; in an AfD, simply producing the existence of sources can be enough to cause a no-consensus or a keep if the deletionist side fails to address the sources, regardless of whether those sources are actually useful for notability when scrutinised. So if someone on the keep side spits out an LLM-generated list of 10+ sources which they haven't even bothered to cursorily check over for suitability, the delete side has to spend the effort in reviewing and responding to those sources in order to break the filibuster, which is way more work than the filibustering party has to do to get their desired outcome. Athanelar (talk) 07:06, 20 October 2026 (UTC)
I don't know if "parity" in terms effectiveness or ability or outcome of deletionist vs inclusionist concepts should even be a valid factor to consider let alone bring up.
It feels akin to a politcal party or ideology in some direction implying - even loosely - that they may deserve some thumb on a scale for 'reasons'. It seems the sort of thing any normalization of is dangerous. — VPP (t/c) 13:43, 20 October 2026 (UTC)
I mean this purely on the level of individual AfD discussions, where there is one group arguing for inclusion and another for deletion.
The whole argument I'm making is that it's the LLM users who are putting the thumb on the scale by being able to filibuster deletion discussions with huge walls of dubious sources that real people are then forced to individually respond to. Athanelar (talk) 16:20, 20 October 2026 (UTC)
Editors should be reading sufficient amounts of the sources they use to be sure that they are accurately representing its contents. They should also find sufficient sources to satisfy themselves about their reliability. How one finds sources or the right passages to read is up to each editor, but they should be ready to explain their decision to deem the sources reliable, and the accuracy of any text they added based on those sources. isaacl (talk) 03:09, 16 October 2026 (UTC)
Yes, WP:LLMRESP, which I'd already linked in a previous reply to you. Kowal2701 (talk, contribs) 10:33, 16 October 2026 (UTC)
Wikipedia can not control what tools you use to aid in your background research. All we can ask is that you DO proper background research.
There are many ways to find potential sources. We could go to a library and use an old fashioned paper card catalog. We could go on-line and use a modern search engine. And, yes, we could formulate an LLM query and use that to locate potential sources.
It’s the NEXT step that only a human can do… We are still expected to actually read those potential sources ourselves… to weigh them against other sources, and to summarize what they say in our own words. Blueboar (talk) 12:20, 16 October 2026 (UTC)
yep Kowal2701 (talk, contribs) 12:21, 16 October 2026 (UTC)
There is a writeup. The writeup is WP:NOLLM.
Neither of your examples are disallowed via NOLLM, and in most cases, neither of them would be detectable if you aren't also using AI to generate or edit the text. Theoretically, it's possible for the LLM to hallucinate a fake source, and then for you to write (without AI) a paragraph about the nonexistent content, trusting the LLM that it exists. But most people who do that skip the middleman and just get AI to do it all. Gnomingstuff (talk) 15:13, 16 October 2026 (UTC)
  • User:Very Polite Person - I don't think any use is generally accepted, it seems more the case of generally forbidden. The recent RFC for AI assistance in citations closed with consensus against revising WP:NOLLM, requests for suggested uses got mostly pushback, and so forth. Personally I don't think this is sustainable - and time will tell if it is OBE. Cheers Markbassett (talk) 07:27, 18 October 2026 (UTC)

Potential WP:BLP violations arising from "Suggested links"

I am concerned that the suggested links feature is apparently capable of introducing WP:BLP violations by proposing links from fictional characters to unrelated living people who happen to share the same name.

In particular, in this August 11, 2026 edit to Truth or Dare (2012 film), the Suggested links feature recommended linking the name of a fictional character in the movie, "Luke Wilson", to the article on the living person, actor Luke Wilson. The fictional "Luke" in the film (I don't actually see a source supporting the fictional character being surnamed "Wilson") is a drug dealer who flippantly kills another character, and is himself subsequently killed. The real Luke Wilson is, of course, neither a drug dealer, nor a killer, nor deceased. The edit was tagged " Newcomer task" and "Suggested: add links" and described in the edit summary as "Link suggestions feature: 1 link added."

This is an order of magnitude more serious than an ordinary erroneous wikilink. Linking the name of a fictional character involved in criminal activity to the biography of a real living person creates a misleading association, in Wikipedia's voice, between that person and the conduct described in the article. I am aware that machine-generated link suggestions are not guaranteed to be accurate, and that editors are expected to review them before accepting them, and that sometimes these kinds of errors are made even without machine intervention. Nevertheless, the feature is specifically intended to facilitate relatively easy edits by newcomers, who are likely to be particularly inclined to trust its recommendations. Furthermore, erroneous links involving living people can be substantially more consequential than other incorrect links, which do not invoke WP:BLP.

Does the suggested links algorithm have any safeguards against suggesting links from the names of fictional characters to biographies of real people, living or dead? Can such safeguards be implemented to prevent, or at least flag, potentially problematic links involving living people, particularly in articles discussing fictional characters engaging in unsavory conduct? Is there any mechanism for identifying existing edits made through this feature that might have introduced similar BLP concerns? BD2412 T 01:07, 19 October 2026 (UTC)

I think that it's up to the editor to double check the link. None of these tools are perfect. Besides, I highly doubt that this would even constitute a BLP violation in the first place. Gaismagorm (talk) 11:36, 19 October 2026 (UTC)
@Gaismagorm: It is a common practice in articles on films to link names of characters in the cast list for the film who happen to have articles because they represent real people. For example, I.Q. (film) links Albert Einstein, Kurt Gödel, and Boris Podolsky in the cast list of that article. Although these are fictional representations of these individuals, they are not defamatory. A reader could readily assume, however, that a link to Luke Wilson means that the fictional drug-dealing killer in this film is meant to represent, well, Luke Wilson. Whether that is actually a BLP violation is up to the community to decide, but it sure as hell isn't a good thing. BD2412 T 12:25, 19 October 2026 (UTC)
I don't see this as a particular problem for cast lists (I assume it can happen anywhere where we're dealing with two people of similar names), nor, honestly, that much of a prolem. I think people reaching a page aout an actor insead of a drug dealer will be more likely to think Wikipedia is imperfect than to assume those are the same people.... just as your linking to WP:BPL in your first sentence above leads to me thinking you typoed a link, and not assuming that you're accusing Luke Wilson of being an Asian cricketeer. --- Nat Gertler (talk) 12:54, 19 October 2026 (UTC)
Typo fixed, but that link should never have been suggested, and the fact that living people can be the target of bad links bodes ill. BD2412 T 13:00, 19 October 2026 (UTC)
once again the solution to this and related problems is staring us all in the face but will not happen: get rid of newcomer tasks Gnomingstuff (talk) 13:52, 19 October 2026 (UTC)
Link suggestions (and newcomer tasks more broadly as GS has said, but especially link suggestions) is just a godawful feature. Expecting new editors who have no Wikipedia experience and may not even be particularly proficient in English to be able to "verify" anything is a recipe for disaster. Someone would need to run the data, but I would bet that for every example of a genuinely helpful wikilink being added by this feature you could find at least two which are misleading at best. The tasks like "revise tone" are even worse. I have to agree with GS that we should really just drop the ill-conceived idea that gamification is the best way to onboard new editors. Athanelar (talk) 06:55, 20 October 2026 (UTC)
Sadly, stating the obvious seldom achieves much on Wikipedia, where 'this would be a good idea if it worked' magically becomes 'this is a good idea' if its proposed purpose is to attract new contributors. AndyTheGrump (talk) 07:00, 20 October 2026 (UTC)
Is disabling newcomer tasks not something that could be achieved through Wiki-side consensus, or is it purely up to our overlords at the WMF? Athanelar (talk) 07:12, 20 October 2026 (UTC)
I'm not sure whether the overlords obtained any consent from the community for this, or whether they even tried. From past experience, getting the WMF to admit something isn't working is practically impossible. AndyTheGrump (talk) 07:59, 20 October 2026 (UTC)
I did a really painful AINB case with an inexperienced good-faith editor who got a lot of "add sources" newcomer tasks, and decided the only way to do that (honestly, it is hard!) was to ask an LLM. They would have been much better off picking an article and working on it, not trying to add sources to fifty random articles. That person hasn't edited since. No part of this is what we would want from a Newcomer Task: this one cost us a good faith newcomer IMO.
My own experience as a newcomer (6 months ago) is that I did a couple link suggestions (about 1/3 of which I could see were bad), got an "update this article" suggestion and refused it because it looked like hours of work, and then got a "copyedit" suggestion that...was an LLM article, took me a month to fix, learned about AfD merge proposals, learned all sorts of things, but that was so not a newcomer task. It was asking me to copyedit a table that was made up from whole cloth.
I think they should be replaced with "How to find an article that needs help" and "How to go about helping an article" pages, with a solid checklist in the second one. M kuhner (talk) 19:30, 21 October 2026 (UTC)

As far as I know, there is no way to make these "newcomer tasks" know that one of their suggestions is unwanted, so chances are another newbie will soon receive the same suggestion. I have encountered this with "revise tone" (or whatever it is called), where reverting an unwanted tone change just lead to another newbie getting offered the same issue. Is there some magic word to disable newcomer tasks from some pages or sections? Fram (talk) 09:43, 20 October 2026 (UTC)

Oh, and if enwiki wants to change these newcomer tasks, we (well, admins) can edit this special page. Fram (talk) 09:47, 20 October 2026 (UTC)
Well, great. If we want to shut the whole thing down we don't need the WMF on board. Athanelar (talk) 10:31, 20 October 2026 (UTC)
If you have a page where you want to disable all newcomer tasks, you can add Template:No newcomer task to it. Fram (talk) 09:49, 20 October 2026 (UTC)
That's the best tool we have and it should be used. It's using a whole-article sledgehammer to crack a one-link nut, but cracking all the nuts may not be a bad thing. Certes (talk) 10:25, 20 October 2026 (UTC)
We would need to add it to every page that has a name that could potentially be linked to a living person. BD2412 T 22:08, 20 October 2026 (UTC)

The suggested links may cause occasional errors, but the "revise tone" is a lot worse. Not only is it rather unclear what it is based on (we are now letting an AI decide which "tone" is acceptable and which isn't?), it also is a poor choice for a newcomer task. Edits like this don't really revise the tone, but they do incorrectly change the meaning. Wich is probably unavoidable if you drop newbies in the middle of an article and tell them to change the tone of a sentence or at best a paragraph, instead of reading the whole article. This is less neutral and general than the previous version.This also changed the meaning. In many cases, the new version reads like AI slop. Fram (talk) 14:31, 20 October 2026 (UTC)

Most likely because in many cases the newbie in question is just prompting an AI to revise the tone for them. Athanelar (talk) 15:43, 20 October 2026 (UTC)
phab:T405185 for named entity recognition was opened in September 2025. I later raised there the issue of people with similar names being linked, but those with the same name is a similar problem. CMD (talk) 22:31, 20 October 2026 (UTC)

Removing trivial edits

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Please review this edit. Is there any policy on English Wikipedia stating that edits should be deleted simply because it is considered unimportant? Besides, this topic has been covered by Fox News and many other media outlets, which suggests that it is not as trivial as some might claim. Pouyasg (talk) 15:25, 20 October 2026 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Template:Infobox officeholder and the topic of residency

Where you live, in some jurisdictions, is a factor in where you can be elected or serve. Knowing what community (obviously not address) an elected official lives in also a public interest matter. So if you live in New York, and you're governor, you "live" in Albany at the mansion, but that's not your "residency". Your residency is where you vote and pay taxes.

Kathy Hochul, the New York Governor, from looking up her history, appears to have been initially in her political career a resident of Hamburg, NY; then Buffalo, NY, and now she lives in Manhattan, NYC.

So if this Infobox had a residency value, we could list the residency location (if known) of the office holder.

A terribly easy set of examples:

Is there any real reason we ought to not have this as an easy option for industrious editors?

It was removed previously back to 2019 and 2024 over a very low-volume low-traffic RFC:

NOTE: That seems to be the only semi-relevant discussion. I'm proposing this ONLY for the officeholder template. This seems like it should really be a thing. — VPP (t/c) 18:30, 20 October 2026 (UTC)

I'm inclined to oppose. In cases where it's a subject of controversy, potentially confusing, or otherwise requires explanation, inclusion in the infobox is contrary to MOS:INFOBOXPURPOSE. In the case of Trump and Hochul, at a minimum, there is a need to distinguish between their "residency" and their "residence". For former office holders, the public interest argument doesn't carry as much weight. This raises the question of whether the infobox should reflect their current residence or residency or at the time they held office. If it's really important, widely covered in reliable sources, and the value surpasses any BLP concerns, where they live or pay taxes during or after holding office can be described, and given context, in the article body. —Myceteae🍄‍🟫 (talk) 21:09, 20 October 2026 (UTC)

CSD G7 on rejected drafts

At AfC, it's reasonably common for editors whose drafts have been rejected and who have been unsuccessful in appealing that rejection to suddenly change tack and instead request that the draft be deleted as soon as possible, which makes it eligible for WP:G7. Often they then proceed to recreate the draft, and resubmit it for review, essentially using this as a means to evade the rejection. This can work, because the next reviewer might not know the history, and it is not easy for non-admins to recover that history. The best we get is a heads up from the AFC helper that the article has been previously deleted, but I'm not sure if that even shows you times that the draft hss been deleted or only the same name in mainspace.

Does anybody have any suggestions on how we might be able to curb this? An obvious thought would be to add a caveat G7 stating that it does not apply to pages in draftspace that have been rejected at AfC. After all, I can't really conceive of a legitimate reason why an author should speedily delete their draft after it's rejected. It'll be deleted under G13 after 6 months anyway, and if in the meantime somebody else wants to create a draft at the same name, they can easily appeal the rejection or it could then probably be speedied under G6 at the new author's request to give them a blank slate. Athanelar (talk) 12:15, 21 October 2026 (UTC)

I see the problem and agree that it would be nice to block this pathway to resubmission of rejected articles. However, I'm trying to imagine explaining the new rule to a newcomer, and failing. Your draft was rejected, you aren't supposed to resubmit it, but you can't delete it? The explanation, while it makes sense, is very much inside baseball.
And while it's not useful per se, I think blanking your rejected draft (which can trigger G7) is a very understandable response to a rejection.
I think the problem here is not G7, it's the resubmission of a rejected article. I admit I don't know how to tackle that, though, given that even barring re-use of the article name is not robust.
M kuhner (talk) 19:15, 21 October 2026 (UTC)
They don't need to understand, they just need to be told they can't. Like I said, I can't see (and please do tell me one if you can) a compelling reason why a rejected draft should be speedily deleted at the author's request? Other than the loophole I'm talking about the only other reason I can see is that it would be out of an embarrassed desire to not have the rejected draft floating in their contribs, but that's not something we need to accommodate.
As for blanking, I agree; but the same caveat could apply there. Blank drafts that have been rejected before they were blanks are not subject to G7. I think "to prevent tendentious resubmission" is a plenty robust enough justification, my only doubt would be if someone else can see a reason G7 should apply. Athanelar (talk) 19:28, 21 October 2026 (UTC)

RFCBEFORE on WP:LLMTRANSLATE

Hi, please see WT:AIC#LLM exemption for translation, trying to workshop the options for an RfC on changing or repealing WP:LLMTRANSLATE, all input welcome Kowal2701 (talk, contribs) 18:24, 21 October 2026 (UTC)