Wikipedia:Village pump (proposals)#rfc 30B8119

With the implementation of Module:Person date, all |birth_date= and |death_date= values in Infoboxes (except for deities and fictional characters) are now parsed and age automatically calculated when possible.

With this implementation, it was found that there are a large number of cases (currently 4537) where the birth/death date is set to Unk, Unknown, ? or ##?? (such as 19??). Full disclosure, Module:Person date was created by me and because of an issue early on I added a number of instances of |death_date=Unknown in articles a few weeks ago. (I had not yet been informed about the MOS I link to below, that's my bad).

Per MOS:INFOBOX: If a parameter is not applicable, or no information is available, it should be left blank, and the template coded to selectively hide information or provide default values for parameters that are not defined..

There is also the essay WP:UNKNOWN which says, in short, Don't say something is unknown just because you don't know.

So the question is what to do about these values? Currently Module:Person date is simply tracking them and placing those pages in Category:Pages with invalid birth or death dates (4,537). It has been growing by the minute since I added that tracking. Now I am NOT proposing that this sort of tracking be done for every parameter in every infobox... There are plenty of cases of |some_param=Unknown, but with this module we have a unique opportunity to address one of them.

I tried to find a good case where the |death_date= truly is Unknown, but all the cases I could think of use |disappeared_date= instead. (See Amelia Earhart for example).

The way I see it there are a few options

• Option A - Essentially do nothing. Keep the tracking category but make no actual changes to the pages.
• Option B - Implement a {{preview warning}} that would say This value "VALUE" is invalid per MOS:INFOBOX & WP:UNKNOWN. (Obviously open to suggestions on better language).
• Option C - Take B one step further and actually suppress the value. Display a preview warning that says This value "VALUE" is invalid per MOS:INFOBOX & WP:UNKNOWN. It will not be displayed when saved. then display nothing on the page. In other words treat |death_date=Unknown the same as |death_date=. (Again open to suggestions on better language for the preview warning).
• Option D - Some other solution, please explain.

Thanks in advance! --Zackmann (^{Talk to me}/_{What I been doing}) 23:43, 21 October 2025 (UTC)[reply]

• We definitely shouldn't be using things like "Unk" or "?" - if we want to say this is not known we should explicitly say "Unknown". Should we ever say "unknown" though? Yes, but for births only when we have reliable sources that explicitly say the date is unknown to a degree that makes values like "circa" or "before" unhelpful - even "early 20th Century" and is more useful imo than "unknown". "Unknown" is better than leaving it blank when we have a known date of birth but no known date of death (e.g. Chick Albion). I'm not sure how this fits into your options. Thryduulf (talk) 00:24, 22 October 2025 (UTC)[reply]

  Agreed. There are cases where no exact date is given but MOS:INFOBOX and WP:UNKNOWN do not apply because the lack of known date can be sourced reliably. If the module cannot account for this, I really think only option A is acceptable. —Rutebega (talk) 18:15, 22 October 2025 (UTC)[reply]

  @Rutebega and Thryduulf: So I can very easily make it so that |..._date=Unknown<ref>... is allowed but just plain |..._date=Unknown is not. That is just a mater of tweaking the regular expression. Not hard at all to do at all. That being said (mostly for curiosity sake) can you give me an example of a page where the lack of known date can be sourced reliably? Every case I could think of (and I really did try to find one) either has a relevant |disappeared_date= (so you don't need to specify that |death_date=Unknown) or you can least provide approximate dates (i.e. {{circa|1910}}, 1620s or 12th century). Zackmann (^{Talk to me}/_{What I been doing}) 18:23, 22 October 2025 (UTC)[reply]

  Metrodora isn't quite date unknown, but the only fixed date we have is the manuscript which preserves her text (c.1100 AD), and her floruit has been variously estimated between the first and sixth centuries AD. Of course, so little is known for certain about Metrodora that every single infobox field would be "unknown" were it filled in, and therefore there's little point having an infobox at all.

  Corinna's dates are disputed: she was traditionally a contemporary of Pindar (thus born late 6th century and active in the fifth century BC) but some modern scholars argue for a third-century date. If the article had an infobox, a case could be made either for listing her floruit as either "unknown", "disputed", "5th–3rd century BC", "before 1st century BC" (the date of the first source to mention her) or simply omit it entirely.

  I'm open to convincing about how these cases should be handled; my inclination is that any historical figure where the date fields alone need this much nuance are probably a bad fit for an infobox, but the size of Category:Pages with invalid birth or death dates suggests that not everybody agrees with me! Caeciliusinhorto-public (talk) 08:56, 23 October 2025 (UTC)[reply]

  @Caeciliusinhorto-public: thanks for some real examples. I think your point that so little is known that Infoboxes don't make sense is a good one... If there were other info that made sense to have in an Infobox I think the dates would still be able to be estimated (even if the range is hundreds of years). You could still put |birth_date=5th-3rd century BC or, of course, just leave it blank! Leaving it blank to me implies that it is Unknown, though it does leave ambiguous whether is it Unknown because no editor has taken the time to figure it out or whether it is Unknown because the person live some 2,200 years ago and we have no real way of knowing when they were born... Zackmann (^{Talk to me}/_{What I been doing}) 09:05, 23 October 2025 (UTC)[reply]

• This is above my pay grade but can you give us an idea of how much "It has been growing by the minute". The scale of those additions may inform our view as to how best to deal with it.Lukewarmbeer (talk) 16:34, 22 October 2025 (UTC)[reply]

  @Lukewarmbeer: so this is mostly a caching issue. I don't think very many new instances of this are being created each day, it just takes a while for the code to propagate. I really don't have an objective way of saying how many new instances are being created daily... Zackmann (^{Talk to me}/_{What I been doing}) 17:13, 22 October 2025 (UTC)[reply]

  FWIW, about 15% of our biographies of living people have unknown birthdates (based on a count by category I did in 2023). I would assume that deceased biographies are perhaps more likely to miss this data, so we're looking at a number in the low hundreds of thousands? Not all of those will have infoboxes, of course. Andrew Gray (talk) 20:39, 22 October 2025 (UTC)[reply]

  @Andrew Gray: when you say have unknown birthdates do you mean "no birthdates are given"? Because that is NOT what we are talking about here... We are talking about |birth_date=Unknown, where someone has specifically stated that the date is Unknown, not just left it blank. Zackmann (^{Talk to me}/_{What I been doing}) 20:42, 22 October 2025 (UTC)[reply]

  @Zackmann08 ah, right - I think I misunderstood, apologies. If the module does nothing when the birthdate field is blank or missing, that sounds good.

  I think the simple tracking category for non-date values sounds fine for now. Andrew Gray (talk) 20:52, 22 October 2025 (UTC)[reply]

• Perhaps the problem is the multiple meanings of "Unknown". Some may have filled it meaning "nobody knows about the early life of this historical guy, only that he became relevant during the X events, already an adult", and others "unknown because I don't know". We may make it so that "Unknown" has the same effect as an empty field, and require a special input for people with truly unknown dates. And note that any biography after whatever point birth and death certificates became ubiquitous should be treated as the second case. Cambalachero (talk) 14:09, 23 October 2025 (UTC)[reply]
• Option D The variant on option C where it's permitted iff there's a citation seems like a good solution to me. By a similar argument to WP:ALWAYSCITELEAD, I think a citation should always be required to assert that someone's date of death is outside the scope of human knowledge. From WP:V we should always cite material that is likely to be challenged, and I think the assertion that someone's date of death is "unknown" falls well within that scope; in particular I myself will always challenge it if unsourced. lp0 on fire () 16:32, 23 October 2025 (UTC)[reply]

  I think whether someone's date of birth or death being unknown falls into the category of material that is likely to be challenged is party a factor of when and where they were born and the time, place and manner of their death and how much we know about them generally. It is not at all surprising to me that we don't know the date of birth or death of a 3rd century saint or 18th century enslaved person, or when a Peruvian athlete who competed in the 1930s died; we do need a citation to say that we only know the approximate date of death for Dennis Ritchie and Gene Hackman. Thryduulf (talk) 16:50, 23 October 2025 (UTC)[reply]

  Do you think the citation always needs to be inside the infobox? Our article about Metrodora has a couple of paragraphs about which century she might have lived in. There's no infobox at the moment, but if we added one, would you insist that the citations be duplicated into the infobox? WhatamIdoing (talk) 18:40, 24 October 2025 (UTC)[reply]

• Option D Allow Unknown but not other abbreviations. Require citations for dates. Rationale: Looking at the Sven Aggesen it’s easy to see that “Unknown” is helpful because it’s communicating that the person is dead. In my opinion it’s still stating a fact. So Unknown should be allowed. “?” Should not. It seems like dates of birth and death should always be cited. Thanks for your work on this!! Dw31415 (talk) 17:54, 23 October 2025 (UTC)[reply]
  • In the case of Sven Aggesen I think we could reasonably expect a reader to infer from "born: 1140? or 1150?" that he is probably dead! In the case of people born recently enough that there might be confusion, I can't imagine there are many cases where both (a) they are known to be dead and (b) their date of death is known so imprecisely that we don't have a more useful value than "unknown" for the infobox. Caeciliusinhorto (talk) 20:35, 23 October 2025 (UTC)[reply]
• Option A - needs more study - The category seems flawed, the concern seems more a flaw in process or concept of the template itself. Looking at a few pretty random clickings from Category:Pages with invalid birth or death dates (4,537) I see that maybe listing them as bad instead is indication that when the context is historical or a short stubby article, it just should not expect modern and detailed precision. And that there was at least one simply a typo to remind me articles are imperfect.

• Carlos Altés 3 Sept 1907 to unknown -- there obviously is a death, but that the death date is unknown is perhaps a correct statement of fact.
• Georgios Anitsas born 1891, died unknown -- well it's a stub article about a 1924 Olympics shooter based on two sports cites.
• Æthelbald of Mercia King of Mercia died 757 - the death would be known from the succession, though exact day not so much, and the birth before rising to Kingship even less so.
• Martín de Andújar Cantos born 1602, died unknown - another stub article from one art source
• Vicente Albán born 1725, died unknown - and typo on birthplace "Viceroyalty if New Gramada"
• Po Aih Khang King of Panduranga died 1622, born ? - the death would be known from the succession, though again exact day not so much, and the person is only known from historical chronicles so the birthdate being a question mark seems informal ask for someone who knows to put in ...

In the actual instances: Option B seems a nonstarter since the pages already exist and such a flag seems meaningless; Option C supression seems in many casesw hiding simple fact of what is not known or what is only known to the year without exact day; and Option D ... I don't have a fix for the cases other than to say 'needs more study' and/or 'thingss are about as good as can be done with what is shown so just leave it'. Cheers Markbassett (talk) 19:35, 13 November 2025 (UTC)[reply]

@Markbassett: to really sure how the concept of the template itself is flawed... Again per MOS:INFOBOX and WP:UNKNOWN we should not be putting Unknown in the infobox... Your comments don't really address that... You give a few examples where the date should supposedly be inferred, but don't address the underlying issue here... Zackmann (^{Talk to me}/_{What I been doing}) 19:40, 13 November 2025 (UTC)[reply]

I think it's complicated and depends on context, this RFC was missing too many questions and too many cases to start trying to make a conclusion.

• The simple list of 'Category:Pages with invalid birth or death dates' has many different situations and various templates -- and some of the fields might well be a good usage or the best that can be expected. Needs considerably more study, maybe the category needs to look at things by-template and by-era for example, or maybe separate out those that are from very short articles with less than 4 cites.
• See my remark for Carlos Altés - "that the death date is unknown is perhaps a correct statement of fact."

If the date is not known and not knowable - does that mean the template 'Infobox football biography' was a bad one to use or that the template is incomplete? Per template guidance "Do NOT use this template when the person's exact date of death is disputed or unknown; consider death year and age instead.'

Does this mean that template death year and age needs to add guidance for if year is unknown ? Should date fields have some text values allowed as options to distinguish 'nobody knows' from 'unknown from limited cites' from 'someone please put in a value'?

• I could ask similarly if 'Infobox royalty' date fields should allow simply year-of values or specify some text values as options, because the template Birth date defaults to Birth year and no further, but in just these few examples I'm seeing that centuries-ago kings seem often not knowing the year of birth.

Perhaps the category list is showing a few thousand places of questions more than issues -- if you broke it out by which template is used from Wikipedia:List of infoboxes - Wikipedia it might be reduced to mostly just a few where birth-date is an issue, or perhaps it would emerge that the template birth-year needs a mod. I don't know, but I think nobody knows without considerably more study -- and meanwhile no change. Cheers Markbassett (talk) 20:46, 13 November 2025 (UTC)[reply]

Again Markbassett you have not bothered to read the beginning of this RFC where the following is clearly stated...

Per MOS:INFOBOX: If a parameter is not applicable, or no information is available, it should be left blank, and the template coded to selectively hide information or provide default values for parameters that are not defined..

There is also the essay WP:UNKNOWN which says, in short, Don't say something is unknown just because you don't know.

so on Carlos Altés the |death_date= in the Infobox should be left blank per the MOS... Zackmann (^{Talk to me}/_{What I been doing}) 21:52, 13 November 2025 (UTC)[reply]

Umm, obviously you're making a claim without ability to know, but I did read that -- and then looked further at the unstated and perhaps unseen flaws in Category:Pages with invalid birth or death dates (4,537) by looking at some specific cases in Category:Pages with invalid birth or death dates (4,537) and chased thru a couple of various Infobox templates with a subfield of birth-date etcetera. Though I don't know why the templates count of issues is small when yours is big, I do know that 'it's complicated'. There's a lot of different situations and different infoboxes and maybe the wrong infobox was used or maybe the wrong fill was used or maybe just maybe this is just too superficial and generic a study so far to start trying for conclusions. I didn't propose INVALID RFC, but suggested it needs a deeper look and made a couple suggestions. I am not excluding that perhaps the infoboxes need to address an area that's not going well and edit there -- in which case removing the indication would be a bad thing. Cheers Markbassett (talk) 22:26, 13 November 2025 (UTC)[reply]

• Option D - estimate to a few decades of precision Wikipedia is unusual for broadly covering global human history. Because of this, unusually as compared to other publications, readers browse biographies not even knowing a person's century or country. Consider the American Civil War veteran Francis A. Bishop. Is this person American, born in the 1800s, and male? The article lacks sources to establish such things, but still, this kind of demographic information is important for categorizing people in Wikipedia. If we can determine a person's century of birth then that is helpful, and if we can narrow it to within a few decades then that also is helpful. Placing biographies in time is critical, and even when we lack an explicit source to WP:V the claim, then I favor doing the WP:OR to place this person into visibility in categories and data structures. Bluerasberry (talk) 20:06, 13 November 2025 (UTC)[reply]
• The documentation for Module:person date is really only useful to the person who wrote it. It's very difficult to figure out where this fits in the infobox ecosystem. But my best guess is that it is only invoked if templates such as {{Death date and age}} and {{Birth date}} are used in the infobox. These templates ONLY support dates in the Gregorian calendar. The earliest possible Gregorian date was 15 October 1582. The discussion above makes reference to a number of examples from antiquity. These articles should not be using any of these date templates. I can't see how mentioning these people in this discussion makes sense. Jc3s5h (talk) 20:27, 13 November 2025 (UTC)[reply]

  User:Jc3s5h for the record you can set |birth_date= to ANY value... It has long been prefered that you using a template such as {{birth date and age}} but with the creation of Module:Person date even THAT is no longer necessary for modern, Gregorian calendar dates. The real issue here is what to do with dates that claim to be Unknown. I would argue there is not an example where the date is COMPLETELY unknown. While you may not know the EXACT date, you at least know a decade, or a century the person was alive. You can simply say |birth_date=6th century or |death_date={{circa|610}}... Zackmann (^{Talk to me}/_{What I been doing}) 20:33, 13 November 2025 (UTC)[reply]

I can't understand your reply without a more complete context. If I have the following:

{{Infobox Christian leader
| type = Pope
| birth_date = c. 530
| birth_place = [[Blera]], [[Eastern Roman Empire]]
| death_date = 22 February 606 (aged 75–76)
}}

It would seem to me such an infobox would not invoke Module:Person date and so would not be a suitable example for this discussion. Jc3s5h (talk) 20:49, 13 November 2025 (UTC)[reply]

@Jc3s5h: you are correct, if you use that code you provided, it would NOT Invoke Module:Person date. My point is that if you had |death_date=Unknown I have yet to find a case where that cannot be replaced with SOME information. We may not know the exact date, or even the exact year, but you should be able to replace Unknown with c. 123 or 15th century and thus resolve the problem of it appearing in the category. I have yet to find a page where there is literally NO CLUE about when the person lived, not even a century.

The root of the question is for those pages that DO use Unknown should we display some sort of {{preview warning}} message to editors that essentially says "Hey this isn't a valid value, you need to put SOMETHING (a decade, a century, a 'circa') or (per MOS:INFOBOX) simply leave it blank". This is the goal of Options B & C. Hope that helps... - Zackmann (^{Talk to me}/_{What I been doing}) 21:59, 13 November 2025 (UTC)[reply]

Should the community harmonize the rules that govern community-designated contentious topics (which are general sanctions authorized by the community) with WP:CTOP? If so, how? 19:55, 22 October 2025 (UTC)

Before 2022, the contentious topics process (CTOP) was instead known as "discretionary sanctions" (DS). Discretionary sanctions were authorized in a number of topic areas, first by the Arbitration Committee and then by the community (under its general sanctions authority).

In 2022, ArbCom made a number of significant changes to the DS process, including by renaming it to contentious topics and by changing the set of sanctions that can be issued, awareness requirements, and other procedural requirements (see WP:CTVSDS for a comparison). But because the community's general sanctions are independent of ArbCom, these changes did not automatically apply to community-authorized discretionary sanctions enacted before that date.^[a]

In an April 2024 RfC, the community decided that there should be clarity and consistency regarding general sanctions language and decided to rename community-authorized discretionary sanctions to "contentious topics". However, the community did not reach consensus on several implementation details, most prominently whether the enforcement of community CTOPs should occur at the arbitration enforcement noticeboard (AE) instead of the administrators' noticeboard (AN), as is now allowed (but not required) by ArbCom's contentious topics procedure.^[b]

Because of the lack of consensus, no changes were made to the community-designated contentious topics other than the naming. As a result, there currently exist 24 ArbCom-designated contentious topics and 7 community-designated contentious topics, and the rules between the two systems differ as documented primarily at WP:OLDDS.

• Question 1: Should the community align the rules that currently apply in community-designated contentious topics with WP:CTOP, mutatis mutandis (making the necessary changes) for their community-designated nature?
• Question 2: Should the community authorize enforcement of community contentious topics at AE (in addition to AN, where appeals and enforcement requests currently go)?

• If questions 1 and 2 both pass, the text at Wikipedia:Contentious topics (community-designated)/Proposal with AE would be adopted as an information page.
• If question 1 passes and question 2 fails, the text at Wikipedia:Contentious topics (community-designated)/Proposal without AE would be adopted as an information page.

In either case above, all existing community CTOPs would be amended by linking to the new information page to document the applicable provisions.

If question 1 fails, no changes would be made.

1. Use Arbitration Enforcement Log (WP:AELOG)
2. Create a new page such as Wikipedia:Contentious topics/Log which can be separated into two sections, one for community, and one that transcludes WP:AELOG
3. Create a new page such as Wikipedia:General sanctions/Log which would only log enforcement actions for community contentious topics (subpages would be years)
4. Continue logging at each relevant page describing the community contentious topics (Wikipedia:General sanctions/Topic area), and if 2 or 3 are chosen, the page would transclude these relevant pages.

— Preceding unsigned comment added by Awesome Aasim (talk • contribs) 20:42, 22 October 2025 (UTC)[reply]

• 2+3+4 as proposer, one of the problems I do notice is that loading WP:AELOG does take a lot of time because the page has a lot of enforcement actions. The advantage of 2 is having a single page that can be quickly searched. Aasim (話す（はなす）) 20:42, 22 October 2025 (UTC)[reply]

  BTW except for 1 the other options are mutually exclusive. If option 1 is chosen, options 2-4 are irrelevant. I am not asking people to pick one and be done, people can choose any combination. Aasim (話す（はなす）) 21:32, 23 October 2025 (UTC)[reply]

• 2 > 1 – Both ArbCom and community CT are forms of general sanctions (see my incomplete essay on the subject); the only distinction is who authorises them. For this reason, '3' does not make sense. Eliminating the sprawling log pages that currently exist for community-authorised regimes should be a priority if our goal is to eliminate red tape, therefore '4' does not make sense either. That leaves me with 2, which allows for a centralised log for both forms of sanctions. I am perfectly fine with creating subpages as needed, but centralisation is paramount in my mind. Yours, &c. RGloucester — ☎ 00:02, 23 October 2025 (UTC)[reply]
• I support option 4. I think it continues to make sense to log individual actions for a given topic area to the corresponding subpage of Wikipedia:General sanctions. isaacl (talk) 01:12, 23 October 2025 (UTC)[reply]

  In the past, there have been concerns raised about it being clear if the enacting authority is the arbitration committee or the community. Thus I do not feel option 1 is the best choice.

  Regarding searching: I feel the typical use case is to search for actions performed within a specific topic area. If necessary, Wikipedia search with a page prefix criterion can be used to search multiple subpages. isaacl (talk) 16:19, 23 October 2025 (UTC)[reply]

  I will note that having the logpages as subpages of Wikipedia:General sanctions (rather than a more tailored page) makes searchability much harder, which is why scripts like WP:SUPERLINKS don't surface community CTOP enforcement entries even though it does surface WP:AELOG entries. Best, KevinL (aka L235 · t · c) 16:21, 23 October 2025 (UTC)[reply]

• 2 I am in favor of fewer, larger pages because they are easier to find and to search. If a searcher needs to confirm that something isn't there, for example, fewer pages, even if very large, are much easier to work with. Darkfrog24 (talk) 13:33, 23 October 2025 (UTC)[reply]
• 1 - in keeping with the spirit for Q1 and Q2, the whole point here is to merge everything into a single system that is simpler to follow. We already have a practice of splitting off subpages when specific sections in the log get too large. _signed, Rosguill ^talk 13:52, 23 October 2025 (UTC)[reply]
• 2 as a first choice, as centralization is helpful, but the current WP:AELOG is ultimately an ArbCom page and shouldn't have jurisdiction over community sanctions. I agree with Rosguill's point about splitting off subpages, and I presume this would be encouraged to a greater extent here. I could also be convinced by 1 (to avoid an unnecessary transclusion, although it should be made clear that it isn't an ArbCom-only page anymore) or by a temporary 3 (to avoid a lag spike until the main subpages are sorted out). Chaotic Enby (talk · contribs) 17:04, 23 October 2025 (UTC)[reply]

  Actually, I'm realizing that 2 doesn't help with centralization compared to 3, and creates a bit of an inconsistency between some topics being directly logged there and others being transcluded. Count 3 as my first choice, with the possibility of a combined log transcluding both for reference. Chaotic Enby (talk · contribs) 19:34, 23 October 2025 (UTC)[reply]

• 1 > 3 > 4, but my actual preference is to delegate this to a local consensus of those who are involved in implementing this. 1 is my preference, like Rosguill, because centralizing where the existing logs live promotes simplicity and would avoid the need for admins to check which types of CTOPs are which (one goal I have is for the community CTOPs and ArbCom CTOPs to feel almost identical). Not to mention, it would preserve compatibility with tools like WP:SUPERLINKS that check AELOG but not other pages. The biggest hurdle in my mind is that #1 would require ArbCom approval, which I think is likely but not certain (given that ArbCom allows AE for community CTOPS, why not AELOG?). Best, KevinL (aka L235 · t · c) 19:29, 23 October 2025 (UTC)[reply]
• 3, but there is a nuance: inclulde the recently-changed bit about protections being automatically logged, as part of a unified page at Wikipedia:Arbitration enforcement log/Protections. Protections for the "overlapping" CT/GS regions (A-A and KURD) are already logged there (as, technically, they fall under both) so this would make, and keep, things simple. - The Bushranger _{One ping only} 20:04, 23 October 2025 (UTC)[reply]
• 5 There should be one system, not two. As noted above, the community is too amorphous and uncertain to be the basis for this. Andrew🐉(talk) 17:28, 25 October 2025 (UTC)[reply]
• 1 > 2 These should be standardized as much as possible. It's already the most confusing and obfuscated system of policies on Wikipedia; we should strive to eliminate as much confusion and pointless red tape as possible. Apart from where actions are logged, there are now pretty much no practical differences between ArbCom and community CTOPs: they are imposed by different bodies, enforced identically, and logged in different places. I agree with others that these systems should feel identical; this would have the additional advantage of making Aquillion's vague long-term proposal, to have old ArbCom topics "expire" into community ones if deemed no longer pertinent, seem like a realistic option. lp0 on fire () 22:49, 10 November 2025 (UTC)[reply]

• Comment I understand the functional difference between an AE sanction and AN sanction is that an AE sanction can be removed only by a) the exact same admin who placed it, called the "enforcing admin" or b) a clearly-more-than-half balance of AE admins at an AE appeal while a sanction placed at AN can be removed by c) any sufficiently convinved admin acting alone. To give an example of how this would change things, I found myself in a situation in which I was indefinitely blocked at AE and then the enforcing admin left Wikipedia, which removed one of my options for lifting a sanction. Some of our fellow Wikipedians will think making it easier to get a sanction lifted is a good thing and others will think it's a bad thing, but we should be clear about that so we can all make our decision. Am I correct about how these changes would affect those seeking to have sanctions removed? Darkfrog24 (talk) 13:31, 23 October 2025 (UTC)[reply]

  @Darkfrog24: I think this is incorrect. As it stands now, restrictions imposed under community CTOPs are only appealable to the enforcing administrator or to AN (see, e.g., WP:GS/Crypto, which says Sanctions imposed may be appealed to the imposing administrator or at the appropriate administrators' noticeboard.). Q1 is about aligning the more subtle but still important differences between community CTOPs and ArbCom CTOPs, while Q2 is about adding AE as a place (but not changing the substantive amount of agreement needed) for enforcement requests and appeals. Best, KevinL (aka L235 · t · c) 13:43, 23 October 2025 (UTC)[reply]

  Thanks, KevinL. I will ponder this and make my decision. Darkfrog24 (talk) 13:50, 23 October 2025 (UTC)[reply]

• Comment: Is there any way that we could implement the semi-automated logging process that is used for page protection of CTOPS here? Is there any expectation that if any of these options were chosen, that process would revert to manual? ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 18:17, 23 October 2025 (UTC)[reply]

  Pinging @L235 whose bot is in charge of that – for the Twinkle integration of the CTOP logging, I'm currently working on a pull request that would work for both. Chaotic Enby (talk · contribs) 19:08, 23 October 2025 (UTC)[reply]

  I bet the bot could be adapted to whichever option the community opts for! KevinL (aka L235 · t · c) 19:24, 23 October 2025 (UTC)[reply]

• Comment – If we are to create a seperate log for community-authorised contentious topics as in alternative 3, it should not be subpage of Wikipedia:General sanctions. 'General sanctions' is a broad category that includes ArbCom sanctions, and also non-contentious topics remedies such as the extended confirmed restriction. This is a recipe for confusion. Please consider an alternative naming scheme. Yours, &c. RGloucester — ☎ 00:19, 24 October 2025 (UTC)[reply]

  The title can always be different. The title I named was just an example title to explain the purpose of the question. Aasim (話す（はなす）) 01:30, 24 October 2025 (UTC)[reply]

• Given this has now passed (aside from the nitty-gritty of logging), does this mean community GSes imposing ECR now conform to Wikipedia:Arbitration Committee/Procedures#Extended confirmed restriction, specifically the portion about Non-extended-confirmed editors may use the "Talk:" namespace only to make edit requests related to articles within the topic area, provided they are not disruptive? Because the fact that, at least previously, that did not apply to community-imposed GSes has tripped me up in the past. - The Bushranger _{One ping only} 23:32, 4 November 2025 (UTC)[reply]

The extended confirmed restriction is a separate kind of general sanction, not part of contentious topics. Nothing in this discussion should apply to community-imposed extended confirmed restrictions. Yours, &c. RGloucester — ☎ 23:39, 4 November 2025 (UTC)[reply]

Should the following be added to the 'Immediate failures' section of the good article criteria?

6. It contains obvious evidence of LLM use, such as AI-generated references or remnants of AI prompt.

Proposed after discussion at Wikipedia talk:Good articles#AI. Yours, &c. RGloucester — ☎ 10:08, 26 October 2025 (UTC)[reply]

• Support – Articles that contain obvious evidence of unreviewed AI use are evidence of a competence issue on the part of their creator that is not compatible with the GA process. Having reviewers perform a spot check for obvious signs of AI use will help militate against the recent problem whereby AI-generated articles are being promoted to GA status without sufficient review. Yours, &c. RGloucester — ☎ 10:08, 26 October 2025 (UTC)[reply]
• Support. Hardly needs saying. The use of AI is fundamentally contrary to the process of encyclopaedic writing. AndyTheGrump (talk) 10:14, 26 October 2025 (UTC)[reply]

  Strong Support: No article of real quality would ever have any signs of AI use easy to see. CabinetCavers (talk) 20:10, 10 November 2025 (UTC)[reply]

• Support This is an excellent proposal to help stop Wikipedia falling into absolute disrepute Billsmith60 (talk) 10:21, 26 October 2025 (UTC)[reply]
• Support Billsmith60 (talk) 10:22, 26 October 2025 (UTC)[reply]

  Billsmith60, presumably you didn't mean to enter two supports? Mike Christie (talk - contribs - library) 12:41, 26 October 2025 (UTC)[reply]

  Sorry about that Mike. Was on my phone for this and it is always temperamental Billsmith60 (talk) 01:02, 27 October 2025 (UTC)[reply]

• Support Per nomination. This would not prohibit AI use per se, but would rule out promoting any low effort usage of AI. AI use in this manner could be argued to be a failure of GA criteria 1 and 2 as well, but explicitly stating as such will give a bit more weight to reviewers' decisions. --Grnrchst (talk) 10:45, 26 October 2025 (UTC)[reply]
• Oppose Per comment in discussion. Rollinginhisgrave (talk | contributions) 10:47, 26 October 2025 (UTC)[reply]
• Support Per nom. Vacant0 (talk • contribs) 10:54, 26 October 2025 (UTC)[reply]
• Oppose per comment in discussion IAWW (talk) 11:05, 26 October 2025 (UTC)[reply]
• Oppose. GAs should pass or fail based only and strictly only on the quality of the article. If there are AI-generated references then they either support the article text or they don't, if they don't then the article already fails criteria 2 and the proposal is redundant. If the reference does verify the text it supports then there is no problem. If there are left-over prompts then it already fails criteria 1 and so this proposal is redundant. If the AI-generated text is a copyright violation, then it's already an immediate failure and so the proposal is redundant. If the generated text is rambly, non-neutral, veers off topic, or similar issues then it already fails one or more criteria and so this proposal is redundant. Thryduulf (talk) 12:20, 26 October 2025 (UTC)[reply]

  As I see it, this proposal as-written is actually quite limited in scope and is not doing anything beyond saving resources. Obvious unreviewed AI use will not meet all criteria, but at the moment a reviewer of the GAN is still expected to do a full review. This proposal if passed would effectively codify that obvious AI is considered (by consensus of users of the GA process) to mean the article has insurmountable issues in its current state and should be worked on first before a full review. Kingsif (talk) 14:07, 26 October 2025 (UTC)[reply]

• Support, we can't afford wasting precious reviewer time (a very scarce resource) on stuff with fake references. —Kusma (talk) 12:29, 26 October 2025 (UTC)[reply]

  If there are fake references then it's already a fail for verifiability. This proposal does not save any additional reviewer time. Thryduulf (talk) 12:42, 26 October 2025 (UTC)[reply]

  It turns a fail into a quick fail, which of course saves reviewer time. —Kusma (talk) 12:49, 26 October 2025 (UTC)[reply]

  See my comment below in the discussion section. Thryduulf (talk) 12:57, 26 October 2025 (UTC)[reply]

• Oppose per IAWW and Thryduulf. All issues arising from AI use are already covered by other criteria, and there are legitimate uses of AI, which should not be prohibited. Kovcszaln6 (talk) 12:33, 26 October 2025 (UTC)[reply]
• Oppose. I sympathize with the intent of this RfC but it's the state of the article, not the process by which it got there, that GA criteria should address. Mike Christie (talk - contribs - library) 12:39, 26 October 2025 (UTC)[reply]
• Oppose. I agree with this in spirit, but I don't think it would be a useful addition. If a reviewer spots blatant and problematic AI usage (e.g. AI-generated references), almost all would quickfail the article immediately anyway. I can't imagine this proposal saving any additional reviewer time or reducing the handful of flawed articles that slip through that process. But if a nominator used AI for something entirely unproblematic and left an edit summary saying something like "used ChatGPT to change table formatting" or "fixed typos identified by ChatGPT", that would be obvious evidence of LLM usage and yet clearly doesn’t warrant a quickfail. MCE89 (talk) 12:52, 26 October 2025 (UTC)[reply]

  Hmm, if “content” was in the proposed text somewhere, would that assuage your legitimate use thoughts? Kingsif (talk) 14:15, 26 October 2025 (UTC)[reply]

  I think that would be slightly better, but I still don't really see what actual problem this proposal is trying to solve. If an article consists of unreviewed or obviously problematic LLM output and contains things like fake references, reviewers aren't going to hesitate to quickfail it (and potentially G15 it) already. I don't see any signs that GAN is currently overwhelmed by AI-generated articles that reviewers just don't have the tools to deal with. And given that lack of a clear benefit, I'm more worried about the potential for endless arguments about process rather than content in the marginal cases (e.g. Can an article be quickfailed if the creator discloses that they used ChatGPT to help copyedit? What if they say they've manually verified and rewritten the LLM output? What is the burden of proof to say that LLM usage is "obvious", e.g. could I quickfail an article solely based on GPTZero?) MCE89 (talk) 15:11, 26 October 2025 (UTC)[reply]

  About the problems, I have a lot of thoughts and happy to discuss, perhaps we should move it to the section below? I also assume and hope people take obvious to mean obvious: if it’s marginal, it’s not obvious. Genuine text/code leftovers from copypasting LLM output is obvious, having to ask a different AI isn’t. Kingsif (talk) 15:29, 26 October 2025 (UTC)[reply]

