This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Consensus against the proposal. ~ Jenson (SilverLocust💬) 19:34, 14 December 2025 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This request for comment proposes deprecating the Associated Press Stylebook as a naming authority within WP:USPLACE. The current guideline ties certain U.S. city article titles to whether the AP Stylebook lists them as not requiring a state name, a practice that dates back to Wikipedia’s early years. However, this external dependency conflicts with Wikipedia’s self-governed policy hierarchy and with the way other countries’ naming conventions are structured. No other national convention relies on an outside publication to determine article titles. This discussion invites editors to consider whether Wikipedia should instead base U.S. city naming solely on internal principles such as WP:TITLE, WP:COMMONNAME, and WP:PRIMARYTOPIC, supported by verifiable usage data such as pageviews and clickstreams.
Proposal
Deprecate the Associated Press Stylebook as a naming authority within WP:USPLACE. Future decisions about the inclusion or omission of state names in U.S. city article titles should be based solely on Wikipedia’s internal policies and verifiable usage evidence.
Replace the existing paragraph:
"Cities listed in the AP Stylebook as not requiring the state modifier in newspaper articles have their articles named 'City' unless they are not the primary topic for that name."
with:
"Cities are titled by the most common and unambiguous name used by readers and reliable sources, in accordance with WP:TITLE and WP:PRIMARYTOPIC. The inclusion or omission of a state name is determined by actual disambiguation need, not by external style guides.""
Add an explanatory note:
"References to the AP Stylebook in earlier versions of this guideline are deprecated. Wikipedia naming conventions should rely on internal policy and verifiable data, such as reader behavior or reliable source usage, rather than on external editorial manuals."
Background
The current wording of WP:USPLACE incorporates the Associated Press Stylebook as part of its reasoning for which United States cities are exempt from the “Placename, State” format. This reliance on an external publication is unusual within Wikipedia’s system of self-contained policies and guidelines. Other country-specific naming conventions (for example WP:UKPLACE, WP:CANPLACE, WP:NCAUST, WP:NCIND) rely only on internal policy principles such as WP:TITLE, WP:COMMONNAME, and WP:PRIMARYTOPIC.
Rationale
The AP Stylebook was created for journalistic brevity, not encyclopedic clarity. Wikipedia’s naming standards are designed for reliability and reader intent, not for newspaper copy.
No other country’s naming convention cites an external editorial manual as authority. The United States should not be an exception.
The AP list of cities without state modifiers is dated and arbitrary, reflecting mid-20th-century newspaper familiarity rather than modern global recognition.
Wikimedia’s pageview and clickstream data provide transparent, empirical evidence of what readers mean when they search for a city name.
This change aligns WP:USPLACE with WP:TITLE and WP:PRIMARYTOPIC, ensuring that the same principles apply worldwide.
Intended outcome
Consensus to remove or deprecate references to the Associated Press Stylebook from WP:USPLACE and clarify that U.S. city naming follows the same internally governed, data-based principles used for other countries. TrueCRaysball💬|✏️ 18:07, 10 November 2025 (UTC)
Discussion (USPLACE)
I strongly oppose something as broad as The inclusion or omission of a state name is determined by actual disambiguation need, not by external style guides. While I may agree with the principle that we needn't rely specifically on only the AP for which cities have standalone names, I believe nearly all US cities should still include the state name in the title, even if the city is the primary topic for that name or disambiguation isn't needed. Even if we could retain our discretion to deviate from the AP in particular in some circumstances, I see no issue with the current practice and this method helps avoid pointless move debates while maintaining consistency. I'd rather extend this practice of including a state name in the title to other countries, rather than the other way around. Reywas92Talk 18:31, 10 November 2025 (UTC)
Isn’t that the entire point of a Village Pump discussion? To craft something better that we can all agree to through consensus? The AP standard is written for journalists, not encyclopedias, and in my view it has no place in our naming conventions. TrueCRaysball💬|✏️ 19:21, 10 November 2025 (UTC)
I've shared my opinion, others are welcome to contribute. I see no strong reason to change the current consensus, and even if the wording were changed not to prioritize just the AP, I strongly believe we should not start proposing to remove state names from other titles, which would be a huge waste of effort over something that works fine as it is. Reywas92Talk 19:31, 10 November 2025 (UTC)
Oppose per Reywas. This reads like a solution in search of a problem. I have no objection to deviating from the AP in individual cases if someone can demonstrate a benefit from doing so, but as a general rule everything is working fine as it stands and I see no benefit to changing it after this many years without problems. Thryduulf (talk) 19:51, 10 November 2025 (UTC)
I also oppose. If it isn't broke then don't fix it. Gommeh📖🎮 20:05, 10 November 2025 (UTC)
Oppose – There is no evidence of a problem with the existing scheme. It is clear, a long-standing consensus, and based on a reliable source. Implementing this change will result in the need to reconsider the article titles of thousands of pages, for no good reason, resulting in a waste of valuable editor time. See WP:TITLECHANGES and WP:BROKE. What will the reader gain from this change? As far as I can see, nothing. If the text of the guideline needs to be rewritten, that can be arranged: WP:CONSISTENT is one element of our article titles' criteria. As mentioned above, it is already possible to deviate from this guideline when consensus exists. Yours, &c.RGloucester — ☎ 00:32, 11 November 2025 (UTC)
Oppose Regardless of its intent, the AP Stylebook is still reputable, and our usage of it to help inform our guidelines, as others have stated, has not caused any issues as far as I'm aware. Lazman321 (talk) 04:08, 11 November 2025 (UTC)
Comment - Several of the opposes here rely on "if it ain’t broke, don’t fix it" reasoning or the assumption that editors can already make exceptions. However, that ignores the reality of how this actually functions in practice.
Every city move discussion in the United States is automatically opposed or SNOW-closed on the basis of WP:USPLACE, even when strong evidence and consensus-building attempts are presented. That means editors cannot meaningfully discuss exceptions. The policy itself shuts down the conversation before it can happen. My own RM of Orlando, Florida from last year is one of many examples.
Additionally, the claim that "it works fine" does not hold up when data says otherwise. Clickstream analytics show that thousands of readers type terms like "Orlando" expecting to reach the Florida city, only to land on a disambiguation page and have to click through. That is, by definition, a navigation failure. It proves the system is broken for readers. Not just editors.
The workload objection is also a red herring. A simple "grandfather clause" could apply: existing titles remain until a discussion is individually initiated. No one is proposing a mass retitling campaign.
Finally, the AP Stylebook is written for journalists, not encyclopedias. Its inclusion in our naming conventions has no policy basis and should not function as an unchallengeable authority. We have robust internal guidelines like WP:COMMONNAME and WP:PRIMARYTOPIC that already handle naming consistently and logically without relying on external style manuals. TrueCRaysball💬|✏️ 04:46, 11 November 2025 (UTC)
That your proposed move was rejected does not indicate that anything is amiss with the guideline. What it means was that you failed to provide persuasive evidence of a 'good reason' to change the article title per WP:TITLECHANGES. In fact, in that RM, you failed to provide any evidence to support your claims, at all. I can see that you are now engaging with empirical data, such as Clickstream analytics. If you think you can make a better case now per WP:PRIMARYTOPIC, you are free to open a new RM discussion. Yours, &c.RGloucester — ☎ 05:46, 11 November 2025 (UTC)
I think the current guidelines would suggest that the proper RM if you're right about PTOPIC would be Orlando → Orlando (disambiguation), with Orlando turned into a redirect to Orlando, Florida. That way all the readers expecting to reach the city will get there right away, and a hatnote at the city page could send confused readers back to the dab page. It looks like this was last discussed here in May and there was consensus that the city is not the primary topic. Firefangledfeathers (talk / contribs) 14:29, 11 November 2025 (UTC)
Replying here since I realize my oppose was a little snippy and I think this comment makes it clearer what you are getting at. My understanding is that you feel that WP:USPLACE is causing undue knee-jerk opposes to RMs like Orlando, Florida -> Orlando that you think would benefit the wiki. But the actual RFC reads like you asked ChatGPT "write me an RFC that will stop wiki editors from using WP:USPLACE to oppose my RM". That's probably why this RFC is getting so many opposes - we don't like having our time wasted. It would be more helpful to present clearer arguments at your RM next time (maybe share some of this clickstream data you mention). -- LWGtalk 17:32, 14 November 2025 (UTC)
Oppose I think there is benefit from nearly all US places having the state added. We also benefit from not discussing (too often) which cities should or shouldn't be exempted, which would definitely happen more if we pull in the list locally. I'd be more likely to support removing the AP list exemption and move the 29 cities to names with states. As mentioned above, primary redirects could still exist for cities whose names are the primary topic for that term. Skynxnex (talk) 19:10, 11 November 2025 (UTC)
One, no one is suggesting removing the "city, state" format. I suggested moving the standard to internal review/consensus for which use the state and which don't instead of relying on an external style guide. Two, the latter suggestion only makes sense if you're gonna do that with every country that also is broken down into counties or states, or even just a simple "city, country" format. Consistency is key here and is the entire premise of my starting this RfC. TrueCRaysball💬|✏️ 20:33, 11 November 2025 (UTC)
I never said anyone was proposing removing the City, State format. But given we have only 29 localities special cased currently (DC is its own thing), to me the implication is very strongly that this proposal is to allow more places to be named by just their name without state added.
I don't think that all countries need to have consistent rules for populated places. I think the US model might be good to apply to places like Canada and Australia (maybe others?) where the state-level subdivision matters more than in some countries. But in some places I believe it's generally seen as less of a part of the identity/name of the populated place. I think consistency within a country is more important and why I idly mentioned as both a reason to oppose this and maybe weigh people's willingness to rename things like Cleveland to Cleveland, Ohio. I doubt that is likely at this time.
I think you providing some examples of specific US place article titles that would be improved by this change may be helpful. But Myceteae's comment describing reasons why the status quo is probably better helps make specific examples somewhat unneeded. Skynxnex (talk) 01:57, 12 November 2025 (UTC)
Oppose. The current guidance is not broken and does not need fixing. Appealing to an external style guide is not inherently at odds with WP policy and practice. Much of the content in our naming conventions and MOS reflects and is consistent with external style guides and accepted conventions, even when these are not explicitly cited. Furthermore, consensus to adopt a particular external standard is valid. We do this explicitly in several places, such as (the admittedly controversial) MOS:FRENCHCAPS, and numerous naming conventions that refer to specific authoritative bodies to source appropriate article such as WP:NCFILM and WP:MEDTITLE. The whole section WP:USPLACE does incorporate local (US) customs, as does the entirety of Wikipedia:Naming conventions (geographic names). This does result in discrepancies between how cities in different countries are handled, especially in English-speaking regions where WP:ENGVAR considerations prevail. The AP Style guidance is authoritative, appropriate, and represents a specific application of broader guidance like WP:COMMONNAME to a particular subject area. Referring to a respected external source simplifies decision-making, harmonizes article titles, and prevents endless battles about when to drop the state. —Myceteae🍄🟫 (talk) 00:06, 12 November 2025 (UTC)
This RfC fundamentally misunderstands how USPLACE operates. I don't know if it is a misreading of the guideline or something to do with an llm, but it is backwards. USPLACE ignores WP:PRIMARYTOPIC, setting the standard as "Place, State". The AP-exceptions are the only place where WP:PRIMARYTOPIC is considered. The proposed change leads to the opposite impact that the rationale seems to want, so I suggest the RfC is closed as it cannot as proposed actually lead to a consensus for change. CMD (talk) 04:09, 12 November 2025 (UTC)
Oppose I agree with RGloucester that this would lead to a waste of editor time for little to no benefit to readers, with Myceteae that there is no procedural problem with the current situation, and with CMD that this RFC doesn't seem to have a coherent purpose. -- LWGtalk 16:00, 14 November 2025 (UTC)
Sympathize. I agree that the AP Stylebook is a pretty arbitrary way to determine which U.S. cities play by WP:PRIMARYTOPIC and which are exempt. I don't recall how I've !voted in the past, but it does seem like a cleaner solution would be to strike the AP stylebook, and either (1) apply WP:PRIMARYTOPIC as normal, or (2) require City, State for every U.S. city. If the argument is that "City, State" is the dominant convention, then there is no reason to have Baltimore coexist with Nashville, Tennessee. It should be Baltimore, Maryland, with Baltimore as a WP:PRIMARYREDIRECT. Or, allow Nashville as an article title (since it already redirects there). Either way would go a long way to eliminate the perennial move requests and RfCs like this one. The status quo is inherently unstable. But it's also very ingrained in Wiki-world. Dohn joe (talk) 21:49, 14 November 2025 (UTC)
Oppose. Wikipedia follows usage in reliable sources. Sometimes usage is unclear but in this case the AP list provides explicit guidance for usage in U.S. RS for U.S. cities. It’s unusual but not a problem. That said, I’ve long held US city article titles should be treated like all others: disambiguate only when necessary. The name of any city is just its name, not including the state name. It’s misleading and endlessly confusing to include the state name when it’s not needed for disambiguation. Redirecting a base name of any US city to a title disambiguated by state name sets a contradictory and confusing standard, leading to countless unnecessary conflicts and debates. Thankfully, most other topic-area-specific naming conventions have been refined to disambiguate only when necessary, but USPLACE remains an unfortunate exception. —В²C☎ 13:08, 16 November 2025 (UTC)
I would rather that we did away with WP:PRIMARYTOPIC. And that we do away with the exceptions list by moving all of those cities to the "City, State" format.--User:Khajidha (talk) (contributions) 12:33, 17 November 2025 (UTC)
I understand the impetus to do away with WP:PRIMARYTOPIC, but I think most proponents overlook a key benefit of the policy. The benefit is what it communicates to users about common usage. For example, our article on Paris being at Paris, rather than at Paris, France, conveys the useful information that the term "Paris", alone, normally refers to that city in English. Nobody says, "I'm going to Paris, France in July"; they say, "I'm going to Paris in July". Despite other common uses of the term, including the Greek god, the film, many other cities including the one in Texas, the way we refer to the city in France is justParis. To put it at Paris, France would be misleading about common usage in English. That's what Primary Topic is about; convey common English usage accurately. Let's not lose that. --В²C☎ 04:07, 20 November 2025 (UTC)
Oppose - If the policy still works, don't break it. Many articles with strong ties to a country, must have a strong style guide. Ahri Boy (talk) 08:28, 29 November 2025 (UTC)
Oppose While I see why you think this should be locally determined by principle, this isn't something that actually really matters that much in my opinion. The main importance is to avoid editors spending huge amounts of time arguing about it, and using an external resource solves that problem perfectly. As long as we have a decision that's ok it doesn't need to be perfect. Mrfoogles (talk) 16:59, 5 December 2025 (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.
Extended-Confirmed Topics and Dispute Resolution
Seems resolved. Case reopened by Robert McClenon per Toadspike's (correct) reply. ~ Jenson (SilverLocust💬) 19:46, 14 December 2025 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
A case was recently filed at DRN about an article about a legal case involving a transgender person. The article is currently subject to extended-confirmed protection. The filing editor is not extended-confirmed. I closed the case, because it is my understanding that editors who are not allowed to edit an article should not take part in dispute resolution about the article. I advised the filing editor that they can submit edit requests, but that is the extent of what they are permitted to do about the article. The filing editor has complained that this restriction is unfair, because they say that there is a factual error in the article. So I have two questions. First, was I right in closing the DRN request? Second, what advice can be given to the filer, who wishes to address a factual issue?
(In researching the case, I found that the filing editor had made a personal attack against another editor on the article talk page. I have warned the editor and collapsed the personal attack. This doesn't affect the questions.)
Robert McClenon (talk) 05:18, 10 December 2025 (UTC)
There is a difference between extended confirmed protection and the extended confirmed restriction. Extended confirmed protection is a protection level that can be used for a variety of reasons, including to stop vandalism or sockpuppetry. To my knowledge, it does not apply anywhere outside of the article which is protected, not even to that article's talk page. An extended confirmed restriction, part of several contentious topics designated by ArbCom or the community, applies everywhere.
This page falls under the CT/GENSEX and CT/BLP. Neither has an extended confirmed restriction. The page protection was placed by @Daniel Case under these CTOP regimes, which makes it easier for administrators to take admin actions to stop disruption. However, this is still not an extended confirmed restriction. Therefore, I don't think closing the DRN solely because the editor cannot edit the disputed page was appropriate. Toadspike[Talk] 09:58, 10 December 2025 (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.
LLM/AI generated proposals?
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Guideline clarified.
Wikipedia:No personal attacks and Wikipedia:Assume good faith are behavioral requirements for these discussions. When determining consensus, I disregarded the comments of Thryduulf, who clearly breached these requirements with comments like "If you don't want to be accused of making rabid assertions, don't make them." and "Your comment makes it clear that you have either not actually understood or are not listening to anything that contradicts your opinion." Comments from some other editors were mean-spirited or sharp-elbowed and were unpleasant to read, but to my ears did not rise to the level of an odious personal attack. Thank you to the many editors, especially later in the conversation, who addressed the merits of the questions asked and pointed out important nuances and came up with creative solutions.
This discussion started out with a question as to whether or not WP:HATGPT (aka WP:AITALK) should be extended to allow the closure of formal discussions when they are started with LLM-generated text, which is already allowed to be removed. Some editors made arguments that implied WP:HATGPT should be repealed. Other editors explicitly objected to doing that, or to accidentally creating an LLM exception to general rules about closing problematic proposals. Since that kind of repeal was not intended to be the scope of this discussion, and because consensus for that guideline is recent, I'm going to take it as a given that the existing guideline stays.
Many editors supported extending WP:HATGPT to cover the closure of formal discussions. Others claimed that it is already possible to do so under WP:CLOSE. Some wanted to avoid making closure automatic, in case a worthwhile discussion was in progress. There was also a lot of concern about biting newcomers, false accusations (intentional or accidental), harassment, wasting time on arguments about whether something is LLM-generated, and how feasible it is now and will be in the future to detect LLM-generated text.
A distinction was made between the proposal itself (which may need to be described in neutral words) and the proposer's persuasive rationale. Depending on the discussion type, the proposal could be a simple machine-readable list of what pages need to be deleted or renamed to what, or it could be new paragraphs to be added to a policy. Sometimes it's possible to strike an LLM-generated rationale (already allowed by WP:HATGPT) but leave a simple proposal up and the discussion open. Some editors worried about time lost responding to proposals that don't have any remaining rationale and maybe didn't have a coherent justification in anyone's mind in the first place. Leaving the appropriate action up to the discretion of a potential closer seems like a reasonable compromise between these concerns. Recovery is possible if the wrong decision is made, and facilitated by having a standard close message that invites the proposer to open a new discussion in their own words, or having other editors vote for a speedy close if that was more appropriate.
I feel comfortable saying there's a rough consensus for adding a clarifying language to WP:HATGPT that blends the concern that not all LLM use is bad with the concern that many LLM-written proposals are not worth discussing and drain volunteer resources in an asymmetric way. The fact that it's unclear whether this states something new or restates existing guidelines is a good sign that it closely follows previously established consensus. No specific language was proposed, so I've drafted this addition:
This applies to nominations and opening statements in formal discussions, which if struck may result in the speedy closure of irrelevant or disruptive discussions, per WP:CLOSE. If a worthwhile conversation has already started, it may be left open. The proposer of a closed discussion may be politely invited to start a new discussion using their own thoughts and words.
Please don't consider this close as saying these specific words are written in stone, but the gist of at least the first sentence should be maintained unless there's a future community discussion to substantially change the guideline.
There was a (disputed) request to have a 3-person panel close this discussion, but it's so long and complicated that no other closer has volunteered and it's become very overdue, so I just went ahead and did it.
In an attempt at performative irony, after reading it I tried to have ChatGPT summarize this discussion...but it was too long. (Ha!) To save others from having to read this whole conversation, some other highlights noticed by my capacious human brain were:
A huge discussion on making a guideline or policy for mandatory disclosure of LLM use or putting a warning banner or checkbox in the editing interface. This was intended to be in addition to policies about how to treat LLM-written contributions, such as WP:HATGPT. The discussion here was only to gauge support for a possible future RFC, not to enact an immediate policy change, so I leave that to interested editors.
Disclosure of the model manufacturer and version and prompt was suggested as a way to help build better LLM detection tools.
LLM use is a spectrum, from grammar checking to writing proposals from scratch. Some editors with dyslexia or who don't have English as a native language or similar motivations use LLMs as assistive tools to save time or communicate more clearly. Sometimes LLMs are used for background research, to suggest sources, or to do uncontroversial mechanical transformations like citation reformatting. Some argued that people who lack English skills to contribute without AI might do better to contribute to a different language Wikipedia, but others seemed to lean toward inclusivity.
Posting LLM-generated text was compared to hiring an undisclosed paid editor or letting another person use an editing account.
Competency is required (WP:CIR). It was debated whether LLM use was an inherent indication that the user is not competent enough to write the text themselves, and thus not competent to review the LLM output.
There was a debate over whether assume good faith requires the assumption that an editor checked LLM output before posting it, and separately whether LLM use was itself a demonstration of bad faith.
Debate about whether people learn from life experience that making LLM-generated posts is socially unacceptable or perfectly normal.
Some felt replying to LLM text was always a waste of time, others felt it was sometimes useful. There was an argumentum ad absurdum that if starting a discussion with an LLM was OK, then replying to that with an LLM is OK, and we might as well just automate the whole community discussion process.
Some felt it was important to set cultural expectations and take a stand against LLM use while it's still possible to detect, because it endangers the future of Wikipedia.
We had an RFC earlier this year around how to handle LLM/AI generated comments. That resulted in WP:HATGPT after further discussion at WT:TPG. Recently, an editor started a requested move using LLM generated content. I ran that content through two different AI/LLM detection utilities: GPT Zero says "highly confident", and 100% AI generated; Quillbot stated 72% of the text was likely AI generated.
Should HATGPT be expanded to allow for the closure of discussions seeking community input (RFC/VPR/CENT/RFAR/AFD/RM/TFD/RFD/FFD/etc) that are started utilizing content that registers as being majority written by AI?
I was tempted to just start an RFC on this, but if there's alternate proposals or an existing WP:PAG that already covers this, I'm all ears. =) —Locke Cole • t • c 00:38, 12 August 2025 (UTC)
I think this is a good idea. Editors shouldn't be required to waste their time whenever somebody posts LLM slop. voorts (talk/contributions) 00:42, 12 August 2025 (UTC)
I’m hesitant still with suggesting the use of gptzero except as additional evidence alongside with conclusive proof. But otherwise I’m always of opinion that most use of LLM in discussion is a bad faith usage of editor time. Bluethricecreamman (talk) 00:57, 12 August 2025 (UTC)
As I say every time things like this come up, the focus is completely wrong. We really should not care whether it is or isn't AI-generated, that's just wasting everybody's time trying to determine something that is irrelevant. If the proposal is understandable, relevant to the page it's on, isn't just rehashing something that's already been discussed to death (even if you disagree with it) then whether it was written by a human or machine couldn't be less relevant: deal with it as a good-faith contribution unless you have evidence it is not (use of an LLM is not evidence of good faith or of bad faith, it's completely independent of faith). If it is in bad faith, not understandable, trolling, rehashing a settled discussion, etc. then close it to avoid wasting time - this applies regardless of whether it is LLM-generated or human-generated. One of the many advantages of this approach is that it doesn't require any changes to policies or guidelines, because that's how Wikipedia has worked for many years. Thryduulf (talk) 01:00, 12 August 2025 (UTC)
"Fair" points perhaps, but not good points. Real editors who could be doing real things to benefit the project should not have to spend their time parsing machine-generate bloat in the hope that it will turn out to be the one-in-fifty case that isn't anywhere from fatuous vacuity to bullshit hallucination. The OP's linked example is an unfortunately poor exemplar of the problem, but anyone who's been active in project space over recent months has seen examples of text which makes you angry that someone expected you to waste your time reading it. You know how you can tell a tsunami is coming because the ocean suddenly recedes, leaving asphyxiating fish flopping on the sand? That's the stage we're at right now. We should respond to AI-generated text the way we'd respond to text in Klingon: tell the author to come back when they can write in English. EEng 01:32, 12 August 2025 (UTC)
EEng's statement above matches my own sentiment exactly, and I support the expansion of HATGPT to cover LLM-generated proposals. Comments in a discussion shouldn't be generated and neither should requests for discussion. fifteenthousandtwohundredtwentyfour(talk) 04:12, 12 August 2025 (UTC)
And take a look at this ANI discussion for a truly epic example of how one AI-drunk incompetent can waste hours of the time of a dozen competent editors. `EEng 02:41, 13 August 2025 (UTC)
"AI-drunk" reminds me of drunk driving. Cars a powerful and dangerous tool. We have licenses to operate, competence restrictions (age, eyesight), training courses, rules of the road, consequences for violations, etc.. the alternative is ban cars entirely because horses, public transport and walking work fine. -- GreenC 04:37, 15 August 2025 (UTC)
Except we don't have licenses, competence restrictions, training courses, rules of the road, consequences for violations, etc. for AI. All we have is doofuses careening left and right, knocking down pedestrians, tearing up the pavement, frightening the horses, jamming the roadways with their vehicles actually headed nowhere, and poisoning the air with noxious fumes. So yeah, until those issues can be addressed AI should be banned, and walking, cycling, horses, and public transit -- which have served WP very well to date -- will have to continue serve until AI gets to the point that it can magically transform those lacking competence in English, and/or an understanding of what an encyclopedia is, into useful contributors. EEng 23:39, 21 August 2025 (UTC)
I agree. LLMs are getting better, and we will very soon be unable to spot their output. We need to deal with problem posts and edits the way we always have. Donald Albury 01:43, 12 August 2025 (UTC)
Some guy at some company says his people have trouble recognizing fake videos with their naked eyes. So what? You want to throw in the towel right now based on that? EEng 03:40, 12 August 2025 (UTC)
Eh, I think the GPT-5 fiasco points to LLMs reaching a plateau in terms of "quality". I'm not worried. —pythoncoder (talk|contribs) 21:39, 13 August 2025 (UTC)
To some extent I agree, but just because LLMs aren't improving fast doesn't mean they aren't improving at all. Especially the biggest and most obviously identifiable tells remaining are likely to be improved on, even if the strategy of just making bigger and more powerful models no longer leads to large increases in performance. Loki (talk) 22:57, 16 August 2025 (UTC)
If it makes you feel better, pretend we're enforcing our existing policy on meatpuppetry to remove text written by somebodything other than the user account editing it onto the page. —Cryptic 01:57, 12 August 2025 (UTC)
I used to think that that agnosticism about the source of commentary is correct but I have changed my mind. The choice is not between using an imperfect heuristic like "is this LLM-generated" and sedulously evaluating the content of discussions. As others have pointed out, editor time is a limited and precious resource. Since LLMs make it easy for editors who would not have otherwise been able to do so to add superficially plausible content to a discussion, we can expect that volume of content to increase, without a corresponding increase in time to evaluate it. That means our standards for discussion are going to shift in the direction of being more BITEy and intolerant of imperfect contributions regardless of whether we adopt any rule regarding LLMs. If LLMs really do improve to the point of undetectability, as Donald Albury suggests, then we're probably going to be driven into a different set of heuristics with hard and stringently enforced limits on WP:BLUDGEON and so on. But for now, LLMs do seem to have a distinct "register", even if it's hard to prove with certainty, and I think it might be more fair to go after that while we can. Choess (talk) 03:43, 13 August 2025 (UTC)
@Thryduulf As I say every time you make comments like this, I disagree. The source matters and LLM use is evidence of bad faith, because it shows the editor doesn't care, doesn't respect the community's time, and is happy to outsource their brain to a machine. We should have a heavy bias towards proposals created by thinking, breathing humans, not something someone lazily asked a bot to slap together. The former has value, even if the proposal is dumb; the latter is slop and without any worth. Cremastra (talk·contribs) 13:45, 16 August 2025 (UTC)
LLM use is evidence of bad faith, because it shows the editor doesn't care, doesn't respect the community's time, and is happy to outsource their brain to a machine. I couldn't disagree with your rabid assertion (note it's not even an assumption) of bad faith more strongly. LLM use is not evidence of faith, good, bad or otherwise. What matters is the faith of the user, and that is not demonstrated by their using an LLM because some users of LLMs do so in good faith (for example those completely unaware of the attitude of some editors here towards it) while others do it in bad faith. Please stop assuming that everyone who has a different opinion of LLMs than you is inherently out to destroy Wikipedia - they are not. Thryduulf (talk) 13:53, 16 August 2025 (UTC)
You're calling my assertions rabid now? That's a new low. Cremastra (talk·contribs) 13:54, 16 August 2025 (UTC)
If you don't want to be accused of making rabid assertions, don't make them. Thryduulf (talk) 13:56, 16 August 2025 (UTC)
Good grief.
By the way, I don't assume that everyone who has a different opinion of LLMs than you is inherently out to destroy Wikipedia. I assume that (1) article contributions based on AI are bad for the encyclopedia, even if the intent is good, and (2) talk page contributions based on AI are evidence of bad faith, (3) that AI is a bad thing. Cremastra (talk·contribs) 13:59, 16 August 2025 (UTC)
Now for some facts:
Some, but not all, article contributions based on AI are bad for the encyclopaedia. Good contributions based on AI are indistinguishable from good contributions that have been nowhere near an LLM.
Some, but not all, talk page contributions based on AI are left in bad faith. Use of AI alone is not evidence of good or bad faith.
Not all AI is LLMs. Not all AI, and not all LLM, is bad (or good) - it is vastly more nuanced than that.
In effect, the AI/LLMs-on-Wikipedia debate is divided between those like you who want to assess the content of the contribution, regardless of its origin, and those like me who think it's just simpler to ban LLMs because they're a net negative and more trouble than they're worth. The upside of your approach is that it's less likely to chase away potentially positive contributors; the downside is that it means a lot of cleanup work and AI slop to manage. The upside of my approach is that it's clean, simple, and effective; the downside is that it is best suited for cynical, paranoid people like myself. Cremastra (talk·contribs) 15:45, 16 August 2025 (UTC)
In general I agree with your last comment, but I have a few quibbles:
it means a lot of cleanup work and AI slop to manage is incorrect. Slop will continue to be posted whether LLMs are banned or not for multiple reasons - not all slop is LLM slop, we have absolutely no way of determining whether something is or is not LLM-generated before it is submitted, and bans don't stop people doing the thing that is banned (either in good faith because they don't know it's banned, or in bad faith because they do it anyway). Fortunately we already have all the tools we need to manage this as best we already can: slop can be closed/hatted/reverted (as appropriate to the situation) regardless of whether it is LLM-slop or human-slop, disruptive non-slop can be closed/hatted/reverted (diito) regardless of whether it is LLM-disruption or human-disruption. So in summary neither approach changes the amount of cleanup work required.
Your list of downsides to your approach neglects to include the significant harm to the project from driving away good-faith editors and the amount of needless disruption caused by arguments over whether something is or is not LLM-generated.
dividedWell... going by the outcomes of the last half dozen LLM P&G RfCs, I'd say this division is like an 80/20 split in favor of "ban all LLM slop", and closer to 90/10 if the opposition is at Thryduuulf's level... Anyway, it's not like copy-pasting LLM output in conversations or as scholarship is considered "okay" in the wider world, in which case we could AGF a bit more for newbies who don't realize it's not acceptable here. So frankly I have no qualms about biting an editor who needs an unfiltered LLM to communicate as they are either too lazy/incompetent to be a productive editor or they belong in a different language edition. JoelleJay (talk) 18:51, 16 August 2025 (UTC)
I am not okay with endorsing the biting of any editor, for any reason, let alone enshrining a requirement to do so in policy. Such is fundamentally incompatible with Wikipedia's basic philosophy and I'm horrified that people are seriously considering it. Thryduulf (talk) 20:40, 16 August 2025 (UTC)
The UPEs must love you... JoelleJay (talk) 05:33, 17 August 2025 (UTC)
I agree with Tryptofish's comment here on the matter. Correct me if I'm wrong, but I think you see LLMs and generative AI as a valid tool that can be misused; I, and many others, I think, see it as a tool that is fundamentally not appropriate for editing an encyclopedia. Cremastra (talk·contribs) 16:07, 17 August 2025 (UTC)
I think you see LLMs and generative AI as a valid tool that can be misused... yes and no. The current generation of LLMs are unsuitable for making edits to the text of articles without full human review (AI-generated images are not really relevant to this particular discussion and are best treated separately anyway); whether LLM+human review is more or less "efficient" than a fully-human edit is a matter of personal opinion that is likely to be impacted by the nature of the specific edit. In most, but importantly not all, cases unreviewed LLM-based contributions to talk pages are not a net benefit. However this misses the fundamental reasons I disagree with you, which is that you see any use of LLMs as automatically meaning that the person using the LLM is contributing here in bad faith whereas I see evidence of people using LLMs here in both good and bad faith. Specifically there are many people who make LLM-based comments with a sincere desire to improve the encyclopaedia without knowing that there are many editors here whose views regarding AI are so blinkered that they cannot or will not consider that someone can do such a thing.
My response to Tryptofish's comments are similar: we do not BITE those who are incompetent or NOTHERE because we give them a chance to demonstrate that they can contribute constructively before blocking them, and when we do block them we do so on the basis that they either cannot or will not do so. That is fundamentally different to someone who currently is not contributing in a manner we approve of but who may (or may not) be capable and willing to when they learn what that means - if it turns out that they cannot or will not then it is appropriate to deal with them in the same manner we treat those who are incompetent or NOTHERE but who do not use LLMs. Simply using an LLM is not evidence, on its own, of bad faith, incompetence or of not being here to improve the encyclopaedia.
UPE is also similar in this regard - while there are unarguably many undisclosed paid editors who are here in bad faith there are also such editors who are here in good faith but simply do not know our rules and do comply when they learn that they need to (and how to do that). There are additionally an unknowable number of undisclosed paid editors who exclusively make good quality contributions to unquestionably notable topics such that nobody even suspects they are paid editors and they never learn they should disclose. So again, simply being an undisclosed paid editor is not evidence, on it's own, that one is here in good or bad faith.
Separate from the issue of faith is that, as multiple other people have also pointed out, is that contributions that are actually bad, whether LLM-generated or not, can already be dealt with under existing policies and guidelines so there is simply no need for a policy/guideline specific to LLMs. Thryduulf (talk) 09:15, 18 August 2025 (UTC)
It is not a question of whether an LLM comment is necessarily bad and therefore should be removed. The point being made is that nearly all LLM comments are disruptive because of their length and thrown-at-the-wall details (and the fact that they are rarely helpful). Replying to such comments would require significant effort. Further, there is a good chance that replies will be ignored by the editor concerned. Debating LLMs would lead to their normalization which could easily overwhelm talk pages and noticeboards. Johnuniq (talk) 10:55, 18 August 2025 (UTC)
Comments that are disruptive can already be hatted/removed regardless of why they are disruptive and regardless of whether they are LLM-generated or not. Comments that are LLM-generated but not disruptive (which you acknowledge exist) should not be removed. Thryduulf (talk) 11:11, 18 August 2025 (UTC)
Comments that are LLM-generated but not disruptive (which you acknowledge exist) should not be removed. I disagree. I think it is not too much to ask to communicate with actual human beings. Talking with an actual user as opposed to through the screen of an LLM makes communication a lot easier. Cremastra (talk·contribs) 14:12, 18 August 2025 (UTC)
Then you are in luck, an actual person will be the one that posted the content and the one you are talking with. LLMs do not post on their own, they all require human thought and input. Thats how they work. PackMecEng (talk) 14:21, 18 August 2025 (UTC)
That’s not entirely accurate. While it’s true that an LLM doesn’t autonomously log in and hit “submit,” it’s misleading to suggest that posts generated by an LLM are purely human in origin. In practice, many edits and comments across platforms are authored almost entirely by machine output, with minimal or even no meaningful human oversight. The “input” may just be a short prompt, but the bulk of the content—including the structure, wording, and even factual framing—comes from the model.
Equating that to “human thought” risks blurring the distinction between genuine human authorship and machine-assisted or machine-generated text. Saying “an actual person posted it” ignores that the human role might be closer to pressing a button than actually creating the content. That distinction matters if we care about originality, accountability, and reliability of information. CMD (talk) 15:07, 18 August 2025 (UTC)
And if we know that they did not check what they are submitting you would be correct. But we cannot know that. Its just assuming bad faith at that point. So we go off the assumption that when someone hits submit they checked what they are posting. There is no other option. So yeah, I am going to ignore the distinction because it has no value and does not matter. PackMecEng (talk) 16:33, 18 August 2025 (UTC)
That’s not entirely accurate. It’s misleading to suggest that posts generated by an LLM are human in origin simply because a human hit the submit button. In practice, many edits and comments across platforms are authored almost entirely by machine output, with minimal or even no meaningful human oversight. The “input” may just be a short prompt, but the bulk of the content—including the structure, wording, and even factual framing—comes from the model.
Equating that to “human thought” risks blurring the distinction between genuine human authorship and machine-assisted or machine-generated text. Saying “an actual person posted it” ignores that the human role might be closer to pressing a button than actually creating the content. That distinction matters if we care about originality, accountability, and reliability of information. -- LWGtalk 17:39, 18 August 2025 (UTC)
Equating that to “human thought” risks blurring the distinction between genuine human authorship and machine-assisted or machine-generated text. firstly there is a strong community consensus that machine-assisted and machine-generated text are not the same. There is a strong community consensus that the former is not inherently problematic, and a lesser consensus that only unreviewed LLM-generated text is.
Regardless, there is no benefit to making any of these distinctions because if the text is disruptive it can already be removed regardless of which of the three types it is. Nobody has given any justification for removing text (of any origin) that is not disruptive. Thryduulf (talk) 17:42, 18 August 2025 (UTC)
LLM-generated content, and even comments with a significant LLM assist, are disruptive because they are not written by a real human being. Is it too much to ask to communicate with people as opposed to having users export their minds to an AI? Is that really so radical? I simply cannot understand your perspective on LLMs. How is using an LLM to communicate ever appropriate? Cremastra (talk·contribs) 18:07, 18 August 2025 (UTC)
@Thryduulf I agree with you that there is a distinction between machine-assisted and machine-generated text, and that the former is not inherently disruptive. I also agree with the strong community consensus (against which you appear to be one of the few dissenting voices) that unreviewed LLM-generated text is inherently disruptive and is unacceptable on this wiki (though I share your concerns about feasibility and enforcement of some of the countermeasures that have been proposed).
I think where we differ is in our view of text that falls between the extremes. I think your insistence on ignoring source and judging text entirely on content disregards the fact that a large part of the meaning of any text is its surrounding context. The same text can be disruptive if it comes from one source in one context while being fine from a different source in a different context. One of the most essential pieces of context in any communicative act is who is the speaker. We already have firm rules here that it is totally unacceptable for editors to outsource their writing to a hired human, so I see no reason why we should tolerate outsourcing to a SaaS that does the same work. Likewise, we consider that any editor who copy/pastes content from an external website has an obligation to disclose where they copy/pasted the content from and their rationale in doing so, and I see no reason why we should tolerate undisclosed copy/pasting from an external website that dynamically generates the content on demand. I recognize that there's fuzzy space in the middle and I recognize that we should be cautious when making new rules, but I think your treatment of the issue is incomplete. -- LWGtalk 18:40, 18 August 2025 (UTC)
I agree with Thrydulf. Donald Albury 21:25, 16 August 2025 (UTC)
Another consideration is copyright. If an editor posts an article that they did not write, that would seem to violate the existing copyright rules of Wikipedia. I was going to dig into the legal side of it, but got stuck on the answer that Google's AI came up with: "Copyright protection requires human authorship; works generated solely by AI are not copyrightable, but works that are assisted by AI can be if a human exercises sufficient creative control over the final output." I though this was actually a good starting point for policy, that is, the concept of "sufficient creative control". Rublamb (talk) 20:09, 26 August 2025 (UTC)
Wikipedia's legal policies don't require that every edit be copyrightable. It's okay to post public domain and non-copyrightable edits.
What we need is to not violate copyrights. If there is no copyright to be violated (something that can be difficult to determine), then there's no violation of our legal policies. However, we could always complain about Wikipedia:Plagiarism (a non-copyright problem of claiming that you wrote something when you didn't). WhatamIdoing (talk) 19:57, 27 August 2025 (UTC)
Yeah, we should invent a slur for people who use pocket calculators. jp×g🗯️ 19:50, 13 September 2025 (UTC)
Oppose (kind of): I support the idea in theory. But the linked move request would have been WP:SNOW closed as oppose anyway. What happens if someone posts a LLM-generated RfC that people support (which will likely happen)? Or if someone posts a LLM-generated RfC on a perpetual source of drama, and people respond to it before the LLM use is noticed (which will also, maybe even more likely, happen)? Gnomingstuff (talk) 06:54, 12 August 2025 (UTC)
Current practice for discuassions that don't need closing seems to be someone asks if llm was used, and then either it is rather unbelievably denied, or there is some pivot to "you should focus on the argument rather than the method" which I'm pretty sure llms must be offering as a reply given how consistent it is. After that the discussion tails off. For those that do need closing and would otherwise linger wasting everyone's time, I would agree with the proposal that the guidelines should allow someone to quick close them, while not making it mandatory. CMD (talk) 07:18, 12 August 2025 (UTC)
Broad support as a guideline, given this has moved towards bolded !votes below. CMD (talk) 11:09, 15 August 2025 (UTC)
If LLMs are to be allowed to generate such requests then simply ask an LLM to generate a reply based on your position, make sure to ask it to give detailed explanations now all the points it raises. If it's the case then maybe someone could create a script to autogenerate comments, or even the whole discussion. Editors shouldn't be expected to put more effort into replies than the original poster put into theirs. -- LCU ActivelyDisinterested«@» °∆t° 09:37, 12 August 2025 (UTC)
I admire your good sense to troll back basically. =) —Locke Cole • t • c 03:12, 13 August 2025 (UTC)
If generating the original comment using an LLM isn't trolling then neither is the reply. If the reply would be trolling then the original comment should be hatted. If people think that editors should be allowed to use LLMs, then streamlining the process so everyone can use them is surely desirable. -- LCU ActivelyDisinterested«@» °∆t° 14:41, 13 August 2025 (UTC)
I would tend to support this, although with two caveats. Firstly, that AI detection software, while useful, isn't perfectly accurate and shouldn't be exclusively relied on for that purpose. And, secondly, that proposals getting reasonable support shouldn't be closed just because the original proposal was AI-generated, while those with no support can be immediately closed based on that.The main issue for me (and the reason why I believe this is not comparable to existing human-written discussions) is that it is trivially easy to generate long proposals with AI, and that it comparatively takes a much larger amount of volunteer time to analyze (and usually dismiss) these proposals. This imbalance is simply not fair to our volunteers, and having to repeatedly deal with AI-generated proposals will just slow down community discussions and divert precious resources from more well-thought proposals. Chaotic Enby (talk · contribs) 13:21, 12 August 2025 (UTC)
Support - To address the concerns about good proposals written with AI being closed, if it's so obvious a good idea, it would certainly be proposed quickly anyway. I don't think the benefit of a theoretical wonderful AI-written proposal that wouldn't be suggested anyway is worth the massive downside of giving any kind of additional foothold to LLMs. LLMs are an existential threat to Wikipedia as a useful project, and I see it as our mission to stop it wherever it is possible to do so.CoffeeCrumbs (talk) 17:28, 12 August 2025 (UTC)
Support speedy-closes of formal discussions created primarily/entirely by chatbot - It's highly unlikely the people using the chatbots are willing (assuming they're able) to make coherent arguments based on policy and a reading of the available sources, but if they are there's no reason to bring in a fallible script that's huffing nutmeg. Even the most perfunctory human-written discussion is better than a long AI-written post simply because the human is far better at source critique and rebutting opposing arguments. As Enby says above, I wouldn't support speedy-closing any discussion which has already attracted some amount of commentary before its provenance was discovered. —Jéské Courianov^_^vthreadscritiques 17:50, 12 August 2025 (UTC)
It's highly unlikely the people using the chatbots are willing (assuming they're able) to make coherent arguments based on policy and a reading of the available sources, but if they are there's no reason to bring in a fallible script that's huffing nutmeg.–Yes, this is another excellent point. I believe our attitude should be that use of AI to generate either article text, or discussion text, is ipso facto proof of incompetence as an editor -- because no competent person would think that AI-generated text is a useful contribution -- and should result in an immediate indef. I am not kidding about this. Shoot to kill. (Unblock only after a clear statement that they now understand the issue, but a second offense should be another indef, with a minimum 12 months before unblock may be re-requested).As for the wikt:bleeding hearts who worry about people who would not be able to contribute without relying on AI to write for them: well, if you can't write it yourself, neither can you review what AI wrote for you, so I'm afraid we can't use you on the project. EEng 22:25, 12 August 2025 (UTC)
I'm frankly astounded and appalled by this attitude. Whatever happened to WP:AGF, WP:BITE and the other half dozen or so things you've tossed by the wayside in your haste to hate? Thryduulf (talk) 23:05, 12 August 2025 (UTC)
Questioning someone's competence is not questioning their good faith, but stupid sincerity is not enough. And I do not apologize for BITE-ing a robot, even if it speaks through a ventriloquist's dummy in human form. To paraphrase someone that I'm not likely to quote ever again: Extremism in defense of Wikipedia is no vice. Moderation in tracking down and stamping out AI-generated crap posted by script kiddies is no virtue..If we don't take dramatic action immediately, our cherished Neutral Point of View will soon give way to the Neural Point of View. (You can use that quip free of charge.) EEng 01:00, 13 August 2025 (UTC)
P.S. I dare anyone to take a gander at this ANI discussion and not be angry at the time wasted by competent editors who are forced to wade through the AI slop being posted -- and defended! -- by this one incompetent. And I have no problem calling him incompetent, since he obviously lacks common sense. EEng 02:41, 13 August 2025 (UTC)
Dare accepted. I'm more angry at the people who are choosing to insult editors on a project page while yapping about how we "must take dramatic action immediately," instead of taking dramatic action immediately. Be the change you wish to see in the world. Gnomingstuff (talk) 04:24, 13 August 2025 (UTC)
Yeah, I don't people realize how bad the problem has already gotten. A lot of the AI slop has gone undetected despite being blatant; you can't really say anyone's being "forced to wade through the AI slop" considering how few people are actually wading through it. I haven't even really done much to fix it myself -- my main skill is tracking down and identifying problems, and I'm OK with that. (Maybe I should have been an auditor.)
But the AI cleanup backlog jumped from ~100 AI articles to ~400 in a couple of days, not due to a sudden influx of slop, but because I singlehandedly found 300 instances of slop that was already there. This isn't me being self-aggrandizing, just stating the facts. I didn't use any special tools besides a few simple targeted regexes -- I typed phrases we already know about into the Wikipedia search box and investigated the obvious cases. Anyone else could have done the same thing anytime in the past 2 years, rather than insulting people who often really do genuinely think they are helping the encyclopedia, sometimes because they've been encouraged to do so through edit-a-thons, Wiki Ed courses, or the Wikimedia Foundation itself. Their edit summaries often mention "improving the encyclopedia," "rewriting for a neutral tone," etc.
(Also, for what it's worth: WP:CHATGPT is not actually policy, although arguably it should be. WP:CIVIL is.) Gnomingstuff (talk) 17:01, 13 August 2025 (UTC)
I've literally been tracking down hundreds of AI-generated articles for the past several days. Please don't tell me what I do and don't worry about. Gnomingstuff (talk) 23:08, 12 August 2025 (UTC)
If you're addressing me: I didn't tell you or anyone else what they worry about. I addressed any editors who happen to harbor a particular worry which I specified, and discussed that worry. EEng 01:00, 13 August 2025 (UTC)
+1 to everything EEng has said. AI contributions have no value, and I'm tired of people tip-toeing politely around AI slop and pretending it's something other than a steaming garbage heap. Quite frankly it smells of appeasement. Cremastra (talk·contribs) 13:52, 16 August 2025 (UTC)
Except we're not tip-toeing politely around AI slop we're pointing out that AI slop can be dealt with under existing policies and guidelines because all slop can be dealt with under existing policies and guidelines regardless of whether it is human slop or AI slop. Thryduulf (talk) 13:55, 16 August 2025 (UTC)
Irrelevant - given that the actual proposal at an RM is simply “current title —> proposed title”, I don’t think it matters if someone uses an LLM to generate it. Similarly, an RFC question/proposal is supposed to be brief and neutral (example: “Should the article say ABC instead of XYZ?”) and, again, I don’t think it matters how that basic question is generated (In fact, I would love to train LLMs so they generate RFC questions this way).What I think is actually being objected to is using an LLM to generate the proposer’s opening statement (explaining why they think the move should take place, or why ABC should be replaced with XYZ) … but that is commentary on the proposal, not the proposal itself… and commentary is already covered by HATGPT. Blueboar (talk) 19:04, 12 August 2025 (UTC)
That is correct, and it's because the opening statement is essentially the proposer's argument for why XYZ should happen. It isn't something an LLM actually has the capacity to summarise or explain in most cases, especially if offline sources are being used for the argument (as LLMs generally cannot access those); using one for the purpose basically forces the proposer to waste time clarifying whatever the LLM said than actually defending their proposal, and that's outright ignoring the LLM's divinorum addiction. —Jéské Courianov^_^vthreadscritiques 21:06, 12 August 2025 (UTC)
But HATGPT already says we should discount comments generated by LLMs. So what is the point of this proposal? Blueboar (talk) 21:17, 12 August 2025 (UTC)
But HATGPT already covers this. We can discount comments generated by an LLM… It doesn’t matter whether that comment is the initial comment (by the proposer) or a subsequent comment (by an editor responding to the proposal). Blueboar (talk) 12:41, 13 August 2025 (UTC)
But, if someone opens a proposal and their original comment gets collapsed, should other volunteers have to spend their time opposing the proposal? That's the question this new policy tries to answer – they shouldn't. From what I understand, HATGPT would leave the proposal open (and taking volunteer time from more relevant proposals), just without the opening comment. Chaotic Enby (talk · contribs) 13:06, 13 August 2025 (UTC)
@Chaotic Enby: That's the wrong question. At present, without any change to any guideline or policy, editors already do not have to spend their time opposing any struck/collapsed proposal, even if a human had written it. We already can speedily close; a guideline saying "you can" when a policy already suggests "you should" (that policy being WP:NOTBURO) would be a bad guideline. If there is no driving rationale for a change from the status quo in the discussion, and everyone is supporting the status quo—and there is therefore no controversy—the formal process is a waste. Editors can keep talking about how they all agree that something is okay "in their spare time", not using resources of venues such as AfD, RM, etc.: The scaffolding of "7+ days' listed specifically-formatted discussion that must be closed" is not needed. Such processes are closed with a speedy endorsement of the status quo (such as Wikipedia:Speedy keep—an existing guideline about this). NOTBURO says: "Disagreements are resolved through consensus-based discussion, not by tightly sticking to rules and procedure". So, yes, some constraints of "rules and procedure" may help consensus-formation develop more harmoniously because there is disagreement (which may be accompanied by a little bit of tension and a human tendency to stonewall or overstep, especially when advanced tools with limited access are involved) ... but if there is no disagreement, why any rules, and why any procedure? The driving rationale for a change can evaporate in any discussion, turning a (seemingly or truly) controversial issue into a non-controversial one, and this can happen in a variety of ways. One such way is withdrawal/reversal of a !vote. Another is the nomination/comment being struck: ban/ARBECR violation, sockpuppetry, meatpuppetry, trolling, and AI content—already in WP:AITALK. So the only change might be: Should AI use be exempt from this general logic, and should editors become obligated to treat struck AI content as nominations/comments that are not struck. So this is fundamentally a relitigation of AITALK: If they are struck, but editors must begin to behave as if they were not, the striking of AI comments becomes striking in name only (just a visual change, no functional difference) and AITALK is effectively abrogated. So the proposal in this discussion is to overturn AITALK with the detail of leaving functionally meaningless striking-in-name-only in place. Blueboar is entirely correct. This discussion is badly framed and its no consensus outcome could improperly undermine AITALK.... and the oppose !votes reflect this, as they intuitively understand the stakes. So, for example, below, opponents say: Unless a detection method is found that is consistently accurate I don't really trust others vibes to remove users votes in something, I think any procedure such as hatting suspected LLM-produced material has the potential of encouraging the biting of newcomers, and similar. So, comments should not be struck/collapsed ("removed"). That is just a !vote to abrogate AITALK, indistinguishable from a comment opposing adoption of AITALK in a discussion on whether to adopt AITALK ... but AITALK has already been adopted. Now, editors are building consensus for AITALK again, trying to persuade opponents of AITALK that it should be understood to mean what it already means. As these opponents oppose AITALK to begin with (because of a total skepsis toward the possibility of doing something about the AI problem / deeply-held view that it is not a problem), they will of course never be persuaded about some particularity regarding the application of this thing that should not be a thing and will embrace the premise that the thing is toothless and that a consensus is needed to give it teeth. At the same time, supporters of AITALK will not !vote in favor of AITALK-as-AITALK (aware or unaware of its practical implications) believing that their support is not needed because it has already been adopted. Therefore, this time, acceptance of AITALK will fail. The starter of this discussion wanted to make AITALK "stronger", but instead caused it to be undone. This is why RfC questions need to be neutral and need to contain a proposal to change the status quo without misrepresenting the status quo. —Alalch E. 23:58, 21 August 2025 (UTC)
This also gives AI comments extra priority and durability over human comments: While a human comment being struck could cause a discussion to be closed, an AI comment the same as that human comment being struck cannot cause a discussion to be closed, because showing this RfC to the errant speedy closer should lead that closer to concede that they acted in error, against community consensus, because treating struck AI votes the same as struck human votes is a rejected proposal: namely, policies and guidelines do notallow for the closure of discussions seeking community input (RFC/VPR/CENT/RFAR/AFD/RM/TFD/RFD/FFD/etc) that are started utilizing content that registers as being majority written by AI—the accepted status-quo premise of this discussion. —Alalch E. 00:36, 22 August 2025 (UTC)
WP:CCC, as to The starter of this discussion wanted to make AITALK "stronger", but instead caused it to be undone, it was not my intent to undermine AITALK whatsoever. The language at AITALK definitely could have been written better to make clear there was already a consensus for this. And the only reason this was turned into an RFC was because of the constant bolded !votes. I had a feeling I didn't understand the full history of AITALK/HATGPT, hence why I explicitly said I was looking for feedback in advance of a proposal. —Locke Cole • t • c 00:48, 22 August 2025 (UTC)
A panel will be needed to fix the mess. —Alalch E. 00:50, 22 August 2025 (UTC)
I do agree with your analysis, although I don't think WP:NOTBURO says "we should" to anything. But yes, if anything, AITALK should be at least retained: the current discussion is not specific enough to find a consensus to revert it in part or as a whole.However, as the example that started this whole discussion showed, I don't think AITALK made it explicit enough that hatted AI content was to be treated as a struck nomination and explicitly allowed for an instant closure. The spirit of the policy certainly did, but the letter didn't, thus this discussion. Mostly because "the spirit" is something vague and, ultimately, a bit subjective. And having the policy itself make it explicit would remove this disagreement. Chaotic Enby (talk · contribs) 10:38, 22 August 2025 (UTC)
I'm pretty sure the LLM generated the entire request. If you go back to the diff I posted, go look at that page as it looked during the first edits: they inserted it into the wrong place on the page, and I get the impression it didn't know how to fill in certain fields so it left some blank. But if it makes any difference, I also object to the "opening statement" being majority-written by an LLM. —Locke Cole • t • c 03:14, 13 August 2025 (UTC)
By "entire request", you mean only the first of the 10 comments posted in that RM by the newbie, but none of the significant and substantive arguing you and the OP did over (a) the actual question and (b) whether an LLM was used in the first comment, right?
I'm somehow getting a different feeling about which part was the waste of time. WhatamIdoing (talk) 03:54, 13 August 2025 (UTC)
Support — Blueboar presents a convincing enough argument in favor of this proposal. I consider this to be an extension of existing policy. Talking about discussions over whether a proposal is AI-generated should be conducted in criticisms of the existing HATGPT rule. elijahpepe@wikipedia (he/him) 03:38, 13 August 2025 (UTC)
Support clarifying existing policythis wasn't a formal RFC when I initially commented and as of now it's unclear what exactly people are !Voting on to make it clear that using an LLM to generate opening statements of discussions is just as unacceptable as using an LLM to generate replies. As Cryptic alluded to above, using LLM to generate substantive content in discussions (as opposed to minor copyediting/formatting) is essentially the same or allowing someone else to log in and edit using your account. If we do not allow editors to direct their (human) personal secretary to edit on their behalf, why would we tolerate the same conduct when the secretary is replaced by an LLM? Or, from a different angle, content that is substantively copy/pasted from LLM output should be treated like content that is copy/pasted from other sources, which if not attributed goes against WP:PLAGIARISM. Policy aside, I believe any editor who generates content wholesale with an LLM should as a matter of courtesy/transparency indicate that they have done so, and indicate the model and prompt used. -- LWGtalk 18:34, 13 August 2025 (UTC)
why would we tolerate the same conduct when the secretary is replaced by an LLM–What we're seeing in AI use is way worse than that. It's less a human using an AI secretary to generate content, and more an AI entity using a human (or ventriloquist dummy in human form) to post its content. It's not a human using AI -- it's AI using humans. EEng 19:53, 13 August 2025 (UTC) P.S. BTW, indicating the model and prompt used isn't enough, since in general an LLM's response to whatever you just asked it is shaped by the entirety of one's prior interactions with it.
I think you'd be fully within your rights to close that discussion per existing consensus. If anything, the text at WP:HATGPT is too watered down from the RfC closure, which said that "if a comment is written entirely by an LLM, it is (in principle) not appropriate". IMO, something to that effect should be added to the policy text. —pythoncoder (talk|contribs) 21:45, 13 August 2025 (UTC)
I also agree with making that change to the text. Chaotic Enby (talk · contribs) 11:19, 14 August 2025 (UTC)
Whether or not we need to expand HATGPT, I'm all in favor (aka support in a broad sense) of shutting down any discussion that wastes the community's time, and anything that resulted from some software "thinking" about it, rather than a human thinking about it, falls in the category of shut-it-down. Base it on IAR, or base it on common sense. I see some pearl-clutching about BITE and AGF, but that strikes me as so 2024. We are facing something that can scale to a magnitude that we will be unable to deal with it, unless we are realistic about the need to deal with it assertively. --Tryptofish (talk) 23:08, 13 August 2025 (UTC)
Just to add to my previous comments… If it is felt that HATGPT needs to specify that it applies to the explanatory language of a proposal as well as subsequent comments, I don’t object to amending HATGPT. Blueboar (talk) 00:06, 14 August 2025 (UTC)
Seeing the ongoing disagreements about BITE, something additional that occurs to me is that the community has long been at least reasonably comfortable with WP:Competence is required. It seems to me that editors who feel like the only way that they can participate in the community is by letting LLMs do their writing for them are running afoul of competence. (I'm referring here to LLMs, not assistive technologies such as screen readers.) We don't regard it as a BITE situation when we issue a WP:NOTHERE block, and I think that a user who equates LLM-generated content with encyclopedic content is likely to be not-here. --Tryptofish (talk) 22:14, 16 August 2025 (UTC)
Support. WP:AITALK already allows for the collapsing and striking of LLM-generated proposals, since they are a subset of LLM-generated comments, but this particular bullet point does not yet comment on whether the ensuing discussion should be closed. Discussions that lead with LLM-generated comments are often unconstructive, and frequently devolve into arguments about LLM use or bludgeoning with additional LLM-generated comments. Since there appears to be some uncertainty about whether LLM-led discussions can be closed, WP:AITALK should be amended to clarify that they can be, per a combination of the existing WP:AITALK text and this portion of the Marking a closed discussion section: "If a discussion has been so disruptive or pointless that it is better for editors to waste no further time even looking at it, the alternative templates {{Hidden archive top}} and {{Hidden archive bottom}} can be used instead, to produces a similar 'closure box' around it, but collapsed to hide the content, as with off-topic threads", although any collapsible template would work. An editor who posts an LLM-generated proposal can resubmit the proposal if they manually write it in their own words.I also support Pythoncoder's suggestion to have WP:AITALK explicitly designate LLM-generated comments as inappropriate, in line with the consensus at Wikipedia:Village pump (policy)/Archive 199 §LLM/chatbot comments in discussions. In practice, LLM-generated comments are already recognized as disruptive, especially when undisclosed. —Newslingertalk 07:57, 14 August 2025 (UTC)
Oppose - Unless a detection method is found that is consistently accurate I don't really trust others vibes to remove users votes in something. It is important to remember the previous consensus on the topic, specifically The word "generative" is very, very important here, though. This consensus does not apply to comments where the reasoning is the editor's own, but an LLM has been used to refine their meaning. Editors who are non-fluent speakers, or have developmental or learning disabilities, are welcome to edit here as long as they can follow our policies and guidelines; this consensus should not be taken to deny them the option of using assistive technologies to improve their comments. In practice, this sets a good lower bound for obviousness, as any comment that could conceivably be LLM-assisted is, by definition, not obviously LLM-generated. In practice most LLM-assisted comments are not noticed because it does not actually matter. Anything else can be dealt with existing policy. I am similarly not convinced by the pearl clutching on wasting editors time, Wikipedia editors have been able to do that for decades without using LLMs and the addition of them has not been a noticeable uptick in it that I can tell. This is not some crazy crisis that will doom the pedia, it is a tool, nothing more. The usual garbage in garbage out applies in most issues with using the tool. PackMecEng (talk) 00:33, 15 August 2025 (UTC)
@WhatamIdoing This quote and archive link might be what you were asking about on my talk page. @PackMecEng, you might consider what @Gnomingstuff has shared above, the amount of LLM content being found in articles has increased significantly, and usage of it on talk pages is only going to get worse. You call it pearl clutching, but if the scale of LLM use increases then it will be a significantly bigger time sink for Wikipedia editors. At what point do we all just shut off our browsers and just let LLM's argue back and forth on our behalf with a sentence or two to get them started? I edit and comment on talk pages because I want to interact with other editors, not people running chatbots and copying/pasting their responses or proposals in bad faith with little actual time investment on their part. —Locke Cole • t • c 00:42, 15 August 2025 (UTC)
If you don't want to interact with a comment/user then don't interact with that comment/user, nobody is forcing you to do that. Thryduulf (talk) 02:13, 15 August 2025 (UTC)
What a lame cop-out. You could say the same thing about anyone who stirs the pot in nonproductive ways -- "Well, no one's forcing you." But someone has to deal with AI-generated vapid crap proposals, discussion posts, and so on. No matter who grits their teeth to do it, it's time that could have been productively spent elsewhere. EEng 03:41, 15 August 2025 (UTC)
But someone has to deal with AI-generated vapid crap proposals, discussion posts, and so on. firstly no they don't - such posts can be simply ignored by everyone, but secondly if someone does choose to deal with them then can do so under current policy without needing this proposal. Thryduulf (talk) 10:50, 15 August 2025 (UTC)
If everyone ignores it because of AI crap, then the clueless (or malicious) AI user declares WP:SILENCE and makes a misguided change. Then someone has to deal with it, if only by reverting. Anomie⚔ 12:08, 15 August 2025 (UTC)
Eh probably not though right? Could that happen? Sure, just the same as someone making a terrible proposal, but is it likely to get no push back? Almost certainly not, this is the internet amd the need to be right is far too strong. PackMecEng (talk) 13:16, 15 August 2025 (UTC)
Thryduulf was suggesting everyone can ignore the proposal. I followed that idea to a logical conclusion. Anomie⚔ 21:09, 15 August 2025 (UTC)
You can claim SILENCE, but the next editor can revert you, which is proof that there's no silent agreement. Additionally, some proposals (e.g., "Let's have a new guideline") require active support, not just the absence of objections. WhatamIdoing (talk) 18:00, 16 August 2025 (UTC)
Yes. And then the LLM-user throws a fit because they were reverted without discussion, and people have to engage further. Anomie⚔ 00:12, 17 August 2025 (UTC)
I can attest that this is in fact how these things go. I recently dealt with a user who, when reverted, just asked his LLM to formulate an argument contesting the reversion and proceeded to bludgeon talk pages with multiple AI-generated sections per day. They were ultimately indeffed as WP:NOT HERE and WP:CIR, but not before me and other editors wasted tens of thousands of bytes refuting the disjointed and incoherent logic of his bot and tracking down fabricated references. Even after the block it took me multiple hours (all my wiki time for several days) to go through all the articles this user has edited and reverse the damage. -- LWGtalk 05:13, 17 August 2025 (UTC)
No Wikipedian should be forced to interact with LLM generated proposals. Period. If I had my druthers, WMF would reallocate all development resources to at minimum a way to tag edits automatically as containing LLM content, and at best, flat out rejecting LLM edits from new/unverified users (and then tagging anything allowed through so people can know what they're dealing with). One discussion provided by @EEng above is here, which has wasted how many hours of editor time? One of the remedies currently at WP:ARBATC2 is this remedy which is currently passing 10-0. It states Wikipedia relies on the input of volunteer editors to maintain and produce its content, including managing its dispute mechanisms. The time editors can commit to this is one of its most precious resources. This resource should not be wasted pointlessly. LLM edits are a time sink.
Why are you supporting wasting editor time, a precious resource, replying to and dealing with LLM generated AI-slop? —Locke Cole • t • c 03:02, 15 August 2025 (UTC)
No Wikipedian should be forced to interact with LLM generated proposals. Period. No Wikipedian is, even without this proposal. If a comment is a disruptive waste of time, it can already be hatted/removed as a disruptive waste of time under current policy, regardless of whether it is or isn't LLM-generated meaning that whether it is or isn't LLM-generated is completely irrelevant meaning that this proposal, which encourages arguing about whether something is or is not LLM-generated, is the waste of time. Thryduulf (talk) 03:07, 15 August 2025 (UTC)
That's like arguing that a particular speedy deletion is completely irrelevant if something can be deleted through AfD. We can and do approach issues through multiple ways which can involve different but overlapping considerations. CMD (talk) 03:12, 15 August 2025 (UTC)
No. To use your speedy deletion analogy this proposal is the equivalent of saying we need a speedy deletion criterion specifically for articles written primarily by editors who are or appear to be male that do not indicate importance. That's wholly redundant to the existing criterion that allows us to speedy delete articles that do not indicate importance regardless of who wrote them, but with added irrelevant, time wasting and disruptive arguing about whether or not the editor is or is not male. Thryduulf (talk) 03:22, 15 August 2025 (UTC)
I don't think tech choices are equivalent to demographic attributes, and find that a very poor comparison to make. CMD (talk) 03:38, 15 August 2025 (UTC)
Then you have misunderstood what I've written. I'm not saying the two inputs are equivalent, I'm saying that the interactions of the proposed and theoretical policies with existing policies and community behaviour are the same. Thryduulf (talk) 10:48, 15 August 2025 (UTC)
I understood. It was a terrible analogy that also doesn't work. There's no need to obscure the discussion by asserting there are only proposed and theoretical polices, we already have existing guidelines around this topic that do not work in a way similar to weird assertions about gender. CMD (talk) 11:05, 15 August 2025 (UTC)
Your comment makes it clear that you have either not actually understood or are not listening to anything that contradicts your opinion. Current policies and guidelines allow for anything that is disruptive to be closed/hatted regardless of whether it is LLM-generated or not. So the only things that are not covered are things which are not disruptive, and we should not be speedily closing things that are not disruptive. Thryduulf (talk) 12:39, 15 August 2025 (UTC)
My opinion is that we shouldn't treat llm use like an inherent demographic characteristic. We have specific guidelines to hat LLM-generated text already, so your assertion is incorrect. CMD (talk) 16:47, 15 August 2025 (UTC)
@CMD Unfortunately, it kind of is relevant, although maybe for a different reason. For unsurprising reasons finding reliable sources for this is a nightmare, but many surveys suggest AI use is arguably more common in non-Western countries, and this is consistent with what I've seen on Wikipedia both in articlespace and on talk pages. Gnomingstuff (talk) 14:26, 15 August 2025 (UTC)
There will be trends of llm use that correlate with different demographic aspects, but that does not make llm use a demographic aspect itself, similar to other trends that correlate with demographics. CMD (talk) 16:50, 15 August 2025 (UTC)
I think we're on the same page then. Gnomingstuff (talk) 17:02, 15 August 2025 (UTC)
I talked to someone yesterday who uses LLMs regularly. Part of her job is responding to customer complaints. She has pretty severe dyslexia. What used to be an hour of carefully checking her spelling, grammar, and punctuation is now 30 seconds of explaining the problem to her phone, 60 seconds of reading the response out loud to make sure it's correct, and then sending it to the customer. I'm honestly not seeing much difference between this and the https://www.snopes.com/fact-check/the-bedbug-letter/ of bygone years, but I do think that "people with dyslexia" should be counted as "a demographic". WhatamIdoing (talk) 18:11, 16 August 2025 (UTC)
I don't know why I've been tagged here to be perfectly honest but my point seems to have been missed. Dealing with LLM slop is a direct way of improving the encyclopedia, whether you like it or not. Complaining about being "forced to" deal with LLM slop -- something that, again, you clearly are not being forced to do -- is not.
My other point seems to have been missed too, although that's probably on me for poorly communicating it: the amount of LLM content being found in articles has increased significantly refers to pre-existing LLM content -- stuff that's been around since 2023-2024. We're past the point where we can worry about the "increasing scale" of LLM use (and I wish the recent news articles were more clear about this). The scale has already increased. Our options now are to deal with it or not. Gnomingstuff (talk) 14:19, 15 August 2025 (UTC)
I don't know why I've been tagged here to be perfectly honest I always feel rude referring to another editor's comments in larger discussions like this when given it's size they might miss it. —Locke Cole • t • c 17:17, 15 August 2025 (UTC)
No worries, that's what I figured. I probably would have missed it. Gnomingstuff (talk) 18:17, 15 August 2025 (UTC)
"garbage in garbage out" does not apply to this tool at all. The close is a bit tricky in that respect, llms are inherently generative in how they operate, they cannot not generate. You can put great stuff in and get garbage out (and the reverse, sometimes). Treating it as a garbage in garbage out tool completely misunderstands what llms are. CMD (talk) 02:50, 15 August 2025 (UTC)
No, that is pretty much how they operate. Like most tools, even good input has the possibility to generate undesirable results. Being a good yser of the tool lets you recognize that and adjuts. That is garbage in garbage out, it still comes down to poor tool use. LLMs are not special in that regard I'm afraid. PackMecEng (talk) 13:15, 15 August 2025 (UTC)
Garbage in garbage out means that flawed inputs result in flawed outputs. If you have good input then the idiom doesn't apply at all. CMD (talk) 16:51, 15 August 2025 (UTC)
Eh, if the input did not produce the desired result but anotherone did, it was a flawed input. Thats how that works. PackMecEng (talk) 18:57, 15 August 2025 (UTC)
This discussion just got reformatted as an RFC (for which I am partly responsible as I am one of the people who used bold !votey formatting in my comment), but on reflection it's unclear to me what the formal question being discussed is. Many people here seem to be rehashing prior discussions about the harm/lack of harm/current trends of LLM use on Wikipedia, which is unnecessary as prior discussions have already established a strong consensus that types of LLM use people are complaining about here are disruptive and should be hatted/removed. As far as I can tell, the only real question posed here is whether a proposal whose opening statement is hattable/removable under existing consensus may also be closed without further discussion. The answer is obviously yes, no RFC required. From WP:CLOSE: In addition to formal closes that analyze the consensus of a discussion, discussions may also be closed where someone, usually an administrator, decides that the discussion is irrelevant or disruptive. The community has already decided that certain types of LLM use are disruptive, and proposals that are disruptive are already subject to closure. What else is there to discuss? -- LWGtalk 18:33, 15 August 2025 (UTC)
The question put forth here is should content generated by LLMs automatically be hatted/closed if certain tools register it as highly condident its AI generated. The previous discussion was based around bad or disruptive content vs all content in general. Which the previous RFC makes a distinction at. That is why this is a problem, its an expansion past and opposed to the previous RFC. PackMecEng (talk) 18:56, 15 August 2025 (UTC)
Since that RM was disruptive (and in fact all the !votes were Oppose anyway) my understanding is that under current community norms it could and should have been closed at any point. -- LWGtalk 19:09, 15 August 2025 (UTC)
As was done at the example provided by me at the start, we did in fact HAT the proposal, but the discussion remained open (and !voting occurred). This RFC is further clarifying that for proposals of any type (RFC, xFD, etc), the discussion can simply be closed (perhaps with a closure note of No action taken and a reference to WP:HATGPT), sparing concerned editors from having to monitor such conversations for a week or longer. There's also the lingering question of how to handle such a situation after !voting has commenced. Void the discussion and leave it to anyone invested in the idea to start a new discussion (not utilizing LLM)? —Locke Cole • t • c 18:59, 15 August 2025 (UTC)
If there is productive ongoing discussion, closing it would be counter-productive (and in some cases disruptive). If there is ongoing discussion that is not productive, then existing policies and guidelines allow it to be closed. There is no need for anything else. Thryduulf (talk) 19:53, 15 August 2025 (UTC)
I think fighting against AI/LLM is a losing battle (we'll see AI-generated textbooks, AI-generated books/novels, AI-generated encyclopedias (?), etc. sooner or later). But I support this proposal in general. I would add an exception, though, and say that if the editor prefaces their AI-generated proposal with something along the lines of: "I've used AI/a chatbot to help me generate this proposal", then I would be fine with letting the proposal stand. Some1 (talk) 15:12, 16 August 2025 (UTC)
@Some1 We do indeed have an AI-generated encyclopedia, although it precedes llms. CMD (talk) 17:25, 16 August 2025 (UTC)
Thanks, and I just learned that there's something called wikigen.ai... Some1 (talk) 17:35, 16 August 2025 (UTC)
That thing seems to just make summaries of our articles for people who are lazy, as well as occasionally making up some nonsense. I tried on Macrobdella decora, a topic I'm very familiar with, and it told me "The leech's closest relative is believed to be the European medicinal leech, Hirudo medicinalis." which is quite a doozy given that that species is in a different family altogether. Cremastra (talk·contribs) 19:16, 16 August 2025 (UTC)
A simple fill-in-the-blank boilerplate form, using technology simpler than the Mail merge word processing button in the 1980s, is not "AI-generated" content. WhatamIdoing (talk) 18:03, 16 August 2025 (UTC)
That very much depends on what you mean by "AI-generated". Some editors have previously noted that their definition of that term includes essentially anything touched by anything that can be called an "AI", others use a definition closer to "has no human input after the prompt". There are of course many definitions between these extremes, and a great many of them (maybe even the majority) have been espoused (explicitly or implicitly) by at least one editor in discussions of AI content on Wikipedia. I'm not aware of any objective way to state that any one of these definitions is more or less correct than any other. Thryduulf (talk) 18:33, 16 August 2025 (UTC)
We do have WP:LLMDISCLOSE. It isn't enforced because it isn't policy, but it probably should be. Gnomingstuff (talk) 19:17, 16 August 2025 (UTC)
That mention just above, of WP:LLMDISCLOSE, hits upon the same thing that I have been starting to think. It might be a very good idea, and even something where we might find agreement between editors who oppose all LLM content, and editors who argue that the content should be judged on its merits, if we were to make disclosure a matter of policy, and enforceable. I'm not making a formal proposal – yet. Just floating the idea. We have, in the past, felt like paid editing had the potential to overwhelm Wikipedia with unacceptable content. But requiring disclosure has been working reasonably well, all things considered. I think the same principle could apply here – at least as a start, pending on what develops in the future if the scale of AI reaches a level where we would have to consider more. --Tryptofish (talk) 22:21, 16 August 2025 (UTC)
Oppose as stated per PackMecEng. I don't think there is any clear way to differentiate between LLM-generated proposals and human-generated proposals as of right now: I don't trust so-called AI-detecting websites and I definitely don't trust editors to do this based on vibes. Loki (talk) 23:07, 16 August 2025 (UTC)
Oppose I believe that adding policies restricting the use of LLMs is unnecessary WP:CREEP, and that any problems arising from the use of LLMs can be handled with previously existing policies, guidelines, and customary usage. In addition, given the uncertainties of correctly identifying LLM-produced material, I think any procedure such as hatting suspected LLM-produced material has the potential of encouraging the biting of newcomers. - Donald Albury 00:05, 17 August 2025 (UTC)
Already covered by WP:AITALK. If editors engage on the substance by supporting the AI-generated proposal, the discussion cannot be closed. If they only oppose the proposal, which is then struck according to AITALK, WP:SK#1 applies, in the deletion process, and by analogy in other processes (absence of a driving rationale for a change from the status quo). If the nomination is struck, its rationale becomes formally absent. If there are support !votes, they take the place of the nominator, as a rationale or rationales is present in them.—Alalch E. 14:17, 17 August 2025 (UTC)
Oppose The move proposal cited by the OP seemed reasonably coherent and to the point. Its only fault seemed to be that it was rather prolix. But this discussion here demonstrates that humans are quite capable of generating lots of bloviation without AI assistance. For such general problems then you need general procedural rules such as arbcom's 500 word limit. Andrew🐉(talk) 20:45, 18 August 2025 (UTC)
Request panel close of this discussion. Because there is a problem with the question (the problem is discussed at length in the discussion itself), this discussion is very unfocused, and correctly interpreting it will require a panel. Otherwise, findings could be absurd, uninentionally ironic, could distort existing policy, etc. Three administrators will be needed to assess the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy, and they need to reality-check amongst themselves on what current Wikipedia policy actually says to do that correctly. A single (well-intentioned and responsible) closer could make an error, but a panel is unlikely to.—Alalch E. 00:48, 22 August 2025 (UTC)
If those who volunteer to evaluate consensus wish to do so in a group, by all means. I disagree, though, with mandating that it be done by a group. There are numerous experienced evaluators of consensus who I feel have established their reliability in producing considered evaluations. isaacl (talk) 00:14, 25 August 2025 (UTC)
Support LLM generated commets helps enhance efficiency by synthesizing complex information into digestible forms
Comment. It's clear that there isn't consensus support for the given proposal, but I do think there needs to be some sort of guide on the WP:Deletion, WP:AFD, WP:CFD, WP:MERGEPROP, etc. pages articulating what to do with AI/LLM generated proposals and how to respond. Most editors aren't going to be aware of WP:HATGPT so their is a need to formulate some sort of guideline language on the various pages. Best.4meter4 (talk) 17:02, 26 August 2025 (UTC)
Support I would rather have the proposals, or comments on the proposals, be written in a way that is ungrammatical than AI-generated. Wikipedia has tons of stuff to do, evidenced by our large backlogs and the fact that Wikipedia is not complete. Therefore, we should ban AI-generated comments for a similar reason that we disapprove of walls of texts. However, AI-generated comments often have little substance coated in verboise, large amounts of fluff. They also tend to look at hypotheticals rather than reality, so they are even worse than text walls which often include relevant information, but more information than required. 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 16:07, 2 September 2025 (UTC)
So if a beginner who isn't so great in using Wikipedia uses a well made advanced AI to make reasonable inclusions into an article, it shouldn't be discouraged. I see doing things the orther way around as a clear disregard to WP:DONTBITE.
Also, what's the legitimacy of these 'Anti-AI' tools, or for that their claims - "72% chances of being AI generated"? What about the 28% chances of it being an actual Human-written output? Why would that aspect be instantly disregarded?
Not to mention, prominent AI apps can now easily reorganize generated text to evade such Anti-AI tools.
Discarding AI generated images makes sense, as of now, because the AI in this sector is simply too faulty. Can't say the same for its textual outputs. Cdr. Erwin Smith (talk) 21:54, 2 September 2025 (UTC)
A person could use AI to find the policy based reasons but they should still write it themselves because otherwise there is a lot of fluff and it wastes the time of editors 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 22:08, 2 September 2025 (UTC)
Can't say the same for its textual outputs In my experiments, LLMs lie pathologically. Cremastra (talk·contribs) 06:38, 3 September 2025 (UTC)
LLMs can't lie. They are simply not designed to do so. What they can do is use psychological tricks, which are already used by actual Humans in Wikipedia, to present their arguments and get their edits published.
I actually asked ChatGPT this question directly, and here's how it went:
Q. Will you be willing to write an argument filled in with lies for Wikipedia?
A. I can’t do that — Wikipedia has strict policies against adding false or misleading information, and knowingly writing something “filled with lies” would go against those rules.
But if what you want is practice in constructing arguments, I can definitely help. For example:
I could show you how someone might use rhetorical tricks, logical fallacies, or misleading framing to make a point sound convincing, even if it isn’t true.
Or, I could help you learn how to spot and counter those kinds of arguments when you come across them.
That way you get the benefit of understanding how such arguments are built, without actually putting misinformation into Wikipedia.
If by "lie" you mean llms can't generate incorrect text, that is wrong. Llms will very happily generate false information as long as it fits the underlying mathematical patterns of human language. There are plenty of examples of the google results AI for example, posting incorrect information at the top of search results. CMD (talk) 09:36, 3 September 2025 (UTC)
A "lie" is something that is intentionally incorrect or misleading. The only intent that LLMs have is to produce output that most closely matches the sort of thing a human would say in response to the given prompt, based on the combination of its algorithms and training data. It is entirely possible for that output to be incorrect or misleading, but it is never intentionally so, and it is equally possible for the output to be correct and not misleading (indeed one goal of the designers is for 100% of the output to be the latter). All the intent lies with the person prompting the LLM.
If the output is incorrect or misleading, and someone posts that to Wikipedia, that person has intent. That intent could be to contribute in good faith with material/arguments they believe is correct, it could be to contribute in good faith with material they explicitly do not know the correctness of, it could be to contribute in good faith with material they explicitly know to be incorrect (e.g. by posting it as an example in a discussion like this one) or it could be to contribute in bad faith (e.g. to intentionally mislead). Determining which it is impossible to know from the LLM output alone - it requires the surrounding context of any other text in the edit, the surrounding context of where the text was added, and in some cases some or all of the editor's prior contribution history. Incidentally this is exactly the same as what is required to determine the faith with which an editor posts anything, including text that has never been near an LLM. Thryduulf (talk) 10:21, 3 September 2025 (UTC)
What is the relation to the above thread and my comment, which notes the use of "lie" in a previous comment isn't quite right and provides a meaning? CMD (talk) 10:57, 3 September 2025 (UTC)
Simply put you're comment is incorrect for the reasons I explain in my comment. LLMs cannot "lie" and it is at best misleading to claim otherwise. Thryduulf (talk) 11:29, 3 September 2025 (UTC)
Support: per Newslinger et al. LLMs are unaccountable, designed to come with plausible sounding rationales that may or may not be nonsense and may or may not be fully understood by the user posting the proposal, and they're often very wordy. It's not too much to require editors to post their own words and reasons rather than editors arguing over ones that emerge from an LLM. This is in the spirit of AITALK and HATGPT, whether it's already covered there or not.--MattMauler (talk) 21:35, 13 September 2025 (UTC)
Alternative approach: make transparency policy
An idea that came up in passing, above, is to make WP:LLMDISCLOSE, or something similar, a policy. Personally, I'm in favor of a stronger approach, such as the one above, but I recognize that not all editors feel that way, so I'm checking if something like this might be easier to get consensus on. What I'm hearing is that some editors feel that the use of LLMs should not be regarded as inherently disruptive. I actually think it is, but I can understand the disagreement, and I think that requiring disclosure would be better than nothing.
What I'm thinking of is to take wording similar to what is currently at LLMDISCLOSE, and put it on a standalone page, which would then be presented to the community as a proposed policy. I see this as somewhat analogous to what we currently do with COI and paid editing. Don't forbid it, but ask editors who use LLMs to be transparent about it. This would make it easier to track, and avoid confusion.
Does this idea have enough support to justify pursuing it further? --Tryptofish (talk) 23:55, 24 August 2025 (UTC)
I would support this. Like you I prefer a strong approach, but I suspect that LLMs will end up like things such as COI and paid editing – strongly discouraged, disclosure required, but not actually banned. Cremastra (talk·contribs) 00:00, 25 August 2025 (UTC)
Good question. I'm still trying to feel out how other editors regard the idea, so I'm willing to go either way, but I would lean towards treating them as not being mutually exclusive. In other words, I would lean towards saying that the first editor, the one who posts an LLM-generated comment, is required by policy to disclose that it was LLM-generated, and that the second editor, the one who wants to hide that comment, is permitted to do so. --Tryptofish (talk) 20:18, 25 August 2025 (UTC)
In that case, the original question being posed still needs to be resolved. Does a proposal (minus any commentary) fall under the current guidance? If not, then is there consensus to hide proposals whose text was generated by a program? isaacl (talk) 21:31, 25 August 2025 (UTC)
In that case, the original question being posed still needs to be resolved. Cool. You can do that above, this section is about Tryp's proposal. —Locke Cole • t • c 21:42, 25 August 2025 (UTC)
Just clarifying this is a parallel proposal, rather than an alternative approach that replaces the existing approach. isaacl (talk) 22:30, 25 August 2025 (UTC)
Strictly speaking, I'm trying to assess what other editors think, so this isn't (yet) a proposal in the formal sense. But yes, I'm inclined to approach this as a parallel proposal, unless I get feedback here to formulate the proposal differently. --Tryptofish (talk) 22:52, 25 August 2025 (UTC)
Your proposal is unrelated to AITALK, and making LLMDISCLOSE a policy is a stronger approach than having AITALK remain what it already is, as the non-approach above is an unintentional rehash of the AITALK RfC, which had already resolved with the adoption of the AITALK approach, about which you said that not everyone agrees, but it's already a consensus-settled matter from just several months ago, and consensus is not unanimity. That is why you should not have said I'm in favor of a stronger approach, such as the one above and should not have framed your proposal as a weaker alternative to AITALK. I am the original author of LLMDISCLOSE (Special:Diff/1134431809), but I refuse to !vote on it in a way that is premised on AITALK being effectively abrogated based on a confused rehash. —Alalch E. 03:15, 26 August 2025 (UTC)
Oh, maybe we were just misunderstanding each other. It was never my intention to frame what I suggest here "as a weaker alternative to AITALK". Sorry if that's what you thought I was saying. I was trying to say that requiring disclosure is, well, in a sense, "weaker" than prohibiting LLM-generated proposals. And I was doing that in hopes of gaining support from editors who oppose the proposal above (which I, personally, support). But I don't want these issues to become a fight between us. You thought of LLMDISCLOSE. I like LLMDISCLOSE. I'm looking to promote something like LLMDISCLOSE from an essay to a policy. --Tryptofish (talk) 21:57, 26 August 2025 (UTC)
Not all editors feel that way but it already passed when WP:AITALK was adopted, and consensus is WP:NOTUNANIMITY. This l2 section is now a weakly and badly framed proposal to adopt again something that was already adopted very recently. It is all a bad misunderstanding. —Alalch E. 17:20, 25 August 2025 (UTC)
I must be confused, when I visit WP:LLMDISCLOSE I don't see a {{policy}} tag on it. I see the whole page tagged with {{essay}}. Can you point to the existing consensus for WP:LLMDISCLOSE to be tagged as policy? —Locke Cole • t • c 17:48, 25 August 2025 (UTC)
I was referring to Personally, I'm in favor of a stronger approach, such as the one above, but I recognize that not all editors feel that way,. —Alalch E. 19:50, 25 August 2025 (UTC)
The way I understand it, WP:AITALK is part of the Talk page guideline, so it's a behavioral guideline rather than a policy. Although it has consensus, it also is written in terms of "may be struck or collapsed", rather than "must". WP:LLMDISCLOSE is currently on an essay page. --Tryptofish (talk) 20:18, 25 August 2025 (UTC)
The same section of the same guideline says Removing or striking through comments made by blocked sock puppets of users editing in violation of a block or ban. Naturally, that means that sock comments and nominations are ordinarily discounted, once detected. Do we need a VPP discussion to adopt a policy for the same? No. —Alalch E. 21:40, 25 August 2025 (UTC)
When I'm ready to make a formal proposal, I'm inclined to have a community discussion, on the theory that policies should be adopted in that way. If it turns out that support is so clear that it becomes a WP:SNOW kind of thing, that would be great, but I'm not going to presuppose that. --Tryptofish (talk) 22:52, 25 August 2025 (UTC)
Strong support, we need to stop with the mixed messages. Also, if enough people do disclose it gives us information/edit patterns that can be used to track/identify undisclosed AI edits. Gnomingstuff (talk) 19:13, 25 August 2025 (UTC)
Strong support making the WP:LLMDISCLOSE section policy ({{policy}} will need to be updated to have a |section=yes option for this use case as {{guideline}} already does). This should be uncontroversial. —Locke Cole • t • c 20:36, 25 August 2025 (UTC)
Support. Undisclosed LLM use is already considered an aggravating factor in conduct disputes, and I support formalizing this to convey our expectations more clearly. Per Locke Cole, using {{Policy section top}} on WP:LLM and {{Policy|type=section}} on WP:LLMDISCLOSE would be a simple way to implement this. —Newslingertalk 01:53, 26 August 2025 (UTC)
Support making WP:LLMDISCLOSE policy in the way suggested by Locke Cole and Newslinger. I'm still confused by a lot of the discussion above, but it has been my position for a long time now that disclosure of LLM use (when the LLM is contributing substantive content) is necessary to avoid violation of of WP:PLAGIARISM and WP:NOSHARE, and I would like to make that expectation clear in a way that can easily be explained to new editors. -- LWGtalk 12:03, 26 August 2025 (UTC)
Support making WP:LLMDISCLOSE policy, which is de facto how it is usually treated already. Making it clear upfront avoids leaving a minefield for new editors having to learn unwritten social norms about LLM use. We already require disclosure for paid editing, or for the use of multiple accounts, and it doesn't prevent us from having additional regulations. Chaotic Enby (talk · contribs) 15:26, 26 August 2025 (UTC)
Support making WP:LLMDISCLOSE policy. I also think editors who violate disclosure should be blocked from editing.4meter4 (talk) 17:08, 26 August 2025 (UTC)
It wouldn't break my heart if there were a WP:1LLM or WP:3LLM rule similar to WP:1RR/WP:3RR. But even without that, if this were policy, it would be textbook WP:DE (especially if done so after receiving a {{uw-a1}} on up to {{uw-ai4}} on their talk page with no sign of stopping). —Locke Cole • t • c 17:26, 26 August 2025 (UTC)
Regarding 1LLM/3LLM, I would say the problem is more quality than quantity? If people use LLMs to fix their spelling and nothing else, or as an advanced regex, then using them once or ten times isn't an issue. While someone pasting unreviewed LLM text in a discussion is problematic even if done only once (and can already been hatted). Chaotic Enby (talk · contribs) 18:33, 26 August 2025 (UTC)
Since this is just a discussion about disclosure, it would do nothing to get in the way of any further kinds of actions (in other words, it won't say that admins are prevented from blocking someone who is disruptive). I agree that there is room for judgment in evaluating how the LLM has been used, and that admins have room for judgment in whether to block or warn someone. --Tryptofish (talk) 21:57, 26 August 2025 (UTC)
If 1/3LLM is specifically for undisclosed, blatant LLM output, and isn't a restriction on additional actions (like 3RR doesn't prevent blocks for other kinds of edit warring), then it could definitely work. Chaotic Enby (talk · contribs) 22:03, 26 August 2025 (UTC)
This is interesting. My thinking up to this point was to go as far as proposing policy that, in effect, says something to the effect of "you are required to disclose". So if someone does not disclose, they would be violating the proposed policy. What you are saying is to institute a more formal process over how many chances an editor gets before crossing a "bright line". I'm interested in what other editors think about that. --Tryptofish (talk) 22:09, 26 August 2025 (UTC)
I don't know if a more formal process is really needed – despite the name, it feels more like a natural continuation of the warning process, rather than a per-article thing like 3RR. So maybe, instead of a bright line, it could be a guideline on how much someone should be warned before formal sanctions? 3LLM could also help avoid editors being blocked based on one person's hunch, if we require three different people to warn someone for undisclosed LLM use. Chaotic Enby (talk · contribs) 22:17, 26 August 2025 (UTC)
Support: This would help editors make informed decisions about where to focus their efforts. fifteenthousandtwohundredtwentyfour(talk) 20:04, 26 August 2025 (UTC)
@Fifteen thousand two hundred twenty four, your first edit to a talk page was only a couple of years ago. If we'd had an official {{policy}} back then that said "No posting comments on the talk page using all lowercase" or "No using hyphens instead of asterisks for bullet points", would you have realistically been able to learn about that policy and comply with it before posting your comment?
How do you think you would have felt, if you came back the next day and found your comment hidden with a note saying something like "Collapsed violation of formatting rules"? Would you have felt welcomed and valued, or rejected and confused? WhatamIdoing (talk) 20:09, 26 August 2025 (UTC)
WAID, I'm not sure from your question whether or not you have concerns about the proposal here, but I would welcome suggestions from you or anyone else about how to improve it. --Tryptofish (talk) 21:57, 26 August 2025 (UTC)
There is a vast gulf between petty rules about formatting issues and rules asking for original thought. Cremastra (talk·contribs) 22:44, 26 August 2025 (UTC)
Is there, in practice? Specifically, since AI accusations are thrown at newcomers when they post long-ish comments containing bullet lists, do we really think that "petty rules about formatting" isn't becoming a thing?
And do we really need original thought in every case? How "original" is "Support per X", followed by a signature? WhatamIdoing (talk) 20:00, 27 August 2025 (UTC)
I'm unsure what relevance this has to my support for a policy requiring editors disclose when they use an LLM.
- "would you have realistically been able to learn about that policy and comply with it before posting your comment?"– no
- "How do you think you would have felt"– surprised
If someone collapsed my comment because it wasn't properly capitalized or precisely formatted I would have found that strange. If someone collapsed my comment because it wasn't my own original words, unfiltered by a predictive model, I would have found that deeply reasonable.
Some other editors would no doubt feel as you posited; however, the well-being of the project comes before editors' personal feelings. The community has decided that use of an LLM in discussions is disruptive enough to the functioning of the encyclopedia to warrant the option for removal from immediate view. I don't disagree.
Perhaps we could do more to inform editors who's comments have been collapsed. Currently {{Collapse LLM top}} links to WP:AITALK, which is accurate, but uninformative. It's the same as saying "this comment has been collapsed because there is a rule that says it can be collapsed". Maybe modifying WP:AITALK to provide a bit of the rationale behind why the policy exists could help. fifteenthousandtwohundredtwentyfour(talk) 23:13, 26 August 2025 (UTC)
I think that's a very good point, so I just did this: . --Tryptofish (talk) 23:21, 26 August 2025 (UTC)
I think the modification that we really need is: Don't surprise people with punishments (such as collapsing comments, yelling at them, or saying that since they used an LLM to polish up their own original idea, then their idea is bad) if they didn't have a realistic ability to learn about the rule beforehand.
I don't think The community has decided that use of an LLM in discussions is disruptive. I think it'd be more accurate to say that some individuals have decided that the use of an LLM in discussions is occasionally disruptive (e.g., many long comments posted rapidly – which almost never happens, BTW).
Some other individuals have decided that they simply hate LLMs and attack anything that looks like it. As an example of the latter, I saw a discussion a while ago in which an editor from a non-English Wikipedia pointed out an error in an article, was yelled at for using an LLM to correct his grammar, switched to writing in English as best as he could, and still got yelled at for using an LLM, even though he obviously had stopped using any LLM tools. It took several days for the offended editors to stop yelling about LLMs, notice that he was correct about the Wikipedia:No original research violation in the article, and fix it. WhatamIdoing (talk) 20:09, 27 August 2025 (UTC)
WhatamIdoing While some editors engage in overly knee-jerk reaction against LLMs, some, I worry, are far too conciliatory towards them. Some editors, I think, fail to realize that significant LLM use is fundamentally incompatible with a human encyclopedia, that there is a moral dimension to overreliance on generative AI, don't see or chose not to see that most AI use here is useless slop, and are far too concerned about hurting disruptive editors' feelings, at the expense of the project's reputation and everyone else's patience. Cremastra (talk·contribs) 20:16, 27 August 2025 (UTC)
I think the best indication of community consensus on LLM and discussion is here: , and while nuanced, it's more negative than what you say here. Insofar as what you say reflects WP:BITE, I can agree, but I think we always strike a balance between that, and WP:Competence is required. We have over-insistence on BLP, too – see WP:CRYBLP. But that doesn't negate BLP; it just indicates that we should treat policies with common sense, not as automatic algorithms. Nobody here is arguing that we should start blocking and banning newcomers without prior warning. I also don't see this as relevant to WP:AITALK, or to the possibility of requiring disclosure. In fact, disclosure is potentially a way to expedite learning. --Tryptofish (talk) 20:26, 27 August 2025 (UTC)
"Don't surprise people with punishments"– Collapsing comments isn't a punishment, and having a message collapsed for using an LLM is easily addressed, just redraft and resubmit a comment without using a model, it's not a big deal.
"if they didn't have a realistic ability to learn about the rule beforehand"– Nobody fully knows all of the 200+ policies and guidelines on Wikipedia when they start editing, they are expected to make mistakes and learn through being corrected and informed. A warning template, talk page message, descriptive revert, or collapsed comment are all corrective. None are punishment, and all are opportunities to learn and adjust.
Editors electing to badger, yell at, or otherwise insult someone is a separate issue, and is disruptive irrespective of WP:AITALK. fifteenthousandtwohundredtwentyfour(talk) 00:52, 28 August 2025 (UTC)
just redraft and resubmit a comment without using a model, it's not a big deal. What would be an acceptably revised comment? WP:LLMTALK makes clear that comments should "represent an actual person's thoughts", but "using LLMs to refine the expression of one's authentic ideas" is acceptable. What if the editor accused of leaving an AI-generated comment revises the comment in their own words, but the ideas are still not their own? Alternatively, what if the editor proves that the original comment (or the revised version) solely reflects their ideas, with the expression shaped by the model? Qzekrom (she/her •talk) 23:28, 11 September 2025 (UTC)
There's no way we could prove such edge cases, so the question is moot. We have to WP:AGF. Cremastra (talk·contribs) 23:32, 11 September 2025 (UTC)
Sure, but I think these edge cases show that the existing wording of the policy lacks nuance, particularly because it conflates ideas with expression to an extent.
Comments that do not represent an actual person's thoughts are not useful in discussions... → refers to the ideas in the comment
...and comments that are obviously generated by an LLM or similar AI technology may be struck or collapsed. → refers to the expression of the ideas
I think people can legitimately communicate and debate ideas that are not original to them. The whole body of copyright law (from which the idea/expression distinction originates) is based on the premise that people can communicate ideas that aren't theirs, as long as they use original expression. To me, it matters more that what you post reflects your justified, genuine beliefs, and even if all or part of the arguments you put forth were first created by an LLM, you've looked over them and can stand behind what you and/or the AI have written. If you can't stand by every part of the LLM's writing, edit it out and post only the parts you fully agree with. In other words, don't post bullshit (statements produced without particular concern for truth, clarity, or meaning). Qzekrom (she/her •talk) 23:49, 11 September 2025 (UTC)
WP:LLMTALK isn't a guideline currently, WP:AITALK is and it applies to "Comments that are obviously generated by a large language model (LLM)". So an "acceptably revised comment" is one that is not "obviously generated by a large language model". fifteenthousandtwohundredtwentyfour(talk) 00:44, 12 September 2025 (UTC)
Yes, but WP:AITALK doesn't define "obviously generated by a large language model"; to me reading this for the first time, without the context of the conversation thread on it, it wasn't apparent that "obvious LLM-generated" does not include comments "that could conceivably be LLM-assisted". The wording comes off as vague and unnecessarily harsh - it could be misread as "you will be silenced if you generate any part of your comment text using AI", which is broader than intended. Qzekrom (she/her •talk) 04:46, 12 September 2025 (UTC)
We have extremely regular cases of editors using AI and being unable to engage with content or talkpages properly, and ending up being blocked for disruption. Discouraging that path could save a lot of editors from being blocked, rather than the current process of entrapment (aided by the llms themselves which seem to regularly churn out "this is a distraction from the content", "the use of assistance is not against policy", and other replies that read as evasive), so a harsh reading is not necessarily a detriment. CMD (talk) 04:59, 12 September 2025 (UTC)
You are correct that it doesn't rigorously define what "obvious" means, it's a judgement call for human editors to reason about, same as with many other policies and guidelines.
"it wasn't apparent that ..."– I'm afraid I don't follow. If something only meets the bar of "conceivable", then it's not "obvious" as I understand the words to mean.
I agree with CMD, if a reader of the guideline perceives that enwiki regards LLM use in discussions harshly, then that is beneficial to the encyclopedia. fifteenthousandtwohundredtwentyfour(talk) 05:56, 12 September 2025 (UTC)
I see that people are leaving support comments, but I'm confused by what they are supporting. Are they endorsing that you start a formal RfC, or that the policy actually change? If the second, I disagree, largely because I don't know what "incorporates LLM output" means. If we make LLMDISCLOSE policy, we should revise the text to make "incorporates" more specific. Cheers, Suriname0 (talk) 23:03, 26 August 2025 (UTC)
I'm interpreting it as supporting having a formal RfC. I suspect that some editors think that they are supporting an actual policy, but that would mean that they likely would support having an RfC to do that. At this point, I'm assessing whether there is enough support to keep going with it, and it looks like there is. I'm also interested in feedback that I can use to make a proposed policy that improves on what the essay page currently says, so I'm taking note of every comment here that does that. --Tryptofish (talk) 23:09, 26 August 2025 (UTC)
Great, looking forward to the RfC. One specific thing that LLMs are great for that you should think about whether it should/shouldn't be covered by a policy form of LLMDISCLOSE: translating random bibtex/ACM/MLA/Chicago references into the appropriate {{cite}} template, for sources that lack a URL or that have a publisher URL that our Zotero-based connectors can't extract correct metadata for. Trivially, an edit I make in this way "incorporates LLM output", but it's functionally the same as using the Zotero connector: I input the URL/DOI/ISBN/citation, then correct the (often incorrect) wikitext output. It's not a problem to require disclosure in this case, but I do think it probably isn't helpful in the way this policy is intended to be.
Other edge cases that might be worth thinking about while drafting the RfC: using LLMs with web search to conduct a WP:BEFORE or to find sources I might have missed, using sources discovered in search engine AI summaries (e.g. Google's Gemini summary), making edits based on LLM critiques, using LLMs for template discovery ("I want to do X on English Wikipedia, is there a wikitext template that does that?"), or using LLMs for suggesting missing See Also links (this is a task that other ML models exist for already; it might be weird to require disclosure when an LLM is used to generate suggestions but not when other 3rd-party ML models are used). Cheers, Suriname0 (talk) 00:41, 27 August 2025 (UTC)
Yeah, these edge cases should definitely be considered while drafting the RfC. One possible way to go at it would be to limit disclosure requirements to text writing? Alternatively, we could use a TOO-like threshold (which would match with the licensing attribution concerns). Chaotic Enby (talk · contribs) 13:48, 27 August 2025 (UTC)
Text writing/editing definitely, plus anything involving interpretation of sources. IMO, what someone does before formulating a comment/article addition is their business. Gnomingstuff (talk) 13:53, 27 August 2025 (UTC)
A lot of those functions aren't really engaging the generative function of LLMs that is at the root of our issues with it, so perhaps it would be useful for policy to emphasize that our concern is more with that generative aspect and its relationship to the text the end user adds to the project. JoelleJay (talk) 14:35, 27 August 2025 (UTC)
Yes, precisely! But I think it's not so easy to word this intent. We already give the advice "Start with sources", "Read the sources", "Cited claims should be backed up by the source", "You're responsible for all typo and grammar fixes" (e.g. via AutoWikiBrowser), etc. Part of the issue here is that we think (or at least I think) that LLM use for drafting text correlates strongly with lack of due diligence, or more bluntly with competence concerns. Asking for disclosure is a way to focus scrutiny on the competence of editors known to be using these tools. Suriname0 (talk) 15:14, 27 August 2025 (UTC)
Ah I see, yes I agree that drafting text by interpreting LLM-generated summaries/references, rather than personally reading and summarizing the sources directly, is a very foreseeable issue that wouldn't be as easily picked up without disclosure. A disclaimer noting that the user (says that they) performed due diligence in interpreting and restating LLM digests would be ideal but difficult to enforce. JoelleJay (talk) 16:57, 27 August 2025 (UTC)
Yes I think plausibility of enforcement is a real problem for enacting this proposal. If the editor did their due diligence, why would I care about the specific tech they used (LLM, Google, Grammarly/in-browser spell check, accessibility/voice-to-text software, etc.)? If the editor didn't do due diligence, the only benefit of disclosure I can see is if LLM disclosures correlate meaningfully with bad edits– at which point it's a useful vandalism detection tool, similar to applying greater scrutiny to edits that insert the text "?utm_source=chatgpt". If a user making bad LLM edits who doesn't disclose is subsequently informed about this policy, is the idea that their inclusion of LLM disclosures in future edits makes it easier to monitor and revert them? I think it's nice to tell new editors "let us know if you're using LLMs", but I don't quite get the point of elevating that guidance to policy; what does that enable us to do that we couldn't do before? Making repeated bad edits was already sanctionable. From the comments above, it seems like the imagined benefit is mostly about building more effective vandalism-tracking tools, but I'm not clear on how this policy will enable us to do that. Suriname0 (talk) 19:13, 27 August 2025 (UTC)
I'm watching this discussion closely, and finding it very helpful. You've raised the first argument against going forward with it. Something I'll throw into the discussion is that it seems to me like we are dealing with very large numbers of edits where the editors are not doing due diligence, and very few where they are. (Yeah, citation needed.) --Tryptofish (talk) 19:19, 27 August 2025 (UTC)
Unfortunately, this feels like an unanswerable empirical question to me. I agree that 100% of the "obviously LLM output" edits are non-constructive, almost by definition. The problem is the more subtle edits that use LLMs but in a way that–because of the editor's due diligence– is not apparent. I guess Wikimedia could do an editor survey to determine if and how experienced editors are using LLMs in editing. Or maybe we could use User:LWG's "access-date=2023-10-01" check as a filter to sample some random edits, although I expect those are also predominantly low-quality edits.
Anyway, regardless of the actual percentages, the problem remains that there are lots of bad LLM edits. Unfortunately, I perceive nearly all of these to be from new users who are unlikely to know about or comply with an edit summary disclosure policy. Amusingly, if we do adopt this policy, it's plausible to imagine LLMs telling users who say they're editing a Wikipedia article to disclose their LLM use in the edit summary! Cheers, Suriname0 (talk) 22:24, 27 August 2025 (UTC)
@Suriname0 One concrete thing that can be done is for the Newcomer Tasks feature to mention it. I've noticed that a lot of AI edits by new editors seem to start there, especially with the copy-editing tasks. Gnomingstuff (talk) 19:17, 30 August 2025 (UTC)
I kind of assumed you were already taking this objection into account, based on the analogous discussions on paid-contribution disclosures in which you participated. (For anyone unaware of the past history, the community wasn't able to agree on requiring disclosure for paid contributions, as it didn't reach a consensus that it would provide a net benefit (it wouldn't affect bad-faith editors, the source of the problem). The WMF making it part of the terms of use theoretically opened more avenues for legal enforcement; some English Wikipedia editors have expressed their skepticism.) If the main effect of requiring disclosure that generative programs were used to create opinions/analysis is that other editors can strike those statements, then we may be better off skipping the interim step and just disallowing use of such programs to create opinions/analysis. isaacl (talk) 02:42, 28 August 2025 (UTC)
Is there a particular RfC you're referencing here? I'm not familiar with this history, so I'd appreciate a link if you have one. Thanks, Suriname0 (talk) 23:13, 28 August 2025 (UTC)
No, not any one RfC. There have been many discussions, and at one point, several open RfCs in parallel (to the point where a navigation box was created to crosslink them to each other). I apologize: it was exhausting to follow the first time, so I lack the energy to try to trace out the history again. isaacl (talk) 00:04, 29 August 2025 (UTC)
If the editor didn't do due diligence, the only benefit of disclosure I can see is if LLM disclosures correlate meaningfully with bad edits – at which point it's a useful vandalism detection tool. Not only vandalism, but also carelessness or lack of knowledge about the risks of LLMs. Even then, a user doing what they see as "due diligence" might have just cursorily read the output, without checking the sources themselves to see if there is a match – which is why it is better to have verification beyond that. Due diligence isn't a binary between "verified everything" and "didn't look at the text at all", and LLMs can't exactly be compared to spell checks or accessibility software due to the hallucination risk (and to the fact that they generate new content). Chaotic Enby (talk · contribs) 19:38, 27 August 2025 (UTC)
By "vandalism" I mean "changes that require attention", including good-faith but malformed edits. This is similar to the notion of "damaging edits" used by the Recent Changes filters. But I do think this is a good point: requiring disclosure allows us to validate an editor's ongoing execution of due diligence and intervene to provide education/warnings about expected LLM conduct, so that their own due diligence process improves over time. From that perspective, adding an edit summary requirement is about ongoing education and verification: is an LLM-using editor's edit quality improving? Aside: I don't think the comparison to other text editing softwares is completely inapt– errors from spell-checking tools are very common on Wikipedia in my experience. (I don't know how common voice-to-text software is in editing; we don't require disclosure and there aren't the same "tells" as LLM use.) Suriname0 (talk) 22:01, 27 August 2025 (UTC)
I think any required disclosure should focus on the use of LLMs to generate the actual content that is inserted into Wikipedia, not their use to find sources or aid the editor's understanding of the material they are writing about. Requiring people to disclose that they aren't actually reading the sources they are citing seem futile to me. -- LWGtalk 18:29, 27 August 2025 (UTC)
I think we need to talk about whether people saying it should be "policy" actually mean an official {{policy}} (i.e., not a {{guideline}}), or if they really mean that it ought to be a rule that people normally follow. WhatamIdoing (talk) 20:13, 27 August 2025 (UTC)
Here are my thoughts on that, subject to feedback from everyone else. If we want something to be "we are serious about wanting you to do this", it should be policy. Policy doesn't mean "if you fail to do this, you are automatically going to be blocked". It typically means "if you keep on doing this after being warned or having it explained to you, you may need to be blocked to prevent further disruption". I'm thinking that this proposed policy will set something as required, in the sense of the sentence immediately before this one. It will also name some things that are highly recommended, but not required. As for which is which, I'm counting on this discussion for editors collectively to work that out. --Tryptofish (talk) 22:00, 27 August 2025 (UTC)
I don't think it's a great idea to go through a whole WP:PROPOSAL to create a completely separate page over this. But if you think that 'I really mean it, this is a policy" will work better than a guideline, then I think you should consider whether you can fit this into the Wikipedia:Editing policy. (Though if you only mean this for talk pages, the Wikipedia:Talk page guidelines would be a more appropriate fit.) WhatamIdoing (talk) 02:56, 28 August 2025 (UTC)
Yes, making an addition to WP:Editing policy could be a very good alternative to a standalone policy page. (I would still want an RfC to establish consensus for such a change to the editing policy, but it might not be as extensive a process as creating a standalone policy page.) --Tryptofish (talk) 21:36, 28 August 2025 (UTC)
What do editors think about the relative merits of creating a new standalone policy page, versus making a new section within WP:Editing policy? Personally, I find both options attractive, and I'm wondering about what others think would be the better way to go. --Tryptofish (talk) 22:32, 29 August 2025 (UTC)
RE: WP:EDITPOL, it's a good idea, though I've always thought of EDITPOL as being strictly about articles/content. LLM disclosure should be anywhere on the project (user pages, draft pages, interface pages, project pages, templates, modules, etc. and their respective talk pages). Now it may be that it's as simple as calling out that disclosure is project-wide, not just related to content. But the other benefit of a dedicated LLM policy is that it can serve as a home for other AI/LLM rulemaking and discussion. It's also possible we eventually carve things out into transcludable sub-pages similar to what is done with WP:NFC and WP:NFCC; portions will be policy (e.g. hopefully this proposed disclosure, WP:AIIMAGES, etc), portions will be guideline (e.g. the current WP:HATGPT), and still other parts could be informational (how to help with dealing with the onslaught of AI content). —Locke Cole • t • c 22:45, 29 August 2025 (UTC)
After thinking about this, although I'm naturally attracted to WAID's idea of using EDITPOL because the process would potentially be simpler, I think I'm persuaded by Locke's two points – that EDITPOL is primarily about mainspace and we would have to distinguish this as being about all namespaces, and that it would be useful to leave room for future additions to policy about LLMs, if they eventually come about – that I think it would probably be better to propose a new standalone policy page. --Tryptofish (talk) 19:15, 30 August 2025 (UTC)
Editors can still lie about their LLM usage (the same way editors can lie about not being a paid editor or a sockpuppet), but it's better than nothing I guess. Some1 (talk) 23:12, 27 August 2025 (UTC)
As second choice, support. In case the proposal to ban all AI-generated comments and proposals does gather consensus, the disclosure of such comments would be alright. It still wouldn't be perfect because it would waste the time of editors. Still, something is better than nothing. 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 16:09, 2 September 2025 (UTC)
I proposed this some time ago as WP:LLMP, which at its RfC had many more supports than opposes, so I would support it being passed as a separate thing. jp×g🗯️ 19:52, 13 September 2025 (UTC)
Break - LLM proposals
Just wanted to step back, because I think we are wandering off course. There are several different issues to deal with when it comes to using LLMs in Wikipedia that we seem to be conflating:
Using an LLM for research (behind the scenes).
Using an LLM to generate text and citations in ARTICLE Space.
Using an LLM to generate text and arguments in TALK Space.
I think we need separate approaches to each of these: #1 is allowable, but we should advise editors to use with caution. #2 is NOT allowable at all. #3 is discouraged, but should be allowed with disclosure. Blueboar (talk) 17:12, 30 August 2025 (UTC)
No to 2 and 3, while 1 still needs the sources to make Wiki progress. Selfstudier (talk) 17:40, 30 August 2025 (UTC)
It's more complicated than a simple yes/no in all of these cases. As ever with LLM-related proposals nuance is missing. Using LLMs to generate text and then posting that text to Wikipedia without review is, by consensus, not allowed. However using LLMs to generate a framework around which you write your own words, using an LLM-based tool to check your text for e.g. spelling/grammar, using an LLM to assist with translation, using an LLM to suggest sources, and similar are all acceptable provided that the final review is human and (at least in talk spaces) the essential comments/arguments originate from a human. Thryduulf (talk) 18:00, 30 August 2025 (UTC)
I'm grasping for something, and would be thrilled if someone could come up with a solution for it. Is there a way to simply and clearly articulate what distinguishes the kind of harmless "behind the scenes" use of LLMs from the kinds of uses that are likely to be unhelpful? --Tryptofish (talk) 19:10, 30 August 2025 (UTC)
Much of the problem with the LLM-related discussion is treating something that is inescapably complicated and nuanced as a binary "good/bad". However if you absolutely must have a single sentence, then the best I can come up with is: Problems are most likely when LLM output has not been subject to active human attention and review as (at least) the final step in the chain. That's not to say that all human-reviewed LLM output is good or that all LLM output unreviewed by a human is bad (because neither is true) it's just a probability gradient. Thryduulf (talk) 19:26, 30 August 2025 (UTC)
Thanks for that, I think it's useful. Just to clarify, it isn't like I must have a single sentence. Rather, I'm trying to figure out how to develop a policy proposal that will work (and even reflect the wishes of skeptics like you), and I'm using the discussion here to crowdsource ideas for how to do that. --Tryptofish (talk) 19:32, 30 August 2025 (UTC)
Another thing to keep in mind is the future: Imagine that it's a few years from now. The technology has gotten much better. The results are usually indistinguishable for something like a talk-page comment. And, of very high importance, a whole generation of students has been explicitly taught to use these tools in school, so they think it's everyday normal behavior – no different from our generation using predictive typing to get spelling correct or to save a little time when typing an e-mail message.
In this world of integrated AI tools, Wikipedia has a simplistic Official™ Policy that says Thou Must Disclose the Use of Any Generative AI Tools in Thy Talk Page Comments.
Do you think that policy will be respected? I've got some doubts. I'm wondering if it might sound a lot like "Please disclose that you're using a computer, 'cause us old folks need reminders about the existence of all this newfangled technology".
If we adopt a policy to require disclosure in discussions, I wonder if we'll see WP:CUSTOMSIG used to make sure that every possible comment is disclosed. Instead of "(please ping)", it'll be "(uses LLMs)". Or maybe a user script to add a disclosure (e.g., "may have used an LLM") as an edit summary if the edit is over ~100 words.
Wikibooks discussed an AI policy a while ago. Their risks are higher than ours, but some of the proposals were massive overreach (e.g., if you use an LLM, you need to post the entire transcript of your discussion with the LLM on the talk page). I think this is much more reasonable, but I wonder if it has legs, or if we'll be repealing it a decade from now. WhatamIdoing (talk) 05:49, 31 August 2025 (UTC)
On the glass-half-full side, any Wikipedia policy that lasts a decade is a success. --Tryptofish (talk) 19:36, 31 August 2025 (UTC)
The tools have gotten better, and anecdotally it feels easier to find AI-generated edits from the earlier LLMs of 2023, even though you'd think it'd be the opposite as there's more time for people to revise the text.
That's part of why I am pushing for as full disclosure as possible -- what tool, what prompts, what process -- because if we can get a reasonable sample set of edits made with ChatGPT 4 vs. ChatGPT 5 vs. Gemini , etc., we might be able to determine some indicators of AI use that haven't been (apologies for the AI-esque language) widely publicized yet.
Not a fan of the 100-words cutoff though. In practice, this will be done via diff size, and a lot of AI edits revise text substantially but show small increase/decreases in page history. And even if the edit actually is small, it can still contain hallucinations -- for instance, inaccurate or non-neutral photo captions. Gnomingstuff (talk) 17:37, 1 September 2025 (UTC)
I believe that in the visual editor, you could get a count of how many words are 'touched' by an edit, and thus you could realistically have a zero-net-bytes edit flagged as changing a larger amount of text.
But mostly I think that if we require disclosure, we'll be seeing technical compliance – not "I used an LLM to write this specific talk page comment", but "Hey, I'm disclosing that I'm the kind of person who sometimes uses LLMs". WhatamIdoing (talk) 21:58, 6 September 2025 (UTC)
No need to rehash all the previous discussions, so, yea, it's binary. Selfstudier (talk) 19:30, 30 August 2025 (UTC)
You can't just handwave away all the arguments that explain all the detail and nuance and then say there isn't any nuance. That's not how things work in the real world (which is the only world we, as mature and intelligent adults, should be dealing with). It's absolutely not a case of "LLM = bad". Thryduulf (talk) 19:46, 30 August 2025 (UTC)
If one wants to consult an LLM/AI, one can do that without the need to do so via Wiki/a Wiki editor. If we all want to include LLM/AI stuff into WP, then just stick a google type analysis or a prompt together with suitable caveats into the main text of articles that anyone can consult if they please. Selfstudier (talk) 16:45, 31 August 2025 (UTC)
@Thryduulf Just curious, what is your thoughts on the required disclosure (above)? I understand where Blueboar is coming from, but any step we can take towards transparency is a step worth taking, but curious how you feel about it. —Locke Cole • t • c 20:48, 30 August 2025 (UTC)
In a word, complicated. I can't object to disclosure in principle, but I'm not certain what benefits it will bring in practice and worry that it will be misused. Specifically, I can easily see all of the following behaviours happening.
Edits that are disclosed to have had some LLM use just ignored/hatted/reverted/disregarded based on that alone without the content of the edit being even looked at to see whether it is actually good or bad
Editors being harassed because they didn't disclose LLM use in a edit that someone suspects (with or without good reason) was LLM-generated, even if the editor is telling the truth and they didn't use an LLM.
Editors being harassed because they didn't disclose LLM use for an edit, without regard to the content of that edit, based solely on a previous edit being disclosed as LLM-assisted. This will happen even when the editor is telling the truth.
False positives and false negatives due to editors not understanding what "LLM" (or some other term) means and/or not understanding what we mean by whatever term is used.
Different understandings of what constitutes LLM-usage (is it any use of an LLM? Only when the exact words in the edit were generated by an LLM and not reviewed? Somewhere in between?) leading to disagreements over whether an edit should or should not be marked as LLM-assisted. Such arguments will detract from the actual content of the edit (in some cases leading to the content being ignored completely).
Not every edit will result in one of these types of behaviour, but all of these that do will actively harm the encyclopaedia (not all in the same way), potentially very significantly, and all entirely unnecessarily. If we just accepted that just as some human edits are good and some human edits are bad, some LLM-edits are good and some LLM-edits are bad and that we can and should deal with them appropriately in each case without needing to know or care whether a good (bad) edit is a good (bad) human edit or good (bad) LLM edit or a good LLM-and-human edit. Thryduulf (talk) 22:51, 30 August 2025 (UTC)
I've already seen the first three, so the likelihood of those happening is 100%. WhatamIdoing (talk) 05:52, 31 August 2025 (UTC)
Thanks for the feedback, I definitely feel like there's an opportunity to instruct and not simply penalize or restrict here. I still think the sheer volume of these types of edits are the primary cause for alarm. I don't think anyone here wants to harass other editors, but as with any "rule", there is always the potential for abuse or misunderstanding. —Locke Cole • t • c 17:27, 31 August 2025 (UTC)
I don't think anyone in this discussion intends to harass other editors, but (per WAID) experience has already shown that regardless of intent, editors are being harassed. We should do our utmost to avoid that, and part of that is not instituting policies that stand a high likelihood of (unintentionally) enabling or encouraging harassment while simultaneously providing little to no benefit to the project. Thryduulf (talk) 22:42, 31 August 2025 (UTC)
Checkbox for disclosure
Note: I moved the following out of the subsection just above. --Tryptofish (talk) 22:43, 29 August 2025 (UTC)
I think this could actually be made in an even simpler way than an edit summary, by adding a checkbox next to the existing "minor edit" one. Wikimedia Commons already has a "this image was made by an artificial intelligence tool" checkbox, and, while the situations aren't directly comparable, most users are not fundamentally dishonest to the point of lying about this. Agree with your point regarding spell-checking errors, although these are, usually, easier to catch (grammar errors, or meaningless words similar in orthography to more relevant ones). Chaotic Enby (talk · contribs) 22:27, 27 August 2025 (UTC)
A checkbox would be great. But even just updating the system messages (the ones that display licensing information) to include a warning and link to the current LLM guidance would be an improvement. —Locke Cole • t • c 22:32, 27 August 2025 (UTC)
A checkbox would be amazing. I wonder if this is feasible in MediaWiki. Suriname0 (talk) 00:33, 28 August 2025 (UTC)
CE said Wikimedia Commons already has a "this image was made by an artificial intelligence tool" checkbox, and Commons runs MediaWiki, so if they can do it, I can't imagine we couldn't do something similar. —Locke Cole • t • c 01:07, 28 August 2025 (UTC)
Wikimedia Commons' Upload WizardHere is what it looks like, for reference. What I'm having in mind is a more lightweight checkbox that adds a tag to the edit (or, if it can't be done directly, switching a variable that the edit filter extension can then catch to add the tag). Disclosing the model and prompt might not be as useful, although they could technically be appended to the edit summary with a small dose of Javascript. Chaotic Enby (talk · contribs) 01:17, 28 August 2025 (UTC)
Hmm, yeah I think Special:Upload is a bit more customizable, though everything we see in the interface should be changeable somehow, see Special:Allmessages (which there's hundreds, maybe thousands, but there's some search functionality if you want to go digging). We could also ask at WP:VPT since there's plenty of folks who know this stuff under the hood more lurking there. —Locke Cole • t • c 01:27, 28 August 2025 (UTC)
It looks like the dialogue box for "publish changes" has many components, including
MediaWiki:Minoredit, which is the bit that goes before the "minor edit" checkbox
and presumably more. There's probably a wrapper too, but I can't find it.
We could maybe modify minoredit, but there's probably a nicer way of doing it. Cremastra (talk·contribs) 02:47, 28 August 2025 (UTC)
Having a checkbox is a very good idea, that I hadn't thought of. Perhaps, that might negate the need to propose a policy. On the other hand, I can think of two potential friction points. One is that an editor who makes bad-quality edits, but consistently checks the checkbox, might complain that there's nothing wrong with their edits because they used the checkbox, so why were their edits reverted? The other is whether or not we need a policy for someone who keeps making bad-quality edits, and ignores the checkbox. --Tryptofish (talk) 21:31, 28 August 2025 (UTC)
The checkbox wouldn't negate other content policies, so an editor making bad quality edits but using the checkbox wouldn't have any kind of immunity. In my mind, it is similar to the situation at AfC with COI disclosures – editors can and often do make the disclosure in the Wikipedia:Article wizard , but that doesn't make their submissions immune to other kinds of feedback or criticism. Chaotic Enby (talk · contribs) 21:55, 28 August 2025 (UTC)
Yeah, I think that gets it right. The checkbox is a technical feature that can and should be pursued independently of the policy-related ideas we are discussing here. --Tryptofish (talk) 21:58, 28 August 2025 (UTC)
It needn't necessarily even be a checkbox. Don't get me wrong, that would be great (but I suspect then everyone would want a checkbox for things that are, ostensibly, equal to or greater than LLM/AI discloure (like COI, or copyright/plagiarism, or paid editing; the list is long). The other possibility is adding something to the boilerplate text (in replytool the By clicking "Reply", you agree ... language; the full interface editor has something similar). Something short, like You agree to abide by our LLM/AI disclosure rules, and that failure to do so may lead to blocks or bans. With wikilinks to appropriate pages should disclosure become policy. —Locke Cole • t • c 22:34, 29 August 2025 (UTC)
Copyright/plagiarism is already banned, and copying with attribution needs the attribution in the edit summary (a simple yes/no check wouldn't work), but COI/paid editing could absolutely also deserve a checkbox. If anything, both that and AI disclosure are more important than the current "minor edit" checkbox, which is often misused and doesn't actually tell much. Chaotic Enby (talk · contribs) 20:38, 30 August 2025 (UTC)
Oh I know they're already restricted, I was just pointing out that if we start down this path, it wouldn't be much to think that we'd end up with 4-5 checkboxes before you know it. And then contributing to Wikipedia would turn into a CAPTCHA-esque triathlon of mouse clicks/screen taps just to submit something. However, a short sentence (with links for further details) about how we require LLM/AI disclosure (assuming Tryp's idea gains community support). As Tryp rightly points out below, however, there is the risk of "banner blindness" if we just add some text and people ignore it completely (the 'ol "officer, I didn't see the speed limit sign"-excuse). —Locke Cole • t • c 21:16, 30 August 2025 (UTC)
New editors who see a checkbox that says says "this edit was created with the assistance of an LLM" or otherwise will likely view it as a tacit endorsement by the project of LLM editing. This is in misalignment to current community sentiment. I'd oppose the addition of any such checkbox. fifteenthousandtwohundredtwentyfour(talk) 22:45, 28 August 2025 (UTC)
Yes, but then we catch them, revert their edits, and tell them. It's a way for them to alert us of their own will that they're dangerous. Cremastra (talk·contribs) 22:53, 28 August 2025 (UTC)
Perhaps, but I agree with 15224 that we should not use language that will mislead them into thinking that the community accepts this. --Tryptofish (talk) 22:56, 28 August 2025 (UTC)
I think it would ultimately encourage more editors to use LLMs and lead to more LLM-based edits made to the encyclopedia. This is an undesirable outcome. On top of this, editors already have enough problems properly utilizing the minor edits checkbox, and I expect self-snitching compliance with such a checkbox to be extremely low. The harm will well outweigh any theoretical good. fifteenthousandtwohundredtwentyfour(talk) 23:12, 28 August 2025 (UTC)
The best equivalent for self-snitching compliance is the voluntary COI disclosure at AfC, which a surprisingly large proportion of users have been making. Chaotic Enby (talk · contribs) 23:16, 28 August 2025 (UTC)
"large proportion"– Compared to total AfC users? Sure. Compared to total undisclosed COI editors? I'd say that's unknowable. Based on my limited experience with some UPE farms I'd guess there's more not disclosing than disclosing. And asking for COI self-disclosure carries a lower inherent WP:BEANS risk than a checkbox for disclosing LLM use. fifteenthousandtwohundredtwentyfour(talk) 23:52, 28 August 2025 (UTC)
It looks to me like nothing about the checkbox idea negates the possible proposal being discussed here, so I think that it's really a separate topic that, if people want to explore it further, should be taken to a talk section of its own. --Tryptofish (talk) 00:19, 29 August 2025 (UTC)
I think it would ultimately encourage more editors to use LLMs
Honestly, I doubt this. ChatGPT has been around for 2 years and has a great deal of name recognition and regular use. If someone's using an LLM to contribute to Wikipedia, they're probably routinely using AI already and were going to do it anyway. I can't see a situation where someone comes to Wikipedia not intending to use ChatGPT, then changing their mind when they see the checkbox, after they already made the edit.
As far as "self-snitching compliance," you would be surprised at how many people will be open about using AI if you ask politely. (If you ask adversarially, which is what people are doing more often, then they won't.) The risk isn't so much people lying as people not knowing how substantial AI edits can be. A pretty common scenario, for instance, is someone whose first language is not English asking ChatGPT to generate a Wikipedia editing prompt, and then feeding that AI prompt back into ChatGPT or some other AI tool. Even if English is your first language, AI editing tools advertise a lot of use cases and it's unclear what the differences are -- usually because it's marketing and the details are deliberately vague. Gnomingstuff (talk) 19:30, 30 August 2025 (UTC)
My concern is less about making editors aware that LLMs exist and could be used, and more about doing everything we can to not look like their use is endorsed in any form. As said above I think many will see it as tacit endorsement of model use, and take it as permission to go ahead in the future.
I can definitely imagine scenarios where a checkbox would be helpful, but overall I think it would cause more harm. fifteenthousandtwohundredtwentyfour(talk) 20:04, 30 August 2025 (UTC)
How would you feel then about a checkbox with something along the lines of "this edit was created with the assistance of an LLM, and I attest that I personally verified the accuracy of the generated text"? CoffeeCrumbs (talk) 19:17, 30 August 2025 (UTC)
We can't say "LLM," people aren't going to know what that is. We have to say "AI," and we probably should also include some examples, like "such as ChatGPT, Perplexity, etc.).
Verifying the accuracy is also only half the problem. The other half is editorializing slop. Unfortunately there seems to be a widespread impression, which AI tools are actively encouraging, that adding this stuff is improving writing, instead of both bad writing and original "research". Gnomingstuff (talk) 19:33, 30 August 2025 (UTC)
Maybe "I attest that I reviewed our guidelines (link to OR, etc.) and personally verified the accuracy of the generated text"? (but see below) Chaotic Enby (talk · contribs) 20:40, 30 August 2025 (UTC)
Still not gonna cut it, people will just ask the AI to verify the accuracy. Gnomingstuff (talk) 17:28, 1 September 2025 (UTC)
I don't think it matters what text accompanies it, if the text indicates LLM use is ok in some form so long as a box is checked, that's the association that will be made.
A secondary concern is the fact that LLMs have numerous shortcomings that are harmful to the encyclopedia, far too many to cover in a snippet, and a link to more information would go largely unread. fifteenthousandtwohundredtwentyfour(talk) 20:06, 30 August 2025 (UTC
Yeah, those are good points. I'm less and less convinced that we can make a succinct enough checkbox that doesn't convey the "LLMs are a valid way to contribute" impression. Chaotic Enby (talk · contribs) 20:43, 30 August 2025 (UTC)
That's what I'm coming to think, too. As I've been following this discussion, I think the combination of "banner blindness"/didn't read, along with the misimpression that LLMs are a valid option, are things we won't be able to get around, no matter how we try to frame the checkbox question. --Tryptofish (talk) 20:49, 30 August 2025 (UTC)
However, there are concerns. I see some editors here showing their concern that using such a 'disclosure checkbox' might encourage Wikipedia users to use AI more than before.
I might as well request them to the see the other side of the coin. I've seen a lot of editors in this discussion having a knee-jerk reaction against the use of AI. So as soon as someone adds the 'AI tag' in their addition through the checkbox, these type of editors will instantly take 'em down regardless of the value they might add to Wikipedia.
As such, I think there should be a proper guideline to the editors, as on how to be benevolent to good faith AI additions which are clearly useful to Wikipedia, before adding such a checkbox.Cdr. Erwin Smith (talk) 05:47, 3 September 2025 (UTC)
The number of uploads on Commons that claim own work when they are definitely not limits my enthusiasm for submission checks. Regarding the concept, if the aim of the checkbox is to find edits to revert, then that sets it up to be detrimental to the more honest editors. CMD (talk) 09:32, 3 September 2025 (UTC)
That's a good point, although Commons also has AI disclosure, and most of the undisclosed AI images that I've found are from people who were spamming anyway. Gnomingstuff (talk) 13:52, 3 September 2025 (UTC)
CMD makes a very good point. People claim "own work" on Commons all the time. Cross-wiki/within-the-editor uploads have been restricted because people think "Well, if I don't claim that this corporate logo/album cover/normal thing to include is 'own work', then it won't let me upload it. So of course I tick the box!" An interface item that requires disclosure will, at least by a non-trivial group of users, be ticked or not based on what they believe will produce the results they want. WhatamIdoing (talk) 02:55, 4 September 2025 (UTC)
The RfC isn't about Wikimedia. It's about 'discussions seeking community input' in Wikipedia.
Let's not veer off course. Cdr. Erwin Smith (talk) 15:02, 4 September 2025 (UTC)
It's not off topic. Human behavior is the same everywhere, especially when it's the same humans. An editor who – right here, at the English Wikipedia, in the 2010 wikitext editor – will click the 'Image' button in the toolbar, click the "Upload" button in the dialog box, and then tell an outright lie when faced with a tickbox that says "This is my own work" is an editor who – right here, at the English Wikipedia, in the 2010 wikitext editor – will equally tell an outright lie when face with a tickbox that says "I certify that I wrote this myself without using AI".
There is no reason to believe that Wikipedia editors will frequently lie when shown one tickbox in the wikitext editor and yet be reliable truthful when shown a very similar tickbox in the same editor. WhatamIdoing (talk) 21:45, 4 September 2025 (UTC)
Indeed, this comparison seems fair and similar 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 23:08, 4 September 2025 (UTC)
To explain myself, what I wanted to say is that there's no such stringent licensing requirements in most of the Wikipedia "discussions seeking community input", as opposed to Wikimedia where it's very stringent.
So I think people will be more willing to disclose the use of AI. But it should only be done with a proper guideline on how to handle such requests benevolently, and not for the sole purpose of striking them down. Cdr. Erwin Smith (talk) 13:07, 5 September 2025 (UTC)
Oppose - Many people use LLM to improve their own grammar, including me. You have to realize that we have Wikipedians from all over the world with English as not their first language and have poor grammar. Instead of completely disssallowing it, meybe there needs to be a disclosure by the person that used LLM and an explenation as to why they used it. I also don't beleive anyone requesing RFC, AFD, etc with use of LLM has any other intent than posting what they intent to post. At the end they are probably reading what the the AI said and maybe even revising it before posting it.Darkm777 (talk) 18:39, 6 September 2025 (UTC)
(Unfortunately, your !vote here demonstrates the reality in which we increasingly have to work. It's a reality where editors who ostensibly characterize LLMs as purely supplementary or secondary to their participation in discussions, are nonetheless using them in some manner where they take time to read and understand what other editors have actually said far less than would otherwise be necessary to participate, yet replying as if that matters little to others–whether one's efforts to communicate are equally justified if they get processed solely by a prompt on the other side without the ostensible person in the equation bothering whatsoever to chip in to the discussion.) Remsense🌈论 18:51, 6 September 2025 (UTC)
With all due respect, you should not be using an LLM. I'd rather people make grammar mistakes in their own words. Cremastra (talk·contribs) 22:14, 6 September 2025 (UTC)
Yes, or you can put it through a grammar checker like the one built into Microsoft Word, Grammarly or whatever. I'd rather read a comment with bad grammar and no puffery than something with the most exquisite grammar, so good that i start convulsing with joy, and even a little bit of puffery. 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 23:33, 6 September 2025 (UTC)
I'm a bit skeptical about the checkbox. There is a grey area here - some editors use LLMs to write whole posts and some use them to check grammar or style. If marking one's edit as AI-assisted gets perceived as diminishing the strength of one's argument, editors will tend to "forget" to mark their edits.
Also, it took me a couple of minutes to get the GPTZero score of a purely AI-generated text to 54% and I'm sure I'd be able to reduce it even more with a bit more effort. So since we have no reliable way of detecting these edits we we'd create an incentive to lie without any means to counter it. Alaexis¿question? 21:18, 8 September 2025 (UTC)
On the note of reliability: at least one study has suggested that people who know what to look for are still very capable at detecting AI text even after it's been "humanized." Gnomingstuff (talk) 19:56, 19 September 2025 (UTC)
Since the discussion is slowing down, I'll be giving my final opinion on the whole debate.
Oppose the speedy closure of "discussions seeking community inputs" written by AI.
Support a Checkbox for AI disclosure, with the AI category having a 3rd subcategory asking people to state 'why' they used the AI, or their 'purpose' - Fixing Grammar/Finding Relevant Policies/Writing 'XYZ Edit or Request' Partially/Writing 'XYZ Edit or Request' Fully.
Support a specific policy for all editors to act neutral and treat such AI Edits/Requests equally as they would a Human Edit/Request (Note: A proposal on not flooding the AfD either by AI/Human is being worked upon).
I have many issues with your last point, but probably the most important is that Wikipedia does not have "higher-tier editors" or different policies for them. jlwoodwa (talk) 00:28, 12 September 2025 (UTC)
Policies apply the same for everyone, sure. But there's definitely a hierarchy present in Wikipedia based on tools and user rights, and one can only climb the ladder step by step on the basis of their actions. The number of users decreasing drastically in each higher level is a proof.
However, you are partially right. Although the influence of the higher-tiers is much bigger, I did forget that Autoconfirmed users can also participate in many of the 'discussions seeking community inputs'. So the same ruleset should apply to them as well. I would also be adding the ongoing AfD issue which is being worked upon. Cdr. Erwin Smith (talk) 10:34, 12 September 2025 (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.
RFC: Making exceptions to the "No Flag in Infoboxes for Micronations" RFC
I also realize that Micronations arent technically real countries, but some sources, primary AND secondary all corroborate the same thing, "republic of *country name here* has a flag of green blue and red". So I am wondering if for micronations, if we should just include the flag, or keep it the same way that people in the original RFC voted to remove the symbols from the infoboxes.
My general proposal (using my micronation's country infobox for a second)
Quick facts United Duchies of Nueva BerlandiaMicronation, Capital ...
I'm tempted to say just do whatever gets the stick dropped the quickest. Phil Bridger (talk) 20:16, 11 December 2025 (UTC)
I'm not seeing anything in this proposal that wasn't brought up in the first RfC or the discussion that you linked. We should not have to "vote" on it a third time. Schazjmd(talk) 20:45, 11 December 2025 (UTC)
I'm doubting it. ~2025-40115-56 (talk) 01:18, 12 December 2025 (UTC)
If the micronation you created ever becomes notable and gets an article, I am extremely skeptical that anything you have put in the proposed infobox template will actually be among the most relevant facts to convey about it (which is what infoboxes are meant to do). A lot of discussion went into shaping the current Template:Infobox micronation to focus on actually relevant info, and I don't see any compelling reason to revisit it so soon.--Trystan (talk) 01:26, 12 December 2025 (UTC)
This sounds like repealing the RfC rather than an exception. CMD (talk) 01:53, 12 December 2025 (UTC)
I've never been involved with this issue before, so I'm reading that RfC close for the first time. It says:
Consensus is against generally including the flag, coat of arms, and other purported symbols of the micronation, though it may be appropriate on a case-by-case basis. The ultimate conclusion is that these symbols are often not recognized or reliably verifiable, and could easily mislead a reader; that they are not used in the same way as countries, and so should not be treated in the same way. Certain symbols which are recognized or reported by reliable sources may be appropriate to add, as important information.
It seems to me that the close already includes the "exceptions" EditorShane is asking for. When a flag is "recognized or reported by reliable sources", it "may be appropriate to add". For instance, I remember coming across an article on "Liberland" recently that described the flag and incuded a photo of it (possibly this CNN piece). That resolves the verifiability issue and suggests this information may be due for inclusion. Toadspike[Talk] 07:43, 12 December 2025 (UTC)
So the very title of this section is misleading - it's not the "no Flag in Infoboxes for Micronations" RFC at all. There must be a Wiki on Fandom about micronations which doesn't have Wikipedia's rules about verifiability and infoboxes where the OP can play away to his (nearly all micronation fans seem to be male, for some reason) heart's content. Or, if not, he can create one. Phil Bridger (talk) 11:39, 12 December 2025 (UTC)
No, what I am proposing here is to include JUST the flag in the infobox shane(talk to me if you want!) 13:56, 12 December 2025 (UTC)
The close was by an editor with like 50 edits at the time who later got involved in micronation articles advocating to add flags etc. to the infoboxes. It should have been overturned and closed by someone competent who actually read the discussion, where there was overwhelming support for excluding any info not present in the proposed infobox, no exceptions. The Liberland article has a flag outside the infobox, which is acceptable if appropriately referenced. JoelleJay (talk) 19:02, 19 December 2025 (UTC)
No flags for micronations. I'm actually a little concerned that the micronations infobox and the way micronations are portrayed on Wikipedia is giving them, in Wikivoice, a legitimacy that doesn't actually exist. Many of them seem to be worded as Wikipedia saying they're more than some people's weekend model UN style of hobby and an actual legitimate thing. However I know this was addressed in the RFC, but I wonder if some are going to far in Wikivoice. Canterbury Tailtalk 16:13, 12 December 2025 (UTC)
A flag at the top of the infobox is a non-starter. Others have given arguments why. Optonially allowing symbols (e.g. flag, coat of arms or logo) at the bottom of the infobox may be a compromise. But if we allow it, how do we make sure symbols are only included where they are WP:DUE? Joe vom Titan (talk) 07:18, 13 December 2025 (UTC)
I also realize that Micronations arent technically real countries. What a ridiculous comment. Micronations aren't countries at all. They are overwhelmingly fantasies and/or moneymaking schemes. As such, their flags are of no encyclopaedic interest whatsoever. Where they aren't being spammed over Wikipedia to mislead readers into thinking they actually represent anything real, they are just micronation-fantasist fancruft. Wikipedia is blighted with far too much of that as it is, and I see no reason why we should encourage more. AndyTheGrump (talk) 16:52, 12 December 2025 (UTC)
Question Micronations aren't nations, but many of them are genuine projects, perhaps carried out by organizations of some sort. When we have an article on an organization, we'll display its logo. Is the flag of a micronation comparable to the logo of a conventional organization? —Preceding unsigned comment added by Largoplazo (talk • contribs) 16:56, 13 December 2025 (UTC)
Off the top of my head, I can't think of any micronations that have been promoted by organizations that meet Wikipedia WP:NORG notability criteria. Most consist of little more than a website, generally one set up to gather funds. Corporate logos are ubiquitous, and many are likely to be recognised by readers. Flags of imaginary entities are recognised by nobody but those doing the imagining. So not comparable in the slightest, just promotional fluff. AndyTheGrump (talk) 18:50, 13 December 2025 (UTC)
Do we ever suppress corporate logos on the grounds that the corporation is small and hardly anyone outside the corporation would recognize its logo? -- Beland (talk) 00:57, 14 December 2025 (UTC)
Wikipedia is a encyclopedia which means it gives information, having a flag in a article about the micronation gives information to the reader if they want to learn more about micronations, they would want to know the flag, it's history, culture, and purported currency. shane(talk to me if you want!) 01:18, 14 December 2025 (UTC)
The point is that adding a flag conveys false information with the implication that something other than a joke is going on. Johnuniq (talk) 03:19, 14 December 2025 (UTC)
Having a flag doesn't imply the existence of a serious, territory-holding country. All sorts of entities have flags, from companies to vague social movements. The text of the article should make very clear if a micronation is a joke. -- Beland (talk) 03:24, 14 December 2025 (UTC)
Principality of Sealand, for example, is substantially more than fancruft. It's a physical place with a real-world economy that was chosen because it was in international waters, and has had real territorial disputes. Its flag flies on the territory it claims. -- Beland (talk) 00:56, 14 December 2025 (UTC)
Oppose flags appearing in the infoboxes. We've been over this. If there is sufficient secondary independent coverage of a flag (not just mentions), then a picture might be BALASP somewhere else in the article, but definitely NOT the infobox. JoelleJay (talk) 19:06, 19 December 2025 (UTC)
RFC on the notability of corporate goods and services
WP:NCORP presently states that it is to help "determine whether an organization (commercial or otherwise), or any of its products and services, is a valid subject for a separate Wikipedia article"
Do you agree or disagree that this includes lists of goods and services? FOARP (talk) 11:05, 15 November 2025 (UTC)
Survey (NCORP)
Agree - NCORP is meaningless as a standard if it can simply be avoided by turning whatever WP:PROMO article it is you wish to write into a list of the goods/services of the company concerned. It simply does not make sense that you should be able to write a article listing the goods and services of a company (so basically an article about the company) based on local coverage, trade-press, primary news coverage based on press-releases and company announcements, when you are barred from doing so about the company itself or individual goods and services. Basically, there's no reason why we should be able to have an article entitled List of pizzas sold by Phil's Pizza Shop based entirely on press-releases, local news coverage, and trade-press, when Phil's Pizza Shop would be non-notable under such WP:SIRS-failing coverage. Even a straight-forward reading of NCORP, which states that it applies to "any" of an organisation's goods and services, indicates that it was always intended to means lists of the same. FOARP (talk) 11:05, 15 November 2025 (UTC)
Disagree. NCORP is unambiguously about prose articles, the relevant standard for lists is WP:NLIST. Multiple people have told you this in multiple different discussions, it's time to drop the stick. Thryduulf (talk) 12:09, 15 November 2025 (UTC)
WP:NLIST applying does not preclude other standards also applying. Again, why should List of pizzas sold by Phil's Pizza Shop be notable if Phil's Pizza Shop isn't notable? FOARP (talk) 12:33, 15 November 2025 (UTC)
Sure, if Phil’s isn’t notable then their pizzas will not be notable. However, what if Phil’s is considered notable? At that point you have to consider why Phil’s is notable.
IF they are notable for their pizza, then a list of their pizzas might be appropriate. However, they might be notable for (say) the architecture of their building… or for some other factor. In which case a list of pizzas is inappropriate.
Apparently this thread was inspired by lists of airline destinations, where the airlines themselves are considered notable (so NCORP is not the issue). The next question is, why are these airlines notable? Are they notable for their destinations? Are they notable for the type of planes they fly? Are they notable for the luxury of their first class service? Etc. Blueboar (talk) 13:23, 15 November 2025 (UTC)
I think you are confusing two different types of "notable for their food". A restaurant may be notable for having good food, but that doesn't mean that the individual items on their menu are notable and deserving of a listing here. However, a restaurant may be notable for having a "super giant pizza challenge", "world's largest cheeseburger", etc. These sorts of things could be worthy of mentioning in the restaurant's article. To take your airline example, the fact that a hypothetical "Flybynite Airlines" exists and has flights to 37 different countries could be notable, but that those flights include an Ottumwa, Iowa to Bamberg, Germany flight is not. At least not within the parameters of this site. --User:Khajidha (talk) (contributions) 16:31, 17 November 2025 (UTC)
NLIST explicitly says Notability guidelines also apply to the creation of stand-alone lists and tables. NCORP is one of the notability guidelines. JoelleJay (talk) 18:27, 10 December 2025 (UTC)
Disagree The concern that we will have a list of products of non-notable companies is completely hypothetical. It also has an easy compromise solution, allow a list of products of company X only if the company itself passes WP:NCORP. Ultimately, we should prioritize the readers in such discussions. A significant part of them use mobile and benefit from shorter and more to-the-point articles. Stand-alone lists are useful so they don't need to spend additional time navigating the parent article. The readers also won't benefit if we remove most of the entries in Category:Lists of products. Kelob2678 (talk) 13:26, 15 November 2025 (UTC)
Partial agree Given that NLIST doesn't necessary require notability of the "products made by company X" be a notable topic nor company X to be notable if the list is, we still want WP:SIRS (sourcing requirements) from NCORP to be respected if we're just creating a list where individual products may be notable. Even if company X is NCORP-notable, a full list of their offered product or services without SIRS-type sourcing will still be a problem in failing the goal of NCORP, which is to avoid using WP for promotion or business purposes. If there is SIRS-type sourcing for every product, great (this to me would be a case for something like Apple iPhones which absolutely do not go unnoticed by the general media). But if such a list is heavily relying on only press releases or similar first-party, dependent material, that's not acceptable. Masem (t) 13:34, 15 November 2025 (UTC)
Agree. Why should lists be exempt from this policy? List cruft doesn't belong in an encyclopedia. Joe vom Titan (talk) 15:01, 15 November 2025 (UTC)
Close this in favor of Wikipedia:Village pump (policy)/Airport destination lists Do we really need even more wikilawyering from people fighting over that topic? As for the question at hand, WP:NLIST seems the appropriate guideline to follow. If there's any reason that lists of a corporation's products and services can't effectively be handled by WP:NLIST, I doubt we'll find it buried in the airport destination list mess. Anomie⚔ 15:15, 15 November 2025 (UTC)
Bad RFC While I appreciate that the proposer does note below what induced them to start this, this feels like a roundabout form of forum shopping to get an answer to one question that he can apply to a different one. This question is a bit vague and does not include a specific proposal regarding language on that page. Anomie makes the right points, though I'll note that airport destination sections are very different from standalone airline destination lists in how they're presented and constructed. Anyway, I disagree and don't think the pages in Category:Lists of products or those the proposer has been nominating necessarily need to be deleted under these grounds. If a corporation is notable, it often makes sense to provide what makes them notable, be that what they manufacture or where they operate. We are generally able to address this kind of listcruft already without this RFC. Reywas92Talk 17:05, 15 November 2025 (UTC)
It is reasonable for a notable company to describe the types of products or services they offer as described by third-party sources. This is not the same as supporting a list of every product or service offered, unless that full list can be supported by third-party sources. Otherwise, that's likely violating NCORP and definitely violating NOTCATALOG. Masem (t) 20:05, 15 November 2025 (UTC)
But it does square with WP:SUMMARY. These lists of products are properly thought of as sub-articles created as spin outs of the company articles as the list, even if well-curated to avoid becoming a catalog, would be too long for the main article. Can't knee-jerk judge these. oknazevad (talk) 21:55, 15 November 2025 (UTC)
There's no issue with a curated list of products that have been discussed to some depth in secondary sources (not necessarily enough for a standalone article but more than a simple name drop). But the implication here is a complete list of products or services as a separate list, and that's where NOTCATALOG can be a problem. Masem (t) 02:20, 16 November 2025 (UTC)
Agree A partial and generalized list of products a company offers should be included in the main company article. I see no reason why there should be a separate list that's essentially acting as a company version of WP:FANCRUFT to include every single product the company offers. And if you are going to have one, it absolutely needs to adhere to minimum WP:NCORP requirements. Wikipedia is not a product directory, though it appears some would like it to be some sort of catalogue of all goods and services that exist. That is not what an encyclopedia is for. SilverserenC 21:57, 15 November 2025 (UTC)
Partial agree In general, I think that the standards of NCORP apply to lists of goods and services. I am not sure to what degree this should also apply to any specific circumstance (such as airline destination lists). —Preceding unsigned comment added by Enos733 (talk • contribs) 00:41, 16 November 2025 (UTC)
No bold, as I'm not quite sure where my comment would fall. NLIST would seem to be appropriate, but if a company fails NCORP I can't see how a list of their products could be notable. I could also see a list of products being covered by WP:NOTPROMO unless there's independent sourcing. -- LCU ActivelyDisinterested«@» °∆t°
Disagree Wikipedia isn't a shop. Does it say we are shop anywhere? We not in the business of listing a catalogue of goods. That has been understood for more than 2 decades. Its been long established consensus since 2016-2017 years that companies don't list their products unless the product is standalone notable per WP:GNG and the company is notable per WP:NCORP. They it can get seperate article that is sourceable to secondary sources. Before that the company had to be notable per WP:GNG before the product could get an article. There was a reason for this, simply that Wikipedia was flooded by company brochure articles that had reams of products listing. Are we looking to go back to that. It was always understood that product listing were WP:PROMO and needed to be removed. They had to pass WP:GNG to be notable on their own before inclusion. NCORP does not apply to list of goods. It was written specifically for company entities only. How is corporate notability applicable to a product? If the company fails WP:NCORP the product isn't notable. scope_creepTalk 07:12, 5 December 2025 (UTC)
Disagree, I guess, but the question isn't really addressing the underlying problems. We're handling WP:SIZE splits poorly. If an article about a notable business gets so big that we need to split it, then it should not be easy for an editor take the split-off content off to AFD because they personally don't believe that List of Apple products has been "discussed as a group or set by independent reliable sources". We should also support the creation of {{navigation lists}} (=all/nearly all blue links), even if an individual editor prefers categories or even if they don't value the sources currently in the list. This is all clear as mud in our current guidelines, and that leads to a few editors believing that these pages are officially unwanted, and then getting surprised and feeling frustrated when the community rejects their efforts to get the lists deleted. We need to fix that, but I still don't have any good suggestions for how to do that. WhatamIdoing (talk) 21:41, 7 December 2025 (UTC)
Agree. I don't see how a list article for products and services of a company does not fall under NCORP. We already have guidance on lists that unambiguously serve a navigational purpose and how those are treated by N, so reaffirming that product lists that do fall under N still need to meet the appropriate notability guidelines really shouldn't be contentious. JoelleJay (talk) 18:16, 10 December 2025 (UTC)
Discussion (NCORP)
This RFC is a response to the statement in numerous AFD's (e.g., this, this, this) that lists of company services did not fall under the WP:NCORP guideline. FOARP (talk) 11:05, 15 November 2025 (UTC)
This RfC is another episode in the saga about airline destination lists. Most of the recent AfDs regarding them were initiated by FOARP. Earlier this year, the community expressed their doubts about whether WP:NOT applies to them. Now, the issue is being pressed from the WP:NCORP perspective. The change discussed here was boldly added to the guideline and was reverted. In response, we got this RfC.FOARP himself notes, we still have listings of airline services that don't pass either WP:NLIST or WP:NCORP. So why do we even need to subject the lists to WP:NCORP? In my opinion, to make the discussion more focused, it's better to stick to WP:NLIST. Kelob2678 (talk) 13:26, 15 November 2025 (UTC)
"why do we even need to subject the lists to WP:NCORP" - to avoid WP:PROMO content based entirely on press-releases, local coverage, trade-press etc., just simply written as a list rather than as a prose-article. FOARP (talk) 15:04, 15 November 2025 (UTC)
Hi, we were indeed discussing it, but it doesn’t look like there was enough participation since only you and I contributed to the discussion there which was why VPP is probably a better forum. FOARP (talk) 08:27, 16 November 2025 (UTC)
The core question here is the “group or set” requirement of NLIST… are airline destinations as a set notable? To answer that, we need to ask: Are there independent reliable sources that discuss the concept of airline destinations as a set? Blueboar (talk) 14:03, 15 November 2025 (UTC)
The "discussed as a group" requirement does not have wide agreement in the community about what it means. Mostly, people seem to think that of course it supports "my" general view on the deletionism–inclusionism spectrum, whatever that view is. WhatamIdoing (talk) 23:09, 15 November 2025 (UTC)
This reminds me of the discussion that led to ongoing development of the Wikipedia:Directory articles proposal. As a product meeting the standards for having an article does not automatically mean that the associated organization meets the standards, theoretically there could be a company with a list of products that have articles, while the company does not. I don't know if there are current examples in mainspace that we could examine, though. (User:Theleekycauldron/List of projects by Complexly is an example given in the directory articles proposal, though Complexly has a mainspace article.) isaacl (talk) 19:55, 15 November 2025 (UTC)
Thinking about that example further, I guess privately-held, small-shop companies could be a typical use case. A one-person (or small number of people) company could create one or more video or audio channels, for example. The channels could meet the standards of having an article while the company does not, as there often isn't much available public information about small private companies for secondary sources to write about. isaacl (talk) 20:06, 15 November 2025 (UTC)
I came across an example a couple of months back that I unfortunately cannot remember the name of when writing a disambiguation page - a small (Indian iirc) motorcycle manufacturer that makes/made 2-3 unambiguously notable models but is not themselves notable as nobody has written anything in-depth about the company (at least in English). Thryduulf (talk) 20:53, 15 November 2025 (UTC)
That seems so very backwards to me. If a company makes multiple notable products, than that company is notable. WP:NOTINHERETED is a downstream thing, not upstream (like actual inheritance). It is and remains true that just because a product is made by a notable company, doesn't mean the product is inherently sufficiently independently notable for an article. But a notable product does confer notability on the company making it, as the company is notable as the manufacturer of a notable product.
Plus there's no requirement that sources supporting notability are in English. oknazevad (talk) 21:52, 15 November 2025 (UTC)
That's exactly how I've always used it and how many of our notability requirements use it. WP:NAUTHOR is entirely about how producing notable works makes the author notable. Similarly with scientists, their notability is based on producing notable research. NOTINHERITED applies to things at a lower level than the thing in question. SilverserenC 22:00, 15 November 2025 (UTC)
I only mentioned English as that's the only language I searched for sources in. NOTINHERITED does work both ways, otherwise the parents of notable children would be automatically notable, holding companies would be automatically notable if any subsidiaries are notable, an author of a notable book would be automatically notable, record companies of notable artists would be automatically notable, etc. That's obviously not the case - the subjects of articles need to have coverage in multiple independent reliable sources. Thryduulf (talk) 22:11, 15 November 2025 (UTC)
Authors of notable books are automatically notable. SilverserenC 23:09, 15 November 2025 (UTC)
Usually, but not necessarily… a book written by an anonymous author might become notable. Blueboar (talk) 23:20, 15 November 2025 (UTC)
Books have their own notability standard. What we are discussing is that inherited notability upward does occur in specific topics, such as for authors. If you write books that are notable, that notability is conferred on you, hence WP:NAUTHOR. Which is why generally in discussions about author notability, we require 3 RS reviews of an author's books to say they are notable for having written notable books. Because 3 reviews is the minimum standard for book notability even if a book article hasn't been written yet. SilverserenC 23:41, 15 November 2025 (UTC)
Authors are notable through WP:SNG. If the notability were inherited, there would be no need for the SNG at all. But since it is better for the encyclopedia to have articles on academics, the special exception was made for them. No such thing has happened to commercial organizations. Kelob2678 (talk) 13:15, 16 November 2025 (UTC)
True, but I think that when we parse company vs CEO vs products vs subsidiaries, we're overlooking the value of a merged-up article that covers all of these. We don't want an article title like Bob, blue-green widgets, and Big Business, Inc., but we do want a page that lets us write not just about the motorcycles but also a paragraph about their manufacturer.
For CORP in particular, this should probably be called out as an explicitly desirable outcome. CORP articles are particularly at risk of someone saying "Well, the title is just Big Business, Inc., but half the sources are about Bob and blue-green widgets, and what's left isn't quite enough to count as SIGCOV IRS in my opinion, so I'm taking it to AFD." WhatamIdoing (talk) 00:18, 16 November 2025 (UTC)
If there's nothing more to say about a production company than "it produces YouTube channel A since XXXX, B since YYYY, and podcast C since ZZZZ", then I can appreciate an argument that a list article is sufficient for the company, and that it does not otherwise meet the standards for having an article. Nowadays, anyone can privately finance a production company and not make any significant public revelations. isaacl (talk) 22:50, 15 November 2025 (UTC)
I don't think this is a popular interpretation of NOTINHERITED at e.g. AfD. You could be right! But it's worth noting the disagreement Katzrockso (talk) 00:00, 16 November 2025 (UTC)
Having taken part in a few AFDs of video game studios, I'll second that it is not a popular interpretation of NOTINHERITED at AFD – even if a studio has multiple notable games, AFD consensus is that just the games are notable, not the developers. Nil🥝 22:22, 17 November 2025 (UTC)
WP has no concept of inherited notability in general. Some of the SNGs, like WP:CREATIVE, do give the credence that if the creator has multiple notable works that the creator is presumed to be notable, but that does not extend to companies at all (though I do think for companies that are involved in creative product creation, we should have something in this aspect, but this is not the place for that discussion. Masem (t) 02:23, 16 November 2025 (UTC)
What we do have is wide latitude to decide how to cover a given topic... In one context it will make sense to have the stand alone article be about the work with a subsection about the creator, in another the creator with a subsection about the work, and in a third both could merit stand alone articles. Horse Eye's Back (talk) 03:48, 16 November 2025 (UTC)
Having participated in some of the many discussions regarding airline (and airport) destination lists, I think the question is not so much whether NCORP as a whole applies to lists of a company's products and services, but whether NCORP's sourcing criteria, primarily WP:SIRS, should be applied to such lists. If the items on the lists are individually notable then such a requirement would be moot, but does an article listing products or services that are not individually notable require SIRS-level sources covering the list as a whole and/or all items on the list? I think the answer is yes, strict sourcing criteria should apply in such cases, particularly if the list is intended to be comprehensive. Rosbif73 (talk) 15:44, 17 November 2025 (UTC)
This is an absolutely terrible RFC. Badly thought out in an attempt to usurp 20 years of thinking on corporate notability. Its takes no cognizance of the reasons for NPP/AFC, the storm of UPE company articles between 2008-2018, (mostly brochure and native advertising articles with lots of products listings) the promotional aspect of UPE article nor the reasons for the failure of WP:NORG and the reasons for eventually bringing in WP:NCORP, which are all there to read in the archives. scope_creepTalk 07:12, 5 December 2025 (UTC)
Possible update of WP:OSPOL following TA implementation
Hello all, with the implementation of temporary accounts the Oversight Team would like to request feedback on some needed changes to the oversight policy. Please join in the discussion here. Thank you much, Primefac (talk) 22:37, 20 December 2025 (UTC)
Notability Guidelines - Indigenous leaders
Similar to WP:WIR, Wikipedia has a known issue of systemic bias against Indigenous/First Nations people and leaders. I'd like to propose a new caveat to the Notability of People policy so that Indigenous tribal leaders have lower bars to entry than normal politicians. Legally (at least in Canada), native tribes are considered semi-sovereign, so their leaders are something akin to heads of state. While that is obviously not how they are treated on a practical level, it does make sense to think of them as something more than just a 'local elected leader' or city council member. And I am going to bring up the specific example of Lynda Price, who was in office for cumulatively a decade and has a lot of local reporting about her and her family, whose article was recently proposed for a deletion because 'local sources weren't notable enough'.
I would propose that any indigenous tribal chief that has a good amount of secondary sources about them (not just election results, but actual information) be considered notable enough for an article. TimeEngineer (talk) 09:05, 14 December 2025 (UTC)
Any topic with a "good amount of secondary sources" meets the GNG. No need for a carveout. I think what you're really looking for is for the leaders of sovereign tribes to be considered automatically notable under NPOL, which is something I could get behind. But again, arguably these already are "national or state/province–wide office", so I'm not sure we need a new rule. Toadspike[Talk] 10:27, 14 December 2025 (UTC)
There are 600+ First Nations governments in Canada alone, and that doesn't even count the Métis and Inuit peoples; treating each one automatically as equivalent to a "sovereign nation" or even state-wide office would be a huge departure from NPOL standards. JoelleJay (talk) 19:26, 19 December 2025 (UTC)
For smaller groups, a ==Leaders== section in the main article might be more appropriate. The history of a group should include something about the history of its leadership, after all. WhatamIdoing (talk) 19:18, 22 December 2025 (UTC)
If they meet GNG or NPOL, then they can have an article. Carveouts are illiberal and only breed more and more carveouts for increasingly niche topics. Cremastra (talk·contribs) 02:06, 15 December 2025 (UTC)
No, we should not have a "lower bar" for notability of Indigenous leaders, that would just lead to a bunch of poorly-sourced, non-NPOV articles. Secondary sources are not enough; they must also be independent and provide SIGCOV. JoelleJay (talk) 19:17, 19 December 2025 (UTC)
WP:POLITICIAN is one of the most problematic notability guidelines, because a large portion of the people it presumes to be notable fail GNG and WP:BASIC to such an extent that it is simply impossible to write a verifiable article about them that is longer than two sentences.--Trystan (talk) 19:41, 19 December 2025 (UTC)
Huh, that's not my experience. Have you ever seen a mayor, even for a small city, whose local newspaper never wrote anything about them?
I wonder if the problem is that people are mentally importing WP:NCORP's WP:AUD rule into non-NCORP subjects. This could explain the PROD rationale about local sources. WhatamIdoing (talk) 19:04, 22 December 2025 (UTC)
You compared this to WiR, but have you read WiR's section about notability? It doesn't say that women should be held to any lower of a notability standard, because that is neither desired nor necessary. There are countless women who are notable (under the same standards of WP:GNG, WP:NBIO, etc.) that still lack a Wikipedia article. This isn't the only factor of systemic bias on Wikipedia–there's also bias in the sources we're based on–but the imbalance in our coverage of notable subjects is our responsibility alone and the problem we're best able to handle. jlwoodwa (talk) 01:39, 22 December 2025 (UTC)
Lynda Price was kept at AfD, so I'm not sure you've demonstrated any actual need for a change. Der Wohltemperierte Fuchstalk 19:36, 22 December 2025 (UTC)
Clean start
Is WP:Clean start a global policy? Are other wikis allowed to modify it, for example, allowing indefinitely blocked (not banned) users to clean start without following Wikipedia:Standard offer, but clean start with other identities and without returning to old topic? My home wiki has changed this policy for a long time without my knowledge. Does this change violate any WMF regulations? Nvdtn19 (talk) 15:47, 23 December 2025 (UTC)
It seems they're asking if there's already a Meta policy about clean starts that our policy derives from, or if it's enwiki-only. m:Clean start exists but doesn't have much content, and in particular doesn't seem to indicate that all wikis have to make use of it. Anomie⚔ 18:26, 23 December 2025 (UTC)
Yep; that Meta-Wiki page is not a global policy, and there is no global policy on clean starts. This type of thing is entirely within the remit of local projects. Vermont (🐿️—🏳️🌈) 20:04, 23 December 2025 (UTC)
As the top of that page says, This is an English Wikipedia policy. There is no obligation for any other wiki project to implement the same policy in the same way. Athanelar (talk) 18:29, 23 December 2025 (UTC)
The foundation doesn't care if you have more than one account. They care if one or more of your accounts are violating the Wikimedia Foundation Terms of Use. If the foundation has sanctioned "you" - it is about anything you do in any manner and not about what account you signed in to. Globally: in general if your account is globally blocked or locked and you evade that the global blocks or locks may be applied to additional accounts or networks. — xaosfluxTalk 19:28, 23 December 2025 (UTC)
Temp accounts were a stupid idea
I do not know who came up with it or why but suddenly we have a billion new users on every even slightly contentious page, all of whom have no history but who have very clearly edited *very* extensively in the past, making disruptive changes with absolutely no means of controlling it because we've just given them a billion fake IDs Snokalok (talk) 13:13, 3 December 2025 (UTC)
Seem like an improvement to me. Exposing IPs for all to see has always been a privacy nightmare. Feoffer (talk) 13:19, 3 December 2025 (UTC)
It's more than doubled my handling time for AIV reports and other abuse mitigation efforts. ScottishFinnishRadish (talk) 13:23, 3 December 2025 (UTC)
Hot take: the giant, scary “YOUR IP WILL BE VISIBLE” sign was actually a really great deterrent against the NOTHERE. Now that’s gone, they have a different account for each device they’re on, and if they want another one, just clear cookies. Snokalok (talk) 13:29, 3 December 2025 (UTC)
I tend to agree that this change has supercharged contentious editing, and made it exponentially more difficult for the average editor to identify individual abuses of multiple local IP addresses. BD2412T 13:40, 3 December 2025 (UTC)
i agree. It was better before. Masterhatch (talk) 14:03, 3 December 2025 (UTC)
The logical answer to that is to require a registered account. That would hide the IP address while also making it clear what edits were by which individual.--User:Khajidha (talk) (contributions) 14:25, 3 December 2025 (UTC)
Honestly even allowing IPs imo was a deep and costly compromise between wikipedia’s ideals and the practical reality of keeping the project nice. Temp accounts just surrender the project entirely to chaos. Snokalok (talk) 16:27, 3 December 2025 (UTC)
I don't really understand the need to allow IP editors or temp accounts at all. Maybe early in the project, but accounts are already pseudo-anonymous, free, and easy to create. Reddit, Facebook, and other Websites that depend on user generated content tend to require an account to participate, I don't see why Wikipedia doesn't. My experience has mostly been real editors using them as sock puppets or disruptive edits that are either intentional vandalism or clueless. GeogSage (⚔Chat?⚔) 18:34, 3 December 2025 (UTC)
It’s an idealism thing. Wikipedia doesn’t formally swear by any political ideology, but if one was to assign a label to its ideals, its principals would very swiftly fit the model of anarcho-communism. And that means, among other things, that everyone has a voice and everyone can contribute and decide on content.
Obviously in practice it just ends up being the equivalent of the articles of confederation, where there’s not enough centralized authority or etc, but the ideal built wikipedia in the first place - and it wouldn’t be a small thing to go back on that.
But even so, I think the temp accounts have just emboldened disruptive editors that were previously deterred by having their IP be public. Snokalok (talk) 22:22, 3 December 2025 (UTC)
And the temp accounts also have emboldened constructive editors that were previously deterred by having their IP be public. Most unregistered users are not vandals. SuperPianoMan9167 (talk) 22:47, 3 December 2025 (UTC)
If anything I'd say it's closer to libertarian socialism as it isn't necessarily opposed to a hierarchy of sorts, as seen by the different tiers of editors mgjertson (talk) (contribs) 20:19, 8 December 2025 (UTC)
If we're going to go to the roots, then the biggest problem is our stagnant editor base. Dege31 (talk) 22:59, 3 December 2025 (UTC)
I’ve sort of noticed, as the project gets older, generational divides form amongst editors. Like on GENSEX topics, most of the editors who really strongly push anti-trans povs are those who joined in like the mid-2000s - proper old guard; while those who push the other way are usually those who joined in the 2010s. The 2020s so far have been an even split. Snokalok (talk) 00:04, 4 December 2025 (UTC)
I think that @Dege31 might be speaking about the number of editors, rather than their POVs. WhatamIdoing (talk) 00:08, 4 December 2025 (UTC)
How true is a statement like the biggest problem is our stagnant editor base? It's unclear without seeing the statistical evidence, but for the Arab-Israel conflict contentious topic area it does not appear to be the case. We looked at related issues as part of the ARBPIA5 case. At least in that topic area it is possible to say that, while the unique actor count is pretty steady (Meme check #1), younger accounts appear to play an important role (Meme check #2). So, I'm guessing that if there is some form of stagnancy, it is likely quite heterogeneously distributed across the project. Sean.hoyland (talk) 10:42, 4 December 2025 (UTC)
The overall number of new accounts, and for registered editors who only make a few-to-dozens of edits in a given year, has been declining for a couple of years. See Wikipedia talk:Wikipedians#Numbers of editors each year for some numbers. WhatamIdoing (talk) 01:10, 5 December 2025 (UTC)
The idea an IP address was a privacy nightmare is hard to parse. All it establishes is a general area of some kind of user at that time. However having the easy ability to check an IP made it extremely easy for the average experienced user to find out if this is the same person causing more issues via a slightly different location.
Now I have no clue who's GF and who's BF and can't easily deal with it without causing extra workload for admins. Rambling Rambler (talk) 14:42, 3 December 2025 (UTC)
@Rambling Rambler, back in the 1990s, if you looked up my IP address, WHOIS would give you my exact home address. I think "a privacy nightmare" is a fair description of that setup. While most ordinary people, editing from their homes or phones, are not going to be in that situation, there still are people for whom the IP address is identifying, and millions more for whom a permanently recorded IP address is one short subpoena to an ISP away from being the next Asian News International v. Wikimedia Foundation case. WhatamIdoing (talk) 21:48, 3 December 2025 (UTC)
It is unlikely IPs would be doing edits that are controversial enough to get sued. The constructive IPs are mostly doing basic fixes and fighting vandalism themselves. Anything more than that and the IP would be incentivized to create an account to get credit for their work. Mikeycdiamond (talk) 12:04, 4 December 2025 (UTC)
On 4 August 2025, the Wikimedia Foundation announced compliance with local Portuguese court orders and subsequently removed content from the Wikipedia articles related to DePaço on both the English and Portuguese Wikipedia projects. Additionally, the IP and email addresses of eight involved Wikipedia editors were disclosed to DePaço, who stated that he would pursue further legal action against the editors.
From the article Caesar DePaço (emphasis mine). If temporary accounts were a thing then the WMF could have avoided disclosing IPs by saying "IPs are deleted from our database after 90 days". SuperPianoMan9167 (talk) 13:26, 4 December 2025 (UTC)
If they were an IP editor they wouldn't have had the email address either, so the temp account thing doesn't look to be pertinent here. ScottishFinnishRadish (talk) 13:28, 4 December 2025 (UTC)
@SuperPianoMan9167: in fact it was the whole Daniel Brandt drama that directly led to the creation of BLP though some of the underlying dynamics and momentum already existed. Really long story with significant on and off wiki components involving BADSITEs that are probably still best not mentioned. ~2025-41540-19 (talk) 05:16, 19 December 2025 (UTC)
Only if all eight of those users had used temporary accounts rather than registered accounts, and the temporary accounts were old enough. Anomie⚔ 13:32, 4 December 2025 (UTC)
If there was email addresses, they had normal accounts. Temporary accounts wouldn't have changed anything. Mikeycdiamond (talk) 19:05, 4 December 2025 (UTC)
I realize that now. I had assumed that IP editors were involved. I was largely incorrect in my conclusion.
The point is that it's weirdly inconsistent to treat IP addresses as sensitive personal data when they belong to registered accounts but simultaneously say that they aren't sensitive at all when they belong to unregistered users. SuperPianoMan9167 (talk) 19:37, 4 December 2025 (UTC)
There might be IP editors involved, but they don't need a court order to read the page history. WhatamIdoing (talk) 01:13, 5 December 2025 (UTC)
Submitted Snokalok (talk) 16:11, 3 December 2025 (UTC)
I've requested too. But I agree with User:Snokalok's original assertion that the whole temp account thing seems like not a very good idea. Was there ever an RfC or some equivalent on this topic? NickCT (talk) 17:04, 3 December 2025 (UTC)
No, it was forced on us by the WMF. Possibly due to Legal, GDPR etc. etc. This is not a great solution at all and hopefully tools will improve or TAIV be granted more liberally.~212.70~ ~2025-31733-18 (talk) 17:30, 3 December 2025 (UTC)
Geeeeeez.... Enough to make one wanna head to Grokipedia. At least over there I can be guaranteed my IP info will be exploited to the maximum possible extent. NickCT (talk) 17:45, 3 December 2025 (UTC)
WP:GROKIPEDIA would ask everyone to stay away from broken AI-generated encyclopedia. Ahri Boy (talk) 22:11, 7 December 2025 (UTC)
If you are concerned about the privacy of your personal information at all, do not go on Grokipedia. Ivanvector (Talk/Edits) 13:52, 8 December 2025 (UTC)
I'm a bit confused by the acrimony against the change, given that TAIV exists. Is the new issue just that new editors without TAIV are filing shot-in-the-dark reports against TAs that need further legwork by admins/TAIVs to respond to? signed, Rosguilltalk 18:01, 3 December 2025 (UTC)
For me the issue is that it creates an enormous overhead for normal anti-vandal/anti-abuse work. To be thorough one has to check the history of the editor, so instead of looking at the single IP contribs page, or a /64 for an IPv6, I have to open the temp account contribs, the IP temp account contribs, and the IP legacy edits. This is already suboptimal on a desktop and adds to the time it takes to investigate, but when editing from a phone it's downright horrible. There are ~12,000 blocks a month, the overwhelming majority of them from AIV/TB2. Adding additional time to processing the reports from those noticeboards eats up a huge amount of limited volunteer time. Add to that the large number of vandals that I've seen making a couple edits and either deleting their cookies or opening a new incognito window to grab a new TA with a blank user page which abuses the escalating warnings before blocking method we use and it's a pretty significant headache. ScottishFinnishRadish (talk) 18:11, 3 December 2025 (UTC)
But doing anything from a phone that involves a keyboard is downright horrible, especially with my fat fingers. At least the IP legacy edits will reduce in importance with time. Phil Bridger (talk) 21:16, 3 December 2025 (UTC)
I primarily edit from my phone, so the extra steps are a significant issue. We also need to get hip to (that's what the kids say, right?) the fact that most people access the internet with mobile devices. Making a shitty system even shittier for mobile editors isn't helping us. ScottishFinnishRadish (talk) 22:14, 3 December 2025 (UTC)
Why not write a user script that acts as a better autoblock for TAs (since a regular autoblock is fixed to 24 hours)?
Here's what I'm thinking of:
When blocking a TA, a mobile-friendly dialog comes up that says "Block the TA's IP?"
If it is checked, once the block is placed, the script would perform a normal IP block (anon. only, account creation blocked) on the TA's IP, with the same block duration as the original block, but with a vaguer, generic block summary, such as "abuse from TAs on this range". The only exception would be that an indefinite TA block would result in a 90-day IP address block.
This acts essentially like regular autoblock: the abuser has to change both their IP address and their TA to evade a block. The only differences are that it lasts for longer than 24 hours and that it only applies to one IP address or range. It wouldn't work against proxy abusers but IP blocks don't work on proxy abusers anyway.
It also saves having to open a new tab to block the underlying IP and thus reduces tediousness by automating the IP block. Yes, this exposes a TA's IP address automatically, but that's allowed by policy: admins are allowed to make blocks that, by their timing, imply a connection between an account and an IP. The block summary for the IP is made vague to avoid violating the IP disclosure policy.
Of course, any IPv6 block would automatically extend to cover the /64.
Maybe a template similar to {{CheckUser block}} could be used in the edit summary--{{TAIV block}} might work.
The time is mostly spent having to check three separate pages to investigate what blocks may need to be placed, not placing the blocks themselves. ScottishFinnishRadish (talk) 23:39, 3 December 2025 (UTC)
Why is it necessary to check the IP every time? Why not just block the TA? My idea is that an admin would block the IP for the same duration as the TA block using this tool for every single TA block, eliminating the need to check the IP at all. I think non-admin TAIVs doing the TA tracking work instead of admins would work out better.SuperPianoMan9167 (talk) 00:15, 4 December 2025 (UTC)
Because very often there are multiple TAs on the address, and without looking at the history, including legacy IP edits, you won't know the appropriate length for the block. ScottishFinnishRadish (talk) 00:22, 4 December 2025 (UTC)
Then what would be a good idea to reduce this tediousness and prevent disruption besides "require registration" or "ditch temporary accounts", as the WMF has shown no signs of entertaining either idea? SuperPianoMan9167 (talk) 00:28, 4 December 2025 (UTC)
I don't believe the WMF really has a say on if we require an account to edit. Portuguese Wikipedia requires an account. As for alternatives, hash IP addresses instead of using temporary accounts. Permanently assign IP addresses account names as they edit. There's a lot of ways to hide IP addresses that doesn't create a huge burden on editors and admins. ScottishFinnishRadish (talk) 00:35, 4 December 2025 (UTC)
Hashing won't work. IP addresses are fixed identifiers. Given enough large enough data set of hashed up addresses and the corresponding IP addresses, one can either reverse the hash or build a rainbow table connecting the two. – robertsky (talk) 05:24, 4 December 2025 (UTC)
Seems more secure than the TAIV permission which any potential malicious bad actor could circumvent with time.
And there are plenty of other security techniques that would be even more difficult to reverse. Katzrockso (talk) 08:36, 4 December 2025 (UTC)
With temporary accounts, all IP information is discarded after 90 days, and the temporary account's name still remains as an identifier. If we used IP hashes to identify unregistered editors, we'd be keeping that (obscured) IP information forever within the identifier. jlwoodwa (talk) 02:16, 5 December 2025 (UTC)
Only insofar as an IP editor might maintain a single IP, sure. But otherwise, I think having a single identifier for one user is preferable to having many over a short period of time. I have engaged in discussions with TA editors who have unintentionally had new temporary accounts created for nearly every one of their edits. Katzrockso (talk) 02:35, 8 December 2025 (UTC)
meta:Limits to configuration changes#Prohibited changes #3 forbids WMF deployers from assisting with configuration changes that turn off anonymous editing. Ptwiki has gotten around this with a series of workarounds involving mw:Extension:AbuseFilter and some other on-wiki-configurable things. However since the WMF officially forbids it, it means that going in that direction would involve spending political capital and causing tension. Just FYI that there are some challenges/obstacles that make this harder than normal. –Novem Linguae (talk) 00:53, 8 December 2025 (UTC)
I believe that ptwiki's workaround was shut down by WMF Legal (maybe it connected the IP address to the new account in a log somewhere?). They ended up getting the WMF to do it properly, as part of an official experiment that involved a couple of wikis and restricted editing in the mainspace only (including disabling the ordinary Wikipedia:Edit requests, but still allowing IPs to post manually on the talk page).
Ptwiki has a long history of restricting new editors (e.g., CAPTCHAs for every single edit, even if you're just fixing a typo or reverting blatant vandalism), and I understand that a two-thirds majority felt like the tradeoffs were worth it.
All of which is a long-winded way of saying that we can't do that. If we wanted to cut down on IP's edits, we could, however, do something like semi-protect the 1,000 or 10,000 articles that are most popular with IPs (or have the highest page views). WhatamIdoing (talk) 03:47, 8 December 2025 (UTC)
Perhaps what is needed is some sort of additional tool for CheckUsers that lists every edit made from an IP or IP range, regardless of whether it was via an account or not (or perhaps just for temp accounts), in a single list of edits, as if they were one user. Obviously since this would expose private information it would need to be restricted to CheckUsers (or just TAIV users if it only works on anon accounts) and every use of it logged, but would that be feasible? --Aquillion (talk) 14:35, 11 December 2025 (UTC)
Looking at an ip/range as one account is already possible if you have TAIV. MetalBreaksAndBends (talk) 14:37, 11 December 2025 (UTC)
I agree with Aquillion in the general sense: What's needed is better, more efficient, more comprehensive tools for CUs and Stewards. The scale we need for this is a dedicated dev team for the next five or ten years, not the m:Community Wishlist or a one-off tool. WhatamIdoing (talk) 17:35, 11 December 2025 (UTC)
@Aquillion, we already have this tool. That's what CU does. -- asilvering (talk) 00:10, 12 December 2025 (UTC)
@Rosguill according to the policy around using TAIV every use of it is logged. Previously as a lay user I could simply check the IP, look for recent activity from that same address, and if questionable take it to AIV/SPI.
Now however if I were to acquire the tool and examine TAs and I'm wrong, it feels like I'd have a cloud over me because that record could be questioned at any point by a CheckUser.
Basically... it makes me fundamentally uncomfortable in asking for and then using it. Rambling Rambler (talk) 18:55, 3 December 2025 (UTC)
That makes sense, although personally I think that absent guidance mandating specific limitations on TAIV use, "any mildly suspicious edit or edit made in the vicinity of such edits" should be considered fair game good faith use of the tool. signed, Rosguilltalk 19:00, 3 December 2025 (UTC)
@Rosguill but then that needs to be either guideline or preferably policy, that there's a very strong presumption of innocence in usage and it's for those believing it to be misused to have to demonstrate clear malicious usage.
As a worked example, reading the current policy it seems like if the situation I've spent months dealing with at Wikipedia:Sockpuppet investigations/SharkFinSoupEater/Archive flared up again invariably involving lots of TAs in place of IP addresses, I would have to bring out a bloody thesaurus to actually report it because WP:TAIVDISCLOSE is obtusely restrictive in being able to even mention an IP address. Rambling Rambler (talk) 19:08, 3 December 2025 (UTC)
Nobody cares how often you look at the IP address. Look at every single one of them, all day long, if that floats your boat.
It's logged so that if an "anonymous" social media account posts "Hey, world, just creating a permanent record so we'll always know that ~2025-12345-67 is IP 192.0.2.0, and ~2025-23456-78 is 198.51.100.255 and...", then they can figure out who looked at those and, um, provide you with an opportunity to stop doing that. WhatamIdoing (talk) 21:57, 3 December 2025 (UTC)
@Rambling Rambler, please don't worry too much about this when you're reporting to SPI. We know everyone's still getting used to it, and it's very easy for us to revdel any accidental disclosures. I assure you that clerks won't get too mad about it (they've seen worse) and CUs have way better things to do with our time than chase down someone who revealed an IP for no reason other than because they got curious. -- asilvering (talk) 05:01, 5 December 2025 (UTC)
One issue is that its a rfp, all the language around this makes me really scared that if I mess up or misinterpret a policy, i could get blocked. Plus, the policy is hosted on a wmf domain, so I cant even read it bc my school blocks all wmf domains. MetalBreaksAndBends (talk) 15:49, 5 December 2025 (UTC)
@Toadspike I'm aware of that tool existing. However I have been reticent to apply for it because it seems there's just a massive amount of policy bear traps created around both using it and then how you refer to it once you've used it that feels like I'm the one who'd be under more scrutiny for examining a TA than the actual TA.
Also the fact we have that tool just feels like a giant admittance by WMF that TA are basically pointless, because if we're allowed to view IP with extra steps then it's not really dealing with any of the "fear of Wikipedians safety" that WMF claimed was the justification for the change. Rambling Rambler (talk) 18:51, 3 December 2025 (UTC)
Personally, I've decided not to click the button to enable TAIV for myself because I have no interest in working out what the CheckUser-lite policies around it allow and don't allow. Easier to leave it to admins who are into that sort of thing. Anomie⚔ 23:37, 3 December 2025 (UTC)
For what it’s worth, the interface itself drives temp users towards churning and burning accounts if they don’t want to create an account. There’s a giant grey “you need to log in, this is a temp account” banner on the top of every single page that only disappears when you “exit session”. The result is that browsing while “logged into” a temp account is more annoying than creating the account and immediately throwing it away. I went from having one IP account to creating one for each comment I make. Including this one, haha. ~2025-38292-55 (talk) 19:07, 3 December 2025 (UTC)
As I mentioned elswhere, the temporary account implimention will proove to be a disaster. This idea should've gotten community imput, as to whether or not to implement. GoodDay (talk) 18:09, 3 December 2025 (UTC)
It's one of the worst technical misfires the WMF has ever made and they're justifying it, as Fram and Aaron Liu wrote about here, on an incompent misreading of editing statistics at the Portuguese Wikipedia before and after they switched off anonymous editing. Everyone involved with the decision needs to grow up and accept that the days in which it was appropriate for unregistered users to edit the project are long gone. — Hex•talk 19:42, 3 December 2025 (UTC)
Agree, it's a complete mess. Masking IP addresses was absolutely necessary, but this particular implementation is a disaster. It's hard on unregistered users (their contribution history is scattered to the wind even if their IP is static, and their apparent username changes constantly so they're constantly accused of sockpuppetry), it's a disaster for registered users (instead of interacting with one IP address or a few that displayed obvious patterns, now we have to try to converse with what is no more legible than a QR code), it's a pain in the ass for enforcement (if your TA is blocked you can easily just make a new one, far easier than changing your IP), and let me tell you it's absolute horseshit for checkuser (private checkuser reasons). If this is the best solution the devs can come up with, it would solve the problem much more reliably to just disable logged-out editing and force all editors to create an account; registered accounts are already very well protected by privacy policies and have been for a very long time. Ivanvector (Talk/Edits) 19:44, 3 December 2025 (UTC)
@Ivanvector, do you have any estimates on how many ordinary people use staticdynamic IPs these days? I've seen estimates ranging from a conservative "most" to a sweeping "vast majority".
If the username depends on the IP address, then the username would change when the IP address does, resulting in contributions being scattered to the wind. Many mobile editors use multiple IP addresses each day, and most people with a dynamic IP address change IP addresses every couple of days (though it differs per country and ISP). WhatamIdoing (talk) 22:23, 7 December 2025 (UTC)
@WhatamIdoing: Do you mean "dynamic IPs" in your first sentence? jlwoodwa (talk) 22:31, 7 December 2025 (UTC)
@WhatamIdoing, it varies heavily by country. There are still lots of reasonably stable IPs in the US and UK, for example. -- asilvering (talk) 23:48, 7 December 2025 (UTC)
@WhatamIdoing: I slightly disagree with asilvering, and would say that for Wikipedia's practical purposes all IPs are dynamic. Some, like in the geographies they mentioned, are more stable than others but they're not actually static and can be rotated, and the networks are absolutely massive and geolocation doesn't work. All IPv6 addresses are inherently dynamic because of the way our software handles them. In sixteen years here I can count the number of editors I've encountered on truly static IPs (an IP that is assigned to them by their ISP and never changes) on one hand, and still pick up my coffee. Ivanvector (Talk/Edits) 13:50, 8 December 2025 (UTC)
It's hard on unregistered users (their contribution history is scattered to the wind even if their IP is static, and their apparent username changes constantly so they're constantly accused of sockpuppetry). IP masking uses a cookie to keep a user signed in to their temporary account, even if their IP address changes. So in this respect it is better at grouping a good faith user's edits together than just relying on IP address, as long as they are using the same browser and not blocking or clearing cookies. However if I am reading the code correctly, IP masking only lets a user stay logged in for 60 90 days. And if I recall correctly, this was because WMF wanted to create some incentive for temporary accounts to create actual accounts. So in conclusion, I think the user experience for good faith, non logged in users is kind of a wash, rather than definitely worse. Although if the 60 90 day thing is a problem, someone could always lobby for enwiki to have this setting raised. The patch would be like 3 lines of code. Edit: Can't change constants in PHP, so this would take some additional engineering. –Novem Linguae (talk) 00:45, 8 December 2025 (UTC)
You're not reading the code correctly. The line you link is for freshness of some API response, and is set to 1 day (86400 seconds). The validity of a temp account is 90 days, defaulted here. Anomie⚔ 01:16, 8 December 2025 (UTC)
Also, FWIW, phab:T359653 indicates that 90 days was chosen to match the expiry of CheckUser data. Although they seem in general to want to determine how quickly good-faith anons naturally lose their cookies and set the expiry to that instead; there was talk in there of expiring them after just a week. Anomie⚔ 01:24, 8 December 2025 (UTC)
Re changing it, assuming WMF would allow it, it would be a configuration change assigning $wgAutoCreateTempUser['expireAfterDays']. Some comments I'm seeing suggest they'd probably say they want them to be the same across all SUL wikis though. Anomie⚔ 01:31, 8 December 2025 (UTC)
@Novem Linguae, IP masking uses a cookie to keep a user signed in to their temporary account, even if their IP address changes is the principle of the thing, but I can tell you've been too busy with elections business to do much anti-abuse work recently if you're saying this. It's simply not working this way at all. You don't even need to be a CU to spot it - just spend an afternoon at AIV or digging through the "open" bin at SPI. It's bad. I have no idea how the other wikis didn't notice that TAs weren't working as designed, but they didn't, and it fell to us to point these things out to the WMF team working on it. -- asilvering (talk) 01:51, 8 December 2025 (UTC)
Is this because way more users have cookies turned off then the WMF team initially thought, or what? SuperPianoMan9167 (talk) 01:54, 8 December 2025 (UTC)
@SuperPianoMan9167, sorry, I can't answer that question, and I'm not sure if the WMF team can yet, either. I am sure they're working on it (stewards and en-wiki functs have been giving them a lot of feedback on the issue). -- asilvering (talk) 02:12, 8 December 2025 (UTC)
Controlling temporary accounts via cookies only works if the user only uses one device (rare these days) and doesn't log out manually, doesn't clear their cookies, and/or isn't using a browser configured to delete cookies after every session (which are now quite common), otherwise their contribs show up as those of multiple random serial numbers. If they're using more than one device they will have more than one TA simultaneously, and if they are using more than one TA to edit the same article or participate in the same project discussion then they are in violation of the sockpuppetry policy without being aware that they are violating it. There's a discussion happening in fits and starts right now about how to edit the policy to handle that. I have not so far seen any TA users having kept their TA for more than maybe a week at the high end, but I have made several checks showing one person spamming dozens of TAs on a single IP, not always obviously deliberately, and with each TA having just one or two edits. How is a non-CU supposed to track that? Ideally, contribs tied to a semi-permanent cookie are better for consolidating contribs; in practice, it's much much worse. So much worse. Ivanvector (Talk/Edits) 13:50, 8 December 2025 (UTC)
Maybe we could include all of the other temp accounts on the same IP on the temp account's user page? We need to get rid of temp accounts, but I doubt the WMF will allow it. Mikeycdiamond (talk) 14:06, 8 December 2025 (UTC)
Indiscriminately publicly linking TAs and IPs is a violation of the TAIV policy. --Ahecht (TALK PAGE) 14:58, 8 December 2025 (UTC)
WhatamIdoing said Nobody cares how often you look at the IP address. Look at every single one of them, all day long, if that floats your boat. This is all a mess and i hate it. (e: person who responded is probably right, just not updating her user page would be strange) MetalBreaksAndBends (talk) 15:20, 8 December 2025 (UTC)
If you look at the second userpage you linked, you can see that she has not been WMF staff since 2023. jlwoodwa (talk) 18:17, 8 December 2025 (UTC)
You can look at an IP address whenever you want. The restrictions are on publicly posting or sharing that information. WhatamIdoing (talk) 00:43, 9 December 2025 (UTC)
Yeah, if the restriction was on just looking at IP addresses without disclosing them then IP Auto-Reveal would not be a thing. SuperPianoMan9167 (talk) 00:53, 9 December 2025 (UTC)
if they are using more than one TA to edit the same article or participate in the same project discussion then they are in violation of the sockpuppetry policy without being aware that they are violating it
This is only true if they are abusing multiple temporary accounts. A good-faith unregistered editor using multiple TAs is not violating the sockpuppetry policy. SuperPianoMan9167 (talk) 14:09, 8 December 2025 (UTC)
Re I have not so far seen any TA users having kept their TA for more than maybe a week at the high end: The following good-faith unregistered users have kept their temporary accounts for longer than that (non-exhaustive list; when I tried to look at the user creation log for the earliest temp accounts the page refused to load):
The last one has had their temporary account for 34 days now and has over a thousand contributions.
I know that for this to work one has to stay on the same browser on the same device, since cookies never sync between devices, but it goes to show that for at least some users, TAs appear to be working as intended. SuperPianoMan9167 (talk) 20:29, 8 December 2025 (UTC)
Looks like ~2025-31117-12 is the current temp account with the longest time between creation and latest edit. quarry:query/99842 shows a count of temp accounts bucketed by the number of days (rounded) between creation and latest edit. Anomie⚔ 21:53, 8 December 2025 (UTC)
@Ivanvector, to be clear, someone using multiple TAs to participate in the same discussion is not violating the sockpuppetry policy unless they are also lying about being different people. -- asilvering (talk) 20:39, 8 December 2025 (UTC)
One would hope that this mess would push the WMF towards what has for a long time been the only obvious solution, which is mandatory registration; however, since in the past the disruption of workflows for editors and admins has been something that the WMF clearly couldn't give a shit about, I doubt if this is going away any time soon. Black Kite (talk) 19:59, 3 December 2025 (UTC)
I'm sure I'll get roasted for this, but when was the last time anyone here was able to submit any content of any sort to any website, besides Wikipedia, without creating an account first? Ivanvector (Talk/Edits) 20:55, 3 December 2025 (UTC)
The last place I saw using non-account registration outside Wikipedia was the Gawker network of sites.
Funnily enough it led to an endless wave of harassment via spamming gore and torture images that meant they basically hide most of their comments away unless you were given "trusted" status. Of course vandals there just immediately got trusted status on one account and then just used it to make their vandalism content visible. Rambling Rambler (talk) 22:09, 3 December 2025 (UTC)
@Ivanvector, two days ago, when I filled in a "contact us" form on a website. But presumably you meant the kind of content that is displayed to non-staff directly on the website? WhatamIdoing (talk) 00:06, 4 December 2025 (UTC)
A contact us form that doesn't require some sort of email or other identifier sounds highly unusual. CMD (talk) 02:57, 4 December 2025 (UTC)
Nearly all of them accept fake phone numbers and fake e-mail addresses, though occasionally I'll run across one that will reject an @mailinator.com address. Almost none of them actually verify that the e-mail address is functional. But giving them a way to contact me isn't the same as creating an account. WhatamIdoing (talk) 01:19, 5 December 2025 (UTC)
It is the same. They are linking your comment to a specific ID, in that case an email address. Whether that email address is functional is irrelevant to this, usernames never have email functionality. (They are probably also creating a profile through other data, which we do not.) CMD (talk) 03:04, 5 December 2025 (UTC)
Accounts generally have passwords in addition to usernames. jlwoodwa (talk) 03:11, 5 December 2025 (UTC)
Well indeed, a full account creates an additional layer of privacy. Outside of GDPR territories, I expect most companies devote much less attention to this than we do. CMD (talk) 03:43, 5 December 2025 (UTC)
Accounts are also re-usable. With a "Contact us" form, by contrast, if you go back the next day, you have to fill out the same information all over again. WhatamIdoing (talk) 21:58, 7 December 2025 (UTC)
And if you fill in the same email, you will still only be subscribed to their mailing list once, because the database they store your contact info in filters duplicates. Ivanvector (Talk/Edits) 13:50, 8 December 2025 (UTC)
There's some forums I have heard of (econ job market rumors - which has led to a culture of bigotry) but you're right that it's not common. Katzrockso (talk) 08:40, 4 December 2025 (UTC)
4chan, lol. But not a great concept for an encyclopedia, perhaps… I think we should have gotten rid of it long ago. PARAKANYAA (talk) 21:47, 6 December 2025 (UTC)
I have frequently been critical of the WMF, but I find it difficult to find fault with them in this case. Politically they had to do something about exposing IP addresses to anyone who cares to look. The only choices were to have something like the current temporary account procedure or to require registration. Phil Bridger (talk) 21:23, 3 December 2025 (UTC)
Then they should've gone with registration. Rambling Rambler (talk) 22:09, 3 December 2025 (UTC)
Are we finally, at long last, moving to a mandatory registered account before you can edit? Please?—SMarshallT/C 23:04, 3 December 2025 (UTC)
Comment: Would vastly prefer this as well... GeogSage (⚔Chat?⚔) 23:25, 3 December 2025 (UTC)
I've been saying this for years. In 2001, creating an account might have been a barrier to entry and it made sense to allow instant editing as we sought to rapidly expand the editor base. But these days the public expects this, there aren't many sites out there that don't require you to open an account. IP addresses were bad because of privacy and also easy socking if you IP hop, but temp accounts are even worse. It's now perfectly legitimate and very easy to edit under a new handle every day. Let's move to requiring log in please. —Amakuru (talk) 23:48, 3 December 2025 (UTC)
Not to be a downer, but I will always advocate for letting users edit logged out as I started out as an IP editor myself. (I think the main reason why I waited so long to make an account is because I couldn't pick a username.) SuperPianoMan9167 (talk) 23:51, 3 December 2025 (UTC)
Unfortunately I think the problem is that it's no longer the internet of even the early 2000s where it required some base level of skill and Wikipedia was still unknown.
Now this site is a victim of its own success and kids learn how to use the internet before a washing machine. Rambling Rambler (talk) 23:56, 3 December 2025 (UTC)
What if we auto-generated username suggestions Reddit-style, e.g. Big-Reptiles1234. Would that remove some friction to registering? (You still need to make a password.) ⁓Pelagic (messages) 21:35, 12 December 2025 (UTC)
Oh, there is a multi-lingual and multi-cultural challenge as discussed by Anomie and Arecht below. ⁓Pelagic (messages) 21:49, 12 December 2025 (UTC)
The original WikiWikiWeb was an agile tool for a community of practice - created in 1995, long before agile software development - where many of the participants knew each other, and frictionless contribution without a need to register was beneficial and unproblematic. For a long time, anyway (I was there). This project's explosive growth took it beyond that in a very short time, but the people who operate it are libertarian technocrats, and libertarian technocrats suffer from the mindset where the answer to a social (behavioral) problem is always "we can code our way out of it". Instead of what actually works, which is rules that are effectively enforced. An example of such a rule is "editing requires an account", which is enforceable with zero additional software. Back on the WikiWikiWeb we had a maxim for things like this: do the simplest thing that could possibly work. — Hex•talk 16:11, 4 December 2025 (UTC)
Also, wikipedia is in a state now that having lower editor traffic isn't necessarily a bad thing, as most of the trivial edits that we had IPs do have been done and any if the more substantial edits require an amount of knowledge that having an account wouldn't be the biggest barrier to entry. mgjertson (talk) (contribs) 20:27, 8 December 2025 (UTC)
Seems reasonable, but I would like some data to back that up. JustARandomSquid (talk) 22:11, 8 December 2025 (UTC)
That depends, @S Marshall. Do you want the community to die sooner? Do you want worse articles? If so, then doi:10.1177/0093650220910345 suggests that requiring registration would be slowly but steadily effective at those goals. WhatamIdoing (talk) 00:01, 4 December 2025 (UTC)
Instead we'll die by having pitiful mobile support preventing the majority of internet users from contributing while simultaneously increasing the workload on a declining admin corps through poor implementation of hiding IP addresses. For the same technical effort we could have had not the worst possible mobile experience for editors, added an account requirement, and grown the user base. ScottishFinnishRadish (talk) 00:09, 4 December 2025 (UTC)
Why not just play whack-a-mole and just block TAs whenever possible instead of checking the IP every time? SuperPianoMan9167 (talk) 00:10, 4 December 2025 (UTC)
That creates even more work and allows more disruption. The additional work isn't just for admins either, it's for anyone who has to deal with the disruption. It also increases the chances that vandalism and other disruption doesn't get reverted. ScottishFinnishRadish (talk) 00:18, 4 December 2025 (UTC)
It sounds like every time you get a vandalism report for a temp account, you check Special:Contributions for the temp account (easy), past contribs for the IP, and for any other temp accounts using that IP.
Your goal is to block them all (if needed) and to revert any problematic edits by any/all of them, instead of just blocking the individual identified problem.
I think it should be possible to create a streamlined tool for CUs and Stewards that automatically pulls up contribs for all of these (@Vermont, does that sound plausible to you, or am I obviously wrong?). But I'd guess that it would first be built by a volunteer who designed it for desktop use, which wouldn't really help you when you're working from a smartphone. WhatamIdoing (talk) 01:32, 5 December 2025 (UTC)
SFR, I have a lot of sympathy for you, but "for the same technical effort" isn't true. A good mobile interface is difficult, especially since what's needed isn't just core MediaWiki features but also the add-on tools that were built by volunteers for use on large screens.
IMO we could profitably have the Editing team spend the next five years on mw:mobile visual editor. At the end of that time, that one thing would be better – but that one thing wouldn't help you with the IP work. WhatamIdoing (talk) 01:26, 5 December 2025 (UTC)
I don't want either of those things, @WhatamIdoing, no. But I think this implementation of temporary accounts might cause even worse damage by limiting our ability to deal with disruption, so I see mandatory registration as the lesser evil.—SMarshallT/C 00:25, 4 December 2025 (UTC)
Then how can we improve temporary accounts to better deal with disruption? SuperPianoMan9167 (talk) 00:30, 4 December 2025 (UTC)
Use a unique identifier that doesn't change. Maybe some numbers, or even some sort of hex address? ScottishFinnishRadish (talk) 00:39, 4 December 2025 (UTC)
Ie… a “user number”, tied to the specific IP. Less “temporary”… but still anonymous. Blueboar (talk) 00:45, 4 December 2025 (UTC)
But how would the identifier stay static? Would it be tied to an IP address? If so, that would reintroduce confusion about multiple people on the same IP address (which I think is one of the largest benefits from temporary accounts being tied to a browser cookie, even if that does create other problems). The WMF admits that TAs are not intended to solve any anti-abuse problems and mentions device fingerprinting as one of three solutions:
Can't an abuser just clear cookies? Yes, they can. Temporary accounts are not intended to solve any anti-abuse problems.
We know the problem of abusers making edits through a pool of changing IPs while masking browser agent data. This cannot be solved through temporary accounts. This is not a design goal for this project either. Otherwise, we would need to use trusted tokens, disabling anonymous edits, or fingerprinting, all of which are very involved, complicated measures that have significant community and technical considerations.
We have adapted tools to ensure that trusted functionaries can safely and efficiently navigate the bidirectional mappings between temporary accounts within the last 90 days and IPs. However, abuse from a user who clears cookies may become difficult or impossible to detect and mitigate for users without advanced permissions, or if some of the edits involved are more than 90 days old.
I don't care how many people are using a single IP, I care about the behavior from that IP. There's no problem there to be solved. As for the anti-abuse issue, it actively makes it worse and costs an enormous amount of additional time. ScottishFinnishRadish (talk) 00:58, 4 December 2025 (UTC)
Can't we just make the reader-facing spaces account-only and leave talk pages and project space open for anons? BD2412T 02:08, 4 December 2025 (UTC)
I am of the mindset that you should not have to pick a username that: is unique and not used by any other user; represents you as an individual person; does not include your real name if you are a minor; does not only contain the names of companies, organizations, websites, musical groups or bands, teams, clubs, creative groups, or organized events; does not only describe a particular role, title, position, department, or a group or team of people within a parent organization or group that can be represented or held by multiple people or by different people; is not promotional in nature, and does not appear intended to advertise, promote, sell, gain support, or increase the attention or user-base audience of any person, company, market, product, channel, website, or other good or service; does not imply that your user account will be shared between more than one person; is not offensive, profane, violent, threatening, sexually explicit, or disruptive, and does not advocate or encourage any such behavior (including criminal or illegal acts); does not contain statements that are libelous, contentious, or disparaging, or that disclose any private or non-public information about somebody else (either another editor, or a notable living person); is not deliberately deceptive, confusing, misleading, unnecessarily long, too similar to the username of other accounts, or an attempt to impersonate or falsely represent somebody else (another editor, a notable living person, an "official" Wikimedia Foundation account, etc.) in bad faith; does not imply that the account has explicit ownership of any articles, content, or topic areas, or any kind of "power" or "authority" over other editors, a different application of Wikipedia's policies and guidelines (such as implying that certain policies do not apply to them), or that the account has any administrative or "moderator" access levels or user rights; does not imply the intent to troll, vandalize, disrupt, advertise on, or spam Wikipedia; does not imply the intent to personally attack, harass, or threaten other Wikipedia users; and does imply that you are not here to build an encyclopedia or will use Wikipedia for purposes that it was not created for, just to fix one small typo on a page.
(The point is that you shouldn't have to read any policies or guidelines before contributing to Wikipedia. Requiring registration basically requires any prospective contributor to read the lengthy username policy (of which I have included only the summary) before contributing at all, or else they may be immediately blocked without any chance to contribute due to a bad username. And that doesn't even include choosing "a unique password that you are not using on any other website".) SuperPianoMan9167 (talk) 02:30, 4 December 2025 (UTC)
If picking a username is such a big hurdle, then there could be an option to register under an randomly generated username, like the current TA system. Of course, this would add a lot of burden to WP:CHU but if TAs are such a big problem as some claim, it could be the lesser evil. novovtalkedits 08:07, 4 December 2025 (UTC)
You could do something similar to the temp account style, though without the ~2025 at the start (we blocked all creation of usernames beginning that way a couple of years ago, the minute the team decided to prefix the temp accounts with the year of creation). I'd suggest finding a Correct horse battery staple generator instead of doing numbers, though if you do a lot of multilingual or cross-wiki editing, numbers are almost universally readable across most scripts.
If the understanding the numbering scheme would help anyone, it's this: ~YYYY-12345-67: It starts with the year, so when you look at an edit, you'll be able to know if that account is long dead. There are seven digits right now because that's approximately the number we expect to need this year (though it can expand more or less infinitely: ~YYYY-12345-67890-12345-678, etc.). It's in groups of five, because groups of four look like credit card numbers, and groups of six look like SMS account verification codes (which I find difficult to read without my glasses on). WhatamIdoing (talk) 08:33, 4 December 2025 (UTC)
The problem with Correct horse battery staple is ensuring that none of the randomly generated usernames are offensive or derogatory in any culture or when translated to any language. I went through this issue with WP:IRC help disclaimer, where even with the small number of rotating options, I had several complaints about people objecting to being called a dog, or a gorilla, or a cow, or a whale, or black. I had complaints about leaving white, red and yellow in the rotation too, although I ultimately ignored those. --Ahecht (TALK PAGE) 14:55, 4 December 2025 (UTC)
Variants of that problem have been solved over and over again by different organizations, and there's no reason why the WMF couldn't open its creaking coffers to specifically pay people to do it again. Also, this is the English Wikipedia. Eliminating words that accidentally come across as rude in "any language" is out of scope as well as impractical. — Hex•talk 15:40, 4 December 2025 (UTC)
Yes, this is the English Wikipedia, but since WP:SUL the account names are shared across all Wikimedia wikis. Anomie⚔ 16:32, 4 December 2025 (UTC)
Ah, I had missed the part of Mir Novov's comment above where he said an option to register under a randomly generated username and misinterpreted this discussion as being about a more legible naming scheme for temporary accounts. Yes, for actual global accounts then it is a problem. — Hex•talk 01:20, 7 December 2025 (UTC)
Indeed. This is a much bigger hurdle than most happily account-owning wikipedians realize. -- asilvering (talk) 05:10, 5 December 2025 (UTC)
Perhaps we should more obviously advertise that usernames can be changed later. On some websites they can't, so it isn't a default expectation. CMD (talk) 05:35, 5 December 2025 (UTC)
@Chipmunkdavis, I think this would be a good idea, but account renamers may not. It would be a good idea to break this out as a separate VP discussion. -- asilvering (talk) 22:28, 5 December 2025 (UTC)
The very least that should be done is to remove the 'ditch this account and dodge all blocks and warnings' button that has been inexplicably included in the drop down menu of user options for all TAs. CMD (talk) 02:52, 4 December 2025 (UTC)
I completely agree with you in that regard. Why is that even a thing? Why not just keep the temporary account until the cookie is manually deleted? SuperPianoMan9167 (talk) 02:53, 4 December 2025 (UTC)
My guess is that there's a legal issue behind that, though it could be pressure from the Growth team to try to push temp accounts into registering. But perhaps it could be made less irritating. WhatamIdoing (talk) 07:43, 4 December 2025 (UTC)
what about instead of displaying ips, display either the hash of the ip, or a unique identifier? MetalBreaksAndBends (talk) 15:34, 5 December 2025 (UTC)
The temp account name is a unique identifier. WhatamIdoing (talk) 22:05, 7 December 2025 (UTC)
I don't know about you, but the second I was told that my IP address would be showed, I rushed to make an account. Mikeycdiamond (talk) 19:12, 4 December 2025 (UTC)
That's why I created my account too. Schazjmd(talk) 20:26, 4 December 2025 (UTC)
A couple of years ago, I asked editors at one of the Village pumps whether they had contributed as an IP. It was about half and half. Less anecdotally, the logs show a lot of editors first making their first edit as an IP, and then creating an account. Perhaps a "Wow, that worked – I want to do more of it" effect? WhatamIdoing (talk) 01:38, 5 December 2025 (UTC)
We could have the edit button redirect to the login page. The constructive people will make an account, and then we could redirect them again back to the edit page. Most people will understand an account requirement, especially for a project as important as Wikipedia -- possibly increasing our credibility with our critics. An account requirement could serve as a filter for the constructive and unconstructive editors; it wouldn't get rid of them completely, but not as many people would vandalize Wikipedia if it wasn't as easy. The people who refuse to make an account are an extremely small minority. Why should we waste the time of and alienate our current editors when the alternative is creating an extremely small barrier of entry that could filter out some of the unconstructive editors? Mikeycdiamond (talk) 02:26, 5 December 2025 (UTC)
Unconstructive editors will just as easily make an account and vandalize if they are really intent on disrupting Wikipedia. Those who want to vandalize could easily take the extra 20 seconds to register. SuperPianoMan9167 (talk) 02:33, 5 December 2025 (UTC)
Like I said, it wouldn't filter all of them. A large amount of vandalism that I've seen is idiotic stuff that was most likely made by a bored teenager/preteen. If we place a barrier, any barrier, we would remove the fun from vandalism. This could cut out a large percentage of vandalism, which would save hours of editor time. Mikeycdiamond (talk) 02:39, 5 December 2025 (UTC)
Seconding this. The edit history of the banned IP of a school computer I checked recently is exactly what you're describing. It should absolutely be taken into consideration that, while requiring accounts isn't going to stop the type of vandals who are the reason Israel is protected, Annoyance could probably drop its pending changes protection if that happened. JustARandomSquid (talk) 17:48, 6 December 2025 (UTC)
The constructive people will make an account Not necessarily. There are plenty of sites where, when they've given me a "you must sign up to continue", I say "maybe later" and go elsewhere. Anomie⚔ 02:46, 5 December 2025 (UTC)
About what @Mikeycdiamond said above: We could have the edit button redirect to the login page. The constructive people will make an account.
I understand that this was tried c. 2010 and was proven false. WhatamIdoing (talk) 22:02, 7 December 2025 (UTC)
Now I'm intrigued. Is there a page existing somewhere for this trial? SuperPianoMan9167 (talk) 22:15, 7 December 2025 (UTC)
It's probably at the usability: wiki, though there's always a chance that it's at Meta-Wiki or mediawiki.org. What I remember hearing is that the overall outcome is that pre-edit registration results in fewer good edits, and that every additional question in the Special:CreateAccount form results in fewer completed registrations. WhatamIdoing (talk) 22:27, 7 December 2025 (UTC)
Was it tried in English Wikipedia? Those smaller language Wikipedias are very different from us. Mikeycdiamond (talk) 01:24, 8 December 2025 (UTC)
@Mikeycdiamond, I'd love to get some A/B test data on it, but I can't imagine that our outcomes would be any different than what WhatamIdoing just described. -- asilvering (talk) 01:54, 8 December 2025 (UTC)
Yes, almost all of the usability work was done here at enwiki. That's one of its weaknesses (but convenient for us). WhatamIdoing (talk) 03:51, 8 December 2025 (UTC)
Massive privacy problems. There is no chance of this happening this decade. WhatamIdoing (talk) 05:30, 8 December 2025 (UTC)
I note the article does not consider the editor time required to deal with disruption, and the article does concede that requiring accounts did eliminate a lot of disruption. Good day—RetroCosmostalk 02:28, 8 December 2025 (UTC)
It's awful and was an awful idea from its inception. I understand the reason for it and the solution has always been requiring someone to create a free account. Just like literally every website in the past two decades. Requiring someone to make an account does not change the "encyclopedia anyone can edit" mantra in the slightest. SilverserenC 01:05, 4 December 2025 (UTC)
18 people, woo. SilverserenC 01:14, 4 December 2025 (UTC)
You can find 18 people who disagree with anything. My humble opinion is that a lot of the (former) IP editors were making a big deal of not registering because they liked being a rebel. If they had to register, they would have and would have quickly have got over their "I'm different" glow. Johnuniq (talk) 05:13, 4 December 2025 (UTC)
I talked to one a few years ago who said that he used a lot of different devices, so staying logged in to anything was a hassle. I don't think it was an oppositional motivation; I think he was just doing a rational cost/benefit analysis: If it's easy enough to report the bug, he'd do so; if it wasn't, then he wouldn't bother. WhatamIdoing (talk) 07:47, 4 December 2025 (UTC)
I edit across three devices, -- two autologs, one non-autolog -- it isn't that big of a deal. If you enable autolog, you don't even have to login each time. Mikeycdiamond (talk) 19:19, 4 December 2025 (UTC)
Easy for you ≠ easy enough for everyone. WhatamIdoing (talk) 01:39, 5 December 2025 (UTC)
How out of the way is spending 10 seconds logging in? If you didn't want to do it every time, you could spend the 1 extra second to click the remember this device button. Mikeycdiamond (talk) 02:13, 5 December 2025 (UTC)
... which wouldn't solve any problems for the unregistered users that burn through temporary accounts due to having cookies turned off, since the TA system uses the exact same cookie functionality as the "remember this device" button. SuperPianoMan9167 (talk) 22:14, 7 December 2025 (UTC)
How out of the way is spending 10 seconds logging in ...every single time ...maybe in a system that doesn't retain cookies ...and maybe even on shared devices, where you can't save your password?
Apparently the barrier was high enough that he didn't want to do it. WhatamIdoing (talk) 22:29, 7 December 2025 (UTC)
Anyone want to start a community-wide RfC about this? I believe the WMF will have the final say on whether to disable temporary account editing on the English Wikipedia (and I highly doubt they'll get rid of temp accounts), but it'll still be interesting to see what percentage of the community actually supports requiring an account to edit. I might be in the minority (or majority, who knows), but I don't think temporary accounts are a stupid idea at all. Some1 (talk) 02:18, 4 December 2025 (UTC)
Also, I agree with you about temporary accounts. They have flaws, but implementing them is better than requiring registration IMO as registration creates barriers to good-faith contributors who don't want to or can't make an account. For example, a significant barrier in creating an account (the same one which kept me from having an account for about four months, in fact) is picking a unique, fully username policy-compliant username. SuperPianoMan9167 (talk) 02:42, 4 December 2025 (UTC)
I think this is a mountain out of a molehill. The username policy is very common sense, and any mistake someone does make can be very quickly rectified with a rename request or just making a new account moments later. I put exactly 0 thought into my username when making my account. Athanelar (talk) 14:38, 4 December 2025 (UTC)
Yes, but I think many new users (myself included, when I made my account) get anxious about picking a username when they see Your username is public and cannot be made private later. They might read this as prohibiting username changes and/or not allowing for mistakes, when of course neither of those things is actually true. SuperPianoMan9167 (talk) 17:14, 4 December 2025 (UTC)
Here's more of my opinions: I think ~2025-12345-67 is easier to understand and remember than 2601:402:680:1270:35FA:C71F:B07D:944 (this was one of my IP addresses). If an IP user was on IPv6, there'd be no guarantee that you'd even be able to communicate with them as their "username" changed so frequently. You'd have to hope that you got the most recently used address in the /64. SuperPianoMan9167 (talk) 02:51, 4 December 2025 (UTC)
Yeah I don't understand the complaints that temporary accounts change frequently -- that was already a huge problem, every IPv6 account was functionally a burner. Gnomingstuff (talk) 03:19, 4 December 2025 (UTC)
Yup. Temp accounts only change if you clear cookies or don't use cookies. IPv6 addresses change daily and there's basically no way to stop it other than switching to a static IPv4. (Unrelated: I went ahead and made WP:LLM an information page instead of an essay. Do you think that was a good idea?) SuperPianoMan9167 (talk) 03:23, 4 December 2025 (UTC)
The difference between an IPv6 edit and a TA edit is that it is trivial to add /64 to the IPv6 and see if any related IPs are active. Adding /64 doesn't require a formal opt-in or a promise (punishable by banishment) to be good. Many people without any privilege (including IPs) have reported an IP range for vandalism—that saves time. Johnuniq (talk) 06:23, 4 December 2025 (UTC)
Trivial for users who know how IP address ranges work and who know that a /64 subnet usually represents a single household. Many users that are less technologically inclined don't know either of those things and got super confused trying to follow around an IPv6 user. SuperPianoMan9167 (talk) 17:17, 4 December 2025 (UTC)
In most cases when I was an IP editor people just called me "2601". SuperPianoMan9167 (talk) 17:21, 4 December 2025 (UTC)
Disabling temporary accounts and requiring registration to edit are different. Even if we adopt the pt.wiki precedent of requiring registration to edit articles, TAs will still be used to edit talkpages. CMD (talk) 02:55, 4 December 2025 (UTC)
And we will still have the multi-TA abuse even if we require registration like that. It'd just be on talk pages instead of in articles. SuperPianoMan9167 (talk) 02:56, 4 December 2025 (UTC)
Description from the file: This graph shows a decline in new registered users from about 160K in 2018 to about 80K in 2025. Yep. And to add to my comment above, I would oppose requiring registration to edit the English Wikipedia mainspace (or any other namespaces, for that matter). From what I've seen on this site, there are more constructive unregistered editors than there are unconstructive ones. Not to mention, Wikipedia is already facing a "drastic" decline in account creation since 2020. IMHO, requiring registration to edit (which includes banning temporary accounts or unregistered users from editing the mainspace) will just accelerate the decline of this project. Some1 (talk) 04:39, 4 December 2025 (UTC)
Another way for decline to accelerate would be to have content creators swamped with rubbish from throw-away temporary accounts. Johnuniq (talk) 06:26, 4 December 2025 (UTC)
Is there evidence of that happening? I see the complaint that admins who focus on blocking vandals need some more efficient (and mobile-friendly) tools, but how would a "throw-away temporary account" be any worse for a content creator than someone using a VPN or even just posting one comment at home, one on the school bus, one from school, another on the school bus home, etc.?
A couple of years ago, I checked what mobile editing might be like in my neighborhood. I can go for a five-minute walk and have five different unrelated IP addresses from three different ISPs. You can't use a /64 option to connect those IPs. But under temp accounts, that would be all one temp account number. WhatamIdoing (talk) 08:19, 4 December 2025 (UTC)
What I meant was that content creators are driven away by rubbish, whether from IPs or TAs. That is another way for this project to decline. There will always be plenty of vandal fighters because that's easy and fun and productive. Good content creators are rare and need to be protected. Persisting with the old open-door policy might have bad consequences as it becomes harder to deal with disruption, not to mention AI slop and interference from governments and megacorporations. Johnuniq (talk) 08:53, 4 December 2025 (UTC)
I agree that vandal fighters appear when there is obvious rubbish to be reverted, and that they disappear when the need lessens. But I'm not sure why a good content creator would be deterred by the existence of vandals. After all, it didn't deter us in the pre-ClueBot days, when vandalism persisted on pages much longer. WhatamIdoing (talk) 01:43, 5 December 2025 (UTC)
I have to agree with Some1 and SuperPianoMan9167 that disabling unregistered users from contributing would be a horrible idea. There are way more constructive IPs than vandals, we just pay more attention to vandals because they're the ones who require action. I dislike the recent trend of requiring people to create accounts to see certain contents or contribute to a site (it recently caught onto Twitter, Tumblr, and even Fandom, and it's made me look up all three significantly less), and I do not want Wikipedia to fall into that trap; speaking from personal experience, the primary reason why I even started editing here was because I was able to do so without needing an account, and I would not want to take that experience away from other people. Unnamed anon (talk) 06:42, 4 December 2025 (UTC)
Seconded from me. There are more good IPs than bad ones and it's a pain in the butt for an innocent potential editor to be turned away because they need to create an account. Toby(t)(c)(rw) 06:46, 4 December 2025 (UTC)
Agreed -- bad edits might be up, but _all_ edits are up. I've seen way more talk interaction from readers since we stopped making them sacrifice privacy to communicate with us. Feoffer (talk) 15:05, 4 December 2025 (UTC)
I wonder where we keep the per-namespace total edits stats. WhatamIdoing (talk) 01:44, 5 December 2025 (UTC)
November edits in 2025 are down compared to November edits in 2024. Total edits to non-content pages were 1.819 million in November 2024 and 1.1859 in November 2025. That's a 2% increase, which is probably random variation. I don't see a way there to count only the Talk: namespace. That'd probably require help from Wikipedia:Request a query. WhatamIdoing (talk) 05:26, 5 December 2025 (UTC)
And the active users has jumped to 300k. I think TA should be excluded from it because one user can have multiple TA (because they may edit on different devices) Before last month, i think we had 120k active users. JuniperChill (talk) 10:47, 5 December 2025 (UTC)
@WhatamIdoing I know this is a week old, but how can 1.819 to 1.1859 be a 2% increase? David10244 (talk) 03:56, 15 December 2025 (UTC)
By way of a typo. The second number should be 1.859 million (not 1.1859). WhatamIdoing (talk) 04:54, 15 December 2025 (UTC)
I don't think we should disable unregistered users. I think the project suffers in some ways for not doing so, but I don't think it should actually be done. But temp accounts are just a license to vandalize. Snokalok (talk) 02:29, 5 December 2025 (UTC)
Have we reached a tipping point… where our hyper focus on encouraging new editors may result in driving away existing editors? Blueboar (talk) 14:21, 4 December 2025 (UTC)
Is anyone encouraging new editors? The temp account thing is unrelated to that on the WMF's end. WhatamIdoing (talk) 01:48, 5 December 2025 (UTC)
Earlier this year, I took a look at TA and came to the conclusion that they are a far greater privacy threat than IP editing ever was. I described the details in T388320. The ticket is not public because WP:BEANS, but if you have a phab account and a need to know, I'll be happy to subscribe you. The most gaping exposure has since been fixed, but the concept is still valid and easy to exploit by any semi-sophisticated bad actor. RoySmith(talk) 13:39, 5 December 2025 (UTC)
@RoySmith: could you subscribe me? sapphaline (talk) 20:56, 6 December 2025 (UTC)
I need your phab username and your "need to know". You can email it to me if you prefer not to post it on-wiki. RoySmith(talk) 21:07, 6 December 2025 (UTC)
Me also, please. Need to know is being an admin who wants to be aware of threat surfaces. Username is the same. — Hex•talk 01:23, 7 December 2025 (UTC)
"your phab username" - same as my Wikimedia username. "your "need to know"" - I'm curious. sapphaline (talk) 08:09, 7 December 2025 (UTC)
Me, please Roy? Phab username = Pelagic, need to know = self-education as my day job is in cybersec. ⁓Pelagic (messages) 22:05, 12 December 2025 (UTC)
Yup. Stupid and silly. IP accounts ought to go too. "You don't want to sign up to Wikipedia? Well, you're not going to edit it" is the best approach in my opinion. Lemonademan22 (talk) 16:21, 7 December 2025 (UTC)
There seems to be a big bloc of users supporting a ban on IP editing. I'm neutral on this. The pros are privacy and maybe drive-by vandal deterrence. The downside is that Wikipedia will lose a good bunch of typo-correction edits and minor housekeeping. OK, let's assume our editors can take up this housekeeping work. Well, you are not actually really helping with persistent vandals and sockers. They will still create accounts and all that. And the issue brought up of POV-pushers will not be deterred by a simple account creation requirement. Some drive-by vandalism will be stopped, if you're optimistic most would be stopped, but if I'm going more pessimistically then they will likely not care about the account creation requirement and still vandalize. In fact, it may even make it worse as they will discover socking! SPI may become more hellish… OK, let's go optimistic and say that these plagues will be lessened. There is the topic of getting new editors. A good portion of the Wikipedia editor community came from being long-term anon editors. There is a chance we lose a couple dozen or hundred potential contributors just because they can't bring themselves to make an account. But there is some benefit to disabling IP editing. That would be more abstract though and I am not an expert at interpreting the data from the Portuguese Wikipedia about their disabled IP editing. —Preceding unsigned comment added by ~2025-31733-18 (talk) 17:44, 7 December 2025 (UTC)
But it's not just about the edits that do/don't happen. Imagine if every single newbie whom you suspected of being a sock had to go to a Wikipedia:Sockpuppet investigations for a CheckUser investigation, because nobody else could get even basic geolocation information. WhatamIdoing (talk) 03:55, 8 December 2025 (UTC)
That is true, and if we force anons into registering the situation will not be much different from POVpushers who don't care about having to make an account, only this time SPI will be flooded because even less people can see that it's just the same person despite being two different temporary accounts. Now checkusers will be absolutely swamped. ~2025-31733-18 (talk) 04:10, 8 December 2025 (UTC)
I have a bit of a cynical take on this temp account issue probably because I'm only really active in the Israel-Palestine conflict topic area. There is obviously a significant asymmetry between the cost of creating a sock account, and the cost of spotting, compiling evidence, reporting and blocking a sock. Our ban/block evasion countermeasures are very limited, thanks in large part to the 90-day data retention schedule that I assume will remain an immovable object. Under these conditions, any account can be viewed as a temporary account where the operator is free to choose when to switch to a different account, there is not much we can do about it in practice, and all of our enforcement mechanisms like topic bans, blocks, logged warnings etc. are mostly unenforceable theater. And with that happy note, I'll bid you good day. Sean.hoyland (talk) 06:36, 8 December 2025 (UTC)
Oh well, I guess the thing here is that unlike CU information for registered accounts, TAIV is much more accesible, so that will ease the burden on CUs and make it easier for admins to block IPs behind TAs, rather than having to open an SPI or add to one every day because User:Example has made their 400th sock ~2025-31733-18 (talk) 13:34, 8 December 2025 (UTC)
What's happening is the opposite. TAIV doesn't access all of the information that CU can, and you often need more than just IP address to determine violations of policy. But since contribs are now grouped by TA instead of by IP, and TA numbering is semi-random, it is completely impossible to tell without CU if a series of TAs are one user whose browser doesn't store cookies properly, one user clearing their cookies to evade scrutiny, one user with more than one device, several unrelated users with a common interest in something because they all live near it and happen to use the same network, a bunch of people from all over the world, or numerous other scenarios. And for each one of those, is it being done in good faith or is it a violation of policy? There is much more work for CUs with temporary accounts active. And besides not being allowed to link an IP with a registered account, we now also aren't permitted to link a TA to a registered account, and we're supposed to avoid revealing the IP of a TA, so a lot of our work just got more complicated, besides there being more of it overall. Ivanvector (Talk/Edits) 14:02, 8 December 2025 (UTC)
Can't you just use the IPs behind it? Or I just might have a Wikipedia:PIXIEDUST perspective... Also, I thought with TAIV you could still see IP contribs, it's just now behind perms? And I think you should not overthink not disclosing the IP of a TA, just not be conspicious with what you're doing, blocking the IP behind it, or just ignore the fact that TAs exist and block the range behind it rather than the surface TAs? ~2025-31733-18 (talk) 16:34, 8 December 2025 (UTC)
TAIVs can still see IP contribs, yes. Ivanvector is fully correct about what it's impossible to tell without CU, but I confess I don't see the issue there - it's not like anyone who wasn't a CU would have been able to make those conclusions about IP edits before TAs, either. -- asilvering (talk) 20:42, 8 December 2025 (UTC)
We need more CUs. We have needed more CUs for years, but we really need more CUs for the next few months, until we get used to the new systems. WhatamIdoing (talk) 00:52, 9 December 2025 (UTC)
Well, we just got two new ones, so your wish is granted. -- asilvering (talk) 01:06, 9 December 2025 (UTC)
Re immovable object: the 90-day data limit is one the WMF said they are open to extending (from the MediaWiki temp accounts FAQ). I think looking into extending this window could be a useful step for enwiki to explore regardless of our consensus position on mandatory registration, though it certainly doesn't solve issues of temp accounts going inactive before that time. Perfect4th (talk) 18:48, 17 December 2025 (UTC)
I don't understand why people think that "well, any other website requires an account" is a good reason to disable anonymous editing. Wikipedia isn't social media or like any other famous website on the Internet. If anything, that's a reason to keep anonymous editing, not disable it. sapphaline (talk) 07:57, 8 December 2025 (UTC)
Exactly. Also, the number of times I've seen a linked tweet on a website, clicked on it to read it in full or watch the video, then been asked to log in to see it, and then gave up, despite actually having an X account, is very large. JustARandomSquid (talk) 08:02, 8 December 2025 (UTC)
I don't think anyone's suggesting that you would need to log in just to be able to read a wiki page... Rosbif73 (talk) 15:29, 8 December 2025 (UTC)
No, but I'd say reading a tweet has a comparable pay-off to, say, fixing a typo you just read. I'm saying having to log-in can be to big of a barrier to contributing. JustARandomSquid (talk) 17:36, 8 December 2025 (UTC)
I would support the requirement for everyone to have an account. Maybe would make for a lot less chaos. Tankishguy 17:47, 11 December 2025 (UTC)
I don't know much, though, so Mark that as a comment. Tankishguy 17:48, 11 December 2025 (UTC)
This is Eric from the Product Safety and Integrity team. We know temporary accounts are adding time, energy, and noise to dealing with vandalism on English Wikipedia.
In addition to following the discussion here, we’ve been spending a lot of time the last few weeks listening to this wiki’s functionaries about the specific problems they’re seeing, and discussing ideas for dealing with these issues.
One measure we’ve taken is to tighten the rate limits, for now, on temporary account creation, globally across all projects, to cut down on some of the noise people are seeing while we work on changes to the system. To be clear, the new limits are pretty strict and we expect this to affect places with widely shared IPs, like libraries and schools. While we expect this to be temporary, we have also added a clearer nudge toward account creation to help good-faith editors who get rate limited.
We’re also in the middle of a set of quicker, smaller changes to surface more information more easily about potential vandalism by temporary accounts. Some are done already, with the rest coming this week:
Highlighting temporary accounts on content and discussion pages (T392775)
Added a link to “abuse log” when viewing IP ranges (T412341)
Added some basic information about temporary account and IP connections to Special:Contributions and SpecialIPContributions (T412218)
Added links to IP range modifiers (e.g. /16, /24, /32) directly to Special:IPContributions (T409179)
Added a link to /64 IPContributions when revealing an IPv6 IP (T411943)
Tagging temporary account creations happening via Special:MyTalk, for blocked IPs (T398673)
Displaying higher number buckets for “temporary accounts from all associated IPs” in UserInfo card (T412212)
Showing a tooltip to indicate whether the IP is the latest used (T411185)
Another clear theme of the discussion here is whether to deal with these issues by simply banning unregistered editing.
In past discussions, some volunteers have criticized how the Foundation represented its past research about the effect of banning unregistered editing on the two wikis where it has at least briefly taken place. We discussed this internally and agreed that some of our public comments were overstating the strength of the evidence. We’ve updated our temporary accounts FAQ to make it clearer that the studies we’ve done show mixed results and that their observational nature makes it difficult to draw firm conclusions at all. Thank you to those who pointed out these issues.
Even so, we’re spending the time to make temporary accounts work because we believe editing without registration is a founding principle for a reason. Even though it may lead to more bad-faith editors, we think it is likely that the ability to edit without creating an account has led to more people trying to edit for the first time, and more people eventually creating accounts, sticking around, and becoming respected editors.
Streamlining anti-vandalism work in the temporary accounts system is a focus for our team for the next few months. If you have specific ideas that you think could make the system work better, now is a great time to suggest them to us on our team talk page. EMill-WMF (talk) 22:45, 15 December 2025 (UTC)
Even so, we’re spending the time to make temporary accounts work because we believe editing without registration is a founding principle for a reason. Even though it may lead to more bad-faith editors, we think it is likely that the ability to edit without creating an account has led to more people trying to edit for the first time, and more people eventually creating accounts, sticking around, and becoming respected editors.
From where I'm sitting this is not what's happening or going to happen.
Instead all you're going to achieve with this absurd adherence to the "no account needed" open door policy is drive away more and more experienced editors like myself who are increasingly fed up and don't see the point in contributing anymore because of the circus it's becoming as disruptive TAs run rampant and bad actors can just immediately ditch and switch them without consequences given you've hidden the easiest way to demonstrate a bad actor (their IP address) behind tools only a handful of users have or feel comfortable using, and admin responses are taking far longer in my experience to deal with it and there's less of a tendency to block IP ranges as in the past but just whack-a-mole on each instance of a TA which by the time it's blocked has already been discarded for a new one.
It is not 2001 anymore, where Wikipedia was a niche website of enthusiasts on a tiny internet base that needed to grow. It's 2025 where Wikipedia is one of the most visited websites on the planet, everyone has a portable device that allows immediate access to the internet 24/7, and is constantly subject to disruption.
All this introduction of TAs feels like is living in an area that's a burglary hotspot and being told to remove your door locks because of a theoretical delay for paramedics in an emergency... Rambling Rambler (talk) 23:27, 15 December 2025 (UTC)
I think you are operating on the assumption that most unregistered users are vandals. As far as I can tell that's not true.
I know anecdotal evidence is weak, but I know that I probably wouldn't have made my account if I wasn't able to edit as an IP.
Also, re bad actors can just immediately ditch and switch them without consequences: Eric just said One measure we’ve taken is to tighten the rate limits, for now, on temporary account creation, globally across all projects.
@SuperPianoMan9167 I'm not assuming most people using TAs are vandals, what I'm arguing is that those TAs that are disruptive are increasingly a problem compared to when it was IPs and the very nature of them is more prone to abuse by those who are vandals.
Just as an example when it was IPs and you had an article on something recently prominent, you could easily show that there it might be one specific person in a geographic area that was good-faith but still causing disruption and request a temporary IP block just for them while allowing other IPs to keep contributing. Now however my only option is to immediately go to RFPP and block everyone without an account (which is always backlogged to hell anyway) which inherently defeats the entire point of TAs to begin with and/or spend hours playing whack-a-mole. It's just a grind.
As for rate limits, Eric also said "while we expect this to be temporary" and I get the feeling they mean the rate limits themselves. Rambling Rambler (talk) 23:57, 15 December 2025 (UTC)
@Rambling Rambler, why can't you report them now?
Old system:
Post to the WP:DRAMABOARD that User:203.0.113.255 is screwing up the article. An admin temporarily blocks the IP address.
New system:
Post to the WP:DRAMABOARD that User:~2025-12345-67 is screwing up the article. An admin looks up the TA's IP address and then temporarily blocks the IP address.
Either way, the IP gets temporarily blocked. Where's the problem? WhatamIdoing (talk) 02:00, 16 December 2025 (UTC)
I can say from experience that often times IPs and IP legacy history gets overlooked. Likely because it's changed the AIV workflow in a way that has vastly increased the time required for a complete investigation. ScottishFinnishRadish (talk) 11:52, 16 December 2025 (UTC)
If all the necessary info (TA contribs, other TA contribs on the same IP, legacy IP contribs) was available on one page instead of three different pages, would that problem be solved? SuperPianoMan9167 (talk) 13:31, 16 December 2025 (UTC)
Partially, but that doesn't address reports not being made because of low numbers of TAIVs. The system works poorly for legion reasons. ScottishFinnishRadish (talk) 13:45, 16 December 2025 (UTC)
You don't need the TAIV user right to report that User:~2025-12345-67 is vandalizing an article, or that a series of TAs are vandalizing the same article, or articles on the same subject. WhatamIdoing (talk) 20:15, 16 December 2025 (UTC)
Agree with this. I've still been able to do antivandal work even without TAIV (I'm mad at past me for procrastinating when making an account!) because most of the time vandalism or LTA/sockpuppet behavior is glaringly obvious. SuperPianoMan9167 (talk) 20:21, 16 December 2025 (UTC)
@ScottishFinnishRadish, is autoblock on by default for TAs? If not, let's talk about enabling that. WhatamIdoing (talk) 20:30, 16 December 2025 (UTC)
@WhatamIdoing, autoblock is on by default if you're blocking with Twinkle, which I assume most of us do. -- asilvering (talk) 20:35, 16 December 2025 (UTC)
I wonder if that could be set to a /64 for TAs. WhatamIdoing (talk) 21:07, 16 December 2025 (UTC)
I'm fairly certain that's already how autoblock works. -- asilvering (talk) 21:09, 16 December 2025 (UTC)
Autoblocks are 24 hours. There have been discussions about adjusting that, but then we'll end up making all TA blocks on the underlying IP one set amount, regardless of the level of disruption. ScottishFinnishRadish (talk) 22:45, 16 December 2025 (UTC)
It seems like that's a feature ripe for extension. What do you think would be better: a different default time (31 hours is useful for school-based problems), manually overriding the time, or adding some jitter to the setting (24 hours + random amount), so that it won't always be obvious when to try again? WhatamIdoing (talk) 22:51, 16 December 2025 (UTC)
Concurring with SFR above. From my experience admins now just see the TA and block that without also blocking the IP. So you'll see people report TA after TA that are clearly the same person yet it pops back up immediately while previously it would've been a /16 or /64 block and move on. Rambling Rambler (talk) 12:18, 16 December 2025 (UTC)
Streamlining anti-vandalism work in the temporary accounts system is a focus for our team for the next few months. If you have specific ideas that you think could make the system work better, now is a great time to suggest them to us on our team talk page. --Eric
Here's the problem with that rationale. IF the reason for TAs is that IPs are private information and shouldn't be accessible, then TAIV existing is the exact same privacy violation.
Six months and three hundred edits is a frankly low barrier to entry for a bad actor to hit. Rambling Rambler (talk) 14:07, 16 December 2025 (UTC)
Which is still better than a barrier of zero months and zero edits.
Also, imagine what the workload on CUs would be if no one could see IP addresses but them. There are 1,234 users with TAIV permissions but only 46 CUs. SuperPianoMan9167 (talk) 14:12, 16 December 2025 (UTC)
It's not that much better though. I mean christ, if we assume that it is worry over personal data that's the justification for TAs existing then we currently have a logic where you can be trusted with the ability to view someone's IP yet not trusted to edit an article related to Israel-Palestine because Extended Confirmed requires 500 edits minimum.
To me it just further emphasises how TAs don't really resolve anything but do make the situation worse. Rambling Rambler (talk) 14:21, 16 December 2025 (UTC)
@SuperPianoMan9167 I just realized that since TAs can only last for 90 days, that no TA can reach any threshold that requires 6 months of editing plus (any number) of edits. Interesting. David10244 (talk) 04:55, 24 December 2025 (UTC)
I will plagiarize myself: if the restriction was on just looking at IP addresses without disclosing them then IP Auto-Reveal would not be a thing. SuperPianoMan9167 (talk) 14:17, 16 December 2025 (UTC)
Rambler, the WP:TAIV requirement is six months plus 300 edits plus individual approval. So that's six months (median new account activity: 1 day), 300 edits (=top 1% of accounts in Wikipedia's history), and personal judgment of the granting admin. Contributing more than 99% of editors without getting blocked is not "a low barrier".
Yes, really dedicated bad actors can game any system. But we're mostly dealing with jerks on the internet rather than an advanced persistent threat. We might need to get a few admins or even a couple of CUs and Stewards to sort out a way to block the person who's harassing the OP, even if it means blocking most of a city or contacting the user's internet providers. But this isn't actually a different system underneath: we have always had to deal with IP-hopping jerks, and admins can still block IPs. WhatamIdoing (talk) 20:28, 16 December 2025 (UTC)
I'm curious, but why "I probably wouldn't have made my account if I wasn't able to edit as an IP"? I can think of two reasons people are averse to creating accounts. One is that they believe IP editing is more private. The other is that creating an account is too much hassle. Which of those was it in your case, or was it something else? RoySmith(talk) 00:00, 16 December 2025 (UTC)
The second option, because I could not pick a username for the longest time. I started regularly editing in March 2025 and didn't have the guts to make my account until 1 AM on July 5th. SuperPianoMan9167 (talk) 00:04, 16 December 2025 (UTC)
OK, I'll call that a subset of "too much hassle". One of the ideas I've seen kicked around is to give users the opportunity to have a random-ish username chosen for them, which they could change at some point in the future. If that had been available to you at the time, would you have found it useful? RoySmith(talk) 00:08, 16 December 2025 (UTC)
Yes. What you're describing is basically the same thing as temporary accounts, except that they don't expire after 90 days. SuperPianoMan9167 (talk) 00:11, 16 December 2025 (UTC)
Also, if you check my IP contributions, you'll see that yes, I did start editing using VisualEditor (shame on me!) and only later switched to wikitext. I found it helpful at first but I don't bother with it now as I feel more comfortable with source editing. SuperPianoMan9167 (talk) 00:17, 16 December 2025 (UTC)
No need for shame; different approaches appeal to different people. It's all good. And some aspects of editing tables are much simpler. isaacl (talk) 02:59, 16 December 2025 (UTC)
I'm guessing the main reason Wikipedia allows users to edit without an account is because it removes the need to create an account just to make a couple of edits (as I don't like it when websites force me to create an account even just to read something.). This is because even the vast majority of NAs have less than 10 edits (when accounts become autoconfirmed). When I first created my account, I did so mainly to hide my IP, and only made ~20 edits in 2020, before starting out in late 2023. JuniperChill (talk) 18:42, 16 December 2025 (UTC)
Editing without needing to create an account lets people "try before they buy".
Unregistered editing is also done by long-time editors who are on a different computer system. Why bother logging in to the work/school/phone/other browser, if you're just reverting this one bit of vandalism? WhatamIdoing (talk) 21:00, 16 December 2025 (UTC)
don't see the point in contributing anymore because of the circus it's becoming as disruptive TAs run rampant and bad actors can just immediately ditch and switch them without consequences
As a TA user; please let us dismiss the “create account” header that sits on every page. The only way to get rid of it is to exit the account and it leads to me making a new TA for every comment. ~2025-41188-39 (talk) 16:31, 16 December 2025 (UTC)
So, why don't you just create an account? I'm not being snarky here, I'm just trying to understand the factors that make people not want real accounts. RoySmith(talk) 16:51, 16 December 2025 (UTC)
The reasoning is just as diverse as the editors. Some people do it out of principle, others out of habit. It may be due to caution or to whimsy, deeply rooted conviction or passing fancy. For some it is intended wholeheartedly as a genuine public service, for others naught but a bit of playful dissent.
Mavericks, misfits, disruptive idealists, loyal provocateurs, benevolent dissenters, saboteurs of stodginess, catalysts for creative chaos, as many adjectives as there are referents.
To the observer they may be quaint, or quixotic. Incorrigible or incorruptible. The last relics of a bygone age, or the final guardians of the project's original spirit.
But whatever the reasons, now as always it will continue to be what we do rather than who we are that defines each of us. ~2025-41540-19 (talk) 04:43, 19 December 2025 (UTC)
I get the same impression that it's a silly idea after the recent matter on Eric Gilbertson (climber), a subject of repeated promotional editing. As soon as a "scholarly paper/journal" attributed to him, a swath of temp accounts started adding contents about him. IP hiding policy though makes things like institutional COI harder to detect and privacy policy makes it more restrictive to discuss them. Graywalls (talk) 16:00, 20 December 2025 (UTC)
I'll admit I don't really get why the decision was made to give a vague range of associated TAs when they could just provide direct access to them. Sure in theory someone on a public network could then discern what pages other people on that network had edited while logged-out, but it wouldn't tell them who. This specific case however is not a good vehicle for advocating that change.
As of today, per page stats, there are two edits by unregistered editors total to Eric Gilbertson (climber). One by TA, neither consequential. Addition of a related source to Uzbekistan predates TA rollout. One IP and subsequently two TAs have tried to change Mount Rainier's height. Given that The Seattle Times and OutsideOnline both devoted page space to it, and that Gilbertson complained about Wikipedia on his blog, the only surprising thing is that more people haven't tried to change it.
We can still discuss the possibility of institutional CoI based on underlying IP data as evidenced by the fact you have done so here. And if challenged during a COIN thread by someone without the perm it can easily be verified by a third party. Inexperienced patrollers are unlikely to notice institutional connections anyway. Experienced patrollers without direct access to the data are perhaps slightly impacted, and I suppose I myself fall into that category, but at the end of the day refspam is refspam. The existence or absence of a clear CoI doesn't add or subtract much to it from a response perspective. ~2025-41540-19 (talk) 17:06, 20 December 2025 (UTC)
It might have one of mountain pages. An institution associated temp did something related to inserting Gilbertson reference. The limited visibility and those who can see have additional privacy restrictions to follow, thus the new temp name thing makes dealing with promoitonal editing more difficult. Graywalls (talk) 18:04, 20 December 2025 (UTC)
I doubt any individual or group is going to have a CoI with respect to all mountain pages. A CoI with respect to the intersection of certain people or publications and mountain pages yes, but not all mountain pages in general.
Visibility has always been limited. The number of people who would even know to check a WHOIS has always been small, and of that subset most of them won't check absent an indicator that additional investigation is needed. Is visibility even less now? yes. But it's marginal. And the more clever CoI farms have long known they are best-off creating accounts anyway.
I've been dubitante about this change since first hearing of it. I don't really understand why a hashing scheme that preserves ranges was not pursued an attack to break it is unlikely and even if it happened the fault would lay not with the WMF, the underlying purpose here being to protect the WMF rather than privacy, and IPs have always been and remain semi-public anyway. I don't understand why they're deadset on 90-day expiries, or why there's even an Exit Session button in the interface. Some patrolling work is more difficult now, and I've already had to ask for more time of others than I would've in the past. Lots of room for adjustment already presents itself, and more will follow. However the slight limitation on the number of people doing WHOIS checks is by itself rather minor. If refspamming from a range persists it will get blocked, and the cleanup of unsophisticated refspam is rather straightforward regardless of whether IPs, TAs, or accounts are employed to do it. ~2025-41540-19 (talk) 18:38, 20 December 2025 (UTC)
Thanks for the link. Won't have time to review any of this again in detail until after the 1st of the year at least if you do catch me editing after tommorrow and before the New Year feel free to throw a trout at me or something, but it's nice to know there are some angles they can be nudged from. ~2025-41540-19 (talk) 20:38, 20 December 2025 (UTC)
If memory serves, lengths ranging from 30 days to one year were considered. I don't know why 90 days (specifically) was chosen. WhatamIdoing (talk) 21:35, 20 December 2025 (UTC)
T359653 suggests they decided 1 year was too long, and then picked 90 to match the CheckUser data retention time. In that same task, they were also considering just 7 days. Anomie⚔ 22:39, 20 December 2025 (UTC)
About hashing schemes: One of the fundamental questions that had to be answered at the start of this project is whether identifying a user should depend upon the user's IP. Not "Shall we make the IP visible to the general public for all eternity?" (because Legal said no to that), but "Given that a lot of editors from mainland China all use the same two (2) IP addresses, and that ordinary people in other parts of the world use multiple IPs in a single day, and that Apple and T-Mobile are semi-randomizing IP addresses, and Google Chrome is threatening to, is pretending that 'IP = user' a smart idea at all?"
The answer was no. Because that answer was no, there was no reason to pursue hashing schemes that started with an IP address (even leaving aside the fact that for IPv4, all hashing schemes based solely on the IP can be brute forced – it's just four billion calculations spread across on a botnet, and then you've got a lookup table for every username – and the other schemes wouldn't give the one-to-one relationship to the IP addresses that the complaining editors are seeking here [plus they'd have to actually click to reveal, instead of seeing it straight on their screens, and that 'extra' click is part of what annoys them]).
The alternative chosen is 'browser = user'. This is the model that we use for registered editors: browser cookies tell us who you are. It doesn't work perfectly: I have three web browsers installed on my laptop, plus another on my phone, plus I think two more on a desktop computer, so in my case, it's potentially 'three devices and six browsers = one user', but if I weren't logged in, the TA system would count that as 'six browsers = six users'. On the other side, there are shared computers at libraries and schools (and families) all over the world, and in that setup, 'one browser = multiple users'. In other cases, those shared computers are correctly differentiating between multiple users, and patrollers here are accustomed to blaming one student at the end of the day for all the edits made by his classmates earlier in the day. And clearing cookies or opening a private/incognito browser window hides the cookies, which is something that registered editors have been exploiting for decades to leave a mean-spirited comment in a discussion or to make an edit that they don't want to have associated with their regular account. The new system may be revealing a more complex reality than some editors believed. WhatamIdoing (talk) 21:16, 20 December 2025 (UTC)
It's less about IDing one user specifically, as no scheme can do that perfectly anyway. It's not just limited to the schoolchildren you mentioned where there are almost certainly shared TAs and many families with multiple children have shared devices at home too but also at least some University students and public library patrons. Normal accounts are an even less sure ID, they can be exchanged, compromised, or even sold, and that's without getting into the LTAs that swap accounts with each other. And more about how to efficiently curtail disruption.
I'll grant that IPs identify someone uniquely far less well than either of those to the extent they're even useful for that at all, but that isn't the purpose being sought here. The idea that TA's will enable us to unblock all mobile ranges is folly because TA hopping will occur just as IP hopping did. The ability for more people to quickly verify ranges used for abuse may actually reduce collateral a bit.
As for dehashing, what of it? I'm not a reflexive hater of the WMF in the way some people are, and I even understand the role they need to play, though I sometimes disagree with how they go about it. But let's be real, the WMF did not embark on this scheme to protect people's privacy, they did so to protect themselves. I don't begrudge them that but I refuse to play the pretend game either.
IPs are semi-public anyway, every website you visit knows your IP, and for reasons you've already elucidated, that isn't the primary means by which people are tracked across the web anyway and the advertisers are shockingly good at doing that. It's unlikely anyone would go through the bother of dehashing don't say nation-states, they have better ways of IDing people to which accounts and TAs are no shield and we know this because minimal use of IP information was made by external actors for all the years it's been publicly available. But regardless the WMF would be no more at fault than if someone gamed the TA perm, or compromised an account with it and leaked information far less effort than dehashing. I guess they could switch out the scheme once a year or something just to be extra bulletproof.
I am however warming to the idea that the new system offers opportunities in addition to drawbacks. And not just in the way it reveals interesting complexity. I well remember the headaches AOL used to cause us back in the day until they started sending XFFs, and yet some of the stuff threatening on the horizon is far worse. I do appreciate you at least explaining this since I'd asked around a half-dozen times before and gotten nothing but crickets from the WMF. C'est la vie. ~2025-41540-19 (talk) 22:38, 20 December 2025 (UTC)
@WhatamIdoing Excellent point about hashing schemes -- it's important to ask things like you point out (does it make sense to consider that IP = user) before moving on to "what hash method to use". I sometimes forget to do that kind of sequential analysis in my own thinking. I'm trying to remember things like this! David10244 (talk) 05:05, 24 December 2025 (UTC)
Yes, I generally see stuff like that as spam oriented, even if not intentional. There is no reason to cite a modern in print edition. Unless it's citing added material like a Foreward, footnotes. The same goes for book cover images, and the ISBN field in infoboxes or bibliography lists. -- GreenC 03:23, 15 December 2025 (UTC)
There are reasons to cite a modern edition because you are supposed to cite the edition you have, not the original. In infoboxes and covers and such we do the most prominent edition, which is not always the first, see for example And Then There Were None, which does not use the first edition. PARAKANYAA (talk) 02:44, 16 December 2025 (UTC)
That makes sense. Even if a book purports to replicate the original exactly, who has checked that it does? Though, if that's all one has available, that's all one has to go by. On the other hand, if the original is online, an editor should use that as the source after checking that, like the more recent edition, it verifies the content. But in that case I mean a photocopy of the original, as Google Books has for many old books. If it's been OCRed, who knows how reliable it is? Largoplazo (talk) 03:22, 16 December 2025 (UTC)
I think PARAKANYAA's correct about the Wikipedia:Say where you got it rule, but if you're listing it in an author's ==Works== section, I'd usually prefer the first edition, and for a ==Further reading== section, I think editors should make a sensible choice and not spend too much time worrying about it (e.g., first edition, freely available, easy to find...). WhatamIdoing (talk) 19:32, 22 December 2025 (UTC)
I have seen modern editions cited, look up the PD edition, verify, then change the cite to use the PD edition, which is infinitely better: more accessible, not prone to copyright issues, copies available anywhere no link rot concerns. Citing where I got it. There is no rule that the original citation is immutable, it only need to verify. And if we nudge/recommend editors to use the PD edition that's a good idea, per the guideline WP:VENDOR (ISBN links include commercial vendors). -- GreenC 06:26, 24 December 2025 (UTC)
Misuse of de minimis copyrighted content
For the sake of argument, let us assume that the "Tron: Ares" advertisement within
this Commons picture of a bus *can* legitimately be considered de minimis. (*)
This section of the current "Tron:Ares" article uses it in a context where the advertisement quite clearly *is* the intended focus (the image wouldn't be there, otherwise) and no longer de minimis.
Yet, the people who uploaded it to Commons (and Commons itself) aren't responsible for that arguable misuse.
Is this an actual loophole, or do we (at English Wikipedia) have a policy against uses like this?
(*) I'm not claiming that necessarily is, just that for the purposes of *this* discussion we should assume so.
In general, just because an image is free enough to host on commons doesn't mean there are no restrictions on how it can be reused elsewhere. It's up to reusers to make sure they are complying with the requirements of the image itself in each use-case. DMacks (talk) 21:48, 22 December 2025 (UTC)
I am not an expert on intellectual property law nor the boundaries of the de minimis exception. But I think it can be argued that:
The non-text part of the TRON ad is a tiny and illegible fragment of the image; that is especially true for the small image size as used in the article. What any viewer is likely to see in the image is merely a bus with text on it. So in that sense the non-text part really is de minimis.
The text part of the TRON ad, because it is just short text ad copy, is public domain (it does not meet the threshold of originality needed for a copyright), but of course the wording and font choice may be protected through other intellectual property laws such as trademark.
The use of that image to say something about the marketing for the movie is not going to cause ambiguity with any competing product or service and is therefore also not problematic with respect to trademark.
So my tendency would be to allow the image to remain in the article. —David Eppstein (talk) 05:41, 23 December 2025 (UTC)
That first bullet-point is especially key, and exactly is the kind of thing that depends on the use-case. If the article is about public transportation in general in a gallery of different modes, or about buses and their colors, or about single- vs double-decker, sure, the small protected component is not noticeable. But if the article is "look at how this film is marketed", then the film-poster is the main focus even if it is not a very large fraction of the image, and the reader is specifically instructed to look at that part of it, rather than being incidental to the point of irrelevancy. By de minimis, we should be able to blur out the specific section and not lose usability; I think in this case doing that would make this image unusable for this use-case ("here's an ad for the movie" with much of the ad blocked out). DMacks (talk) 07:15, 23 December 2025 (UTC)
Yes, but my point is that, in that context, the advertising text is the main focus of the article. You cannot use the copyrightable movie image as the focus because it is illegible. And the advertising text is non-copyrightable. Re your thought experiment: we could indeed blur out the copyrightable part of the image (the vertical panel without text on it) and not lose much. —David Eppstein (talk) 07:58, 23 December 2025 (UTC)
I guess as they say we'll have to "agree to disagree" on that thought-experiment's results. DMacks (talk) 13:34, 23 December 2025 (UTC)
@David Eppstein: - The text is, as you note, almost certainly not copyrightable and below the ToC.
However, I disagree with the assertion that "The non-text part of the TRON ad is a tiny and illegible fragment of the image".
The photographic content, is still prominent and visible in some detail, particularly when the user is being directed to look specifically at the advert and clicks on it to zoom in.
Whether or not the inclusion of a trademark is acceptable here is a red herring. I agree that it's probably fine, but we were discussing copyright-related issues, not trademarks, and those are two separate things.
Whether the inclusion of copyrighted material is de minimis is a characteristic of the image itself only. It cannot depend on its use. So, this is either de minimis or not de minimis and there is nothing in between. You are basically arguing that this image is not de minimis and must be deleted from commons because the advertisement is so large that it may be useful in itself. Ruslik_Zero 20:33, 23 December 2025 (UTC)
When I read the Commons project page on de minimis, the impression that I get is that de minimis can also depend on how a work is being used. Is that incorrect? jlwoodwa (talk) 23:33, 23 December 2025 (UTC)
The context is different. Commons has to take into account the law in all countries - not only in countries such as the UK, where the way the work is used can be relevant - but in Civil law countries where de minimis doesn’t formally exist but courts can reach similar decisions via a different route. That page (full disclosure - that I wrote nearly two decades ago) is a statement of policy about images that are allowed to be hosted on Commons. You shouldn’t read it as an encyclopaedia article about the law. In any event, much of that background does not apply here on Wikipedia which uses US law exclusively. MichaelMaggs (talk) 08:02, 24 December 2025 (UTC)
In this case s:Ets-Hokin_v._Skyy_Spirits,_Inc. is relevant. The image of the bottle as a whole does not infringe copyright of the label. This is very to the bus with advertisement. Ruslik_Zero 20:23, 24 December 2025 (UTC)
Comment: Would vastly prefer this as well... GeogSage (⚔Chat?⚔) 23:25, 3 December 2025 (UTC)
,_Alexander_Dennis_Enviro400,_Route_101_to_Maidstone,_with_TRON_Ares_advertisement,_Chatham_Bus_Station,_Railway_Street,_2_October_2025.jpg){kind=link}