• Oppose largely per Thryydulf, except that I don't believe that AI content necessarily violates criterion 1. AI style is often recognisable but if it's well-written then I wouldn't care and we should investigate if the sources were not hallucinated. Fake references (as opposed to incomplete/obscure/not readily available references) should be an instafail reason. Szmenderowiecki (talk) 13:13, 26 October 2025 (UTC)[reply]
• Support Per my comments in discussion and here. I also see no objection that couldn’t be quelled by the proposed text already having the qualifier “obvious”: the proposal includes benefit of the doubt, even if I personally would take it much further. Kingsif (talk) 14:12, 26 October 2025 (UTC)[reply]
• Support per Kingsif and following the spirit of the guidance contained in WP:HATGPT and adjacently WP:G15. —Fortuna, imperatrix 14:36, 26 October 2025 (UTC)[reply]
• Support. On a volunteer-led project, it is an insult to expect a reviewer to engage with the extruded output of a syntax generator and not the work of a human volunteer. I am not interested in debating this; please don't ping me to explain that I'm being a Luddite in holding this view. ♠PMC♠ (talk) 14:52, 26 October 2025 (UTC)[reply]
• Oppose per MCE89. LLM use isn't necessarily problematic (even if it often is), and the proposed wording would discourage people from disclosing LLM use in their edit summaries. Anne drew (talk · contribs) 15:28, 26 October 2025 (UTC)[reply]
• Weak support -- Did not realize this discussion had been ongoing, I noped out because I was frankly way too exhausted to sisypheanly re-explain things I had already tried to explain. Anyway, I don't object to these criteria per se but this is a really low bar. What I would really support is mandatory disclosure of any AI use, because if AI was used then the spot-checking that is required in GA review is not going to be nearly enough. Nor is the problem really fake sources anymore, the problem is "interpretations" of sources that might not seem worth checking if you don't know what AI text sounds like, but if you do know what AI text sounds like, are huge blaring alarms that the text is probably wrong. Here's an example (albeit for a Featured Article and not a Good Article). All the sources were real, but the text describing the sources was fabricated. And it took me about 15 minutes to zero in on the references that were likely to have issues because I know how LLMs word things; without AI disclosure, reviewers are likely to spot-check the wrong things (as happened here). Gnomingstuff (talk) 17:34, 26 October 2025 (UTC)[reply]
• Weak oppose While I fully agree with the intent of this proposal, in practice I am concerned that this is subject to misuse by labeling anything as "AI". I agree with Thryduulf and others that any sort of poorly done AI use (which is almost all of it) will already be failable per the existing GA criteria. I share others' concern about the proliferation of AI generated articles and reviews but I'm not convinced this is the solution. Trainsandotherthings (talk) 18:37, 26 October 2025 (UTC)[reply]
• Weak oppose per my comments at WT:GAN. I also agree that LLM-generated articles are problematic, but the existing criteria already cover most of what's proposed - for instance, evidence of persistent failed verification is a valid reason to quickfail already. I'm concerned that a reviewer would use an LLM detector to check an article, the detector incorrectly says that the article is AI, and the reviewer fails based on that basis. AI detectors are notoriously unreliable - you can run a really old document, like the United States Declaration of Independence, through an AI detector to see what I'm talking about. (Edit - I would support changing WP:GACR criterion 3 - It has, or needs, cleanup banners that are unquestionably still valid. These include {{cleanup}}, {{POV}}, {{unreferenced}} or large numbers of {{citation needed}}, {{clarify}}, or similar tags  - to list {{AI-generated}} as an example of a template that would merit a quickfail, since AI articles can already be quickfailed under that criterion. 13:01, 27 October 2025 (UTC)) Epicgenius (talk) 20:18, 26 October 2025 (UTC)[reply]

  Wrong. I don't use AI detectors, but the best ones achieve ~99% accuracy. The Declaration of Independence is one of the worst possible counterexamples -- no shit, a famous English-language public domain text is all over the training data? Gnomingstuff (talk) 02:24, 27 October 2025 (UTC)[reply]

  They have high numbers of both false positives and false negatives. See, for instance, this study: Looking at the GPT 3.5 results, the OpenAI Classifier displayed the highest sensitivity, with a score of 100%, implying that it correctly identified all AI-generated content. However, its specificity and NPV were the lowest, at 0%, indicating a limitation in correctly identifying human-generated content and giving pessimistic predictions when it was genuinely human-generated. GPTZero exhibited a balanced performance, with a sensitivity of 93% and specificity of 80%, while Writer and Copyleaks struggled with sensitivity. The results for GPT 4 were generally lower, with Copyleaks having the highest sensitivity, 93%, and CrossPlag maintaining 100% specificity. The OpenAI Classifier demonstrated substantial sensitivity and NPV but no specificity.

  The link you provided says annotators who frequently use LLMs for writing tasks excel at detecting AI-generated text. This is about human writers detecting AI, not AI detectors detecting AI. That is not what I am talking about. Other studies like this one state that human reviewers have significant numbers of false positives and false negatives when detecting AI: In Gao et al.’s study, blind human reviewers correctly identified 68% of the AI-generated abstracts as generated and 86% of the original abstracts as genuine. However, they misclassified 32% of generated abstracts as real and 14% of original abstracts as generated. – Epicgenius (talk) 02:57, 27 October 2025 (UTC)[reply]

  The study also contains a chart comparing the performance of automatic AI detectors such as Pangram, GPTZero, and Binoculars. As you would have noticed if you read it fully. Gnomingstuff (talk) 16:03, 27 October 2025 (UTC)[reply]

  If you'd read to the conclusion you'd see While AI-output detectors may serve as supplementary tools in peer review or abstract evaluation, they often misclassify texts and require improvement. The limitations section also notes that paraphrasing the AI output significantly decreases the detection rate. This clearly indicates they are not fit for the purpose they would be used for here - especially when the false positive rate is sometimes over 30%. We absolutely cannot afford to tell a third of users that their submission was rejected because they used AI when they didn't actually use AI. Thryduulf (talk) 17:42, 27 October 2025 (UTC)[reply]

  Seconding what Thryduulf said. I've said my piece, though, so I won't belabor it any further. – Epicgenius (talk) 01:38, 28 October 2025 (UTC)[reply]

• Support It's not fair to submit GA checkers to the noxious task of checking everything in a long detailed article for AI problems. Even without a rule, if you see evidence of AI, say so in the review, that everyone can see, the AI rabbit hole has been found. Nobody is obligated to go down that warren, note it and pass it by. Heck make some warning templates or essays, so future reviewers understand their obligation. It should take 10+ hours to correctly verify an AI article, requires reading all sources and understanding topic in depth. -- GreenC 20:52, 26 October 2025 (UTC)[reply]

  It's not fair to submit GA checkers to the noxious task of checking everything in a long detailed article for AI problems they don't have to at the moment. If there are problems the review is already failed regardless of whether or not the problems result from AI use. If there are no problems then whether AI was used is irrelevant. Thryduulf (talk) 20:57, 26 October 2025 (UTC)[reply]

  Also, I should note that if a reviewer finds so many issues that the article requires 10+ hours to fix, it is already acceptable to quickfail based on these other issues. GA is supposed to be a lightweight process; reviewers already can fail articles if they find things like failed verification or issues needing maintenance banners, and determine that the issues can't be reasonably fixed within a week or so. The proposed GA criterion is well-intentioned, but I think focusing on the means of writing the articles, rather than the ends, is not the correct way to go about it. Epicgenius (talk) 22:40, 26 October 2025 (UTC)[reply]

  With AI you don't even know errors exist. It took me 7 days once to find all the problems in an AI generated article. Turned out to have a reasonable sounding but nationalistic-bent supported by errors of omission. How do you know this without research on the topic? This is why so many are against AI, it's incredibly difficult to debug. Normally a nationalistic writer is easy to spot, but AI is such a good liar, not even the operators realize what it is doing. Not to say AI is impossible to use correctly, with a skilled, disciplined, and intellectually honest operator. — GreenC 23:41, 26 October 2025 (UTC)[reply]

  I agree, and based on some known AI model biases, any controversial topic (designated or just by common sense) should probably have AI use banned completely. Kingsif (talk) 23:50, 26 October 2025 (UTC)[reply]

  I do see, and agree with, the point that you would have to very carefully examine all claims in an article that is suspected of containing AI content. However, WP:GAQF criterion 3 (It has, or needs, cleanup banners that are unquestionably still valid. These include {{cleanup}}, {{POV}}, {{unreferenced}} or large numbers of {{citation needed}}, {{clarify}}, or similar tags ) already covers this. If an article is suspected of containing AI, and thus deserves (or has) {{AI-generated}}, it is already eligible for a quick fail under QF criterion 3. – Epicgenius (talk) 02:53, 27 October 2025 (UTC)[reply]

  Epicgenius, yeah that sounds right. Maybe somewhere in the GA rules there could be a reminder about adding {{AI-generated}} if AI is discovered during the vetting process. Then QF#3 takes effect. — GreenC 06:27, 27 October 2025 (UTC)[reply]

  That's fair, and I can agree with adding it to QF#3. – Epicgenius (talk) 13:02, 27 October 2025 (UTC)[reply]

• Weak oppose while i am against use of AI in GA and the GANR process I think this is a somewhat misguided proposal as it covers things that would already fall under quick fail criteria and does not actually identify the scope of the issues (i.e what is considered obvious evidence of AI use?). I would be able to support a non-redundant and more detailed proposal but it would need to be more fleshed out than this. IntentionallyDense ^(Contribs) 02:18, 27 October 2025 (UTC)[reply]

  The proposal clearly identifies 'obvious evidence of AI use' as AI-generated references, such as those that can be detected by Headbomb's script, and remnants of AI prompt. Yours, &c. RGloucester — ☎ 04:03, 27 October 2025 (UTC)[reply]

  So you want people to quick-fail a nomination on the basis of @Headbomb's script, about which the documentation for the script says it "is not necessarily an issue ("AI, find me 10 reliable sources about Pakistani painter Sadequain Naqqash")". That sounds like a bad idea to me. WhatamIdoing (talk) 06:20, 27 October 2025 (UTC)[reply]

  I think I have made my stance on LLM use in relation to good articles very clear. You are free to object as you see fit. Yours, &c. RGloucester — ☎ 07:12, 27 October 2025 (UTC)[reply]

  your wording says 6. It contains obvious evidence of LLM use, such as AI-generated references or remnants of AI prompt. this tells me that you can’t have AI prompts in your writing and no AI generated references. Okay… so both of those would be covered by the current criteria. It didn’t mean took the headbomb script. And I definitely would not support any quickfail criteria that relies on a used script especially when the script states “ This is not a tool to be mindlessly used.” also on what basis of HB script are we quick failing?

  The current proposal tells me nothing about what is considered suspicious for AI usage outside of the current existing quick fail criteria. It gives me no guidance as a reviewer as to what may be AI unless it is blatantly obvious. IntentionallyDense ^(Contribs) 13:18, 27 October 2025 (UTC)[reply]

  WP:AISIGNS is a good start. Gnomingstuff (talk) 20:15, 28 October 2025 (UTC)[reply]

  I agree, we do have some pretty solid parameters around what is a red flag for AI but I believe any proposal around policy/guidelines for AI needs to incorporate those and lay out what that looks like before we take action on it. I would just like an open conversation on what editors think signs of AI use are, and what we can gain some consensus around regarding indications of AI, then it will be a lot easier to implement policy on how to deal with those indications.

  My main issue with this proposal is that it completely skipped that first step of gaining consensus about what the scope of the problem is and jumped to implementing measures to resolve said problem that we have not properly reached consensus on. IntentionallyDense ^(Contribs) 20:26, 28 October 2025 (UTC)[reply]

• Oppose. If a GAN is poorly written, it fails the first criterion. If references are made up, it fails the second criterion. If the associated prose does not conform with the references, then it fails the second criterion. We shouldn't be adding redundant instructions to the good article criteria. I don't want new reviewers to be further intimidated by a long set of instructions. Steelkamp (talk) 04:53, 27 October 2025 (UTC)[reply]
• Oppose, as I pointed in other discussions, and many already pointed here, GA criteria should be focused on the result, not the process. But besides that, I see a high anti-AI sentiment in those discussions and fear that if those proposals are approved, they will be abused. Cambalachero (talk) 13:16, 27 October 2025 (UTC)[reply]
• Support. Playing whack-a-mole with AI is a problematic time sink for good-faith Wikipedia editors because of the disparity in how much time it takes an AI-using editor to make a mess and how much time it takes the good-faith editors to figure it out and clean it up. This is especially problematic in GA where even in the non-AI cases making a review can be very time consuming with little reward. The proposal helps reduce this time disparity and by doing so helps head off AI users from gaming the system and clogging up the nomination queue, already a problem. —David Eppstein (talk) 17:29, 27 October 2025 (UTC)[reply]

  Please rewrite that. By writing "good-faith Wikipedia editors" meaning editors who do not use AI, you are implying that those who do are acting in bad faith. Cambalachero (talk) 17:37, 27 October 2025 (UTC)[reply]

  "Consensus-abiding Wikipedia editors" and "editors who either do not know of or choose to disrespect the emerging consensus against AI content" would be too unwieldy. But I agree that many new editors have not yet understood the community's distaste for AI and are using it in good faith. Many other editors have heard the message but have chosen to disregard it, often while using AI tools to craft discussion contributions that insist falsely that they are not using AI. I suspect that the ones who have reached the stage of editing where they are making GA nominations may skew more towards the latter than the broader set of AI-using editors. AGF means extending an assumption of good faith towards every individual editor unless they clearly demonstrate that assumption to be unwarranted. It does not mean falsely pretending the other kind of editor does not exist, especially in a discussion of policies and procedures intended to head off problematic editing. —David Eppstein (talk) 18:31, 27 October 2025 (UTC)[reply]

• Support. People arguing that any article containing such things would ultimately fail otherwise are missing the point. The point is to make it an instant failure so further time doesn't need to be wasted on it - otherwise, people would argue eg. "oh that trace of a prompt / single hallucinated reference is easily fixed, it doesn't mean the article as a whole isn't well-written or passes WP:V. There, I fixed it, now continue the GA review." One bad sentence or one bad ref isn't normally an instant failure; but in a case where it indicates that the article was poorly-generated via AI, it should be, since it means the entire article must be carefully reviewed and, possibly, rewritten before GA could be a serious consideration. Without that requirement, large amounts of time could be wasted verifying that an article is AI slop. This is especially true because the purpose of existing generative AI is to create stuff that looks plausible at a glance - it will often not be easy to demonstrate that it is a long way from meeting any one of the six good article criteria, wasting editor time and energy digging into material that had little time and effort put into it in the first place. That's not a tenable situation; once there is evidence that an article was badly-generated with AI, the correct procedure is to immediately terminate the GA assessment to avoid wasting further time, and only allow a new one once there is substantial evidence that the problem has been addressed by in-depth examination and improvement. Determining whether an article should pass or fail based only and strictly only on the quality of the article is a laborious, time-intensive process; it is absolutely not appropriate to demand that an article be given that full assessment once there's a credible reason to believe that it's AI slop. That's the entire point of the quickfail criteria - to avoid wasting everyone's time in situations where a particular easily-determined criteria means it is glaringly obvious that the article won't pass. --Aquillion (talk) 19:46, 27 October 2025 (UTC)[reply]

  Bravo, Aquillion! You explained my rationale for this proposal better than I could have done. I am much obliged. Yours, &c. RGloucester — ☎ 23:55, 27 October 2025 (UTC)[reply]

• Support in principle, although perhaps I'd prefer such obvious tells in the same criteria as the copyvio one. Like copyvio, the problems might not be immediately apparent, and like copyvio, the problems can be a headache to fix. Llm problems are possibly even much more of a timesink, checking through and potentially cleaning up llm stuff is not a good use of reviewer time. This QF as proposed will only affect the most blatant signals that llm text was not checked, which has its positives and negatives but worth noting when thinking about the proposal. CMD (talk) 01:34, 28 October 2025 (UTC)[reply]
• Support. Deciding on the accuracy and relevance of every LLM's output is not sustainable on article talkpages or in articles. Sure, it could produce something passable, but there is no way to be sure without unduly wasting reviewer time. They're designed to generate text faster than any human being can produce or review it and designed in such a way as to make fake sources or distorted information seem plausible.--MattMauler (talk) 19:34, 28 October 2025 (UTC)[reply]
• Support: per Aquillion who's reasoning matches my own thoughts exactly. fifteen thousand two hundred twenty four (talk) 21:12, 28 October 2025 (UTC)[reply]
• Support AI is killing our planet (to an even worse extent than other technologies) and we need to strongly discourage its use. JuxtaposedJacob (talk) | :) | he/him | 00:46, 29 October 2025 (UTC)[reply]
• Oppose This proposal is far too broad. This would mean that an article with a single potentially hallucinated reference (that may not have even been added by the nominator) would be quickfailed. Nope. voorts (talk/contributions) 01:19, 29 October 2025 (UTC)[reply]

  If an article has even a single hallucinated reference, it should be quickfailed, as that means the nominator has failed to do the bare minimum of due diligence. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:28, 2 November 2025 (UTC)[reply]

  That's why I said potentially hallucinated. I'm worried this will be interpreted by some broadly and result in real, but hard to find, sources being deemed hallucinated. Also, sometimes editors other than the nominator edit an article in the months between nomination and review. We shouldn't penalize such editors with a quickfail over just one reference that they may not have added. voorts (talk/contributions) 19:34, 2 November 2025 (UTC)[reply]

• Comment Here's a list of editors who have completed a GAN review. voorts (talk/contributions) 01:29, 29 October 2025 (UTC)[reply]

  "Whoever wants to know a thing has no way of doing so except by coming into contact with it, that is, by living (practicing) in its environment. ... If you want knowledge, you must take part in the practice of changing reality. If you want to know the taste of a pear, you must change the pear by eating it yourself.... If you want to know the theory and methods of revolution, you must take part in revolution. All genuine knowledge originates in direct experience." – Mao Zedong

  Editors who have never done a GA review or who have done very few should consider that they may not have adequate knowledge to know what GAN reviewers want/need as tools. It seems to me like a lot of support for this is a gut reaction against any AI/LLM use, and I don't think that's a good way to make rules. voorts (talk/contributions) 15:48, 29 October 2025 (UTC)[reply]

  I like the way you’ve worded this as it is my general concern as well. While I’m not too high up on that list I’ve done 75 ish reviews and have never encountered AI usage. I know it exists and do see it as problem, however I don’t feel it deserves such a hurried reaction to create hard and fast rules. I would much prefer we take the time to properly flesh out a plan to deal with these issues that involves community input from a range of experiences and reviewers on the scope of the problem, how we should deal with it and to what extent. IntentionallyDense ^(Contribs) 20:32, 29 October 2025 (UTC)[reply]

  Yes. Recently, I've noticed a lot of editors rushing to push through new PAGs without much discussion or consideration of the issues beforehand. It's not conducive to good policymaking. voorts (talk/contributions) 20:35, 29 October 2025 (UTC)[reply]

  I echo this sentiment. In my 100+ reviews done in the last year I have only had a few instances where I suspected AI use, and I can't think of any that had deep rooted issues clearly caused by AI. IAWW (talk) 22:10, 29 October 2025 (UTC)[reply]

  This rule would’ve been useful years ago when we had users who really wanted to contribute but couldn’t write well enough, their primitive chat bot text was poor and they were unable to fix it, and keeping a review open to go through everything was the response because they didn’t want to close it and insisted it just needed work. As gen AI use is only increasing, addressing the situation before it gets that bad is a good thing. Kingsif (talk) 19:13, 30 October 2025 (UTC)[reply]

  Cool, but I am easily highest up that list (which doesn’t count the reviews I did before it, or took over after) of everyone in this discussion, so your premise is faulty. Kingsif (talk) 19:07, 30 October 2025 (UTC)[reply]

  I don't think my premise is faulty. I never said everyone who does GAN reviews needs to think the same way, nor do I believe that, and I see that you and other experienced GAN reviewers disagree with me. My point was that editors who have never done one should consider whether they have enough knowledge to make an informed opinion one way or the other. voorts (talk/contributions) 19:12, 30 October 2025 (UTC)[reply]

  While you didn’t speak in absolutes, your premise was based in suggesting the people who disagree with you aren’t aware enough. Besides being wrong, you must know it was unnecessary and rather unseemly to bring it up in the first place: this is a venue for everyone to contribute. Kingsif (talk) 19:19, 30 October 2025 (UTC)[reply]

  That wasn't my premise. I just told you what my premise is and I stand by it. I felt like it needed to be said in this discussion because AI/LLM use is a hot button issue and we should be deliberative about how we handle it on wiki. If editors who have never handled a GAN review want to ignore me, they can. As you said, anyone can participate here. voorts (talk/contributions) 19:51, 30 October 2025 (UTC)[reply]

  Forgive me for disagreeing with your point, then, but I don’t think it even really requires editing experience in general to have an opinion on “should we make people waste time explaining why gen AI content doesn’t get a Good stamp or just let them say it doesn’t” Kingsif (talk) 20:11, 30 October 2025 (UTC)[reply]

  Fair enough. No need to apologize. I'm always open to disagreement. voorts (talk/contributions) 20:39, 30 October 2025 (UTC)[reply]

• Oppose. The proposal lacks clarity in definitions and implementation and the solution is ill-targeted to the problems raised in this and the preceding discussion. Editors have stated that the rationale for new quick fail criteria is to save time. On the other hand, editors have said it takes hours to verify hallucinated references and editors disagree vehemently about the reliability of subjective determinations of AI writing or use of AI detectors. Others have stated that it is already within the reviewer's purview to quick fail an article if they determine that too much time is required to properly vet the article. It is not clear how reviewers will determine that an article meets the proposed AI quick fail criterion, how long this will take, or that a new criterion is needed to fail such articles. Editors disagree about which signs of AI writing are "obvious" and as to whether all obvious examples are problematic. The worst examples would fail, anyway, and seemingly without requiring hours to complete the review so again it is unclear that this new criterion addresses the stated problem. Editors provided examples of articles with problematic, (allegedly) AI-generated content that have passed GA. New quick fail criteria would not address these situations where the reviewer apparently did not find the article problematic while another felt the problems were "obvious". Reviewers who are bad at detecting AI writing or don't verify sources or whatever the underlying deficit is won't invoke the new quick fail criterion and won't stop AI slop from attaining GA status.—Myceteae‍🍄‍🟫 (talk) 01:42, 29 October 2025 (UTC)[reply]
• Support in the strongest possible terms. This is half practical, and half principle: the principle being that LLM/AI has no place on Wikipedia. Yes, there may be some, few, edge-cases where AI is useful on Wikipedia. But one good apple in a barrel of bad apples does not magically make the place that shipped you a barrel of bad apples a good supplier. For people who want a LLM-driven encylopedia, Grokipedia is thataway →. For people who want an encyclopedia actually written by and for human useage, the line must be drawn here. - The Bushranger _{One ping only} 01:53, 29 October 2025 (UTC)[reply]
• Oppose per IntentionallyDense and because detecting AI generation isn't always "obvious", and because the nom's proposed method for detecting LLM use to generate the article's contents will also flag people who use (e.g.) ChatGPT as a web search engine without AI generating even a single word in the whole article article. Also: if you want to make any article look very suspicious, then spam ?utm_source=chatgpt.com at the end of every URL. The "AI detecting" script will light up every source on the page as being suspicious, because it's not actually detecting AI use; it's detecting URLs with some referral codes. I might support adding {{AI generated}} to the list of other QF-worthy tags. WhatamIdoing (talk) 02:09, 29 October 2025 (UTC)[reply]
• Oppose. If it's WP:G15-level, G15 it (no need to quickfail). Otherwise, we shouldn't go down the rabbit hole of unprovable editor behaviour and should focus on the actual quality of the article in front of us. If it has patently non-neutral language or several things fail verification, it can already be quick-failed as being a long way from the criteria. ~ L 🌸 (talk) 07:01, 29 October 2025 (UTC)[reply]
• Oppose per MCE89. If you use an LLM to generate text and then use it as the basis for creating good, properly verified content, who cares? It's not as if a reviewer has to check every single citation — if you find one that's nonexistent, that alone should be sufficient to reject the article. Stating "X is Y"<ref>something</ref>, when "something" doesn't say so or doesn't even exist, is a hoax, and any hoax means that the article is a long way from meeting the "verifiable with no original research" criterion. And if we encounter "low effort usage of AI", that's certainly not going to pass a GA review. And why should something be instantly failed just because you believe that it's LLM-generated? Solidly verifying that something is automatically written — not just a high suspicion, but solidly demonstrating — will take more work than checking some references, and as Whatamidoing notes, it's very difficult to identify LLM usage conclusively; we shouldn't quick-fail otherwise good content just because someone incorrectly thinks that it was automatically written. I understand that LLMs tend to use M-dashes extensively. I've always used them a lot more than the average editor does; this was the case even when I joined Wikipedia 19 years ago, long before LLMs were a problem this way. Nyttend (talk) 10:44, 29 October 2025 (UTC)[reply]
• Support per PMC, David Epstein and Aquillion. A lot of opposes to me look like they are either completely missing the point of a useful practical measure over irrelevant theoretical concerns. I also do find it absolutely insulting to not give reviewers every possible tool to deal with this trash, making them waste precious time and effort to needlessly satisfy another of the existing criteria. Choucas0 🐦‍⬛⋅💬⋅📋 15:25, 29 October 2025 (UTC)[reply]

  I also do find it absolutely insulting to not give reviewers every possible tool to deal with this trash, making them waste precious time and effort to needlessly satisfy another of the existing criteria. I've reviewed a lot of GAs and oppose this because it's vague and a solution in search of a problem. I see that you've completed zero GAN reviews. voorts (talk/contributions) 15:44, 29 October 2025 (UTC)[reply]

  You are entitled to your opinion, but so am I, and I honestly do not see what such a needlessly acrimonious answer is meant to achieve here. The closer will be free to weigh your opposition higher than my support based on experience, but in the meantime that does not entitle you to gate-keep and belittle views you disagree with because you personally judge them illegitimate. Choucas0 🐦‍⬛⋅💬⋅📋 15:58, 29 October 2025 (UTC)[reply]

  You are entitled to your opinion. But when your opinion is based on the fact that something is insulting to a group to which I belong, I am entitled to point out that you're not part of that group and that you're not speaking on my behalf. I don't see how it's acrimonious or gate-keep[ing] or belittl[ing] to point out that fact. voorts (talk/contributions) 16:06, 29 October 2025 (UTC)[reply]

  That is not what my opinion is based on (the first half of my comment pretty clearly is), and I did not mean to speak on anyone's behalf; I apologize if it was not clearer, since it is something that I aim to never do. I consider being exposed to raw LLM output insulting to anyone on this site, so I hope what I meant is clearer now. On another hand, your comment quoting Mao Zedong immediately after your first answer to me clearly shows that you do intend to gate-keep this discussion at large, so you will forgive me for being somewhat skeptical and not engaging further. Choucas0 🐦‍⬛⋅💬⋅📋 16:31, 29 October 2025 (UTC)[reply]

  I'm not sure how pointing out that editors should think before they opine on something with which they have little to no experience is a form of gatekeeping. That's why I didn't say "those editors can't comment" in this discussion. It's a suggestion that people stop and think about whether they actually know enough to have an informed opinion. voorts (talk/contributions) 16:44, 29 October 2025 (UTC)[reply]

• Oppose per LEvalyn. Like WhatamIdoing, I would rather treat {{AI generated}} as reason to quick-fail under GA Criteria 1 and 2. ViridianPenguin🐧 (💬) 15:35, 29 October 2025 (UTC)[reply]

  I've seen a couple people suggest this, and... I don't really get how this is different at all? Anything under the proposed criterion can be tagged as AI-generated already, this would just be adding an extra step. Gnomingstuff (talk) 20:25, 31 October 2025 (UTC)[reply]

• Oppose. If it has remnants of a prompt, that's already WP:G15. If the references are fake, that's already WP:G15. If it's not that bad, further review is needed and it shouldn't be QF'd. If AI-generated articles are being promoted to GA status without sufficient review, that means the reviewer has failed to do their job. Telling them their job is now also to QF articles that have signs of AI use won't help them do their job any better - they already didn't notice it was AI-generated. -- asilvering (talk) 15:56, 29 October 2025 (UTC)[reply]
• Oppose. The article should be judged on its merits and its quality, not the matter or methods of its creation. The judgment should be based only on its quality. Any AI-generated references will fail category 2. If the AI-generated text is a copyright violation, it would be an instant failure as well. We didn't need to write up new rules for things that are forbidden in the first place anyway. Another concern for me is the term "obvious". While there may be universal agreement that some AI slop are obvious AI ("This article is written for your request...", "Here is the article...") some might not be obvious for other people. The use of em-dashes might not be an obvious AI use as some ESL writers might use them as well. The term "obvious" will be vague and it will create problems. Obviously AI slop can be dealt with G15 as well. ✠ SunDawn ✠ Contact me! 02:55, 30 October 2025 (UTC)[reply]
• Support - too much junk at this point to be worthwhile. Readers come here exactly because it is written by people and not Grokipedia garbage. We shouldn't stoop to that level. FunkMonk (talk) 13:38, 30 October 2025 (UTC)[reply]
• Support If there is an obvious trace of LLM use in the article and you are the creator, then you have no business being anywhere near article creation. If you are the nominator, then you have failed to apply a basic level of due diligence. Either way the article will have to be gone over with a fine comb, and should be removed from consideration. --Elmidae (talk · contribs) 13:54, 30 October 2025 (UTC)[reply]
• Support Per nom. LLM-generated text has no place on Wikipedia. The Morrison Man (talk) 13:59, 30 October 2025 (UTC)[reply]
• Support GAN is not just a quality assessment – it also serves as a training ground for editors. LLM use undermines this; using LLMs just will not lead to better editors. As a reviewer, I refrain from reading anything that is potentially AI generated, as it is simply not worth my time. I want to help actual humans with improving their writing; I am not going to pointlessly correct the same LLM mistakes again and again, which is entirely meaningless. LLM use should be banned from Wikipedia entirely. --Jens Lallensack (talk) 15:59, 30 October 2025 (UTC)[reply]
• Oppose. The Venn Diagram crossover of "editors who use LLMs" and "editors who are responsible enough to be trusted to use LLMs responsibly" is incredibly narrow. It would not surprise me if 95% of LLM usage shouldn't merely be quickfailed, but actively rolled back. That said, just because most editors cannot be trusted to use it properly does not mean it is completely off the table - using an LLM to create a table in source given input is fine, say. Additionally, AI accusations can prove a "witch hunt" where just because an editor's writing style includes m-dashes or bold, it gets an AI accusation - even though real textbooks may often also use bolding and m-dashes and everything too! If a problematic LLM article is found, it can still be quick-failed on criterion 1 (if the user wrote LLM-style rather than Wikipedia-style) or criterion 2 (if the user used the LLM for content without triple-verifying everything to real sources they had access to). We don't need a separate criterion for those cases. SnowFire (talk) 18:40, 30 October 2025 (UTC)[reply]
• Oppose – either the issues caused by AI make an article a long way from meeting any one of the six good article criteria, in which case QF1 would apply, or they do not, in which case I believe a full review should be done. With the current state of LLMs, any article in the latter category will be one that a human has put significant work into. Some editors would dislike reviewing these nominations, but others are willing; I think making WP:LLMDISCLOSE mandatory would be a better solution. jlwoodwa (talk) 04:20, 31 October 2025 (UTC)[reply]

  I would also fully support mandatory LLM disclosure IAWW (talk) 08:58, 31 October 2025 (UTC)[reply]

  But wouldn't those reviewers that are possibly willing to review an LLM generated article be primarily those that use LLMs themselves, have more trust in them, and probably even use them for their review? A situation where most LLM-generated GAs are reviewed by LLMs does not sound healthy. --Jens Lallensack (talk) 12:00, 31 October 2025 (UTC)[reply]

  I think that's a stretch. I've used an LLM to create two articles, but wouldn't trust it to review an article against GAN criteria. ScottishFinnishRadish (talk) 12:15, 31 October 2025 (UTC)[reply]

  LLM usage is a scale. It is not as black-and-white as those who use LLMs vs those who don't. I am of the opinion that LLMs should only be used in areas where their error rate is less than humans. In my opinion LLMs pretty much never write adequate articles or reviews, yet they can be used as tools effectively in both. IAWW (talk) 13:22, 31 October 2025 (UTC)[reply]

• Oppose - Redundant. Stikkyy t/c 11:53, 31 October 2025 (UTC)[reply]
• Oppose. GA is about assessing the quality of the article, not about dealing with prejudice toward any individual or individuals. If the article is bad (poorly written, biased, based on rumour rather than fact, with few cites to reliable sources), it doesn't matter who has written it. Equally, if an article is good (well written, balanced, factual, and well cited to reliable sources), it doesn't matter who has written it, nor what aid(s) they used. Lets assess the content not the contributor. SilkTork (talk) 12:15, 31 October 2025 (UTC)[reply]
• Oppose. Focuses too much on the process rather than on the end result. Also, the vagueness of 'obvious' lays the ground for after-the-event arguments on such things as "I already know this editor uses LLMs in the background; the expression 'stands as a ..' appears, and that's an obvious LLM marker". MichaelMaggs (talk) 18:20, 31 October 2025 (UTC)[reply]

  I already know this editor uses LLMs in the background

  How is this not a solid argument? Gnomingstuff (talk) 00:57, 3 November 2025 (UTC)[reply]

• Support per Aquillion. Nikkimaria (talk) 18:50, 1 November 2025 (UTC)[reply]
• Support GA is a mark of quality. If you read something and you can obviously tell it is AI, that does not meet our standards of quality. Florid language, made up citations, obvious formatting errors a human wouldn't make, whatever it is that indicates clear AI use, that doesn't meet our standards. Could we chock that up to failing another criteria? Maybe. But it's nice to have a straightforward box to check to toss piss poor AI work out--and to discourage the poor use of AI. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:34, 2 November 2025 (UTC)[reply]
• Support In my view, if someone is so lazy that they generate an entire article to nominate without actually checking if it complies with the relevant policies and guidelines, then their nomination is not worth considering. Reviews are already a demanding process, especially nowadays. Why should I or anyone else put in the effort if the nominator is not willing to also put in the effort. Lazman321 (talk) 03:10, 3 November 2025 (UTC)[reply]

  This proposal would impact those people, but it would also speedily fail submissions by people who do (or are suspected of) using LLMs but who do put in the effort to check that the LLM-output complies with all the relevant policies and guidelines. For example:

  • Editor A uses an LLM to find a source, verifies that that source exists, is reliable, and supports the statement it is intended to support but doesn't remove the associated LLM metadata from the URL. This nomination is speedily failed, despite being unproblematic.
  • Editor B uses an LLM to find a source, verifies that that source exists, is reliable, and supports the statement it is intended to support, and removes the associated LLM metadata from the URL. This nomination is speedily failed if someone knows or suspects that an LLM was used, it is accepted if someone doesn't know or suspect LLM use, despite the content being identical and unproblematic.
  • Editor D finds a source without using an LLM, verifies that that source exists, is reliable, and supports the statement it is intended to support. This nomination is accepted, even though the content is identical in all respects to the preceding two nominations.
  • Editor D adds a source, based on a reference in an article they don't know is a hoax without verifying anything about the source. The reviewer AGFs that the offline source exists and does verify the content (no LLMs were used so there is no need to suspect otherwise) and so the article gets promoted.

  Please explain how this benefits readers and/or editors. Thryduulf (talk) 04:36, 3 November 2025 (UTC)[reply]

  I am nitpicking, but you got two "Editor D" there. ✠ SunDawn ✠ Contact me! 00:55, 4 November 2025 (UTC)[reply]

  Whoops, the second should obviously be Editor E (I changed the order of the examples several times while writing it, obviously I missed correcting that). Thryduulf (talk) 01:23, 4 November 2025 (UTC)[reply]

• Oppose "Obvious" is subjective, especially if AI chatbots become more advanced than they are now and are able to speak in less stilted language. Furthermore, either we ban all AI-generated content on Wikipedia, or we allow it anywhere, this is just a confusing half-measure. (I am personally in support of a total ban, since someone skilled enough to proofread the AI and remove all hallucinations/signs of AI writing would likely just write it from scratch, it doesn't save much time). Or if it did, they'd still avoid it out of fear of besmirching their reputation given the sheer amount of times AI is abused. ᴢxᴄᴠʙɴᴍ (ᴛ) 11:31, 3 November 2025 (UTC)[reply]

  A total ban of AI has not gained consensus, in part because there are few 'half-measures' in place that would be indicative that there is a widespread problem. The AI image ban came only after a BLP image ban, for example. CMD (talk) 11:53, 3 November 2025 (UTC)[reply]

  Adding hypocritical half-measures just to push towards a full ban would be "disrupting Wikipedia to make a point". As long as it's allowed, blocking it in GAs would make no sense. It's also likely that unedited AI trash will be caught by reviewers anyway because it's incoherent, even before we get to the AI criterion. ᴢxᴄᴠʙɴᴍ (ᴛ) 15:46, 4 November 2025 (UTC)[reply]

  I'm not sure where the hypocrisy is in the proposal. Whether reviewers will catch unedited AI trash is also not affected by the proposal, the proposal provides a route for action following the catch of said text. CMD (talk) 16:01, 4 November 2025 (UTC)[reply]

• Support-I think at some point LLMs like to cite wikipedia whenever they spit out an essay or any kind of info on a given topic. Then an editor will paste this info into the article, which the AI will cite again, and wikipedia articles will basically end up ouroboros'd User:shawtybaespade (talk) 12:01, 3 November 2025 (UTC)[reply]
• Support Aquillion's comment above expresses my view very well. Stepwise Continuous Dysfunction (talk) 20:11, 3 November 2025 (UTC)[reply]
• Support. Obviously a sensible idea. Stifle (talk) 21:15, 3 November 2025 (UTC)[reply]

  There is extensive explanation above of why this is not a good proposal, so this comment just indicates you haven't read anything of the discussion, which is something for the closer to take note of. Thryduulf (talk) 21:25, 3 November 2025 (UTC)[reply]

  I urge everyone not to make inferences about what others have read. The wide diversity of opinions makes it clear that different editors find different arguments compelling, even after reading all of them. isaacl (talk) 23:58, 3 November 2025 (UTC)[reply]

  If Stifle had read and thought about any of the comments on this page it would be extremely clear that it is not "obviously" a sensible idea. Something that is "obviously" a sensible proposal does not get paragraphs of detailed explanation about why it isn't sensible from people who think it goes too far and from those who think it doesn't go far enough. Thryduulf (talk) 01:27, 4 November 2025 (UTC)[reply]

• Oppose I feel the scope that this criteria would cover is already redundant by the other criterias (see Thryduulf's !vote). Additionally, I am concerned that this will raise false positives for those whose writing style is too close to what an LLM could generate. Gramix13 (talk) 23:02, 3 November 2025 (UTC)[reply]
• Support, as per expressed by Aquillion. Furthermore would rather not see Wikipedia become a Grokipedia. Lf8u2 (talk) 01:41, 4 November 2025 (UTC)[reply]

  Grokipedia is an uncontrollable AI slop where no one can control the content (except for Elon Musk and his engineers). Current Wikipedia's rules is enough to stop such travesty without adding this quickfail category. GA criteria #1 and #2 is more than enough to stop the AI slop. G15 is still there as well. No need to put rules on top of other rules. ✠ SunDawn ✠ Contact me! 04:37, 4 November 2025 (UTC)[reply]

• Oppose For the statements made above and in the discussion that the failures of AI (hallucination) are easily covered by criterions 1 and 2. But, additionally, because I am not confident that AI is easily detected. AI-detector tools are huge failures, and my own original works on other sites have been labeled AI in the past when they're not. So I personally have experience being accused of using AI when I know my work is original all because I use emdashes. And since AI is only going to improve and become even harder to detect, this criterions is most likely going to be used to give false confidence to over-eager reviewers ready to quick-fail based on a hunch. Terrible idea.--v/r - TP 01:40, 4 November 2025 (UTC)[reply]
• Support after consideration. I do not love how the guideline is currently written - I think all criteria for establishing "obvious" LLM use should be defined. However, I would rather support and revise than oppose. Seeing multiple frequent GA reviewers !vote support also suggests there is a gap with the current QF criteria. NicheSports (talk) 04:58, 4 November 2025 (UTC)[reply]
• Support, the fact that people are starting to write like AI/bots/LLMs means that "false positives" will be detecting (in some cases) users who are too easily influenced by what they are reading. Let's throw those babies out with the bathwater. Abductive (reasoning) 05:16, 4 November 2025 (UTC)[reply]

  It's literally the opposite of that. LLMs and GenAI are trained on human writing. It mimics human writing. Not the other way around. And are you suggesting banning users for writing in similar prose to the highly skilled published authors that LLMs are trained on? What the absolute fuck?!?--v/r - TP 15:21, 4 November 2025 (UTC)[reply]

  The Washington Post says "It’s happening: People are starting to talk like ChatGPT with a subheading "Unnervingly, words overrepresented in chatbot responses are turning up more in human conversation." Abductive (reasoning) 06:20, 5 November 2025 (UTC)[reply]

  LLMs are trained on highly skilled published authors? Pull the other one, it's got bells on. I didn't know highly skilled published authors liked to delve into things with quite so many emojis. Cremastra (talk · contribs) 15:26, 4 November 2025 (UTC)[reply]

  Yes, LLMs are trained on published works. Duh.--v/r - TP 00:47, 5 November 2025 (UTC)[reply]

  Yeah, I know that. Dial down the condescension. But they're trained on all published works, including plenty of junk scraped from the internet. Most published works aren't exactly Terry Pratchett-quality either. Cremastra (talk · contribs) 00:56, 5 November 2025 (UTC)[reply]

  You want me to dial down the condescension on a request that anyone whose prose is similar to that of the material the AI is trained on, including published works, be banned? Did you read the top level comment that I'm being snarky to?--v/r - TP 00:59, 5 November 2025 (UTC)[reply]

  I did, and it isn't relevant here. What's relevant is your misleading claim that AI writing represents the best-quality writing humanity has to offer and is acceptable to be imitated. In practice, it can range from poor to decent, but rarely stellar. Cremastra (talk · contribs) 01:07, 5 November 2025 (UTC)[reply]

  First off - I made no such claim. I said AI is trained on some of the best quality writing humanity has to offer. Don't put words in my mouth. Second off - Even if I did, calling for a ban on users who positive contribute because their writing resembles AI is outrageous. Get your priorities straight or don't talk to me.--v/r - TP 22:17, 5 November 2025 (UTC)[reply]

  Modern LLMs are trained on very large corpuses, which include everything from high-quality to low-quality writing. And even if one were trained exclusively on high-quality writing, that wouldn't necessarily mean its output is also high-quality. But I agree that humans picking up speech patterns from LLMs doesn't make them incompetent to write an encyclopedia. jlwoodwa (talk) 22:30, 5 November 2025 (UTC)[reply]

• Support per Aquillion and Lf8u2, most editors I assume would not want Wikipedia to become Grokipedia, a platform of AI slop. LLMs such as Grok and ChatGPT write unencyclopedically or unnaturally and cite unreliable sources such as Reddit. Alexeyevitch^(talk) 07:55, 4 November 2025 (UTC)[reply]

  Users !opposed to this proposal are not supportive of AI slop or a 'pedia overrun by AIs. It's just a bad proposal.--v/r - TP 15:22, 4 November 2025 (UTC)[reply]

We can either wait for the 'perfect' proposal, which may never come, or try something like this, so as to have some recourse. It has been years since ChatGPT arrived. If there are some problems that arise with this criterion in actual practice, they can be dealt with by modifying the criterion through the usual Wikipedia process of trial and error. The point is that there is value merely in expressing Wikipedia's stance on AI in relation to good articles. I hope you can understand that users who support this proposal think something is better than nothing, which is the current state of affairs. Yours, &c. RGloucester — ☎ 22:02, 4 November 2025 (UTC)[reply]

There is already something. 1) That sources in a GA review are verified to support the content, and 2) That it follows the style guide. What does this new criterion add that isn't already captured by the first two?--v/r - TP 00:48, 5 November 2025 (UTC)[reply]

Adding this criterion will make clear what is already expected in practice. Namely, that editors should not waste reviewer time by submitting unreviewed LLM-generated content to the good articles process, as Aquillion wrote above. It is true that the other criteria may be able to be used to quick-fail LLM-generated content. This is also true of articles with copyright violations, however, which could logically be failed under 1 or 3, but have their own quick-fail criterion, 2. I would argue that purpose of criterion 2 is equivalent to the purpose of this new, proposed criterion: namely, to draw a line in the sand. The heart of the matter is this: what is the definition of a good article on Wikipedia? What does the community mean when it adds a good article tag to any given article? Adding this criterion makes clear that, just as we do not accept copyright violations, even those that are difficult to identify, like close paraphrasing, we brook no slapdash use of LLMs. Yours, &c. RGloucester — ☎ 01:34, 5 November 2025 (UTC)[reply]

I disagree that the quickfail criterion, as proposed, would make that clear. Not all obvious evidence of LLM use is evidence of unreviewed LLM use. jlwoodwa (talk) 01:43, 5 November 2025 (UTC)[reply]

Any 'successful' use of LLMs, if there can be such a thing, should leave no trace behind in the finished text. If the specified bits of prompt or AI-generated references are present, that is evidence that whatever 'review' may have been conducted was insufficient to meet the expected standard. Yours, &c. RGloucester — ☎ 07:25, 5 November 2025 (UTC)[reply]

If someone verifies that an article's references exist and support the claims they're cited for, I would call that a sufficient review of those references, whether or not there are UTM parameters remaining in the citation URLs. jlwoodwa (talk) 07:47, 5 November 2025 (UTC)[reply]

No, because not only the references would need to be checked. If such 'obvious evidence' of slapdash AI use is in evidence, the whole article will need to be checked for hallucinations, line-by-line. Yours, &c. RGloucester — ☎ 07:53, 5 November 2025 (UTC)[reply]

Shit flow diagram and Malacca dilemma have obvious evidence of LLM use, in that my edit summaries make it clear I used an LLM, and I've disclosed that on the talk page. Is that sufficient for a quickfail? ScottishFinnishRadish (talk) 11:45, 5 November 2025 (UTC)[reply]

Unfortunately I think it might be. Malacca dilemma for example, claims a pipeline has been "operational since 2013" using a source published in 2010 (and that discusses October 2009 in the future tense); in fact most of that paragraph seems made up around the bare bones of the potential for these future pipelines being mentioned. I assume the llm is drawing from other mentions of the pipelines somewhere in its training data, or just spinning out something plausible. Another llm issue is that when actually maintaining the transfer of source content into article prose, such as the first paragraph of background, it can be quite CLOPpy. CMD (talk) 11:59, 5 November 2025 (UTC)[reply]

That's actually found in Chen, but with with 2013 given as the planned operational date. China-Myanmar 2000 Kunming 20, for 2013 1.5
Oil Pipeline 30 years... Construction of the two pipelines will begin soon and is expected to be completed by 2013. China National Petroleum Corporation (CNPC), the largest oil and gas company in China, holds 50.9 per cent stake in the project, with the rest owned by the Myanmar Oil and Gas Enterprise (MOGE). (Sudha, 2009) I've wikilinked the article on the pipeline and added another source for becoming operational in 2013. That was definitely an issue, but would you call that a quick fail? ScottishFinnishRadish (talk) 12:12, 5 November 2025 (UTC)[reply]

What's found in Chen are parts of the text, the bare bones I mention above. The rest of the issues with that paragraph remain, and it is the presence of many of these issues, especially with the way llms work by producing words that sound right whether actual information or not, that is the problem. CMD (talk) 12:35, 5 November 2025 (UTC)[reply]

Oppose as WP:CREEP—bad GA noms should be failed for being bad, not specifically for using AI. – Closed Limelike Curves (talk) 01:23, 6 November 2025 (UTC)[reply]

• Oppose as discussed above by Myceteae. Adumbrativus (talk) 04:03, 6 November 2025 (UTC)[reply]
• Support: Yes, this is redundant, but it also saves time, and discourages editors who have used AI from submitting their (really, the LLM's) articles at GAN. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 10:08, 9 November 2025 (UTC)[reply]
• Support a change in the status quo, not necessarily this proposal but a similar one. FaviFake (talk) 17:17, 11 November 2025 (UTC)[reply]
• Oppose per Mycetae. I see several arguments in this discussion to advance the proposal.

1) That AI usage is bad and this proposal addresses it. I think all editors here agree that uncritical use of AI is an increasing problem facing Wikipedia. What editors don't agree is that this proposal effectively addresses the issue in a way that doesn't introduce new problems 2) This will save editor time when reviewing for GAR. I find this very unconvincing: I haven't seen any examples or explanations of an article that this guideline would save editor time, but rather magnify debates over whether or not particular aspects of an article are "evidence of AI usage". Editors argue that there are a class of articles that would be quickfailed under this guideline, but are currently not quickfailed and that this detracts from editor time. Whether or not this class of articles exists (something I'm skeptical of given the lack of examples), the application of the guideline would not effectively reduce editor time because there is no clear way to apply this guideline - the lack of specificity in the proposal defeats its functionality. In general, I haven't seen any evidence that there is a problem here. If a problem exists with how GA reviews function, that evidence is still forthcoming. I agree with editors who point out that this guideline is a solution in search of a problem. Katzrockso (talk) 22:38, 12 November 2025 (UTC)[reply]

• Support per RGloucester's reasoning. AI is clearly the next big thing, and we have to make sure that its hallucinations, including making up fake sources, which can be incredibly dangerous, do not get in the way of good articles.

• Support per Aquillion. AI usage is going to be more common in the coming years, so this proposal is timely and well due. BootsED (talk) 16:17, 18 November 2025 (UTC)[reply]

• I sometimes use AI as a search engine and link remnants are automatically generated. I'd rather not face quickfail for that. I'm also not seeing how the existing criteria are not sufficient; if links are fake or clearly don't match the text, that is already covered under a quickfail as being a long way from demonstrated verifiability. Can a proponent of this proposal give an example of an article they would be able to quickfail under this that they can't under the current criteria? Rollinginhisgrave (talk | contributions) 10:47, 26 October 2025 (UTC)[reply]

  The purpose of this proposal is to draw a line in the sand, to preserve the integrity of the label 'good article', and make clear where the encyclopaedia stands. Yours, &c. RGloucester — ☎ 12:55, 26 October 2025 (UTC)[reply]

  In a nutshell the difference is that with AI-generated text, every single claim and source must be carefully checked, and not just for the source's existence; GA only requires spot-checking a handful. The example I gave above was a FA, not GA, but it's basically the same thing. Gnomingstuff (talk) 17:56, 26 October 2025 (UTC)[reply]

  Thankyou for this example, although I'm not sure how it's applicable here as it wouldn't fall under "obvious evidence of LLM use". At what point in seeing edits like this are you invoking the QF? Rollinginhisgrave (talk | contributions) 21:23, 26 October 2025 (UTC)[reply]

  The combination of "clear signs of text having been written by AI..." plus "...and there are multiple factual inaccuracies in that text." Or in other words, obvious evidence (#1) plus problems that suggest that the output wasn't reviewed well/at all (#2). Gnomingstuff (talk) 02:20, 27 October 2025 (UTC)[reply]

  I've spent some time thinking about this. Some thoughts:

  • What you describe as obviously AI is very different to what RGloucester describes here, which makes me concerned about reading any consensus for what proponents are supporting.
  • I would describe what you encountered at La Isla Bonita as "possible/probable AI use" not "obvious", and your description of it as "clear" is unconvincing, especially when put against cases where prompts are left in etc.
  • If I encountered multiple substantial TSI issues like that and suspected AI use, I would be more willing to quickfail as I would have less trust in the text's verifiability. I would want other reviewers to feel emboldened to make the same assessment, and I think it's a problem if they are not currently willing to do so because of how the QF criteria is laid out.
  • I see no evidence that this is actually occuring.
  • I think that the QF criteria would have to be made more broad than proposed ("likely AI use") to capture such occurrences, and I would like to see wording which would empower reviewers in that scenario but would avoid quickfails where AI use is suspected but only regular TSI issues exist (for those who do not review regularly, almost all spot checks will turn up issues with TSI).

  Rollinginhisgrave (talk | contributions) 17:49, 29 October 2025 (UTC)[reply]

  Not a fan of RGloucester's criteria tbh, I don't feel like references become quickfail-worthy just because someone used ChatGPT search, especially given that AI browsers now exist.

  As far as the rest this is why I !voted weak support and not full support -- I'm not opposed to quickfail but it's not my preference. My preference is closer to "don't promote until a lot more review/rewriting than usual is done." Gnomingstuff (talk) 05:00, 1 November 2025 (UTC)[reply]

  It's correct that every single claim and source needs to be carefully checked, but it needs to be checked by the author, not the GA reviewer. The spot check is there to verify the author did their part in checking. – Closed Limelike Curves (talk) 01:23, 6 November 2025 (UTC)[reply]

• What's "obvious evidence of AI-generated references"? For example, I often use the automatic generation feature of the visual editor to create a citation template. Or I might use a script to organise the references into the reflist. The proposal seems to invite prejudice against particular AI tells but these include things like using an m-dash, and so are unreliable. Andrew🐉(talk) 10:53, 26 October 2025 (UTC)[reply]

  Yeah, it's poorly written. "Obvious evidence of AI-generated references" in this context means a hallucination of a reference that doesn't exist. Viriditas (talk) 02:43, 28 October 2025 (UTC)[reply]

  If the article cites a nonexistent reference, that should be grounds for failure by itself. – Closed Limelike Curves (talk) 01:16, 6 November 2025 (UTC)[reply]

• What about something similar to WP:G15, for example 6. It contains content that could only plausibly have been generated by large language models and would have been removed by any reasonable human review. Kovcszaln6 (talk) 10:59, 26 October 2025 (UTC)[reply]
• This would be the first GA criterion that regulates the workflow people use to write articles rather than the finished product, which doesn't make much sense because the finished product is all that matters. Gen AI as a tool is also extremely useful for certain tasks, for example I use it to search for sources I may have missed (it is particularly good at finding multilingual sources), to add rowscopes to tables to comply with MOS:DTAB, to double check table data matches with the source, and to check for any clear typos/grammar errors in finished prose. IAWW (talk) 11:05, 26 October 2025 (UTC)[reply]

  It’s irrelevant to this discussion but I don’t think it’s right to call something “extremely useful” when the tasks are layout formatting, and source-finding and copy editing skills you can and should develop for yourself. You will get better the more you try, and when even just pretty good, you will be better than a chatbot. You also really don’t need gen AI to edit tables, there are completely non-AI tools to extract datasets and add fixed content in fixed places, tools that you know won’t throw in curveballs at random. Kingsif (talk) 14:24, 26 October 2025 (UTC)[reply]

  Well, "extremely useful" is subjective, and in my opinion it probably saves me about 30 mins per small article I write, which in my opinion justifies the adjective. I still do develop all the relevant skills myself, but I normally make some small mistakes (like for example putting a comma instead of a full stop), which AI is very good at detecting. IAWW (talk) 14:55, 26 October 2025 (UTC)[reply]

  You still don’t need overconfident error-prone gen AI for spellcheck. Microsoft has been doing it with pop ups that explain why your text may or may not have a mistake for almost my whole life. Kingsif (talk) 15:02, 26 October 2025 (UTC)[reply]

  GenAI is just faster and easier to use for me. IAWW (talk) 16:15, 26 October 2025 (UTC)[reply]

  Well yes, if you consider speed and ease of use to be more important than accuracy, generative AI is probably the way to go... AndyTheGrump (talk) 21:09, 26 October 2025 (UTC)[reply]

  @AndyTheGrump is there any evidence that the uses to which IAWW puts generative AI result in a less accurate output than doing it manually? Thryduulf (talk) 21:11, 26 October 2025 (UTC)[reply]

  I have no idea how accurately IAWW can manually check spelling, grammar etc. That wasn't the alternative offered however, which was to use existing specialist tools to do the job. They can get things wrong too, but rarely in the making-shit-up tell-them-what-they-want-to-hear way that generative AI does. AndyTheGrump (talk) 21:40, 26 October 2025 (UTC)[reply]

  Generative AI can do that in certain situations, but things like checking syntax doesn't seem like one of those situations. Anyway, if the edits IAWW makes to Wikipedia are accurate and free of neutrality issues, fake references, etc. why does it matter how that content was arrived at? Thryduulf (talk) 21:48, 26 October 2025 (UTC)[reply]

  'If' is doing a fair bit of work in that question, but ignoring that, it wouldn't, except in as much as IAWW would be better off learning to use the appropriate tools, rather than using gen AI for a purpose other than that it was designed for. I'd find the advocates of the use of such software more convincing if they didn't treat it as if it was some sort of omniscient and omnipotent entity capable of doing everything, and instead showed a little understanding of what its inherent limitations are. AndyTheGrump (talk) 23:02, 26 October 2025 (UTC)[reply]

  I clearly don't treat it as an omniscient and omnipotent entity, and I welcome any criticism of my work. IAWW (talk) 08:05, 27 October 2025 (UTC)[reply]

  To me - and look, as much as it's a frivolous planet-killer, I am not going to go after any individual user for non-content AI use, but I will encourage them against it - if we assume there are no issues with IAWW's output, my main concern would be the potential regression in IAWW's own capabilities for the various tasks they use an AI for, and how this could affect their ability to contribute to the areas of Wikipedia they frequent. E.g. if you are never reviewing your own writing and letting AI clean it up, will your ability to recognise in/correct grammar and spelling deteriorate, and therefore your ability to review others' writing. That, however, would be a personal concern, and something I would not address unless such an outcome became serious. As I said, with this side point, I just want to encourage people to develop and use these skills themselves. Kingsif (talk) 23:21, 26 October 2025 (UTC)[reply]

  why does it matter how that content was arrived at? Value? Morality? If someone wants ChatGPT, it's over this way. We're an encyclopedia. We have articles with value written by people who care about the articles. LLM-generated articles make a mockery of that. Why would you deny our readers this? I genuinely can't understand why you're so pro-AI. Do you not see how AI tools, while they have some uses, are completely incompatible with our mission of writing good articles? Cremastra (talk · contribs) 01:57, 28 October 2025 (UTC)[reply]

  Once again, Wikipedia is not a vehicle for you to impose your views on the morality of AI on the world. Wikipedia is a place to write neutral, factual encyclopaedia articles free of value judgements - and that includes value judgements about tools other people use to write factual, neutral articles. Thryduulf (talk) 02:17, 28 October 2025 (UTC)[reply]

  Your refusal to take any stance on a tool that threatens the value of our articles is starting to look silly. As I say here, we take moral stances on issues all the time, and LLMs are right up our alley. Cremastra (talk · contribs) 02:28, 28 October 2025 (UTC)[reply]

  That LLM is a tool that threatens the value of our articles is your opinion, seemingly based on your dislike of LLMs and/or machine learning. You are entitled to that opinion, but that does not make it factual.

  If an article is neutral and factual then it is neutral and factual regardless of what tools were or were not used in its creation.

  If an article is not neutral and factual then it is not neutral and factual regardless of what tools were or were not used in its creation. Thryduulf (talk) 02:52, 28 October 2025 (UTC)[reply]

  You missed two: If an article is not neutral and factual and was written by a person, you can ask that person to retrace their steps in content creation (if not scan edit-by-edit to see yourself) so everyone can easily identify where the inaccuracies originated and fix them. If an article is not neutral and factual and you cannot easily trace its writing process, it is hard to have confidence in any content at all when trying to fix it. Kingsif (talk) 03:01, 28 October 2025 (UTC)[reply]

  It’s irrelevant to this discussion but I don’t think it’s right to call a calculator “extremely useful” when the tasks are division, exponentiation, and root-finding skills you can and should develop for yourself. – Closed Limelike Curves (talk) 01:18, 6 November 2025 (UTC)[reply]

• Now, relevantly, this proposal clearly does not regulate workflow, only the end product. It only refers to the article itself having evidence of obvious AI generation in its actual state. Clean up after your LLMs and you won’t get caught and charged 😉 Kingsif (talk) 14:28, 26 October 2025 (UTC)[reply]

  The "evidence" in the end product is being used to infer things about the workflow, and the stuff in the workflow is what the proposal is targeting. IAWW (talk) 14:50, 26 October 2025 (UTC)[reply]

  Y’all know I think gen AI is incompatible with Wikipedia and would want to target it, but I don’t think this proposal does that. If there’s AI leftovers, that content at least needs human cleanup, and that shouldn’t be put on a reviewer. That’s no different to identifying copyvio and quickfailing saying a nominator needs to work on it rather than sink time in a full review. Kingsif (talk) 14:59, 26 October 2025 (UTC)[reply]

• Regarding "fake references", I can see the attraction in this being changed from a slow fail to a quick fail, but before it can be a quick fail there needs to be a reliable way to distinguish between references that are completely made up, references that exist but are inaccessible to (some) editors (e.g. offline, geoblocked, paywalled), references that used to be accessible but no longer are (e.g. linkrot), and references with incorrect details (e.g. typos in URIs/dois/ISBNs/titles/etc). Thryduulf (talk) 12:56, 26 October 2025 (UTC)[reply]

  If you cannot determine if a reference that doesn’t work is AI or not, then it’s not obvious AI and this wouldn’t apply… Kingsif (talk) 14:09, 26 October 2025 (UTC)[reply]

  I think this is the problem: The proposal doesn't say "a reference that doesn’t work". It says "AI-generated references". Now maybe @RGloucester meant the kind of ref that's completely fictional, rather than real sources that someone found by using ChatGPT as a type of cumbersome web search engine, but that's not clear from what's written in the proposal.

  This is a bit concerning, because there have been problems with citations that people can't check since before Wikipedia's creation – for example:

  • Proof by reference to inaccessible literature: The author cites a simple corollary of a theorem to be found in a privately circulated memoir of the Slovenian Philological Society, 1883.
  • Proof by ghost reference: Nothing even remotely resembling the cited theorem appears in the reference given.
  • Proof by forward reference: Reference is usually to a forthcoming paper of the author, which is often not as forthcoming as at first.

  – and AI is adding to the traditional list the outright fabrication of sources: "Proof by non-existent source: A paper is alleged to exist, except that no such paper ever existed, and sometimes the alleged author and the alleged journal are made-up names, too". These are all problems, but these need different responses in the GA process. Made-up sources should be WP:QF #1: "It is a long way from meeting any one of the six good article criteria" (specifically, the requirement to cite real sources. A ghost reference is a real source but what's in the Wikipedia article {{failed verification}}; depending on the scale, that's a surmountable problem. A forward reference is an unreliable source, but if the scale is small enough, that's also a surmountable problem. Inaccessible literature is not grounds for failing a GA nom.

  If this is meant to be "most or all of the references are to sources that actually doesn’t exist (not merely offline, not merely inconvenient, etc.)", then it can be quick-failed right now. But if it means (or gets interpreted as) "the URL says ?utm=chatgpt", then that's not an appropriate reason to quick-fail the nomination. WhatamIdoing (talk) 06:10, 27 October 2025 (UTC)[reply]

  Perhaps a corollary added to existing crit, saying that such AI source invention is a QF, would be more specific and helpful. I had thought this proposal was good because it wasn’t explicitly directing reviewers to “this exact thing you should QF”, but if there are reasonable concerns (not just the ‘but I like AI’ crowd) that the openness could instead confuse reviewers, then adding explicit AI notes to existing crit may be a better route. Kingsif (talk) 16:05, 27 October 2025 (UTC)[reply]

• Suggestion: change the fail criterion to read "obvious evidence of undisclosed LLM use". There are legitimate uses of LLMs, but if LLM use is undisclosed then it likely hasn't been handled properly and shouldn't be wasting reviewers' time, since more than a spot-check is required as explained by Gnomingstuff. lp0 on fire () 09:17, 27 October 2025 (UTC)[reply]

  My concern here is that these in practice are basically the same thing: WP:LLMDISCLOSE is not mandatory, so almost all LLM use is undisclosed, even when people are doing review. Gnomingstuff (talk) 16:08, 27 October 2025 (UTC)[reply]

  It would also be so hard to implement making it mandatory, in practice. Heavy rollout means some users may not even know when they’ve used it. Left google on AI mode (or didn’t turn it off…)? Congrats, when you searched for a synonym you “used” an LLM. Kingsif (talk) 16:12, 27 October 2025 (UTC)[reply]

• Any evidence of LLM use? Does that include disclosing LLM use used in article development/creation? See Shit flow diagram and Malacca dilemma for examples. Should both of those quick fail based only on LLM use? ScottishFinnishRadish (talk) 11:10, 27 October 2025 (UTC)[reply]

  I took evidence to mean things in the article. I hope no reviewer would extend the GA crit to things not reviewed in the GAN process - like an edit reason or other disclosure. I can see the concern that this wording could allow or encourage them to, now that you bring it up. Kingsif (talk) 15:56, 27 October 2025 (UTC)[reply]

  A difficult part of workshopping any sort of rule like this is you have to remember not everyone who uses it will think the same way you do, or even the way the average person does. What I'd hate to see happen is we pass something like this and then have to come back multiple times to edit it because of people using it as license to go open season on anything they deem AI, evidence or no evidence. I don't mean to suggest you would do anything like that, Kingsif, but someone out there probably will. Trainsandotherthings (talk) 01:52, 28 October 2025 (UTC)[reply]

  I didn't think you were suggesting so ;) As noted, I agree. As much as obvious should mean obvious and evidence should be tangible evidence, and the spirit of the proposal should be clear... I still support it, as certainly less harmful than not having something like it, but I can see how even well-intentioned reviewers trying to apply it could go beyond this limited proposal's intention. Kingsif (talk) 01:59, 28 October 2025 (UTC)[reply]

• I mentioned this above in my !vote, but isn't this already covered by WP:GAQF #3 (# It has, or needs, cleanup banners that are unquestionably still valid. These include {{cleanup}}, {{POV}}, {{unreferenced}} or large numbers of {{citation needed}}, {{clarify}}, or similar tags)? Any blatant use of AI means that the article deserves {{AI-generated}} and, as such, already is QF-able. All that has to be done is to modify the existing QF criterion 3 to make it explicit that AI generation is a rationale that would cause QF criterion 3 to be triggered. – Epicgenius (talk) 01:44, 28 October 2025 (UTC)[reply]

  To keep it short, isn't QF3 just a catch-all for "any clean-up issues that might not completely come under 1 & 2" and theoretically both those quickfail conditions come under it and they're unnecessary? But they're important enough to get their own coverage? Then we ask is unmonitored gen AI more or less significant than GA crit and copyvio. Kingsif (talk) 02:06, 28 October 2025 (UTC)[reply]

• Suggestion: combining the obvious use of AI with evidence that the submission falls short of any of the other six GA criteria (particularly criteria 2). Many of the current Opposes reflect a sentiment that this policy would encapsulate too much: instead of reflecting the state of the article, it punishes those who use AI in their workflow. This suggestion would cover a quickfail of articles with AI-hallucinated references (so, for instance, if a reviewer notes a source with a ?utm_source=chatgpt.com tag and determines that the sentence is not verifiable, they can quickfail it); however, this suggestion limits the quickfail potential for people who use AI, review its outputs, and put work into making sure it meets the guidelines for a Wikipedia article. Staraction (talk | contribs) 07:41, 30 October 2025 (UTC)[reply]

  We already have this: it's WP:QF #1. Kovcszaln6 (talk) 08:23, 30 October 2025 (UTC)[reply]

  Sorry, I don't think I worded the tqi part well. I mean that, if there is obvious use of AI and any evidence of a hallucinated source, unverified citation, etc. at all that the reviewer is allowed to quickfail.

  If this still is WP:QF #1, then I sincerely apologize for wasting everybody's time. Staraction (talk | contribs) 08:39, 30 October 2025 (UTC)[reply]

  I see. I support this. Kovcszaln6 (talk) 08:45, 30 October 2025 (UTC)[reply]

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Wikipedia technical issues and templates When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

An edit filter can perform certain actions when triggered, such as warning the user, disallowing the edit, or applying a change tag to the revision. However, there are lesser known actions that aren't currently used in the English Wikipedia, such as blocking the user for a specified amount of time, desysopping them, and something called "revoke autoconfirmed". Contrary to its name, this action doesn't actually revoke anything; it instead prevents them from being "autopromoted", or automatically becoming auto- or extended-confirmed. This restriction can be undone by any EFM at any time, and automatically expires in five days provided the user doesn't trigger that action again. Unlike block and desysop (called "degroup" in the code), this option is enabled for use on enwiki, but has seemingly never been used at all.

Fast forward to today, and we have multiple abusers and vandalbots gaming extended confirmed in order to vandalize or edit contentious topics. One abuser in particular has caused an edit filter to be created for them, which is reasonably effective in slowing them down, but it still lets them succeed if left unchecked. As far as I'm aware, the only false positive for this filter was triggered by PaulHSAndrews, who has since been community-banned. In theory, setting this filter to "revoke autoconfirmed" should effectively stop them from being able to become extended confirmed. Some technical changes were recently made to allow non-admin EFMs to use this action, but since it has never been used, I was told to request community consensus here.

So, should edit filter managers be allowed to use the "revoke autoconfirmed" action in edit filters? Children Will Listen (🐄 talk, 🫘 contribs) 05:04, 28 October 2025 (UTC)[reply]

• @ChildrenWillListen: Does current policy/guideline prohibit edit filter managers from using the "block autopromote" setting? I am looking at WP:EF#Basics of usage and WP:EF#Recommended uses and it makes several references to "block autopromote" as an available option. It seems to me that edit filter managers already have discretion to use that setting under the current guidelines. Is there a particular edit filter that you feel the setting would be useful? Mz7 (talk) 05:08, 28 October 2025 (UTC)[reply]

  See Wikipedia:Edit filter/Requested/Archive_21#Set 807 to revoke autoconfirmed. Children Will Listen (🐄 talk, 🫘 contribs) 05:10, 28 October 2025 (UTC)[reply]

  Got it, thanks for that context. Unless I am missing something, there does not seem to be any written rule that prevents edit filter managers from using the "block autopromote" setting. However, it seems the reason why edit filter managers are hesitant to use it is because it is rarely actually helpful. Looking at 807 in particular, I see it listed at Template:DatBot filters, meaning a bot will automatically report filter hits to WP:AIV—maybe that takes care of the need to use "block autopromote"? Mz7 (talk) 05:33, 28 October 2025 (UTC)[reply]

  They're generally active in a time where most admins are asleep, so it isn't effective in all cases. See, for example, whatever happened at Erika Kirk. Children Will Listen (🐄 talk, 🫘 contribs) 05:37, 28 October 2025 (UTC)[reply]

  For example, see Utube2 who is active right now and has triggered this filter. If we set it to prevent them from becoming extended confirmed, we wouldn't have to worry about this. This has been happening every single day for the last three months. Children Will Listen (🐄 talk, 🫘 contribs) 06:11, 28 October 2025 (UTC)[reply]

• See Wikipedia talk:Protection policy#Revised proposal to improve extended confirmed grants, which is still open and asks an mostly overlapping question. I doesn't look (to me, but I'm not neutral) to have a clear consensus in that discussion. Thryduulf (talk) 09:57, 28 October 2025 (UTC)[reply]

  @Daniel Quinlan: "Revoke autoconfirmed" doesn't actually... revoke autoconfirmed (or anything else), as strange as it sounds. See [1], [2], and [3]. The name is extremely misleading and I'll look to get that changed.

  Also, I wasn't aware of $wgAutopromoteOnce until now, and since that code path doesn't call into HookRunner::onGetAutoPromoteGroups, this might not even block the extended-confirmed autopromotion. Children Will Listen (🐄 talk, 🫘 contribs) 13:22, 28 October 2025 (UTC)[reply]

  We can change the label locally by editing MediaWiki:abusefilter-edit-action-blockautopromote. Getting it changed for everyone would require a code patch. Anomie⚔ 14:08, 28 October 2025 (UTC)[reply]

  It would be easier to revise the documentation on https://www.mediawiki.org. Daniel Quinlan (talk) 16:54, 28 October 2025 (UTC)[reply]

  Also, it looks like you're right that it won't block the promotion to extendedconfirmed. Anomie⚔ 14:26, 28 October 2025 (UTC)[reply]

  I've put in a request at WP:CR for someone to close the discussion at WT:PP, but looking at the backlog there, it doesn't seem likely to happen quickly. – PharyngealImplosive7 (talk) 13:49, 28 October 2025 (UTC)[reply]

  The problem is we can't implement that solution since revoke autoconfirmed doesn't revoke anything, and it looks like my idea isn't going to work either. Children Will Listen (🐄 talk, 🫘 contribs) 19:44, 28 October 2025 (UTC)[reply]

  If (you think) the proposal there can't be implemented for technical reasons then you should note that in the discussion so participants and the closer are aware. Thryduulf (talk) 21:11, 28 October 2025 (UTC)[reply]

  The blockautopromote filter action works fine (after the above discussion, I tested it on test.wikipedia.org) although it's worth clarifying that it doesn't technically "revoke" permissions in the way people are used to thinking about permissions. It helps to understand that autopromotion doesn't actually add users to a group. MediaWiki dynamically checks whether a user meets the conditions for autopromotion when it's checking a user's rights or groups. The blockautopromote action prevents those conditions from being met for a temporary period of time (five days). The rights are effectively revoked during that period, but once the period ends, autopromotion works normally and the "revoked" rights return to the user. The confirmed permission can also be granted manually during that period and edit filter managers also have an interface to undo blockautopromote mistakes.

  I will also mention that enabling blockautopromote for one or two filters as proposed in the WT:PP RFC will have another immediate effect (i.e., without any additional configuration changes): it will lower the edit rate throttle for the five day period from the user edit rate limit to the newbie edit rate limit. Based on the current settings, that would shift the rate limit from 90 edits per 60 seconds to 8 edits per 60 seconds.

  Caveat: I've done my best to explain the technical details in a straightforward way, but the code is complex and corrections are welcome! Daniel Quinlan (talk) 23:08, 28 October 2025 (UTC)[reply]

  I investigated this and you are indeed correct (except for some caching issues which probably won't matter.) I think this RfC can be closed in preference of the WP:PP RfC. Children Will Listen (🐄 talk, 🫘 contribs) 00:54, 29 October 2025 (UTC)[reply]

• Is the use of "revoke autoconfirmed" prohibited somewhere? Is an RFC to start using "revoke autoconfirmed" in edit filters necessary, or would a WP:EFN discussion be sufficient to get this started? (RFCs are expensive in terms of editor time.) Does this perhaps overlap too much with Wikipedia talk:Protection policy#Revised proposal to improve extended confirmed grants? Did you notify WP:EFN using subst:Please see or a similar template? –Novem Linguae (talk) 22:36, 28 October 2025 (UTC)[reply]

  If the discussion at WT:PP reaches a consensus against that proposal (or does not reach a consensus), then I'd say that a discussion at that or similarly prominent venue (such as a village pump) would be required to start using the option. If that discussion is concluded with a consensus in favour then anything similar would probably be fine with just an EFN discussion, but anything significantly different would probably benefit from a more prominent discussion.

  Does this perhaps overlap too much with [the discussion at WT:PP]? I'm inclined to say yes, but others might disagree. Certainly I can't see the utility in this discussion before that one is closed.

  WP:EFN has not been notified of this discussion. Thryduulf (talk) 22:47, 28 October 2025 (UTC)[reply]

  It has been notified now. – PharyngealImplosive7 (talk) 01:06, 29 October 2025 (UTC)[reply]

• I don't think this is really prohibited so much as it's not something anyone particularly wants to use without a heavy level of specific community consensus. It certainly could be used, but in the modern age unless it's an emergency it's almost certain to go through a long discussion first. I don't think there's a lot of EFMs who are eager to use that option without a lot of code review and being confident of consensus in favor first. EggRoll97 ^(talk) 01:30, 29 October 2025 (UTC)[reply]

In general, this proposal seems highly dangerous, and policy shouldn't change. Just go to WP:STOCKS and you'll find some instances in which misconfigured filters prevented edits by everyone; imagine that these filters also included provisions to block or revoke rights from affected editors. However, the proposal seems to be talking about a filter for one particularly problematic user; I could support a proposal to make an exemption for egregious cases, but I think such an exemption should always be discussed by the community, so the suggested reconfiguration is the result of community consensus. Nyttend (talk) 10:51, 29 October 2025 (UTC)[reply]

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia proposals WikiProjects and collaborations When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Increase the frequency of Today's Featured Lists from 2 per week to 3 or 4 per week, either on a trial basis, with the option to expand further if sustainable, or without a trial at all. Vanderwaalforces (talk) 07:02, 2 November 2025 (UTC)[reply]

Background

Right now, Today's Featured List only runs twice a week; that is Mondays and Fridays. The problem is that we've built up a huge (and happy?) backlog because there are currently over 3,400 Featured Lists that have never appeared on the Main Page (see category). On top of that and according to our Featured list statistics we're adding about 20 new Featured Lists every month, which works out to around 4 to 5 a week, and looking at the current pace of just 2 per week, it would take forever to get through what we already have, and the backlog will only keep growing.

Based on prior discussion at WT:FL, I can say we could comfortably increase the number of TFLs per week without running out of material. Even if we went up to 3 or 4 a week, the rate at which new lists are promoted would keep things stable and sustainable. Featured Lists are one of our high-quality contents and they get this less exposure compared to WP:TFAs or WP:POTDs, so trust me, this isn't about numbers, and neither is it about FL contributors being jealous (we could just be :p). Giving them more space would better showcase the work that goes into them. We could run a 6‑month pilot, then review the backlog impact, scheduling workload, community satisfaction, etc.

Of course, there are practical considerations. Scheduling is currently handled by Giants2008 the FL director, and increasing the frequency would mean more work, which I think could be handled by having one of the FL delegates (PresN and Hey man im josh) OR another experienced editor to help with scheduling duties. Vanderwaalforces (talk) 07:03, 2 November 2025 (UTC)[reply]

Options

• Option 1: Three TFLs per week (Mon/Wed/Fri)
• Option 2: Four TFLs per week (e.g., Mon/Wed/Fri/Sun)
• Option 3: Every other day, with each TFL staying up for two days (This came up at the WT:FL discussion, although it might cause imbalance if comparing other featured content durations.)
• Option 4: Three TFLs per week (Mon/Wed/Fri) as a 6‑month pilot and come back to review backlog impact, scheduling workload, community satisfaction, etc.
• Option 5: Four TFLs per week (e.g., Mon/Wed/Fri/Sun) as a 6‑month pilot and come back to review backlog impact, scheduling workload, community satisfaction, etc.
• Option 6: Retain status-quo

• Generally supportive of an increase, if the increase has the support of Giants2008, PresN, and Hey man im josh. Could there be an elaboration on the potential main page balance? TFL seems to slot below the rest of the page, without the columnar restrictions. CMD (talk) 10:01, 2 November 2025 (UTC)[reply]

  @Chipmunkdavis Per the former, yeah, I totally agree, which is why I suggested earlier that one of the FLC delegates could help share the load, alternatively, an experienced FLC editor or someone familiar with how FL scheduling works could assist. Per the latter, nothing changes actually, the slot for TFL remains the same, viewers only get to see more FLs than the status-quo. It might fascinate you that some editors do not know if we have TFLs (just like TFAs) on English Wikipedia either because they have never viewed the Mainpage on a Monday/Friday or something else. Vanderwaalforces (talk) 17:06, 2 November 2025 (UTC)[reply]

• Support Option 2 with the Monday list also showing on Tuesday, the Wednesday list also showing on Thursday and the Friday list also showing on Saturday — Preceding unsigned comment added by Easternsahara (talk • contribs) 16:28, 2 November 2025 (UTC)[reply]
• Option 1, for two main reasons: (1) there is no reason to rush into larger changes (we can always make further changes later), and (2) FL topics tend to be more limited and I think it's better to space out similar lists (e.g., having a "List of accolades received by <insert movie/show/actor>" every other week just to keep filling slots would get repetitive). Strongly oppose any option that results in a TFL being displayed for 2 days; this would permanently push POTD further down, break the patterns of the main page (no other featured content is up for more than 1 day), and possibly cause technical issues for templates meant to change every day. RunningTiger123 (talk) 18:08, 2 November 2025 (UTC)[reply]
• Option 1 – Seeing the notification for this discussion pop up on my talk page really made me take a step back and ponder how long I've been active in the FL process (and my mortality in general, but let's not go there). I can't believe I'm typing this, but I've been scheduling lists at TFL for 13 years now. That's a long time to be involved in any one process, as this old graphic makes even more clear. Where did the time go? Anyway, I agree with RunningTiger that immediately pushing for 4+ TFLs per week when we may not have enough topic diversity to probably support that amount would do more harm than good, but I think enough lists are being promoted through the FL process to support an increase to three TFLs weekly. In addition, I agree with RT that we don't need to be running lists over multiple days when none of the other featured processes do.
  While I'm here, I do want to address potential workload issues. My suggestion is that, presuming the delegates have the spare time to take this on, each of us do one blurb per week. With the exception of the odd replaced blurb once in a blue moon, I've been carrying TFL by myself for the vast majority of the time I've been scheduling TFLs (over a decade at this point). If I take a step back and ignore the fact that I'm proud to have had this responsibility for the site for this many years (and that the train has been kept on the tracks fairly well IMO), it really isn't a great idea for the entire process to have been dependent on the efforts of a single editor for that long. I just think it would be a good sign of the strength of the TFL process for a rotation of schedulers to be introduced. Also, in the event of an emergency we would have a much better chance of keeping TFL running smoothly with a rotation. Of course, this part can be more thoroughly hammered out at TFL, but I did want to bring it up in case the wider community has any thoughts. Giants2008 (Talk) 01:42, 4 November 2025 (UTC)[reply]
• Option 1, and I'd be willing to do some TFL scheduling. --PresN 15:59, 4 November 2025 (UTC)[reply]
• Option 1, though I would support any permanent increase to the frequency of TFLs as long as the coords or other volunteers have the capacity for that. Toadspike [Talk] 20:13, 4 November 2025 (UTC)[reply]
• Option 4, let's see if some backlog can be cleared and evaluate the workload. Blue Riband► 01:00, 5 November 2025 (UTC)[reply]
• Option 1, sounds like the best option to me at this stage. – Ianblair23 (talk) 12:26, 12 November 2025 (UTC)[reply]
• Option 1, Slow changes are better. Also, this doesn't explicitly need to be a pilot (opt4) since we can always switch back to the status quo ante if unforeseen problems crop up. -MPGuy2824 (talk) 14:20, 12 November 2025 (UTC)[reply]
• Option 1, in agreement with others. I would be open to an increase in frequency after some time, with input from editors involved in TFLs about the impact of the initial change. —Myceteae‍🍄‍🟫 (talk) 20:15, 12 November 2025 (UTC)[reply]

Option 1, but I think that this should be trialled and then returned for further discussion based on how it affects the backlog and the wider response to the change. JacobTheRox^{(talk | contributions)} 20:45, 20 November 2025 (UTC)[reply]

Based on your response, you should choose option 4. -MPGuy2824 (talk) 04:35, 21 November 2025 (UTC)[reply]

When a new COI edit request is posted, it appears on Category:Wikipedia conflict of interest edit requests. When a volunteer starts to address the request, it can be tagged with the {{started}} template. But we still have to click on each request to go to the request on the talk page to see if it's been tagged with "started" yet. It would save time if the presence of the started template triggers some kind of visual alert on the category page. Currently, a lot of real estate and color coding goes to show that an article is edit protected, but that has very little impact on most editors handling these requests. Instead, if a field could be used to simply say "started", or "new" (default), it would make it easier for volunteers to clear the queue by highlighting new requests that aren't already being worked on by someone else. STEMinfo (talk) 23:46, 4 November 2025 (UTC)[reply]

You're talking about User:AnomieBOT/COIREQTable, which is transcluded on the category page, right? jlwoodwa (talk) 01:40, 5 November 2025 (UTC)[reply]

@Jlwoodwa: Yes - I didn't know there was another location for the queue. On the link you shared, there's even more empty space, so it seems there would be room to put in a "started" icon or the word started in a stareted column to help the volunteers.STEMinfo (talk) 00:07, 8 November 2025 (UTC)[reply]

@STEMinfo, when was the last time you had an actual problem with wasted work because someone else was answering the same request that you picked?

There are usually about 200 open requests on that page, and I would be surprised if there were even 10 editors using the list (the cat gets about 20 page views per day). I estimate the odds of a conflict as being significantly less than 1% per article chosen, especially if you're picking an article that isn't one of the very top or very bottom entries. WhatamIdoing (talk) 18:25, 12 November 2025 (UTC)[reply]

@WhatamIdoing: Every time I read a request and find it's been started and is being worked on, I feel I've wasted time. And the queue continues to grow. If it was shorter, there wouldn't be an issue. I supposed I could just jump to the bottom every time I click on a request to see what's new, but a simple modification to the queue showing "started" would be more efficient. I usually try to work the oldest ones first, but might respond to a newer one if it's well written and/or uncontroversial. I don't always remember which ones I've clicked on before, so a tag would help. STEMinfo (talk) 08:44, 20 November 2025 (UTC)[reply]

I do not believe this message, which appears when a temporary account attempts to exit session, is necessary. The wikilinks in message is currently broken due to T409630, and no good faith user would believe that it is ok to disrupt Wikipedia, evade a block or ban, or to avoid detection or sanctions. The exit session dialogue is already cluttered enough, and the message can come across as assuming bad faith. Ca ^{talk to me!} 13:15, 8 November 2025 (UTC)[reply]

Pinging translator @K6ka Ca ^{talk to me!} 13:19, 8 November 2025 (UTC)[reply]

You can do such a thing? We should just get rid of that "feature", which has probably already been abused by vandals. Children Will Listen (🐄 talk, 🫘 contribs) 13:32, 8 November 2025 (UTC)[reply]

We have disabled system messages before; simply replacing them with a - is usually enough to hide them. As for the message itself, I'm all for simplifying interface messages (as long as they're still informative enough) so I have no major issues with this message being hidden for us. —⁠k6ka 🍁 (Talk · Contributions) 14:05, 8 November 2025 (UTC)[reply]

I'm talking about the logout button offered for temp accounts. Children Will Listen (🐄 talk, 🫘 contribs) 14:07, 8 November 2025 (UTC)[reply]

Ah yes, that feature wasn't too well documented. Yes, users of temporary accounts can use the "End Session" button to essentially log out of their temporary account (forever), no cookie-clearing required. I suppose there is a concern that it could be used for abuse, but it's not like a warning message would stop determined malice anyway. —⁠k6ka 🍁 (Talk · Contributions) 16:48, 8 November 2025 (UTC)[reply]

At a minimum, I support disabling the "Exit session" feature for blocked temporary accounts. Even if this only stops less determined vandals, removing the feature would still reduce the anti-vandalism workload. — Newslinger talk 16:15, 10 November 2025 (UTC)[reply]

The only qualm I have disabling the feature is that when using a TA, it adds an obnoxious gray bar at the top. Ca ^{talk to me!} 23:43, 10 November 2025 (UTC)[reply]

I agree that being "logged in" to a temporary account offers a worse visual experience than being logged out. As someone who spends a lot more time reading than editing, I'll log out of a temporary account after making an edit to get back to normal. ~2025-32801-03 (talk) 11:24, 11 November 2025 (UTC)[reply]

Hey @~2025-32801-03, this is interesting - why exactly do you believe that the temp account experience is worse for reading? Could you elaborate? Thank you! SGrabarczuk (WMF) (talk) 01:30, 15 November 2025 (UTC)[reply]

Hi @SGrabarczuk (WMF), in addition to the grey bar mentioned above, there's also a sticky header, which by its nature reduces the amount of content on screen. The main menu and tools sidebars also open on each page visit instead of staying closed throughout a session. There's no settings menu for TAs that I'm missing anywhere, is there? I suppose needing to reapply them for each new account would be frustrating in itself, but maybe that would encourage longtime temporary users to create permanent accounts. @SGrabarczuk (WMF) (Forgot to sign) ~2025-34084-82 (talk) 11:09, 17 November 2025 (UTC)[reply]

Thanks @~2025-34084-82, I'm glad to hear back from you. Let's unpack this:

• Sticky header - well, it's there to make it easier to use some tools and reduce scrolling. Some people dislike it, but it's proven to be useful, so it will stay.
• "The main menu and tools sidebars also open on each page visit" - this is a bug; unfortunately not so easy to fix.
• "There's no settings menu for TAs (...) needing to reapply them" - what would you like to see in such a menu? what do you mean by them?

Thank you! SGrabarczuk (WMF) (talk) 11:27, 17 November 2025 (UTC)[reply]

Well, another temp user here to say I hit “end session” every time because the giant banner telling me to make an account is annoying to see on every page. You’ll see a lot of additional churn. ~2025-34811-10 (talk) 01:23, 21 November 2025 (UTC)[reply]

Support – makes no sense FaviFake (talk) 17:20, 11 November 2025 (UTC)[reply]

Pinging @SGrabarczuk (WMF), because this smells like the kind of thing that would be created for legal compliance. WhatamIdoing (talk) 18:29, 12 November 2025 (UTC)[reply]

@K6ka I think there is a mild consensus here to delete. The message also serves to give vandals ideas. Ca ^{talk to me!} 13:33, 20 November 2025 (UTC)[reply]

Agreed. FaviFake (talk) 16:04, 20 November 2025 (UTC)[reply]

The page has been blanked. The message now shown to users ending their session looks like this: File:Enwiki temp account end session dialog as of November 2025.png. —⁠k6ka 🍁 (Talk · Contributions) 23:45, 20 November 2025 (UTC)[reply]

Thanks! Ca ^{talk to me!} 00:01, 21 November 2025 (UTC)[reply]

We have a number of "royal family" templates like Template:British royal family, Template:Danish royal family, Template:Monegasque princely family and so on (see Category:Royal and noble family templates and its subcats) which tend to use formal titles instead of recognisable names / article titles, making them IMO more obscure and unnecessary deferential than is the standard on Wikipedia. I tried to correct this on the British one but was reverted[4].

I don't think it is reader-friendly or useful if a template e.g. has a link to "The Princess of Hanover" when we actually mean Princess Caroline of Monaco, to "The Dowager Princess of Sayn-Wittgenstein-Berleburg" when we mean Princess Benedikte of Denmark, "The Emperor Emeritus" when we mean Akihito, or to "The Duke of Sussex" when we mean Prince Harry, Duke of Sussex. I would propose as a rule that these templates should use the article titles they link to (minus unnecessary disambiguation if applicable) instead of the formal titles. Thoughts? Fram (talk) 09:45, 10 November 2025 (UTC)[reply]

One benefit of the formal titles is that they are resilient to change in who is holding the position - i.e. "The Queen" at Template:British royal family is always covered by 'The Queen' if even the person with that title changes. Katzrockso (talk) 11:55, 10 November 2025 (UTC)[reply]

Hardly a good reason to keep these, as their position in the tree will often change anyway when the title holder changes (e.g. switching of King and Queen in the UK a few years ago). Fram (talk) 14:10, 10 November 2025 (UTC)[reply]

In many cases these are not really "positions" that transfer from one person to another. For example, there was no Duke of Sussex for 175 years until the title was recreated for Harry in 2018. It's possible there will never be another Duke of Sussex when he no longer holds the title. I think Fram is right here, using the article titles is much better for clarity and ease of navigation. I'll also point out that these are borderline WP:EASTEREGGs: in the British template, the link text is "The Duke of Edinburgh" but does not connect readers with Duke of Edinburgh (etc). —Rutebega (talk) 21:18, 13 November 2025 (UTC)[reply]

Agree it is generally a good principle to use article titles, which are already vetted for useful things such as recognizability. If an additional short description is needed then that should be added separately, if too many are needed that suggests the template may not be in the most useful form it could be for navigation. CMD (talk) 04:41, 16 November 2025 (UTC)[reply]

I strongly disagree. The only reason the article on someone like Catherine Middleton is titled “Catherine, Princess of Wales” is because her actual legal name “Catherine Elizabeth The Princess of Wales” 1 would be too long and the title alone “The Princess of Wales” would be too ambiguous. Which is why we had to compromise and choose titles such as “Catherine, Princess of Wales”, “Meghan, Duchess of Sussex”, etc. as article titles despite them being styles used by divorced peeresses. We don't need to perpetuate a wrong format across multiple pages and templates; that goes against the spirit of an encyclopedia that aims to convey the information accurately. Additionally, I don't know why no notifications about this discussion were actually posted to Template talk:British royal family and I cannot understand why the editor who advocated for this change made his alterations limited to the template on the British royal family alone. Also, Wikipedia:WikiProject Royalty and Nobility should have been notified as well because the input of editors who actually edit those articles matters. Keivan.f^Talk 21:53, 18 November 2025 (UTC)[reply]

No, the reason for these article titles is WP:COMMONNAME and consensus. We don't use legal names as article titles in nearly every case, no matter if the subject is a royal or not. This is not a "wrong format". And this is the reason I brought this here without informing the template talk page, to get input from people from outside the bubble, outside the Wp:LOCALCONSENSUS which (in many projects) ignores wider rules or guidelines and ignores what is best for the reader and instead emphasizes some incrowd exactness. Fram (talk) 10:03, 19 November 2025 (UTC)[reply]

That is not entirely correct. "Diana, Princess of Wales" is not the most common name of the subject also known as "Princess Diana" if we were to look at all the available sources, yet we have chosen the title (through several RMs incidentally) based on the fact that 1) it's common AND accurate 2) it's consistent with other titles 3) it follows the MOS:IDENTITY principle as that's how the subject wanted to be known. Same thing applies to her daughters-in-law. Additionally, there was a long discussion back in 2011 as to whether the article on Catherine should be titled "The Duchess of Cambridge" or "Catherine, Duchess of Cambridge" and the community chose the latter as it's clearer even though it is the style of a divorced woman. Also, I never said that you should not have sought input from the wider community. What I did say was that editors who work on these articles should have been notified as well to balance the odds if neutrality is indeed what you seek. And you never know; they might as well end up supporting your proposal. Keivan.f^Talk 14:57, 19 November 2025 (UTC)[reply]

No need for changes, as we have pipelinks. GoodDay (talk) 21:58, 18 November 2025 (UTC)[reply]

If I start an RfC on this (on WP:VPP probably), what would be good questions? I was thinking of

Should the templates in Category:Royal and noble family templates display

• Descriptive titles (like "The Princess Royal" or "The Dowager Princess of Sayn-Wittgenstein-Berleburg" or "The Countess of Carladès"
• Article titles (like "Anne, Princess Royal" or "Princess Benedikte of Denmark" or "Princess Gabriella, Countess of Carladès")

Are more options or other descriptions of the options needed? Fram (talk) 10:09, 19 November 2025 (UTC)[reply]

The big qualitative difference seems to be pure titles vs actually including the subject's name. I doubt it makes a difference to readers if Anne or Benedikte is disambiguated with Princess before or after their name, or even if that disambiguation is different between the title and the template. It is the use of nameless titles that creates the EGG issue. CMD (talk) 15:06, 19 November 2025 (UTC)[reply]

I wanna add the religion and ethnology tables to Slovak places. Example is simple:Prešov#Ethnic_composition and simple:Prešov#Religion. It is a part of my project "SK".

None problem to change a frontend or visual (list or only text), but default visual is 1% table + full text.

Translates (key prefix "en:"):

• c:Data:Translates_of_Religious_belief_of_Slovak_municipalities.tab
• c:Data:Translates of Population ethnicities of Slovak municipalities.tab

This is a extension of Wikipedia:Village_pump_(technical)/Archive_223#h-Population_progress_table_for_Slovak_places-20250730061900. Dušan Kreheľ (talk) 11:01, 18 November 2025 (UTC), Dušan Kreheľ (talk) 16:21, 18 November 2025 (UTC)[reply]

'Unknown' or 'not stated' would be better than 'not found out' Secretlondon (talk) 12:10, 18 November 2025 (UTC)[reply]

@Secretlondon: Both terms are not using. Dušan Kreheľ (talk) 13:46, 18 November 2025 (UTC)[reply]

Well as it stands it's bad English. Secretlondon (talk) 16:06, 18 November 2025 (UTC)[reply]

Yes, perhaps on Simple Wikipedia that passes muster due to the limited vocabulary that is used there, but on normal English Wikipedia it's definitely just wrong, and Secretlondon's suggestion is better. Otherwise this seems like a good effort, provided that relevant sources are available. _signed, Rosguill ^talk 16:09, 18 November 2025 (UTC)[reply]

NEW CCTOP

There is consensus to create a new community-designated contentious topic for "weather events, broadly construed". Administrators are authorized to use the standard set of contentious topic restrictions in this topic area. Toadspike [Talk] 17:00, 18 November 2025 (UTC)[reply]

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.

---

The ongoing disruption around Typhoon Matmo makes me think administrators should have extra tools in the topic area. Previously, in 2022, the topic area was the subject of an arbcom case due to off-wiki coordination around these sorts of issues. Therefore, I propose that administrators are given the ability to use the standard set of community topic restrictions tools on articles related to tropical cyclones, broadly construed. This wording matches the wording that was used for WP:GS/ACAS, but I am open to anything where the meaning is broadly similar. -- Guerillero ^{Parlez Moi} 17:50, 9 October 2025 (UTC)[reply]

Notified: Wikipedia:Administrators' noticeboard. voorts (talk/contributions) 01:16, 10 October 2025 (UTC)[reply]

Support, but preferably for weather as a whole. For reasons which I can’t really identify, the entire topic area is highly controversial and tends to be caught up in ArbCom cases, ANI reports and edit wars. ^EF⁵ 17:57, 9 October 2025 (UTC)[reply]

Climate change. Sapphaline (talk) 19:51, 9 October 2025 (UTC)[reply]

It’s not even that, it’s just that there is a long history of disputes throughout the entire topic area. So much so that I proposed the same thing as a result of numerous LTAs, two ArbCom cases and overall disruption, but was shot down. ^EF⁵ 20:10, 9 October 2025 (UTC)[reply]

Contentious topics tend to arise when a majority of the editors involved start attaching significant emotional weight to whether articles are (by their definition) "right", which correlates with a high concentration of either special interests or special interests. There's a small amount of the former regarding weather, but it's mostly the latter. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 03:16, 10 October 2025 (UTC)[reply]

I've been watching the most recent saga at AN/I, and while making no comments on that particular case, I think some of the disruption in the area is at least partially because the weather editor base skews very young. (At least, that's been my impression) Which isn't in itself an issue (there's plenty of younger Wikipedia editors who are, not just constructive, but highly skilled editors!), but if you put a bunch of developing humans learning conflict resolution for the first time in group, give them conflict and very little supervision, then edit wars and the like are just going to happen. Anyways, I support giving admins an increased ability to quietly separate people in this topic area (weather or tropical cyclones) and tell them to knock it off without dragging them through high-profile AN/I threads. GreenLipstickLesbian💌🦋 18:07, 9 October 2025 (UTC)[reply]

To clarify, are you proposing that the community-authorised discretionary sanctions procedures be followed, with the standard set of contentious topic restrictions authorized for use? As I discussed earlier this year, the community-authorised discretionary sanctions procedures have different notification requirements and restriction durations than those under the contentious topics framework. isaacl (talk) 18:28, 9 October 2025 (UTC)[reply]

What are the different notification and restriction requirements? I'm not seeing anything at WP:GS that indicates a difference. voorts (talk/contributions) 01:29, 10 October 2025 (UTC)[reply]

The contentious topics framework requires a specific template to be used the first time an editor is made aware of a contentious topic, but any message can be used to make editors aware of further contentious topics (see Wikipedia:Contentious topics § Awareness of contentious topics). A single administrator can impose an indefinite restriction upon an editor (see Wikipedia:Contentious topics § Procedural summary).

With the authorization for discretionary sanctions framework, a specific template must be used to make an editor aware for each topic covered by discretionary sanctions, and the notification must be re-issued every twelve months (see Wikipedia:Arbitration/Index/Discretionary sanctions (former) § Awareness). (Anyone participating in proceedings related to the discretionary sanctions area in the last twelve months is also considered to be aware; this is more generally covered by the "any message" condition for contentious topics.) Restrictions on an editor enacted on the basis of the authorization for discretionary sanctions can have a maximum duration of one year (see Wikipedia:Arbitration/Index/Discretionary sanctions (former) § Sanctions). One approach that some administrators take, when appropriate, is to impose a one-year restriction under the discretionary sanctions framework, and a subsequent indefinite restriction under regular policy (if it permits). This means that appeals of the restriction have to take place at the arbitration enforcement noticeboard for the first year, but then reverts to the usual appeal process.

There may be other differences between the two frameworks that I do not recall at the moment. isaacl (talk) 02:00, 10 October 2025 (UTC)[reply]

RE your second paragraph, there's a big notice at the top of that page that says:

This Wikipedia page has been superseded by the contentious topics procedure and is retained primarily for historical reference. It is also referenced by some community sanctions. For more information on the transition to the contentious topics procedure, see the Committee's transition guide. This page reflects the text of the discretionary sanctions procedure immediately prior to the adoption of the contentious topics procedure.

voorts (talk/contributions) 02:08, 10 October 2025 (UTC)[reply]

It says "referenced by some community sanctions", not all. We don't need to follow that for future community sanctions. voorts (talk/contributions) 02:09, 10 October 2025 (UTC)[reply]

Yes. That's why the community should make it explicit: is this a proposal to use the older discretionary sanctions procedures, or to use the contentious topics procedures? The community hasn't obsoleted the use of the discretionary sanctions framework for new topics, and it hasn't converted any of the pre-existing community-authorized topic areas to use the contentious topics framework. (The arbitration committee did both of these, and they own the discretionary sanctions page, so they wrote the notice from their point of view.) isaacl (talk) 02:24, 10 October 2025 (UTC)[reply]

For whatever reason our weather (as opposed to climate) articles appear to have attracted a rather immature crowd with (I'm not sure how to say this without offending anyone) trainspotterish tendencies. Most seem to be be prepared to listen, at least more so than the nationalist editors who inhabit many other contentious topics, so I think they just need a little more adult guidance than is usually the case rather than any formal declaratiom that this topic area is contentious. Phil Bridger (talk) 20:33, 9 October 2025 (UTC)[reply]

No, you’re completely right - “weather nerds” do tend to have ASD-related conditions, something studied by the American Meteorological Society in 2020, a study visible on my userpage. Plus, a lot of the weather-interest community is younger (theres a newspaper somewhere mentioning how many of WPTC’s members are teenagers). ^EF⁵ 20:47, 9 October 2025 (UTC)[reply]

In my opinion,the best way to provide that adult guidance would be through empowering admins rather than dragging people through very public threads at AN or ANI -- Guerillero ^{Parlez Moi} 10:26, 10 October 2025 (UTC)[reply]

Us "trainspotters" have been able to self-police and avoid major disruption just fine. Why is it that weather editors cannot? I'm quite literally on the spectrum myself... Trainsandotherthings (talk) 20:51, 10 October 2025 (UTC)[reply]

Support, I have spent the last couple of days going over this issue and started writing an essay about this which can be found here. I've pull some highlights and plots from that essay here to make my point but the tldr is we need to make some changes because this keeps happening.

My recent interaction with the Typhoon Matmo (2025) article brought up a lot of challenges storm articles face as an outline of the Matmo storm I noticed the following.

• As of sometime yesterday of the 199 edits to the article 65 (or 32%) have been reverted or restored this week.
• Requested admin actions came into RFPP, Wikipedia:Requests_for_page_protection/Archive/2025/10#Draft:Tropical_Storm_Matmo_(2025)
• ANI Wikipedia:Administrators'_noticeboard#Can_someone_figure_out_what_is_going_on_with_these_tropical_storm_drafts? and Wikipedia:Administrators'_noticeboard/Incidents#Ban-evading_proxy_IP_causing_disruptions_across_typhoon_articles
• Even I screwed up! User_talk:Dr_vulpes#Draft:Tropical_Storm_Matmo_(2025).

Standardized Chaos: When Everyone Has Their Own Storm

One source of conflict I observed from a recent article Tropical Storm Mateo stems from how tropical cyclones are named and by which meteorological agency. For inexperienced editors or editors who are new to the project they either lack knowledge of the rules or only grasp the basic fundamental rules. From this perspective it creates an odd edge case as the material on storm names being added or removed from articles is not a case of unreliable versus reliable sources. To new editors all of these meteorological agencies qualify as reliable sources, further they are all being reported on by trusted reliable secondary outlets. So when the Japan Meteorological Agency calls a storm "Neoguri" while PAGASA calls it "Helen," both names are at least somewhat “correct”.

In the Western Pacific, typhoons face a complex naming situation. The Japan Meteorological Agency assigns international names to tropical cyclones on behalf of the World Meteorological Organization, while PAGASA assigns names to any tropical cyclone that enters or forms in their country. This means a typhoon can legitimately carry two different names simultaneously. For example, CNN had to report both names last month “Typhoon Ragasa, known in the Philippines as Nando”. Other issues arise when agencies use different ways of describing typhoons. For example Hong Kong has used a numbered warning system since 1917 that had been introduced by the British.

The New Editor Problem

Active tropical cyclones attract editors who may be participating in Wikipedia for the first time. These storms are current events with readily available structured data, making them seem like easy and important articles to edit. However, editors’ unfamiliarity with Wikipedia's policies and culture, leads to a rise in problematic behaviors: article ownership, edit wars, and Misunderstanding when to get an admin involved. There is a longer version of this in my essay.

Why is this all a problem?

Active edit conflicts can create a lot of work our community. Instead of working on articles or performing admin tasks, resources are instead dedicated to:

• Monitoring and policing active storm articles
• Helping out and educating new editors with policies and guidelines
• Handling disputes that arise between new editors
• Page protection that are dealing with an edit war
• Handing out warnings to talk pages and blocks if needed

Analysis

I did some analysis in R (code) to look at the number of weather related issues at WP:RFPP, and WP:AN/I.

Weather Related Page Protections at WP:RFPP

Looking at this plot we see that there's a spike in page protection activity from WP:RFPP during tropical storm seasons in the northern hemisphere.

Weather Related WP:AN/I Complaints

6053 weather related complaints brought to WP:AN/I between 2010 and early October 2025 by category.

What can we do to address this?

These were just some things I thought might address the issue with storm articles.

• Welcome templates: Creating a new welcome message for weather articles. Include links to policies and sources new users might find helpful. Clearly explain known issues like the multiple source naming issue for Typhoons.
• Talk page templates: Create banners for article talk pages that explain the issues these articles have.
• Proactive protection: Protecting active storms articles with semi-protection until a period of time has passed after the storm has dissipated

Dr vulpes (Talk) 23:45, 9 October 2025 (UTC)[reply]

This feels like a mis-analysis of the situation. Typhoon naming practices are long established and standardised: the JMA name is used for article titles and most text, other names are included where relevant in the lead in the normal Wikipedia fashion. Naming is not an issue. The most recent disruption is around DATEVAR, curiously enough. I'm not sure about the newness of all the editors, but the broad and somehow persistent problem (went to arbcom a few years ago) seems to be that WPTC develops an insular culture that drifts from the general expectations of en.wiki. If the community is going to intervene, the best way to do that would be to figure out why this drift happens, and try to develop the WikiProject to better guide new editors. CMD (talk) 01:45, 10 October 2025 (UTC)[reply]

I think Dr vulpes' analysis matters less than the data, which are clearly cause for concern. voorts (talk/contributions) 01:50, 10 October 2025 (UTC)[reply]

(edit conflict) "Naming" being the root cause of these issues is unconvincing. A few years back, the biggest issue was the constant conflict in updating storm data (pressure, wind speeds, position, etc.) but that hasn't been a problem since {{Infobox weather event/live}} was deleted (see discussion, related ANI). We've had a long history of including data from various meteorological agencies with no issue. What becomes an issue is when editors, especially new ones, jump into the weather article topic without any prior knowledge of Wikipedia, try to race to be the "first person" to add something to the article, and end up complaining or reverting when others get it done first. This applies to both edits and drafts; we even have editors making drafts under any conceivable potential name, which there are many as a storm develops (e.g. "Tropical Depression Matmo", "Tropical Depression Paolo", "Tropical Storm Matmo", "Tropical Storm Paolo", "Typhoon Matmo", "Typhoon Paolo", and all other variants of this with a year disambiguator). I find this issue to be a worse case of what we have on recent events articles in general: people trying to race to keep an article "up to date" and exhibiting WP:OWN-like behavior when they don't get their way.

That aside, I'm wondering what methodology was used in the analysis of ANI topics related to weather complaints. 6,054 sections of weather-related complaints in a 15-year period does not seem likely. Doesn't look like any R code was included for this so I'm unable to tell just how this conclusion was made. I also find the need to point out that "proactive protection" is specifically against WP:PREEMPTIVE. The LLM used here really missed the mark and it, much like the weather editors, seems unaware of how Wikipedia policies and guidelines work. Chlod (say hi!) 01:52, 10 October 2025 (UTC)[reply]

Please do not accuse other editors of illicitly using LLMs.That is a serious accusation. voorts (talk/contributions) 01:56, 10 October 2025 (UTC)[reply]

The code writes I used an AI/LLM to help with dates and regex because they always frustrate me. in the comments and the full essay is something that I would consider as LLM-supported (not necessarily "written", I don't have an issue with people using LLMs to help them improve their own writing) text. Am I supposed to think otherwise? Chlod (say hi!) 01:59, 10 October 2025 (UTC)[reply]

I don't think I even mentioned that the use of the LLM here is "illicit" either. Last I checked, WP:LLM is just an essay. Chlod (say hi!) 02:01, 10 October 2025 (UTC)[reply]

You stated that [t]he LLM used her really missed the mark and it ... seems unaware of how Wikipedia policies and guidelines work. That clearly implies that you believe Dr vulpes advanced the views of AI rather than his own. voorts (talk/contributions) 02:03, 10 October 2025 (UTC)[reply]

@Chlod the only LLM use that was used here was in the code section and is noted in the comments. At around line 2 and 446.

"# I used an AI/LLM to help with dates and regex because they always frustrate me."

"# I used AI/LLM here for the shading on dates in this plot because I'm lazy"

Dr vulpes (Talk) 02:07, 10 October 2025 (UTC)[reply]

I'll strike that section from my comment then. We're getting hung up over LLMs rather than the point that having different names for cyclones is not the proper analysis here. Chlod (say hi!) 02:10, 10 October 2025 (UTC)[reply]

Does the cause of the disruption really matter all that much? Ultimately, we're deciding whether to authorize standardized sanctions. voorts (talk/contributions) 02:13, 10 October 2025 (UTC)[reply]

I believe the reasoning for why we're deciding whether to apply sanctions is definitely relevant to the discussion and is highly important in informing anyone else who comes across this thread with no prior background on the 'situation' of tropical cyclone (and general weather-related) articles on the wiki. I, for one, would prefer not having sanctions on a topic area based on uninformed consensus. Much like we don't block users who haven't done anything, we shouldn't apply sanctions on topic areas without properly asserting the cause and, if applicable to whoever's participating in the discussion, determining whether such sanctions are necessary for the causes identified. Chlod (say hi!) 02:20, 10 October 2025 (UTC)[reply]

Of course the cause matters in applying sanctions, it helps determine whether the sanctions are effective. We should not be making them on the back of lllm-analyses. The underlying issue has not yet been figured out, and proposed solutions like proactive protection are far outside of the usual community norms, as well as not going to do anything for any of the non-IP editors. CMD (talk) 02:28, 10 October 2025 (UTC)[reply]

Sorry if it wasn't clear, this isn't a full analysis and breakdown of the issue. I should have put some more work into the post to explain that this is just what I saw as issues that came up or could come up and somethings I could support with data. For example there's this edit showing what I'm talking about with storm names. I'm not saying it's the whole issue at hand, it's an edge case that could be an issue (or might have been in the past). The real question to ask "is there abnormal disruptions in active storm articles? Should we do something about it?" and the answer to both I believe is yes. Dr vulpes (Talk) 03:47, 10 October 2025 (UTC)[reply]

Support authorizing the standard set for all edits related to weather events, broadly construed (n.b. this would encompass, at the very least, all articles in Category:Weather events) and allowing administrators to impose preemptive semi-protection on articles or drafts related to weather events, broadly construed, per @Dr vulpes and @EF5. voorts (talk/contributions) 01:43, 10 October 2025 (UTC)[reply]

FWIW, I would also support a broader topic area, such as weather events. I thought that the more narrow scope of just tropical cyclones would have a better chance here. -- Guerillero ^{Parlez Moi} 10:30, 10 October 2025 (UTC)[reply]

Support for weather events, broadly construed. Oppose preemptive protection. In the ongoing AN/I thread, the greater disruption has come from registered accounts than from IPs. The main thing community CTOP would be useful for here is allowing admins to impose TBANs, page-level revert restrictions, and editor-level revert restrictions. A lot of weather editors seem to have fallen under the impression that they are allowed to revert freely and infinitely as long as they are on the right side of their wikiprojects' guidance or just an informal consensus of a few weather editors. They need to either course-correct or face editing restrictions. I've also added a proposal below for a warning to the wikiprojects collectively. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 03:42, 10 October 2025 (UTC)[reply]

Comment: (Copy-paste from what I just posted at AN/I:) Whereas the recent events were all around tropical cyclones and DATERET (and are in fact still ongoing) I would rather say the actual problem in question was essentially (i) a general bias among some aggressive users against unregistered editors, (ii) the tendency among some admins to grant page protections and blocks too easily, again, against unregistered editors, and, most importantly, (iii) the non-compliance attitude among some editors towards established policies and guidelines, and the atmosphere that such policies and guidelines can be ignored or looked down upon and the reasonable expectation among them that they would face no sanctions for doing so. 219.79.142.128 (talk) 17:31, 10 October 2025 (UTC)[reply]

It's not just recent events that are at issue. We don't propose community sanctions over recent events, but rather ongoing disputes. Weather events have long been contentious. voorts (talk/contributions) 20:01, 10 October 2025 (UTC)[reply]

I don't know whether what I have observed happens only around weather topics. 219.79.142.128 (talk) 13:05, 12 October 2025 (UTC)[reply]

Support for weather events, broadly construed. I've been involved in the weather scene as an enthusiast (mostly off-Wikipedia) for over a decade, and the observations made above, such as by Phil Bridger, about the "trainspotterish" (or autism-related) tendencies of people in this scene I have found from my experience to be broadly correct. And it does not help that much of this audience tends to skew younger; and there are, well, other factors as well that, while relevant, are IMO not really worth talking about here. I'll only say that the toxicity I have witnessed both on and off Wikipedia in this topic area has got me to keep away from editing much in the area (partly due to a feeling of frustation). Leastways I think that a CTOP designation would help with dealing that toxicity and the related rampant edit-warring that has been common in the area, as well as the user-conduct issues that are periodically brought to the noticeboards. The WPTC ArbCom case dealt with some of these issues, but it is my experience that the area now has new troublemakers; and enabling admins to deal with them through the CTOP toolkit would make for a better editing environment in the weather area. JavaHurricane 10:52, 11 October 2025 (UTC)[reply]

• Support any version of discretionary sanctions or contentious topic procedures for tropical storms. There has been too much disruptive editing in this area for too long. I do not have an opinion about extending the sanctions to weather in general at this time, but would be interested in seeing examples of disruptive editing on weather outside tropical storms. Robert McClenon (talk) 23:28, 15 October 2025 (UTC)[reply]
• Support for weather events, broadly construed. The above discussion makes it clear that this is necessary. (Procedural point, I believe this would, as community imposed, be a general sanction; contentious topics are imposed by Arbcomm.) - The Bushranger _{One ping only} 00:41, 16 October 2025 (UTC)[reply]

  I closed a discussion a year and a half ago to change GS/DS to CTOPs, but I guess nobody ever implemented it. voorts (talk/contributions) 00:51, 16 October 2025 (UTC)[reply]

  For better or worse, the arbitration committee is more willing to engage in the amount of process-wonkery needed to establish a type of general sanctions than the community. There just hasn't been enough people interested in figuring out the details of a process for community-designated contentious topics, and to establish a consensus to adopt it. Taking this proposal as an example, people focus on making the standard set of actions from the contentious topic framework available, and assume the rest of the process is staying the same (which implicitly means the discretionary sanctions framework). isaacl (talk) 03:02, 16 October 2025 (UTC)[reply]

  General sanctions is a general term for editing restrictions that aren't being applied to a specific user, but to all users. One type of general sanction is the designation of contentious topics, which was created by the arbitration committee to replace its use of the authorization for discretionary sanctions. (The arbitration committee intentionally designed the contentious topics framework to enable the community to use it, if it chose to.) The community has also authorized discretionary sanctions for some topics, but unlike the arbitration committee, it never converted them to the contentious topics framework. The community could choose to either use the discretionary sanctions framework, or the contentious topics framework for new general sanctions. isaacl (talk) 02:51, 16 October 2025 (UTC)[reply]

• Comment: If we are going to do this, I would urge that that scope be set towards the narrower rather than the broader portion of the range described by differing editors above. I trust the analysis of various editors above in describing the problems with this area, but "Weather" is just such an immensely broad descriptor with potential for overreach into all kinds of areas not necessarily contemplated by this discussion. I can't be the only one on this project with a concern that CTOP has grown to subsume so much of the overall subject matter of this project that we are quite literally nearing an inflection point where it will, if you use even moderately broad interpretations of the scope of particular designations, include the majority of content on the encyclopedia, thus fundamentally changing the community and governance model of the project? I mean to be fair, I haven't seen a single other person acknowledge that point is coming soon or arguably has already arrived, and that it carries implications that we haven't collectively addressed...but I just assume that this has surely occurred to others, and that among those who have considered it, I'm also not the only one who has concerns about the potential unintended knock-on impacts of the fact that this has augmented the remit (and power to curtail or shape discussion) of the average admin by a factor of about fifty? SnowRise ^{let's rap} 05:25, 17 October 2025 (UTC)[reply]

  I am pretty sure that I heard people wondering when every set of pages was going to be subject to its own DS or GS scheme years ago. Jo-Jo Eumerus (talk) 09:12, 17 October 2025 (UTC)[reply]

  I share your concern. Phil Bridger (talk) 09:30, 17 October 2025 (UTC)[reply]

  The broadest version that seems to have support here is "weather events" not everything having to do with "weather" -- Guerillero ^{Parlez Moi} 11:03, 17 October 2025 (UTC)[reply]

  All the !votes I see are for my proposal for weather events. I think that's as narrow as we can get. voorts (talk/contributions) 13:49, 17 October 2025 (UTC)[reply]

  I guess we could limit it to articles about particular weather events (ie the weather events category I linked to above), lists about weather events, and sections of articles about weather events, and any edits related to those things, but I think that is effectively the same as "weather events". voorts (talk/contributions) 13:52, 17 October 2025 (UTC)[reply]

  Would it be sufficient to apply it to tropical cyclones only? JoJo Eumerus mobile (main talk) 14:07, 17 October 2025 (UTC)[reply]

  That might be ideal, but I do think "weather events" is probably as narrow as we can go while still reading consensus from the forgoing discussion. I do think that is still an improvement upon just "weather", though it might be important to make sure the closer leaves out the typical "broadly construed" verbiage from the formal wording when the CT is defined/logged; otherwise I fear there might as well be no distinction made between "weather" and "weather event" when the CTOP is interpreted. SnowRise ^{let's rap} 22:09, 17 October 2025 (UTC)[reply]

  I don't think that's broad enough. The disruption isn't limited to tropical cyclones. voorts (talk/contributions) 22:11, 17 October 2025 (UTC)[reply]

Supplementary proposal: General warning to WikiProjects Weather and Tropical Cyclones

[edit]

Moved to WP:ANI § Proposed general warning to WikiProjects Weather and Tropical Cyclones

 – Tamzin^{[cetacean needed]} (they|xe|🤷) 07:25, 11 October 2025 (UTC)[reply]

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.

Hi! Some days ago, with a group of users at eswiki, we created a module + template for easily creating colored maps. I just imported it to enwiki (see Template:Map, Module:Map and Module:Map/world). Here's a very basic example of the wikitext followed by the output:

{{Map
| countries = Brazil, Mexico, Egypt, China, Australia
}}

See the template documentation for more examples and features. The template not only makes it easy to create maps (no more need to upload SVGs to Commons) but also to update said maps, and to watch said updates.

We're continuing development at a fast pace, but would love to hear your ideas, needs and feedback too. Cheers! Sophivorus (talk) 13:27, 19 November 2025 (UTC)[reply]

Before you usurp a redirect, please check all incoming links to ensure that it is not being used or linked to with a different meaning. – Jonesey95 (talk) 18:05, 19 November 2025 (UTC)[reply]

I did! I might have missed something though. Sophivorus (talk) 23:11, 19 November 2025 (UTC)[reply]

This is awesome!! Are you planning to build similar templates for sub-national boundaries (for example, US states)? Anne drew (talk · contribs) 18:21, 19 November 2025 (UTC)[reply]

Yes! The module is already prepared for it, actually. It's just a matter of creating and curating the data for each specific new map. We'll get to the US soon enough! ;-) Sophivorus (talk) 23:12, 19 November 2025 (UTC)[reply]

Looks good, thanks. Ymblanter (talk) 22:04, 19 November 2025 (UTC)[reply]

First of all, yes, brilliant idea! Secondly, what boundaries are you using in the case of disputes? Which countries are "recognized" by this template? It sounds silly, but could be a real concern in the case of India/Pakistan, Israel/Palestine, Abkhazia, Transnistria, Somalia, Ukraine/Russia, etc. It looks to me like "lines of actual control" are used in Kashmir, and that the West Bank appears but not Gaza. —Ganesha811 (talk) 12:16, 20 November 2025 (UTC)[reply]

@Ganesha811 Hm, that's a tough one. Could you help us by creating a topic about this issue at Module talk:Map? Sophivorus (talk) 12:47, 20 November 2025 (UTC)[reply]

Done. —Ganesha811 (talk) 12:50, 20 November 2025 (UTC)[reply]

		What a Brilliant Idea Barnstar
		I love this suggestion, thank you for it! Wikieditor662 (talk) 06:25, 20 November 2025 (UTC)[reply]

PS for suggestions, I'd recommend adding ways to change the color, if you haven't already. Wikieditor662 (talk) 06:25, 20 November 2025 (UTC)[reply]

Looks like that's already in the documentation Katzrockso (talk) 12:29, 20 November 2025 (UTC)[reply]

It's a really cool idea, but I'm not sure if the current API is the best design. I think it'd be better to have color1/countries1, color2/countries2, etc. For complex maps it would make it a lot easier to see what countries are what and update the colours.  novov talk edits 03:57, 24 November 2025 (UTC)[reply]

@Mir Novov Interesting idea! Could you bring it over to Module talk:Map, please? Thanks! Sophivorus (talk) 11:26, 25 November 2025 (UTC)[reply]

They already have a few days ago... Wikieditor662 (talk) 16:25, 25 November 2025 (UTC)[reply]

• We know the article is from Wikipedia, so that's mostly redundant text.

• Replacing it with the short description of an article would offer the reader more information and allow them to gleam what the article is about when the lede is very long
• In the case of no short description, keep "From Wikipedia, the free encyclopedia"

OmegaAOLtalk? 10:19, 20 November 2025 (UTC)[reply]

Support - better to have some information than none. GarethBaloney (talk) 13:21, 20 November 2025 (UTC)[reply]

Interesting idea, although I don't think I can support it.

That tagline has never been my favorite, since roughly 95% of readers are going to misinterpret "free". Still, it's an opportunity to establish our brand. It's also a place where we recently agreed to add good/featured status, which would be overridden with this.

I also have concerns about putting the short description there. Short descriptions were developed for the express purpose of helping readers disambiguate among search results. I've never been happy with the decision to display them on the mobile version of articles because they are generally redundant to the lead sentence, and displaying them on desktop as well would make that issue worse. If the lede is very long and doesn't establish the topic up front, then that's an issue to fix with the article, not something to be addressed via the tagline. Sdkb ^talk 15:34, 20 November 2025 (UTC)[reply]

TBF, many featured articles have quite long leads. Although I didn't know about the article status addition. Maybe we can add it before? For example:

Act of Accord

==================

1460 act of the Parliament of England • A featured article from Wikipedia, the free encyclopedia OmegaAOLtalk? 16:11, 20 November 2025 (UTC)[reply]

This raises the question of using every article status. Maybe just GA and FA-class articles? I don't think non-editors would really understand the ranking system that's used. Maybe hovering over FA and GA gives a short blurb about what an FA and GA is. PhoenixCaelestis ‣ _Talk // ^{Contributions} 16:48, 20 November 2025 (UTC)[reply]

I think that this is the plan already. OmegaAOLtalk? 16:57, 20 November 2025 (UTC)[reply]

@Sdkb also, if you are unhappy with the mobile design, try using the Monobook skin on mobile instead. It has a responsive mobile design that is basically just the full-featured desktop site in an accessible, phone-usable format. Vector or Vectornew doesn't have a responsive design though so you can only do this with monobook. OmegaAOLtalk? 16:59, 20 November 2025 (UTC)[reply]

Please read MediaWiki talk:Sp-contributions-footer#Implement the following code on MediaWiki:Sp-contributions-footer-temp?. Thanks. Codename Noreste (discuss • contribs) 14:36, 21 November 2025 (UTC)[reply]

Temporary accounts should be allowed to create their own user page. Of course after a few days of inactivity this page will be automatically deleted. It helps with allowing new users to see what they can do on Wikipedia. And also helps make clarifications and introductions instead of dumping it on the talk page. ~2025-34140-84 (talk) 01:39, 22 November 2025 (UTC)[reply]

I tried creating your userpage and it seems to work. It seems that users with normal accounts can create temporary account userpages. But you can't? ✨ΩmegaMantis✨^blather 01:49, 22 November 2025 (UTC)[reply]

@~2025-34140-84 replied on my talk page and said it was because I was an AC user, which can create all user pages. ✨ΩmegaMantis✨^blather 01:52, 22 November 2025 (UTC)[reply]

There's still no mechanism for deleting the page when the temp account goes away. The page you just created will exist forever or until MfD, whichever comes first. ―Mandruss ☎ 2¢. IMO. 01:54, 22 November 2025 (UTC)[reply]

Then it should automatically be deleted. To save space and so other users who later adopt the IP feel like they have a fresh start. ~2025-34140-84 (talk) 01:58, 22 November 2025 (UTC)[reply]

I will propose it at MfD. This is a very trouty moment for me and I apologize.

Also, it seems you have put your political views on your de facto userpage. You're welcome to do so, but the primary focus for a user account and page is for edits, not WP:SOAP. ✨ΩmegaMantis✨^blather 02:02, 22 November 2025 (UTC)[reply]

Disagree. The purpose of a Userpage is for the user to introduce themselves. SmokeyJoe (talk) 09:25, 22 November 2025 (UTC)[reply]

I believe that the deletion (or maybe just blanking) is better suited for WP:BOTREQ. Currently, there are bots which blank out IP talk pages after a certain duration. ~/Bunnypranav:<ping> 03:18, 22 November 2025 (UTC)[reply]

Ooh, good suggestion! Would you mind doing it -- I've already screwed up quite a bit on this matter, including with my deletion proposal. 😅...sigh ✨ΩmegaMantis✨^blather 03:34, 22 November 2025 (UTC)[reply]

Temporary account holders with any desire to have a Userpage should WP:Register. SmokeyJoe (talk) 09:23, 22 November 2025 (UTC)[reply]

+1 fifteen thousand two hundred twenty four (talk) 14:20, 23 November 2025 (UTC)[reply]

Ageee. Given the ephemeral nature of temporary accounts giving them userpages will result in large amounts of abandoned pages piling up.  novov talk edits 01:23, 24 November 2025 (UTC)[reply]

This is a perennial request. I think I've seen it at WT:TWINKLE three different times. I'd like to get wider feedback before making a change:

Under what circumstances should Twinkle inform a page creator that one of their pages has been nominated for deletion? Example notification.

• Option A - Post a deletion notification for both unblocked and blocked authors. (status quo)
• Option B - Post a deletion notification for unblocked authors only. Skip posting to blocked authors. (proposed change)

Note that this will apply to every kind of XFD: articles, templates, categories, redirects, files, etc. This may also apply to PRODs and CSDs. This may apply to both nominations and instant deletions. Note that there is a small subset of blocked users that are also deceased. –Novem Linguae (talk) 09:37, 25 November 2025 (UTC)[reply]

• Option A - I filed the above pro forma because I am a Twinkle maintainer. I actually prefer the status quo. 1) if the user ends up unblocked soon, they may want to know what is happening to their articles, 2) talk page watchers may also want to keep an eye on that user's articles, and 3) it's been the status quo for a very long time. –Novem Linguae (talk) 09:37, 25 November 2025 (UTC)[reply]
• Option A - We want blocked users to return and make helpful contributions. We should give them the tools to do so and not withhold information that would be useful when they're unblocked. ~2025-36374-38 (talk) 10:49, 25 November 2025 (UTC)[reply]
• Option A. I follow the talk page of a user who hasn't edited in years to keep track of the articles they have created getting nominated for deletion, as most of them can be saved. I am sure this is a reasonable use case for blocked users too.Katzrockso (talk) 10:56, 25 November 2025 (UTC)[reply]
• Option A per above. Twinkle should be notifying more users about potential deletions (e.g. major contributors), not fewer. Thryduulf (talk) 12:01, 25 November 2025 (UTC)[reply]
• Option C - I agree with most of the considerations expressed by the thus far unanimous A position. However, there are some cases, like editors blocked for UPE, or in other cases of indefs for serious abuse, where it would be nice to have the option not to send an automatic notification, thus my suggestion would be to have this be an optional toggle rather than always/never notifying blocked editors. _signed, Rosguill ^talk 14:26, 25 November 2025 (UTC)[reply]

  @Rosguill there's already a toggle for notifying or not. I think it's in practice mostly used to avoid spamming notifications when there's a ton of connected nominations from the same creator at once. An option could be to change the default to don't notify for users in certain categories or that have certain block templates on their page. There might be something of the kind already but couldn't find it with a quick look at the code if so. Trialpears (talk) 16:30, 25 November 2025 (UTC)[reply]

  I guess that shows how long it's been since I've actually nominated an article for deletion myself _signed, Rosguill ^talk 16:32, 25 November 2025 (UTC)[reply]

  I was also going to suggest the categories idea. Does anyone have some specific categories in mind to automatically exclude? Sockpuppets, retired, deceased? Category:Wikipedians who opt out of template messages? Although the downside of that would be that talk page watchers would not be able to see and participate in those deletion discussions. –Novem Linguae (talk) 17:19, 25 November 2025 (UTC)[reply]

  Globally locked accounts maybe? I feel like there’s a subset of LTAs that we’d want to minimize contact with, but I don’t think they’re already denoted with any particular exclusive category _signed, Rosguill ^talk 17:28, 25 November 2025 (UTC)[reply]

• Option A per points (1) and (2) in Novem's !vote. I don't mind an option to not notify, but it shouldn't be the default. Sdkb ^talk 16:34, 25 November 2025 (UTC)[reply]
• Option B User:Ritchie333/Don't template the retirees applies in force. In practice when a prolific user is blocked (or stops editing for any other reason) the result is that the talk page gets taken over by a nearly endless amount of templates, the vast majority of which don't lead to any useful action. * Pppery * _{it has begun...} 16:53, 25 November 2025 (UTC)[reply]
• Option A per Katzrockso. While I kind of lean towards B, personally, Katzrockso makes a good argument about TPS getting the notifications as well. And if someone is blocked for a month and a notification is missed, that's not ideal either. --SarekOfVulcan (talk) 16:59, 25 November 2025 (UTC)[reply]
• I'm unsure but I do feel that option B should definitely not apply to editors on short term blocks. I'd probably support it for indefed editors. That said, what's the problem with their notifications stacking up anyway? It's not like many people are going to see them. I do worry that somebody could game option B. Imagine some troll who goads an editor into catching a short block and then uses a sock or meat account to nominate all that editor's articles for deletion in the hope that they won't notice. OK, sure, they can do that anyway without Twinkle, but let's not make it easier for them. --DanielRigal (talk) 19:07, 25 November 2025 (UTC)[reply]

  I agree. For example we regularly block people and delete their spam articles. Some users then get renamed and rehabilitated. They'd like to know that their article has been deleted. Secretlondon (talk) 22:32, 25 November 2025 (UTC)[reply]

• If it has to be A or B then I guess A, as I think we should certainly template people who are temporarily blocked for edit warring or similar, and it would be detrimental if we didn't. Secretlondon (talk) 22:34, 25 November 2025 (UTC)[reply]

The alert and notification bell icons, at least as seen in Vector 2010, Monobook, Cologne Blue, and Modern, are blurry at the scale of these older skins and do not fit the skins in question, as they were added after the time of these skins. The example of Monobook before (http://bayimg.com/baHhPAAbh) and after (http://bayimg.com/cAhHAaABH) deleting the icon classes in DevTools shows that it is both more fitting with the rest of the design and more readable.

They do work nicely in Vector 2022, Minerva, and Timeless, so they should be retained there. OmegaAOLtalk? 07:56, 26 November 2025 (UTC)[reply]