Wikipedia:Village pump (all)

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

(to see recent changes on Village pump subpages)

Village pump sections

Policy

post, watch, search
Discuss existing and proposed policies

Technical

post, watch, search
Discuss technical issues about Wikipedia

Proposals

post, watch, search
Discuss new proposals that are not policy-related

Idea lab

post, watch, search
Incubate new ideas before formally proposing them

WMF

post, watch, search
Discuss issues involving the Wikimedia Foundation

Miscellaneous

post, watch, search
Post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations

I want...	Then go to...
...help using or editing Wikipedia	Teahouse (for newer users) or Help desk (for experienced users)
...to find my way around Wikipedia	Department directory
...specific facts (e.g. Who was the first pope?)	Reference desk
...constructive criticism from others for a specific article	Peer review
...help resolving a specific article edit dispute	Requests for comment
...to comment on a specific article	Article's talk page
...to view and discuss other Wikimedia projects	Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography	Citing Wikipedia
...to report sites that copy Wikipedia content	Mirrors and forks
...to ask questions or make comments	Questions

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Are political userboxes now allowed in Templatespace?

Back in 2006, political userboxes were userfied per WP:Userbox migration as a result of the Great Userbox War. Since then, it appears that a lot of them have popped up again in the Template namespace. Also, the index page for WP:Userboxes/Politics by country, which had been userfied following MfD in 2009, was moved back to Projectspace in 2020 by a now-indeffed user, apparently without discussion. I was would revert the move, but then 16 years is a long time for consensus to possibly have changed, so I thought I'd ask here first:

1. Is current consensus in favour of allowing political userboxes in the Template namespace? Where is the line drawn for those that should only be in Userspace?
2. Is it acceptable that WP:Userboxes/Politics by country was moved back to Projectspace in contravention of the 2009 MfD?

I recently posted this at WT:Userboxes, though it that page doesn't appear to get a lot of traffic, so also asking here. --Paul_012 (talk) 10:58, 22 June 2025 (UTC)

Any content that's "inflammatory or substantially divisive" is not allowed in userboxes, per the guideline at WP:UBCR. Thebiguglyalien (talk) 🛸 22:53, 22 June 2025 (UTC)

That describes userboxes that are not allowed, period. My question, however, is about userboxes that are only allowed in Userspace and not Templatespace. The relevant guideline is under WP:UBXNS, which is rather vague. The convention was developed way back in 2006 and doesn't appear to have been clearly documented. --Paul_012 (talk) 14:22, 23 June 2025 (UTC)

Just curious as to what is sufficiently divisive to be banned. This user has an “anti-UN” user box, in addition to multiple pro-2nd amendment userboxes. They popped up in the anti-AI discussion using a signature saying “Hail Me” and crosses that are similar to the Iron Cross. This was addressed on their talk page; where they disclaim any connection to Nazism, but refuse to remove the crosses. 173.177.179.61 (talk) 20:46, 23 June 2025 (UTC)

I failed to see why the ✠ have to be connected to Nazi Germany. I failed to see why multiple pro-2nd amendment and anti-UN statements are regarded as supportive to Nazism. I would again claim that I have no love for Hitler and Nazi Germany. I refuse to remove the ✠ from my signature as I didn't think that it is a symbol of Nazism. If you feel that the ✠ are sufficiently divisive to be banned you can go to WP:ANI for that. Have a good day. ✠ SunDawn ✠ Contact me! 10:57, 24 June 2025 (UTC)

To clarify, I do not think the anti-UN and pro-2nd amendment userboxes are supportive of Nazism of themselves. But including them, along with several pro-Trump userboxes makes it clear you support fascist causes. Hope that helps clear things up! 173.177.179.61 (talk) 11:44, 24 June 2025 (UTC)

I second this comment. 208.87.236.180 (talk) 11:46, 26 June 2025 (UTC)

This is at least the 3rd time I've seen someone bring up the iron crosses. At what point do we get to call a dogwhistle a dog whistle? Sock-the-guy (talk) 17:17, 24 June 2025 (UTC)

@Sock-the-guy and IP editor 173... this is the wrong venue for discussion of a specific editor, if you believe action should be taken then make your case, with evidence, at AN or ANI. If you don't believe action should be taken then stop talking about it. Thryduulf (talk) 17:26, 24 June 2025 (UTC)

Sure, I’ll restate my original question then. Is a userbox for being “anti UN” sufficiently divisive to be removed?

For clarification, I have only been browsing these boards for a couple weeks. I saw that this user was asked to adjust their signature, but there was no comment about the userboxes, so I was unsure if they were allowed or not.

I don’t know how to file an ANI unfortunately. That said, I’m not really interested in helping out a community that is pro-Trump, so as a queer Canadian, I guess I’m outta here. 173.177.179.61 (talk) 17:54, 24 June 2025 (UTC)

If User:SunDawn wants people to assume that they support fascist causes, then they are quite welcome to keep their signature, as long as they don't complain when people call them out on it. Black Kite (talk) 18:42, 24 June 2025 (UTC)

The swastika predates the Nazis, but if you buy it in your signature you will end up having to explain why all the time. In the same way the iron cross predates WW2 but is now heavily associated with the Nazi's use of it, don't be surprised if people are offended by it's use. -- LCU ActivelyDisinterested «@» °∆t° 12:03, 26 June 2025 (UTC)

I mean the other option for using the Iron Cross is generally to show allegiance to outlaw biker clubs. But this all seems something of a digression from the key question of the thread. Simonm223 (talk) 13:47, 26 June 2025 (UTC)

Apologies if this isn’t allowed but I ended up commenting on this thread before & after I registered. So for complete clarity, the IP above (173.177.179.61) is me. ExtantRotations (talk) 16:00, 30 June 2025 (UTC)

All Userboxes should be moved out of template space. If you find one, move it.

The unresolved question is whether political Userboxes should be moved out of Wikipedia?

If Wikipedia:UBXNS is vague, fix it. Userboxes don’t belong in template space. Userboxes are Userpage content and are not real templates. SmokeyJoe (talk) 14:31, 23 June 2025 (UTC)

I've never heard of any guidance to that effect. Presumably you don't mean to include Babel boxes? But what about user group userboxes? WikiProject membership userboxes? Legitimate areas of expertise and/or interest? --Paul_012 (talk) 14:51, 23 June 2025 (UTC)

(edit conflict) All Userboxes should be moved out of template space. If you find one, move it. is this just your opinion? It's not something I've ever heard before and doesn't seem to match what is written at WP:UBXNS,

If Wikipedia:UBXNS is vague, fix it. this is what they are explicitly seeking to do. Thryduulf (talk) 14:53, 23 June 2025 (UTC)

Wikipedia:Userbox migration SmokeyJoe (talk) 22:15, 23 June 2025 (UTC)

That's a historical page that proposes moving some userboxes to userspace and which explicitly eschews being a policy or guideline, it does not support your statement. Thryduulf (talk) 22:43, 23 June 2025 (UTC)

It describes the rationale and the practice, and it still occurs, and is often an MfD result. In my opinion nothing needs fixing, if someone doesn’t like a template space userbox, Userfy it to User:UBX. SmokeyJoe (talk) 03:19, 24 June 2025 (UTC)

is this WP:IJUSTDONTLIKEIT? --cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 19:30, 3 July 2025 (UTC)

No. SmokeyJoe (talk) 11:27, 4 July 2025 (UTC)

For me it's same shit, really. They can be probably deployed as templates, they can be coded, they can be in Template: or User: namespace (not projectspace though, because that IMHO is supposed to be somehow related to Wikipedia's functioning). It's like arguing over whether we want to put our luggage in locker 26 or 38 when they are the same size. The only thing that really matters is the userbox's content.

There is a userbox discussion going on (at MfD) and I see some support for blanket removal of all political userboxes, userspace, templatespace or elsewhere, essentially per WP:NOTADVOCACY, WP:NOTSOCIAL and as being generally not conducive to editing.

And I suggest that we consider that option as well.

Also, unwritten conventions like the one described just above me suck. If it is a convention that actually has much influence on outcomes, it ought to be a rule. Szmenderowiecki (talk) 22:13, 25 June 2025 (UTC)

Holy shit… I’m going to be real for a second. I’ve been hanging around reading things for a bit still cause I was like “well okay… maybe I jumped off the handle… it’s not like anti-LGBT userboxes exist, right? I mean, that would be crazy offensive.”

OH! Oh wait they do and people have to argue politely and civilily as to why it might be considered upsetting to realize the person editing the same niche article as you disrespects you on a fundamental human level. 173.177.179.61 (talk) 00:01, 26 June 2025 (UTC)

Controversial Userboxes don’t belong in ProjectSpace because that gets read as implying official Wikipedia status. They don’t belong in TemplateSpace because they don’t function as templates, and because template gnomes don’t like them there and are template-deletionists. They do belong in userspace because they are a form of user expression. If they are idiosyncratic, keep them in their creator’s userspace. If they are broadly used, put them under USER:UBX.

Let’s make this decades old practice “the rule”. SmokeyJoe (talk) 00:29, 26 June 2025 (UTC)

I think a clearer definition is needed for "directly collaborative in nature," as currently stated. Logically, it should be fine for a userbox (even in Templatespace) to say "This user is interested in the history of Nazism," but not "This user identifies as a Nazi." The former identifies the user's area of interest in contributing to Wikipedia; the latter is just plain inflammatory (or a bad joke). Requiring such wording may be a way to draw the line. On the other hand, it might be opening a loophole for people to exploit. Anyone got better ideas? --Paul_012 (talk) 06:55, 26 June 2025 (UTC)

1. I would prefer, even if it is a small preference, for project supporting Userboxes to be organised in Projectspace, not Template space. I think many would belong in a WikiProject.

2. I suggest NOT seeking to define a good and proper userbox. This could be constraining on future good ideas. Instead, I suggest that if someone wants to challenge a userbox as not being for the benefit of the project, that they consider migrating it to userspace, to the authors userspace or to User:UBX. If definitions are wanted, define unacceptable Userboxes. This has already begun. SmokeyJoe (talk) 08:13, 26 June 2025 (UTC)

I note the userbox in the MFD linked earlier is already in the author's userspace. But since it touches on an area where we have many people intent on promoting the victimhood of certain groups, it's getting a lot of delete votes based purely on that activism. Perhaps we really do want to ban userboxes that take positions on divisive social and political issues, but that environment (or any where discussion is going to be dominated by people throwing around WP:NONAZIS or its various clones) is not a good place to make a reasoned decision. Anomie⚔ 12:05, 26 June 2025 (UTC)

I’m sorry, I’m having trouble understanding your argument. Is your claim that LGBT people are “promoting victimhood” by voting to delete a userbox that reads “This user does not support the LGBT ideology” and that the delete votes are therefore insincere? They seem to come from genuine users. I don’t think it makes a difference who is placing the votes so long as they arent breaking rules. 173.177.179.61 (talk) 16:51, 26 June 2025 (UTC)

No, you're misinterpreting basically everything there. And this isn't the place for a political discussion. Anomie⚔ 17:10, 26 June 2025 (UTC)

Okay, would you like to explain why you think only the Delete votes are due to activism? 173.177.179.61 (talk) 17:13, 26 June 2025 (UTC)

No. Anomie⚔ 17:55, 26 June 2025 (UTC)

AGF be damned. LightNightLights (talk • contribs) 11:01, 27 June 2025 (UTC)

I'll be honest. I deleted all the userboxes from my user page a while back. This was principally because of two reasons: one - they'd got rather multitudinous and some of them were a snapshot of who I was nearly two decades ago more than now and two - the political userboxes never brought me anything but grief. I'd be supportive of a blanket elimination of political userboxes from Wikipedia full-stop. Frankly it would probably improve general adherence to WP:AGF even if it meant that we would lose the opportunity to occasionally have a bigot out themselves before they disrupt the encyclopedia meaningfully. Simonm223 (talk) 13:50, 26 June 2025 (UTC)

I would support the deletion of all such boxes. -- LCU ActivelyDisinterested «@» °∆t° 15:34, 26 June 2025 (UTC)

I'd be neutral to deleting all such userboxes. They can be useful to get an idea of someone's interests or possible biases. But I'd oppose deleting only the ones for positions an angry mob opposes while keeping the ones for their side, since the angry mobs seem to have difficulty distinguishing between actually-bad and just-expresses-an-opposing-viewpoint. Anomie⚔ 16:01, 26 June 2025 (UTC)

I worry that "political" may be conflated to end up supporting the removal of anything queer-related. Could we have assurances in any official thing that that wouldn't happen? Sock-the-guy (talk) 17:03, 26 June 2025 (UTC)

I support a total ban on political infoboxes. Addressing your concern, it's one thing to say "This user is queer" in the infobox. I'd question their judgment of posting their sexual orientation on the Internets, but if they really insist, there isn't much we can do. Just like editing under real-name identities - questionable practice but allowed.

It's another to say "This user feels queers are being discriminated against" or even "This user supports LGBT rights". The first is an open invitation to a shitshow; the second is quite innocuous in most Western societies but this is a political statement nevertheless and has nothing to do with editing Wikipedia - and it may be very controversial in, let's say, Pakistan. Also, consider this for comparison: "This user supports LGB rights", which will inevitably start all sorts of drama over transgender editors. Yeah, just sit back and get some popcorn.

If you are interested in queer topics on Wikipedia, "This user is part of WikiProject LGBTQ+ studies" is a great way to signal your editing preferences. Szmenderowiecki (talk) 18:27, 26 June 2025 (UTC)

This is exactly my concern, thank you for the transparency Sock-the-guy (talk) 18:44, 26 June 2025 (UTC)

The ideal solution would be to remove connotation of politics from the rights of people, but that'd be difficult to implement because it isn't only on Wikipedia, this is across society. --cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 19:37, 3 July 2025 (UTC)

I would support the ban of political advocacy Userboxes. SmokeyJoe (talk) 09:56, 27 June 2025 (UTC)

Nudging the question of a total ban of political userboxes

It appears from this discussion that there may be some support for banning political infoboxes (or "political advocacy" infoboxes). Before we proceed to further discussion, if it is ever needed, please tell me, among these userboxes, which kinds of userboxes would you be in favour of disallowing, if any?

I tried to sort them by categories so that it's easier to analyse them.

• the A cluster is political. A is "this user supports country X", which would seem to endorse a certain position in the conflict, e.g. Israel-Palestine, Pakistan-India, Armenia-Azerbaijan, Ukraine-Russia etc. A1 just lists party membership, without any further indication of political beliefs. A2 endorses/opposes particular politicians or personalities reasonably connected to politics. A3 lists the user's ideology. A4 indicates user's attitude to a certain political phenomenon. A5 indicates a user's attitude to countries or supranational bodies.
• B cluster is social. B is about LBGT issues (note: only in cases like: X should (not) have rights, should (not) serve in the military; it's not about declaring your sexual orientation), B1 is about opinions on marriage, B2 is about abortion, B3 is about censorship
• C groups causes that may appear uncontroversial.

A. This user supports Palestine/This user supports Israel

A1. This user supports the American Solidarity Party/is a US Anti-Federalist, member of the Republican/Democratic/Labour/Liberal/Swiss People's Party...

A2. All userboxes in Category:Politician user templates or Wikipedia:Userboxes/Politics by country (e.g. was against Assad/Ivan Duque/Juan Manuel Santos/Alvaro Uribe/Rodrigo Duterte/Stephen Harper/Justin Trudeau; Bernie Sanders for President Trump's the best; admires Amelia Andersdotter, Anna Politkovskaya, etc.

A3. This user is an anarchist, progressive, liberal, conservative, Communist, anti-Communist supports Hindutva/Pan-Slavism/MAGA (errm, I meant this), opposes monarchy, supports DEI, denies global warming...

A4. This user ardently opposes the alt-right/futarchy/believes that the alt-right is killing the US Republican Party/that white nationalism is Anti-American/demands that Azerbaijan release Armenian POWs

A5. This user supports a South-East Asian integrated community through ASEAN, against the EU/is Austro-European/supports the EU, Brexit templates, was against Euromaidan, against the UN... like 90% of the Category:Political user templates

B. Supports rights for queer people, gay people; does not support LGBT+ ideology due to legal, religious and moral reasons.

B1. Supports/opposes polyamorous marriage/supports cousin marriage/equal marriage for all/marriage only between one man and one woman/believes that marriage should be religious/is against extramarital sex/is generally against divorce

B2. Basically all templates in Category:Abortion user templates except User:UBX/Abortion, Template:User WikiProject Abortion and User:The Homosexualist/Irrelevabortion

B3. against most/no/all forms of censorship

C. Against dictators/terrorism/racism/oligarchy/slavery

C1. This user supports animal rights, Indigenous rights

Note that any infobox of the style "This user is part of WikiProject" or "This user is interested in" or "This user is gay" is not in the scope as it either directly refers to Wikipedia activity or else is not a political statement. Also note that it is for now more of a brainstorm to see which formulation of the userbox guideline will be potentially in play. Szmenderowiecki (talk) 20:33, 29 June 2025 (UTC)

Discussion (userboxes)

• If you ask me, I believe every single one of these is inappropriate. We don't get to endorse, or not endorse, people's political views or social views with political relevance. This is not our goal. Therefore, we either need to allow them all or ban them all. I totally understand the people's outrage when a guy posts a "this person is a proud Nazi" or "this person believes we have to straighten up the gays" on their userpage based on the notion that "this is clearly disruptive" but the thing is, it is only disruptive if people notice it, and the current guidance simply says "wait and see until a bunch of editors drag you to MfD" instead of just "don't do it". People who post such things are either trolls - a not-so-easy block for less obvious cases - or genuinely believe this and will go like "Wikipedia is biased and libtards rule there". To the fullest extent possible, Wikipedia should be apolitical and this is a way to do it. The benefit to keep these userboxes is minimal; the potential harm and waste of time - pretty big. Imagine a ARBPIA RfC where an editor looks up a userpage and see something like "This person supports Israel". Do you think the pro-Palestinian editor will never think along the lines of "he should not be editing here because he just said he's biased?" Szmenderowiecki (talk) 20:57, 29 June 2025 (UTC)

The conflation of support for human rights with discrimination in this makes it impossible to support. Sock-the-guy (talk) 20:54, 29 June 2025 (UTC)

If you want to announce support for human rights, you have plenty of options. Twitter, Bluesky, Blogspot, Wordpress, your local city hall, etc. Thebiguglyalien (talk) 🛸 21:02, 29 June 2025 (UTC)

This was not meant to be "support all or nothing". You are free to propose which infoboxes are appropriate or inappropriate within a category. In fact, that was the whole point - I need feedback. If we are speaking of B, which I think was one of your key points you mentioned to me, AFAIK LGBT rights is a political issue in quite a large part of the world (the T part is in particular is in the vogue in the Western world, there's even an ArbCom case request about it). My position is clear on this, and because this is a controversial issue (it shouldn't be, but it is), I could not put it into the C cluster. Szmenderowiecki (talk) 21:13, 29 June 2025 (UTC)

• As far as I'm concerned, every single one of the listed examples violates WP:SOAPBOX and is a misuse of Wikipedia. Thebiguglyalien (talk) 🛸 21:00, 29 June 2025 (UTC)
• If political userboxes such as the ones listed above were banned, what's stopping editors from writing political statements on their userpages instead e.g. "This user supports/opposes _____."? Is there really a difference, for example, between having a userbox that says "This user supports Palestine" vs having an image of the Palestinian flag on their userpage with a message saying "I support Palestine"? Some1 (talk) 21:20, 29 June 2025 (UTC)

  I believe that if we decide that userboxes like these are inappropriate, it would be automatically inappropriate to write their content in plaintext. Arguing that it wouldn't be inappropriate would be wikilawyering. Also see WP:UP#GOALS ("Extensive personal opinions on matters unrelated to Wikipedia, wiki philosophy, collaboration, free content, the Creative Commons, etc.") and WP:POLEMIC. That said, you make a good point. Updating WP:UP is probably a good idea. Szmenderowiecki (talk) 21:39, 29 June 2025 (UTC)

• I would say allow them all. This isn't (exactly) about free speech; it's legitimate to say "you can say what you want just not here". That said, it's sometimes useful to know where people are coming from. As long as it's a simple statement of position (even a radically unpopular position) and doesn't devolve into disruptive argumentation, I think it should be allowed. --Trovatore (talk) 23:03, 29 June 2025 (UTC)
• All of these are appropriate if they are written in a straightforward way that is not an attack. They are useful to indicate the bias or worldview of the editor. Perhaps there could be a way to classify the political biases of editors by how they edit. But far more difficult for the casual observer to determine in general. For it to be soapbox material it should be very prominent and the main feature of the user page. Claims of discrimination and violation of human rights by the existence or use of a userbox are unfounded, as boxes do not take away any rights or do anything that discriminates. It is also more useful to have userboxes rather than use of plain text as that would ensure that text used meets our standards for decency, and also make it easy to find who uses that box. Graeme Bartlett (talk) 23:29, 29 June 2025 (UTC)

  I mean, the existence of pro-discrimination infoboxes does make it clear to the individuals who are being addressed that they are not wanted here. Putting the burden on the targeted individuals to enforce rules will lead to a reduced number of them that stick around. ExtantRotations (talk) 01:29, 30 June 2025 (UTC)

  At most, it suggests that there are some people who don't want them here. Which is always going to be true. There will always be some people who don't want you here. --Trovatore (talk) 02:36, 30 June 2025 (UTC)

• Personally, I decided almost 20 years ago to remove the closest things I had to political user boxes from my userpage [1], so, yeah, I don't think such things should be on a user page, but I am hesitant to make that a hard rule for others. - Donald Albury 00:33, 30 June 2025 (UTC)
• While I don't use such userboxes, it's certainly far too broad a brush to do anything about these as a broad category. "political userboxes" is essentially and "political opinion" (in a box), and a "political opinion" is just an "opinion" because everything is political. We can't really have a "C groups causes that may appear uncontroversial", as that it an inherent contradiction. If something was uncontroversial, it would not be a "cause". If it's a cluster by cluster whack, there should be care to nix all opinions, even those widely agreed on by the community. CMD (talk) 00:53, 30 June 2025 (UTC)
• This seems to be escalating way beyond what I expected when originally asking. But what exactly do we mean by banning userboxes anyway? Like Some1 mentioned, it shouldn't stop people from writing the same statements directly on their user page. What about manually formatting them in boxes, without making them into transcludable templates/subpages? If that's allowed, then nothing should be stopping people from copying manually formatted boxes from other people's talk pages either. Deleting the index pages might add an inconvenience and discourage people from using them, but I don't think there's a realistic way to stop people from seeking them out. Maybe that's why the original solution from 2006 was just to userfy them. --Paul_012 (talk) 07:05, 30 June 2025 (UTC)
  • One issue with the userfication solution is that it largely amounted to much ado about nothing, as the userboxes hosted under User:UBX/Userboxes or anyone's user subpage are still performing the same function. Maybe they (and others that we think should be removed form Templatespace) should all be subst'ed. This would allow more diversity in users' self-expression and hold them directly accountable for the content they have on their userpage. I don't know if this will cause a significant increase in storage requirements; would appreciate if someone could do the numbers. --Paul_012 (talk) 07:44, 30 June 2025 (UTC)

    Userspace pages don’t speak for Wikipedia. This is a big thing for controversial Userboxes. Userfying diminishes the pecived problem. Subst’ing would work similarly. SmokeyJoe (talk) 08:18, 30 June 2025 (UTC)

  In my opinion, “banning userboxes” would mean taking things in line with the username policy, whereby certain items would be eligible for immediate deletion or ban rather than allowing them to hang around until someone challenged them.

  For clarity’s sake, I am also the IP further up this debate that asked about specific userboxes. In my opinion, I think “political userboxes” is a bit of an incorrect target. I do not have a problem with “political support” userboxes such as “this user supports Trump”. As much as I disagree with that statement politically, I don’t think it is designed to be inflammatory. But if the point of Wikipedia is to improve collaborative work, then it is counterproductive to allow userboxes that champion arguments Wikipedia itself deems as biased or false. ExtantRotations (talk) 15:54, 30 June 2025 (UTC)

• Comment most of this discussion, I don't want to touch with a ten foot pole. However in opposition to the maximalist view here, I do think some ideological userboxes are helpful as an easy way for editors to disclose possible sources of bias, which is part of WP:DGF. -- LWG ^talk 16:47, 30 June 2025 (UTC)

  I agree with LWG.

  My current rule of thumb is that if a rule would require changes to User:Orangemike, then I don't want that rule. WhatamIdoing (talk) 02:01, 4 July 2025 (UTC)

• allow them all - although I hadn't expected to be cited as an example, I agree with LWG and WhatamIdoing that they serve as a method of full disclosure. I thus acknowledge my belief systems and my preferences, and fully expect people to take them into account when giving my edits the scrutiny we all deserve. --Orange Mike | Talk 17:48, 4 July 2025 (UTC)

  We already have established Wikipedia:No Nazis as a deletion reason for Userboxes, Userboxes that you won’t find any more. Do you mean “go no further”? SmokeyJoe (talk) 23:31, 4 July 2025 (UTC)

• Comment Not going to frame it as a !vote (yet), or for any option, but I'm somewhat supportive. It fuels disruption that could've otherwise been prevented, and for little gain. The benefit of disclosure does not seem to me like it outweighs the other costs. Furthermore, if it's so valuable, is a possible conclusion that we must all disclose our political positions on user pages? Surely not. Therefore, this argument doesn't move me very much. Maybe I'm wrong, but I feel like this type of disclosure only becomes relevant when a problem (such as POV pushing) arises. However, if the problem has been identified, it is superfluous- barring exceptional cases. Dege31 (talk) 22:11, 4 July 2025 (UTC)
• At one point I put a bunch of political userboxes on my page, then I later removed them, and I think they should be deleted and removed because they are kind of a trap. Andre🚐 00:32, 14 July 2025 (UTC)
• No change necessary. Imho, your userspace is clearly your userspace, and to the extent that WP is not used for webhosting or copyright violations, you should be free to use your userspace as you see fit. InvadingInvader (userpage, talk) 14:11, 14 July 2025 (UTC)

  The question was about templatespace. SmokeyJoe (talk) 20:59, 14 July 2025 (UTC)

• I'm not sure what problem gets solved by removing these. SportingFlyer T·C 09:45, 17 July 2025 (UTC)

  Acquiescence to hand wringing. SmokeyJoe (talk) 13:18, 17 July 2025 (UTC)

• Allow them all. I often find userboxes silly and don't use them, but I still strongly hold to the idea of a user page as a freeform self-identification page. Especially with the Internet how it is now, all smoothed out by Corporate Memphis and CSS frameworks, I love seeing userpages that remind me of the old days. If a user wants to include inflammatory statements on their userpage, fine by me. If they're really the kind of person that wants to make Wikipedia a soapbox for their cause then they'll surely end up blocked for that in their other activities. Dan Leonard (talk • contribs) 18:31, 18 July 2025 (UTC)
• No change. The userbox wars (just linking to a small part of them) were more damaging to Wikipedia than userboxes ever were. Let's not repeat that. —Kusma (talk) 18:44, 18 July 2025 (UTC)

  Agreed and I'd support a moratorium on future userbox wars so these discussions can be summarily closed on sight. Dan Leonard (talk • contribs) 19:05, 18 July 2025 (UTC)

Using concise date for leading sentence of articles to improve readability

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.

---

Hi, to complete this discussion, I really propose to create and use a template named Template:Concise date that:

• Takes as input "Full date" like "February 24, 1955" (Birthdate of Steve Jobs)
• Gives as output:
  • Just year: 1955, by parameter y (default output)
  • month and year: February 1955, by parameter my
  • decade: 1950s, by parameter dec
  • century: 20th century, by parameter cen

All these outputs would have a tooltip indicating "full date" by template Template:Tooltip. This way, the leading sentence of all articles like Steve Jobs article would have only tooltiped year, which makes it much more readable than the existing one.

Myself is a volunteer to implement Template:Concise date. Hooman Mallahzadeh (talk) 12:13, 10 July 2025 (UTC)

Why do you want to "complete" that discussion when consensus was clearly against doing anything? Phil Bridger (talk) 12:36, 10 July 2025 (UTC)

@Phil Bridger I noted in that discussion that:

We are humans (not computer) and humans better understand concise date. This is a property of "human mind" and according to cognitive psychology human mind uses prototype and sketch.

See, the leading sentence is like the sketch of a drawing, so it should be very concise.

• If a computer (printer) wants to print a picture, then it begins with pixelling from the bottom of a page to its top.
• But, if a human wants to print a picture, then he should use sketching.

Readability of improves by sketching in the lead sentence. The same as what we do in the introduction of IELTS writing exam. Do you disagree? Hooman Mallahzadeh (talk) 12:46, 10 July 2025 (UTC)

Yes, you said that, but others did not agree. I myself do not at the moment agree or disagree, but can see that consensus was clearly against you. Phil Bridger (talk) 19:35, 10 July 2025 (UTC)

I like it, but note that {{concise date|February 24, 1955|cen}} should render as 20th century CE, since 1901 <- 1955 <= 2000. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:43, 10 July 2025 (UTC)

@Chatul You are right! I corrected that. Thanks, Hooman Mallahzadeh (talk) 12:47, 10 July 2025 (UTC)

This is a non-starter per MOS:NOHOVER. Use of your proposed template should be prohibited in mainspace and discouraged elsewhere. —Kusma (talk) 13:19, 10 July 2025 (UTC)

@Kusma So we should consider a tradeoff between "Readability" and MOS:NOHOVER. I think "Readability" wins the tradeoff. Hooman Mallahzadeh (talk) 13:24, 10 July 2025 (UTC)

I should note that Wikipedia uses hover in many places, like Template:circa. And Template:Tooltip has 466169 applications. Hooman Mallahzadeh (talk) 13:32, 10 July 2025 (UTC)

Abbreviations are allowed explicitly at MOS:NOHOVER, but tooltip use needs to go down, not up (besides issues with screenreaders, tooltips are also pretty terrible on mobile). We can't make trade-offs that reduce accessibility, and we really shouldn't make such trade-offs to implement your idea against widespread opposition. —Kusma (talk) 13:38, 10 July 2025 (UTC)

Wikipedia gets about three times as many mobile views as it gets desktop views (source: [2]). Mobile users simply have no way to access tooltips. Here readability would be impaired and not improved (or at any rate we would hide some information), for about three readers out of four. — Alien  3
3 3 13:45, 10 July 2025 (UTC)

Ok, so it cannot be implemented this way, tooltip is not an appropriate technique.

But I think unlike rules that exist in IELTS and academic articles, Wikipedia original writers (from 2001) were not concerned about "Readability problems" of leading sentence and leading paragraph of articles.

So please vote for using "concise year" policy for leading sentence of articles. This "concise year" policy says

• Leading sentence is preferred to use concise year
• Full year is better to be mentioned in the Infobox or in the other sections of that article, like birth and death sections of that article.

Hooman Mallahzadeh (talk) 13:58, 10 July 2025 (UTC)

For the same reasons I (and almost everyone else) opposed your proposed policy last time, I also oppose it this time, regardless of the method proposed to implement. Thryduulf (talk) 17:30, 10 July 2025 (UTC)

Do not understand the why behind this. JackFromWisconsin (talk | contribs) 21:21, 10 July 2025 (UTC)

I agree with others that this should not be used nor encouraged. Per recent consensus, we should not be discouraging full dates in the first place. I was not involved in that discussion but in skimming it now, I concur with the seeming unanimous consensus there. Full dates of birth are standard for an encyclopedia and are easy to gloss over for readers who don't care about them. The guidance at MOS:HOVER provides further reasons why this particular solution should be avoided. --MYCETEAE 🍄‍🟫—talk 19:17, 11 July 2025 (UTC)

Using footnotes to implement the idea

@Alien333@Kusma What about using footnote? Do you agree with using footnote for this template? For example:

Steven Paul Jobs (1955 - 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc. .

Is that good? Are there any rules on Wikipedia about not using footnotes? Because I think we have no other choice to implement the idea. Hooman Mallahzadeh (talk) 14:06, 10 July 2025 (UTC)

Why do this? Full dates can be supplied in an infobox and/or in the text (at least for articles that are not about a living person). Doing so in footnotes from the lead sentence seems terribly redundant. Donald Albury 16:35, 10 July 2025 (UTC)

@Donald Albury I propose to discuss this idea with a skilled IELTS examiner, and ask them to comment if "concise year idea" improves readability or not. Thanks, Hooman Mallahzadeh (talk) 17:19, 10 July 2025 (UTC)

doesn't look too good, i think. this is just moving info that would normally be placed on the infobox elsewhere, which would make it harder for the average reader to find it. this obviously means that i think it becomes less readable as a result consarn _{(grave) (obituary)} 17:28, 10 July 2025 (UTC)

This looks terrible and does not seem helpful. We just choose not to implement your idea at all. —Kusma (talk) 17:44, 10 July 2025 (UTC)

MOS:BIOFIRSTSENTENCE already says If specific day–month–year dates for birth/death are given elsewhere in the article, then a simple year–year range may be sufficient to provide context., so it's fine to have "John Doe (1900-1980)" if the full dates are already in the infobox. No tooltip or footnote is necessary. I'd support modifying MOS:BIOFIRSTSENTENCE to make this the default rather than an option. Levivich (talk) 18:01, 10 July 2025 (UTC)

That's sounds like a much better option than what has been proposed. -- LCU ActivelyDisinterested «@» °∆t° 22:10, 10 July 2025 (UTC)

Oppose modifying MOS:BIOFIRSTSENTENCE in this way. DOB is a standard piece of information that readers expect to find in an encyclopedia article. That the MOS allows some flexibility but does not encourage omitting the full DOB is appropriate. Footnotes are one solution when consensus determines that an abbreviated DOB is preferable at a particular article but their proliferation should not be encouraged. --MYCETEAE 🍄‍🟫—talk 19:22, 11 July 2025 (UTC)

• Opposed - I see no benefit to the proposal. Full dates are not a problem. Further, I would point Hooman Mallahzadeh to WP:IDIDNTHEARTHAT. Blueboar (talk) 23:37, 11 July 2025 (UTC)
• Oppose: we've been through this before. Full dates are fine. Please drop the stick. Cremastra (talk) 03:49, 12 July 2025 (UTC)

  Even though I still guess "explanatory power" of these two "competing topic sentences":

  1. Steven Paul Jobs (1955 - 2011) was an American businessman.

  2. Steven Paul Jobs (February 24, 1955 – October 5, 2011) was an American businessman.

  for 90% of readers are the same, and then we can apply Occam's razor and choose the simpler one, for proving this guess, I need some psychological tests.

  But according to consensus and implementation problems, I forget about the idea. Please close the discussion. Thanks for your attention. Hooman Mallahzadeh (talk) 05:46, 12 July 2025 (UTC)

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

Is using selective transclusion to remove citations ever an acceptable way to reduce page size or overcome template maximums

A few weeks ago I came across a development over at the list of common misconceptions, one of our most famous articles: it is now displayed to readers without references. There was consensus some time ago to split the large list into three pages. In the course of those discussions, an idea emerged that the three could be transcluded to reconstruct a slimmer version of the original (some of the support was indeed predicated on such a plan), leading us to the current version without references.

The citations still exist, but in order to see them you have to find the link to the subject-specific page and click it. According to pageviews for the last 30 days, the main article received 141,198 pageviews. The other three combine for 3,917. In other words, almost nobody clicks through to where the citations are. While it's true that citations take up a lot of space, they're also quite important where big claims are made (like X is a common misconception, Y is how it really is).

I thought about opening an RfC on the article talk page, but -- with apologies to the regular contributors there -- it seems like the underlying concept is something that could really use more centralized discussion: is using selective transclusion to remove citations ever an acceptable way to reduce page size ^or overcome template maximums? — Rhododendrites ^talk \\ 14:46, 13 July 2025 (UTC) Expanded on request — Rhododendrites ^talk \\ 00:42, 15 July 2025 (UTC)

• No — GhostInTheMachine ^{talk to me} 16:02, 13 July 2025 (UTC)
• Talk page discussions don't override community expectations on referencing for articles. I've tagged the page as unreferenced.Nigel Ish (talk) 16:09, 13 July 2025 (UTC)

  I'm undecided so far on the issue at question, but your edit seems pointy to me. I'd recommend you self-revert, allowing this discussion to reach a conclusion and that conclusion to be implemented. Anomie⚔ 16:26, 13 July 2025 (UTC)

  My edit has been reverted, so that point is now moot. I couldn't find any discussion where consensus was obtained for removing all references from the page (there was a discussion on splitting it, but that isn't the same thing at all.Nigel Ish (talk) 16:48, 13 July 2025 (UTC)

  I don't think we should be using transclusions for content at all - this is effectively presenting the casual user with an unreferenced article where they cannot edit the contents and someone has to watchlist all of the subpages to check for vandalism. This is a bad idea.Nigel Ish (talk) 17:54, 13 July 2025 (UTC)

  Normally, transclusions do carry standard inline references over, but the split was done as to wrap the refs in a manner that they were excluded from the transclusion. Masem (t) 18:07, 13 July 2025 (UTC)

  Let me correct myself, the references were already wrapped in the #invoke magic word which prevents reference expansion from triggering the "too many templates" limit on pages, which made sense given how many items and references were used. But when the split happened, the #invokes were kept, so the references do not get transcluded.

  Obviously, it would be a problem if the transcluded split pages replaced the #invoke with normal ref calling (the full list would still be a problem).

  We're still left with a page that appears to have no references. What should have happened is gradual splitting of the larger sections of the pages, leaving only main/seealso calls to those lists and not transclusions, as to still direct readers to those lists with references still all in place in the main and sublists. Masem (t) 19:15, 13 July 2025 (UTC)

  The #invoke hack does not "prevent" reference expansion from triggering the "too many templates" limit on pages. It merely makes it possible to cram a few more things in there before the WP:PEIS limit is hit. Think of it as a compression system for a big suitcase: it lets you put some more clothes in, but it doesn't let you put an infinite number of clothes in the suitcase. WhatamIdoing (talk) 22:00, 13 July 2025 (UTC)

  Ah, so the refs are just not there on the big page due to the template limit still being hit when all the transclusions, invoke or not, are included. That would make sense. Masem (t) 23:00, 13 July 2025 (UTC)

  The issue is that since every entry is a short summary that is carefully cited, the character count of the references is quite large in comparison to the actual text of the article. To keep the article size to a manageable level, <noinclude> tags were placed around the references so that they appear in the sub-articles but not the main article.

  The #invoke directives were a stop-gap solution that bought a bit more time and predated the split by several months, but as the article grew there was concern that it was not sustainable, hence the split. Mr. Swordfish (talk) 14:18, 14 July 2025 (UTC)

  Why it was done is not relevant. What matters is the outcome: we an article that is uncited, which is explicitly contrary to one of Wikipedia's core policies. Thryduulf (talk) 15:01, 14 July 2025 (UTC)

• I've now posted a reference to this discussion on the article's talk page, since that was apparently overlooked only mentioned deep in an earlier discussion on the page. Anomie⚔ 16:29, 13 July 2025 (UTC)
• Its never acceptable. Pages have to be comprehensive as standalone articles so pushing the citations elsewhere is not acceptable. Masem (t) 17:22, 13 July 2025 (UTC)

  I just figured out what happened in that in this diff, the list was replaced with several transclusions to the subpages. The subpages have the references but were implemented in a way so that they do not get transcluded into the full list. This just doesn't work again that every page should be standalone and references must be there on that page. The split should have literally just split off major sections to subpages without worrying about transclusions, so that the sourcing remains in place as normal for all articles. Masem (t) 17:33, 13 July 2025 (UTC)

  That was a BAD idea. Thanks to the way the WP:PEIS limit is calculated, all those citations would now double their contribution to the limit (their size gets added once when transcluded on the original page, and then thanks to a quirk in the software, gets counted a second time when that page is transcluded). --Ahecht (TALK
  PAGE) 18:02, 14 July 2025 (UTC)

• No, and a local consensus can't override policy. -- LCU ActivelyDisinterested «@» °∆t° 17:29, 13 July 2025 (UTC)

  I would expect anything on a page about common misconception would be "likely to be challenged". -- LCU ActivelyDisinterested «@» °∆t° 17:32, 13 July 2025 (UTC)

• Stop! You're not being given a complete set of reasons why we set up the page like that.—S Marshall T/C 21:44, 13 July 2025 (UTC)

  The reasons do not matter, it's not policy compliant no matter what reason editors have come up with. -- LCU ActivelyDisinterested «@» °∆t° 12:07, 14 July 2025 (UTC)

• No. I don't care why the current setup exists, all that matters is that article content should always be supported by references to reliable sources and the references should always be on the same page as the content they support. Thryduulf (talk) 21:48, 13 July 2025 (UTC)

  On a technical level, there is a hard cap about the number of templates that can display on one page. And I expect you're thinking, "What?" I know I did when I first came across this.

  Why is there a hard cap on the number of templates that will display? Well, it's necessary to protect the servers from certain kinds of sophisticated vandalism that amount to attacks. A clever vandal could set up templates that called each other recursively, so you end up with very large numbers of templates proliferating and absorbing our resources. There are good security reasons why we wouldn't want to change the cap. And the cap is set at such a high level that it almost never comes up (which is why it's confusing).

  How does the hard cap affect this article? Well, all our references are in templates (and they rightly should be). So, around November 2024, we'd made this article unexpandable: we could not add further references. For a while now, editors had been using a workaround by adding special code into the references, but that too was on the point of failure.

  That is a policy disaster. From a WP:V perspective, we could not possibly allow an article to exist that we couldn't add further citations to.

  WhatamIdoing arranged an RFC. She advocated splitting the article into subarticles, but editors insisted on having a version of the article that displayed on one page. So after a truly enormous amount of discussion, we implemented a split into List of common misconceptions about arts and culture, List of common misconceptions about history, and List of common misconceptions about science, technology, and mathematics. Each of those articles can be expanded, can have citations added to it, and is not the policy disaster we were previously faced with.

  Then, in obedience to a talk page consensus, we created a version that transcluded the split articles. But the version that displays on one page is not the article. It's a single page that transcludes the three articles without the citations; but with a link to the subarticle with citations very prominently displayed.

  You can of course reach consensus to change this at this discussion, but I do think it's important that you fully understand what you're doing before you !vote.—S Marshall T/C 21:57, 13 July 2025 (UTC)

  • Thanks for this explanation, S Marshall. The template limit is interesting indeed. But I think the crux is but editors insisted on having a version of the article that displayed on one page - "Split the page but treat the split pages as templates to transclude without references where the list once was" is simply not a valid option for a split proposal, so IMO should've just been disregarded upon closure. At the end of the day, we cannot have an article (and whichever page the reader is on when they're reading the text is the article) without references. — Rhododendrites ^talk \\ 22:01, 13 July 2025 (UTC)

    I'd have written "but some editors insisted..."; otherwise, I think S Marshall's description is fair.

    The split-or-not discussion was Talk:List of common misconceptions/Archive 33#Split proposal (15 editors, 70 comments; includes first description of ref-hiding system).

    A further discussion about how to split was at Talk:List of common misconceptions/Archive 34#How to split.

    The how-many-sublists RFC was Talk:List of common misconceptions/Archive 34#RFC on number of pages to split to (17 editors, 49 comments). WhatamIdoing (talk) 22:15, 13 July 2025 (UTC)

    ...and WAID was thorough. The split proposal RfC was advertised and crosslinked on this page (Village pump policy), on Village pump technical, on FTN, and on WikiProject Lists. This wasn't some halfassed local consensus.—S Marshall T/C 22:26, 13 July 2025 (UTC)

    Many of the reasons to maintain one single list (even with the transclusions) are very weak ("its a popular article"), in comparative weight to the core need to have comprehensive pages with everything appropriate sourced, even with the use of summary style splits. It would be far better to just have a notice box on the article page to explain that the topic is too large for a single page and thus split for readability and usability. Masem (t) 22:27, 13 July 2025 (UTC)

    Equally, a decision that involved multiple sitewide RfCs doesn't get overturned on the basis of one discussion on VPP.—S Marshall T/C 22:39, 13 July 2025 (UTC)

    • The split proposal was advertised and crosslinked. The "how many to split into" discussion was likewise advertised. But neither of those produced a consensus to create a transclusion zombie article. In fact, the first says explicitly There is not, however, a consensus whether to split the article in 2, split it into 3, or to do some wizardry using templates and transclusion to somehow be even more creative. The "How to split" discussion linked above was not advertised, and involves only five people. Nobody is suggesting to overturn either of the RfCs. What I am suggesting is that the basis for the subsequent decision of creating a high-teaffic unreferenced article is concerning, and that, in general, we should not remove references from the actual user-read versions of articles to save space. — Rhododendrites ^talk \\ 22:57, 13 July 2025 (UTC)

      Yes, the decision to split, and how to split, seems both well advertised, decided fairly by an RFC. Its this last minute of "but lets keep one big article using transclusions" that doesn't have that support, and that's what is breaking policy requirements. Masem (t) 23:01, 13 July 2025 (UTC)

      I invite you to re-read the RfCs, paying careful attention to the sequence in which these ideas were introduced to the community. It is profoundly unfair to call that proposal "last minute". In fact, the idea was discussed and agonized over for weeks. The community didn't love it. But it thought the alternatives were worse.—S Marshall T/C 23:14, 13 July 2025 (UTC)

      Amusingly, I see that when we discussed the idea at Wikipedia talk:Verifiability/Archive 82#Source display, ActivelyDisinterested who was so opposed to this just now, seemed quite supportive!—S Marshall T/C 23:19, 13 July 2025 (UTC)

      You've misunderstood my comments, they were never in support of removing all citations. Maybe I should have made that clearer at the time. -- LCU ActivelyDisinterested «@» °∆t° 12:09, 14 July 2025 (UTC)

      But of course, that's not what happened. Nobody removed all the citations.—S Marshall T/C 12:21, 14 July 2025 (UTC)

      The entire split discussion seemed predicated on the fact that while the full list was fully sourced, even with #invoke, the template limit was reached and the citations appeared "removed" in the rendered code (not in wikitext), which is why some type of split was required. Masem (t) 12:24, 14 July 2025 (UTC)

      @Rhododendrites, I'm not sure from your comments whether you're more interested in a Wikipedia:Close challenge or finding out whether there is currently a consensus for this arrangement. If the latter, then it doesn't really matter what the previous discussions did/didn't say. WhatamIdoing (talk) 23:34, 13 July 2025 (UTC)

      My question is still the one in the heading. I was responding there to S Marshall arguing that a discussion here would not take precedence over well attended discussions at the article. My point is, there was no strong consensus for creating an unreferenced list -- only to split, and then to split in 3. So, on one hand, there's no closure to challenge. On the other, I'm looking to gauge opinions on the general concept. — Rhododendrites ^talk \\ 23:39, 13 July 2025 (UTC)

      At this rate we'll need a list of common misconceptions about the list of common misconceptions.

      If there hadn't been a one-page version option, then the split proposal failed and we're back to one merged list.—S Marshall T/C 00:02, 14 July 2025 (UTC)

      I'm not sure that's true, but I think the more important question is "What do we want today?", not "Exactly how would you interpret comments made last year?" WhatamIdoing (talk) 01:04, 14 July 2025 (UTC)

    • One RFC on a talk page can't overturns WP:V even if it did have 70 participants. -- LCU ActivelyDisinterested «@» °∆t° 11:55, 14 July 2025 (UTC)

• No, this is a terrible idea. And now the current version just had a permanent template at the top? It looks awful. Just make gosh darn separate sub pages, like we do with so many other primary high level topics. Transclusion in this manner is a non-starter. Silverseren^C 23:18, 13 July 2025 (UTC)
• The article was approaching 600kb, so something had to be done. I do not agree with this particular solution, but once page sizes get that large slowdowns occur, especially on weaker systems and when opening source editor. A potential solution could be turning it into a pseudo-disambiguation page pointing to the other subpages as we do at List of Nazis. But I tend to agree that presenting without citations should be avoided. Curbon7 (talk) 23:20, 13 July 2025 (UTC)
• I'll say what I said on the talk page in question: For a list that is meant to combat misinformation, it would really help to be able to see the citations whenever necessary; just looking at the page gives the sense that things are made up, and then I have to click on another page just to see where the information came from. Given that a fair few of these are related to actual political controversies (such as the vaccines and autism one, or the tariffs one that was recently added), I think that saying "these are false" would fall within the "likely to be challenged" part of WP:V and thus need citation here. Compare Lists of unusual deaths, which was also recently split into a list of lists. Also note that tags like {{Better source needed}} and {{Citation needed}} are not excluded from the combined list. -BRAINULATOR9 (TALK) 23:44, 13 July 2025 (UTC)

  Vaccines and autism isn't politics. It's woo, plain and simple.—S Marshall T/C 23:58, 13 July 2025 (UTC)

  Given what's happening in the US right, vaccines and autism are 100% in the political arena right now Masem (t) 00:05, 14 July 2025 (UTC)

  Oh for the love of... It's woo. Fully disproven and discredited.—S Marshall T/C 00:13, 14 July 2025 (UTC)

  Indeed, woo, but an example of how the politicization of science is now in a world where both the left and right wings are departing from the consensus reality-based community into the world of alternative facts. Wikipedia should not do that, though, Wikipedia should firmly treat this as a question of science, not politics. Andre🚐 00:23, 14 July 2025 (UTC)

  Exactly. I fully believe the science here, but in terms of the doubt being thrown around by ppl in high government positions, we as a neutral work should absolutely still be sourcing (using the good medical sources that disprove there is any connection, of course, in addition to those that identify that there's a misconception). These need to be with the text, not shuffled away in in a sub-list article, which, given we're always going to be limited by template inclusion limits, means that the main transclusion list is broken in light of WP:V and other core content policies. Masem (t) 01:00, 14 July 2025 (UTC)

  I, too, believe the science; I'm just using it as an example of material likely to be challenged. -BRAINULATOR9 (TALK) 17:19, 14 July 2025 (UTC)

  "All content likely to be challenged" per policy requires online inline citations. It is very hard to see how any of this isn't going to be challenged, even if the challenges are poor. -- LCU ActivelyDisinterested «@» °∆t° 11:57, 14 July 2025 (UTC)

  Inline citations - not online citations. Blueboar (talk) 12:01, 14 July 2025 (UTC)

  Good spot, corrected. -- LCU ActivelyDisinterested «@» °∆t° 12:06, 14 July 2025 (UTC)

• I closed the first discussion with there being a consensus to split; as Rhododendrites notes, I didn't see a consensus of how to split. I do have some slight reservations about hiding references but as WAID has noted, most people do not check them anyway, and as S Marshall notes the split compromise allows the existence of 3 full split articles and a merged form for convenience. I see this as a valid use of templates and a valid, well-advertised, local consensus. Andre🚐 00:28, 14 July 2025 (UTC)

  WP:BURDEN "material the verifiability of which is likely to be challenged" given the content of this article this can not be a valid format. And a local consensus, no matter how well advertised, can not over turn a policy. -- LCU ActivelyDisinterested «@» °∆t° 12:00, 14 July 2025 (UTC)

  I agree with what S Marshall writes below. The citations are there, they are simply indirected slightly. Andre🚐 02:05, 15 July 2025 (UTC)

  I believe we may have a differing opinion on indirection, the concept of being "inline", and the relation between the two. Alpha3031 (t • c) 11:42, 15 July 2025 (UTC)

• There are technical issues and there are editorial issues; although there is an argument to be made that a long articles like this should be broken up for readability, this issue arose from a technical problem: since the entries are all short summaries that are carefully cited, the citations are much larger than the actual text of the article, making the page load hit some internal limits.
  Since this is a technical problem, we should seek a technical solution that preserves the editorial decisions as much as possible. The current transclusion approach that suppresses the cites is one; I understand the arguments being made against it.
  Is there another, better, technical solution? If I were writing the article on my own I would look to some JSON/Ajax solution that does partial rendering and only loads what the reader clicks on. I'm not aware of anything like this that is available, but perhaps someone knows something. Mr. Swordfish (talk) 14:39, 14 July 2025 (UTC)

  IMO it makes sense to explore other technical options on the article talk page -- all I want to establish with this discussion is that any solution that removes references from view of the reader is not something we want. — Rhododendrites ^talk \\ 14:49, 14 July 2025 (UTC)

  Given the RFCs on splitting, the only reason I see mentioned for trying to maintain some version of a single page version is along the lines of ITSUSEFUL which seems like a very weak rational to try to force a technical solution for what is basicly a non problem if a normal page split was done. It really doesn't make sense to try to justify trying to maintain one master list page for minimal returns for the purposes of being an encyclopedia Masem (t) 14:58, 14 July 2025 (UTC)

  Mr. Swordfish is one of the top editors to that page, and within the limits of WP:OWN, I think that his assessment of what works (or doesn't) should be respected. That said, he made arguments along these lines throughout the prior discussions, and I mostly felt like they boiled down to (a) Change is bad [it is! I agree with him!] and (b) a genuine inability to believe that anyone would want to split up this list for editorial reasons, even though I have personally told him more than once that I really do want to split this list up for editorial reasons [specifically, the unreasonable amount of time that it would take someone to read the whole page because of the WP:SIZE of the readable prose] and would want to do this even if the technical issues hadn't made it urgent. WhatamIdoing (talk) 19:12, 14 July 2025 (UTC)

  The technical solution would be to WP:NAVIFY the page instead of having massive transclusions. --Ahecht (TALK
  PAGE) 18:04, 14 July 2025 (UTC)

• Was there significant consideration given to converting the main page into a more formal Wikipedia:Lists of lists rather than trying to preserve the single list? That technical contortions are needed to avoid PEIS seems to be a strong signal that the topic itself is incredibly diffuse and likely WP:TOOBROAD. CMD (talk) 15:00, 14 July 2025 (UTC)

  The list is WP:TOOBROAD by definition; a misconception has to be common among a group, it cannot be common in and of itself. A misconception common in America is not common in the world. There's a common misconception in Texas that picking bluebonnets is illegal: is that a common misconception? Rollinginhisgrave (talk | contributions) 15:17, 14 July 2025 (UTC)

  Yeah, make a list of lists. What's the point of doing a SIZESPLIT and then just smushing the whole thing together again? Alpha3031 (t • c) 15:28, 14 July 2025 (UTC)

  Yes, it's definitely too broad by our normal guidelines. The community is well aware and doesn't care: we're keeping it, at least in its current split form.—S Marshall T/C 15:50, 14 July 2025 (UTC)

  When we started the discussion, I assumed that we would end up with something approximately like this:

  This is a list of common misconceptions.

  * List of common misconceptions about arts and culture

• List of common misconceptions about history
• List of common misconceptions about science, technology, and mathematics

  ...and quickly send readers along to the page that interested them most. WhatamIdoing (talk) 19:18, 14 July 2025 (UTC)

• No. Citations should never be cut from an article to "reduce page size". Citations are the most important thing in an article. Displaying this list without citations is a disservice to our readers. JackFromWisconsin (talk | contribs) 17:00, 14 July 2025 (UTC)

  ...and this is a problem. People !voting without taking the time to read and understand.—S Marshall T/C 19:21, 14 July 2025 (UTC)

  @S Marshall, I read and understood fully, kept my comment brief, but I will explain further. Yes I understand technically the citations are available in a separate page. However, this list uses a non-intuitive way of citing material that as far as I'm aware is the sole time its used on wikipedia. We already have ways to deal with long articles (clean cuts into separate articles), which don't include surgically transcluding the readable text back into a main article. The matter of fact is most readers will not reach the sub pages. The main page has 2100 views on July 14, whereas the Arts and Culture subpage had 50 views. History, had 55 views also. Science and tech had 38 views, again just on July 14. So all together, the subpages have 7% of the viewership of the main article. This is a problem. JackFromWisconsin (talk | contribs) 03:13, 16 July 2025 (UTC)

  Why is that a problem? Don't most readers not bother clicking on citations anyway? We insist on citations for various reasons, but as far as readers go we stop at making them available and most don't avail themselves of them. If you want to pursue this view-count based argument, you'd need to do more to establish that readers really aren't finding the citations they want to find. As it is, those numbers seem well in line with readers who care about cites finding their way to the sub articles. Anomie⚔ 11:59, 16 July 2025 (UTC)

  I had a look at https://wikinav.toolforge.org/?language=en&title=List_of_common_misconceptions which agrees that the sub-articles are not popular destinations. Since only 0.3% of readers try to read sources (and even some of those will be misclicks), this is what I expected.

  But I also noticed that most of the incoming traffic to the List of common misconceptions is redirects, disambiguation pages, and links in articles. Much of that should be re-pointed to the subarticle. For example, the link in Fan death#See also should probably be redirected to the List of common misconceptions about arts and culture. I have fixed three today; anyone who wants readers to see the little blue clicky numbers (or just to get to more immediately relevant information!) could do this. I suggest starting with the Wikinav pages, as they're the most popular ones, but most of these redirects should be repointed, and many of these links should be retargeted to a more specific article. WhatamIdoing (talk) 16:52, 16 July 2025 (UTC)

  I at least took care of repointing the redirects. -BRAINULATOR9 (TALK) 20:44, 16 July 2025 (UTC)

  Thank you! WhatamIdoing (talk) 21:06, 16 July 2025 (UTC)

  My "problem" is the fact that this article is unique and very different in how it handles citations. It is very inconvenient to have to navigate to a sub page, do ctrl-f and find where you were reading, just to find the citation. Wikipedia, for like 24 years, has inline citations next to every claim that needs one. The fact that this article should be treated any differently is absurd and will confuse readers.

  I'm not going to argue how many readers actually care about citations, because thats probably fairly low. Most of the trust of Wikipedia is seeing the cite (and lack of [cn] tags) and trusting the process. If a reader doesn't see a cite, they will get the idea this isn't a checked page and there could be misinfo.

  Why hiding the cite just to make it look pretty still baffles me and I believe its the wrong move. JackFromWisconsin (talk | contribs) 22:31, 16 July 2025 (UTC)

  @JackFromWisconsin, the point is not "to make it look pretty".

  The point is that the servers have Template limits, and when you exceed them, then it does its best, but eventually it stops showing the content of the template, and instead just shows the name of the template.

  That means that although you would usually expect to find the refs the looking something like this:

  References

  1. Brown, Rebecca (2006). "Size of the Moon", Scientific American, 51 (78).
  2. Miller, Edward (2005). The Sun. Academic Press.

  and so forth, through hundreds and hundreds and hundreds of refs, it will instead actually display something like this:

  References

  Template:Reflist

   

  You can see a screenshot of the "sources" – or at least, where the sources would have been displayed, if the template limits weren't exceeded.

  The options therefore are:

  • have one page that doesn't display the refs, because so many templates "physically" can't be displayed on any single page, or
  • split things across multiple pages, so that we have several pages with a few hundred templates each, instead of one page with ~a thousand templates.

  I proposed the latter. Editors chose "both!" WhatamIdoing (talk) 23:52, 16 July 2025 (UTC)

  Why bring in all the talk about only 7% of readers viewing the sublists if that's not relevant to what your actual problem is? The way you wrote it, it seemed like you were saying that it being only 7% is the problem. Anomie⚔ 12:11, 17 July 2025 (UTC)

• My thoughts: Splitting the original list article into sub-articles was the correct resolution to the technical issues.
  However, re-merging (transcluding) the information back into a main article (without the citations) was a serious mistake. As others have noted, citations are needed in every article on which “likely to be challenged” information appears. “But it’s cited over in the other article” is never acceptable. This can be resolved by making the original page into an index or “list of lists”. Blueboar (talk) 21:05, 14 July 2025 (UTC)
• A version of an article stripped of citations is fundamentally flawed in its failure to comply with the letter or spirit of WP:V. In the case at hand, I support replacing the uncited merged list with an index or list of lists.--Trystan (talk) 21:28, 14 July 2025 (UTC)
• No, that shouldn't be done. If the page is too large, split it up into several smaller pages. This applies to any page large enough where removing citations can be considered. --cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 22:10, 14 July 2025 (UTC)
• In this discussion: First, Rhododendrites asks whether selective transclusion is an acceptable way to reduce page size; then I explain that the purpose of the selective transclusion isn't about the page size, but is to overcome template display limits; then substantial numbers of editors come along and !vote on the original, erroneous framing of the question. Rhododendrites, may I fix the question and the header, or would you prefer to do that yourself?—S Marshall T/C 00:28, 15 July 2025 (UTC)
  • It seems to have evolved (or I have been corrected). I have amended the heading/question. Is anyone really going to revise their statement to say "no, we should not toss aside basic wikipolicy for page size, but for template maximums yes"? — Rhododendrites ^talk \\ 00:34, 15 July 2025 (UTC)
    • Again: That is not a fair framing of what happened. Please: be fair.
      Nobody has tossed aside basic wikipolicy. Everything that's challenged or likely to be challenged is supported by an inline citation to a reliable source. The issue is that that source is one click away. You're framing that as a policy violation, but WP:V does not say what you think it says. It was written before transclusion was commonplace and before new features like LST were implemented, and on the question of whether the references can be a click away from the thing they're citing, it is silent. Because we knew this was novel, WhatamIdoing asked on WT:V about it here.
      WAID was scrupulous about asking the community about this before we did it and she got very little response. Now we're getting a big lot of responses, but they're responses to the wrong question. You've framed this as "using selective transclusion to remove citations", which would be outrageous behaviour, so of course it's getting the response it is. The citations have not been removed. They're in place, one click away, with prominent links to help readers find them. It's been done after a great deal of thought and discussion, with the utmost transparency. But when WAID asked this, she framed the question accurately, and therefore got much less engagement and drama.—S Marshall T/C 01:58, 15 July 2025 (UTC)
      • A citation on a different page that the overwhelming majority of readers will never even see is not an inline citation. which would be outrageous behaviour - Yes, it is (an outrageous decision, that is -- I don't think there's a behavioral issue here). That you can try to justify it as a well-meaning kludge doesn't change that it strips away references from the only version of the article most readers will ever see. — Rhododendrites ^talk \\ 02:24, 15 July 2025 (UTC)
        • I'm not "justifying it as a well-meaning kludge". I'm telling you it's a thing we did openly, transparently and after a substantial amount of policy consultation in the appropriate places. And I'm telling you that it doesn't violate the black letter of policy. If the community thinks citations absolutely must be on the same rendered page as the claim, and it might think that, although we did ask---if that's the community's view then that needs to be added to policy, because the policy doesn't say so, and it never has.—S Marshall T/C 02:50, 15 July 2025 (UTC)

          Where content is referenced on article A, the community has never accepted a link from article B to article A as an acceptable reference for content on article B. That is hasn't explicitly said that the specific transclusion method used here is unacceptable previously is not relevant when the situation has never come up previously.

          Please can you link to these consultations about not including references on the page, because while the "should we split?" and "into how many should we split?" questions were widely consulted on, the fundamental question here "is it OK if the combined page is unreferenced?" doesn't seem to have been. Thryduulf (talk) 03:02, 15 July 2025 (UTC)

          I think Wikipedia talk:Verifiability/Archive 82#Source display is the cleanest attempt at addressing the sourcing question (by "cleanest", I mean that it's by itself and not distracted by other questions).

          NB that present List of common misconceptions is not an uncited page. It lists six ==Sources==, plus eight Wikipedia:Further reading pages and three Wikipedia:External links (all of which look like they should be moved to the end of List of common misconceptions about science, technology, and mathematics). The only failing is that material Wikipedia:Likely to be challenged is not displayed with an inline citation in the main page. WhatamIdoing (talk) 03:16, 15 July 2025 (UTC)

      It doesn't matter how we got there, we have a page that was purposely designed to not include references, which violates content and cannot be overridden by local consensus. We know the citations exist elsewhere, but that's absolutely not an acceptable solution, so it doesn't make sense to dwell on the how we got to this situation and instead how to resolve the situation, of which there is a KISS solution (remove the transclusions, and simply make it a list-of-list page). Masem (t) 03:34, 15 July 2025 (UTC)

      And that's not true either. The page was purposely designed to show that there are references, and to make sure people can find them.—S Marshall T/C 08:27, 15 July 2025 (UTC)

      But it was still by design not made to include those referecens, which is a minimum requirement for sourcing. It doesn't matter that you have a big arrow pointing "Refs are this page", even though that may seem like a way to show the reader where the refs cite. Pages have to be fully comprehensive even if viewed offline, so a page that says the references are elsewhere is fails that. Masem (t) 12:11, 15 July 2025 (UTC)

      A citation on another page is not inline to the statement on the page it was transcluded on. Therefore, it cannot be considered a inline citation for the purposes of WP:MINREF on that transcluded page any more than a bibliographic WP:GENREF would be, even if it was used as an inline citation on another page that the reader can get to. Alpha3031 (t • c) 11:36, 15 July 2025 (UTC)

• I understand why it was done this way. It's a novel attempt at a solution. But I'm not sure why the other two solutions commonly used - either splitting alphabetically or by field (such as by sciences, math, arts, etc) - into multiple articles that could be linked from a template on each other wouldn't have worked. In fact, it looks like there's three good separations into separate pages on that page already, which are being used for these transclusions. This page can be turned into a disambiguation page that just links to those three other pages, and the three pages can have see also or similar added to their top. -bɜ:ʳkənhɪmez | me | talk to me! 00:33, 15 July 2025 (UTC)

  The common solutions do work. The 'problem' is that some (a few?) editors really, really, really want all 27,000 words about common misconceptions all on the same page, without having to click between them. This method was suggested as a way to (attempt to) give everyone what they want. WhatamIdoing (talk) 03:18, 15 July 2025 (UTC)

• No. I understand and appreciate the problem this solved, the work that went into the discussion and implementation, and the frustration editors who worked on this may feel. But every list and article requires references and the very problem that this was designed to solve points to the particular importance of references for List of common misconceptions. The current setup is also a barrier to editing. The fact that most readers don't look at references is not sufficient, nor is the fact that motivated readers can click through to check references and edit the real lists. --MYCETEAE 🍄‍🟫—talk 03:04, 15 July 2025 (UTC)

  About "every list and article requires references": Technically, we don't have a policy or guideline requiring a source to be cited in every list or every article. That rule applies only to BLPs, and to articles containing WP:MINREF content (so not, e.g., a list or article that contains purely 'obvious' content, such as "The capital of France is Paris" or "Cancer is a disease"). I have been surprised how little interest the community has in creating such a rule. WhatamIdoing (talk) 03:22, 15 July 2025 (UTC)

  WP:WHYCITE specifically calls out this situation, "If a section from the wikilinked page is copied or transcluded, sources must still be cited in the sampled section even if the wikilink page already has it cited." Masem (t) 03:37, 15 July 2025 (UTC)

  Also (emphasis added): In particular, sources are required for material that is challenged or likely to be challenged. MINREF contains similar statements. By definition, List of common misconceptions requires lots of citations. The P&G rarely use such strong language, often saying what "should" be done or avoided. And in practice, pages with zero references face steep challenges at AFC and AFD. I overstated the breadth of the requirement but the circumstances where references are not required do not apply here. --MYCETEAE 🍄‍🟫—talk 04:45, 15 July 2025 (UTC)

  Yes, we know what it says. There's been a lot of unintentional mansplaining to WhatamIdoing in this discussion, so I feel as if I need to stress that she is one of the principal authors of WP:V. Compared to her, I'm a callow newbie on policy pages, but even I have racked up some four-figure number of edits to WT:V over the last sixteen years. Everything we've done is meticulously compliant with the core content policy that we, to a substantial extent, wrote. We have set aside a guideline or two -- which we did knowingly, in unusual circumstances, and after copious quantities of discussion.—S Marshall T/C 08:41, 15 July 2025 (UTC)

  Thing is, the end result of how you handled this ISN’T in line with core content policy. Blueboar (talk) 12:01, 15 July 2025 (UTC)

  What I'm learning from this discussion is that the community thinks the inline citations must appear on the same rendered page as the information they're meant to cite. But that's not actually to be found anywhere in core content policy, and we did ask. We seem to need to add it -- most likely to WP:V, which is where it naturally fits.—S Marshall T/C 13:05, 15 July 2025 (UTC)

  As noted above there has never been a need to explicitly say it previously, because everybody previously agreed it was the case anyway. Thryduulf (talk) 13:09, 15 July 2025 (UTC)

  An inline citation should appear inline to the text that it is meant to support. That is why it's called an inline reference, and not a general reference or a "reference on another page". Alpha3031 (t • c) 13:10, 15 July 2025 (UTC)

  Huh… We have had multiple discussions through the years about the need for articles to stand on their own in regards to verification and citations. We have repeatedly reached consensus that “but it is cited at the linked article” is not good enough. The idea that we must repeat citations in every article in which (likely to be challenged) information appears is hardly new.

  I am actually rather surprised that two editors with the years of experience and policy involvement of WAID and S Marshall were not already aware that this was consensus.

  That said, S Marshall is correct in saying that this consensus isn’t directly spelled out in policy. And the fact that (despite their years of experience) they apparently didn’t know of this consensus tells me that perhaps it needs to be. Blueboar (talk) 15:11, 15 July 2025 (UTC)

  As I've noted WHYCITE does express this requirement, but that's also a guideline and not a core content policy. This probably needs to be very clear in WP:V, particularly on citing any material that could be challenged. Masem (t) 15:14, 15 July 2025 (UTC)

  (edit conflict) @Blueboar this consensus isn’t directly spelled out in policy [...] perhaps it needs to be. I don't know whether it needs to be, but I don't think adding it will harm anything. Exactly how and where to add it is probably something best suited to a separate discussion at Wikipedia talk:Verifiability rather than here. Thryduulf (talk) 15:15, 15 July 2025 (UTC)

  We could add an explanatory footnote to must be accompanied by an inline citation to a reliable source that directly supports the material... clarifying that "accompanied by" means displayed on the same page as the content, including where the content is transcluded, subject to the narrow exceptions in WP:WHENNOTCITE (DAB pages and most lead content).--Trystan (talk) 15:36, 15 July 2025 (UTC)

  On this point, Thryduulf is correct. This discussion isn't a sufficient basis to make a substantial edit to a core content policy. There needs to be workshopping on WT:V.—S Marshall T/C 15:41, 15 July 2025 (UTC)

  I would agree that this should be workshopped at WP:V. Blueboar (talk) 15:49, 15 July 2025 (UTC)

  I think you mistake or understate the consensus found in policy: it is explicit consensus that you don't need to inline cite in situations where challenge is unlikely, thus we may allow it in limited circumstance like the often broad unconstrovertial overview of a lead, some uncontroversial lists and otherwise . . . but not where challenge is likely (or quotes) in any matter, including lead or list, per policy. -- Alanscottwalker (talk) 18:07, 15 July 2025 (UTC)

  Not having citations in the lede when that information is cited in the body of the article is reasonable, because if the page was being viewed offline or in print, those citations are still present. The problem is when the citation information exists on a completely separate page. Masem (t) 12:06, 16 July 2025 (UTC)

  As leadcite says, its still not a pass from when an inline cite is required, in any event. Alanscottwalker (talk) 12:32, 16 July 2025 (UTC)

  Do we really need to refer to a committee the task of workshopping a proposal to formally discuss the decision to confirm the fact that inline, does, actually, quite literally, in fact, mean in-line (adj. from in, meaning in; and line meaning line). Alpha3031 (t • c) 16:51, 15 July 2025 (UTC)

  Perhaps I am easily confused, but I see the inline requirement as already quite clear:
  WP:V — This page in a nutshell box: ... any material challenged or likely to be challenged must be supported by inline citations.
  WP:V — In the very first sentence, after the TOC: All content must be verifiable. ... it is satisfied by providing an inline citation to a reliable source ....
  WP:INLINE — Defines the concept: On Wikipedia, an inline citation is generally a citation in a page's text vs. ... a general reference. This is ... often placed at or near the end of an article. Nothing about citations outside the article.
  wikt:inline — An element that occurs within the flow of the text.
  wikt:in-line — (writing) Inserted in the flow of a text.
  Perhaps WP:V is not explicit that an inline citation should be visible, but does it honestly need to say not to hide it? What did I miss? — GhostInTheMachine ^{talk to me} 16:34, 15 July 2025 (UTC)

  I agree, the standard is clear. I suppose explicit clarification is harmless but I'm not sure it's necessary. --MYCETEAE 🍄‍🟫—talk 18:13, 15 July 2025 (UTC)

  I have been hoping for several years that we could get community consensus to add a line to WP:V that says completely unreferenced articles are disallowed. However, the community has so far rejected this (usually for overreach – instead of saying "c'mon, guys, there really ought to be some kind of source in every article", the proposal is usually too close to "You must add an independent secondary source that indisputably provides SIGCOV of the exact subject all by itself, under penalty of instant deletion").

  Before this was implemented, I asked about this at WT:V in the full expectation that the community would immediately land on it like a ton of bricks. However, @Blueboar was the only editor who directly opposed it at the time. WhatamIdoing (talk) 17:00, 16 July 2025 (UTC)

  Can you link? I am curious as to what my comments were at that time… what the context was, and whether I have changed my mind? Blueboar (talk) 18:08, 16 July 2025 (UTC)

  Sure.—S Marshall T/C 20:36, 16 July 2025 (UTC)

  Thanks, but not what I was asking for. I was asking for a link to the discussion WAID was referring to (where I apparently opposed his suggestion for needing some kind of source in every article) Blueboar (talk) 20:44, 16 July 2025 (UTC)

  That is the discussion. Your comment was the third one (out of four). WhatamIdoing (talk) 21:07, 16 July 2025 (UTC)

  ...and, this is how confusions arise. WAID wrote: "Before this was implemented, I asked about this at WT:V..." By "this", she meant, "the combined/transcluded List of common misconceptions". But that was actually a change of subject; her previous paragraph was about a policy requiring some kind of source in every article. Blueboar, being a little less close to this, didn't see that the subject had changed (and why would he?) He thought WAID was saying he'd !voted against a policy requiring some kind of source in every article. And so we get confusion. Two people reading the same text and understanding completely different things by what they read.

  That confusion is at the heart of this. A requirement that every controversial claim on Wikipedia is verified by inline citations is written in policy. A requirement that every controversial claim on Wikipedia is verified by inline citations on every mainspace page where the claim appears is not written into policy, and it never has been.

  All these people who think there's no possible confusion and it's all so blindingly obvious that it doesn't need writing down, were nowhere to be seen when we specifically asked this question. And all the people who think it's absolutely verboten to split up the List of common misconceptions for any reason including technical constraints, are nowhere to be seen now. Got to love consensus.—S Marshall T/C 09:15, 17 July 2025 (UTC)

  It is natural for even very experienced editors undertaking careful, good-faith interpretations of policy to reach different conclusions about how it applies. That sort of thing happens all the time even in fields when the wording being considered is more formally drafted (like an appellate court overruling a trial judge's interpretation of a statute), and our WP:PG are not written or intended to be applied in a legalistic way. It's the unfortunate risk of innovation that sometimes, once the thing is actually created, having more eyes on it will escalate issues that for whatever reason didn't attract much attention at the conceptual stage.--Trystan (talk) 12:55, 17 July 2025 (UTC)

  Ghost… what we don’t explicitly state is that the inline citation has to be repeated in every article containing the information… saying “but there IS an inline citation over at (linked article)” isn’t good enough. Blueboar (talk) 18:19, 16 July 2025 (UTC)

  Well, to imagine that scenario, rather robs the word "inline" of meaning. An article (or sentence, or phrase) that does not have an inline cite, does not have an inline cite, and that's all there is to it. Alanscottwalker (talk) 18:25, 16 July 2025 (UTC)

  In the situations I am referring to, everything is technically supported by inline citations - it’s just that those citations are “inline” at other articles, not at the article being read.

  I suppose you could say that problem is less whether an inline citation has been provided, and more where one hasn’t been provided. That’s why we need something in policy that says… “repeat the inline citation in every article where the information is stated” (or similar) Blueboar (talk) 21:14, 16 July 2025 (UTC)

  That seems like a strange use of "technically", rather it seems what you actually are saying is it's not technically inline cited, rather it is inline cited elsewhere, just not here. Which means it is not inline cited where it matters and is required to be. Alanscottwalker (talk) 21:24, 16 July 2025 (UTC)

  Ok, sure … but while currently that requirement is implied, but not explicitly stated anywhere, and I think it should be made explicit.

  FYI - An attempt was just made to add language on this to WP:V, but it was reverted pending conclusion of this discussion. Blueboar (talk) 21:50, 16 July 2025 (UTC)

  Yeah, I know, I was called to explain something on a user talk page about this discussion and that change. I don't see a need for change but if anyone wants to discuss it at the policy page, fine by me. Alanscottwalker (talk) 21:55, 16 July 2025 (UTC)

  I agree with those saying that an inline citation is, by definition, contained inline within the text that it is supporting, and not in another text passage elsewhere. I appreciate the desire to add more text to guidance whenever someone presents a different interpretation, but I think we should do our best to avoid adding more specialized guidance. Less text is more likely to be read than more text. isaacl (talk) 22:27, 16 July 2025 (UTC)

  A requirement for challenged or likely to be challenged material to be accompanied by an inline citation is clearly not met when that material appears unaccompanied by any citations. It is already quite explicitly stated. I have no objection to making it even more clear, but I see this more as a hyper-specific technical clarification than filling in any sort of gap in the policy.--Trystan (talk) 22:04, 16 July 2025 (UTC)

• No, and whatever was tried to be done, it does not work, eg. someone going to List of common misconceptions#Judiasm or the following "Sports" section, etc. has no idea what the cites are or how to find them or correct them or dispute them. And by the list's nature, these things are subject to challenge. Alanscottwalker (talk) 11:34, 15 July 2025 (UTC)
• There is absolutely nothing about this topic that warrants invention of a new type of list article. The topic is perfectly suited to be a list of lists, which is such a common article style that we even have a list of such articles. Zero^talk 12:40, 15 July 2025 (UTC)

Moreover, people who claim there is no policy against it are wrong. We have all seen newbies who think that a wikilink to another article removes the need for a citation, and we tell them that Wikipedia is not allowed as a source. That's policy. This newly-invented article style is both unnecesssary and policy-violating. Zero^talk 14:12, 16 July 2025 (UTC)

That's a very good point. Even if these are excerpts, the presentation for the casual reader and likely to newer users is the same as an article. CMD (talk) 16:04, 16 July 2025 (UTC)

• Comment. I don't think the transclusion limit will go away just with just wishing it wasn't there and trying to restore the old style of the article. So while the solution is not great, I respect why it was done, but we should still be searching for a technical workaround. Is it possible to have a per-article exemption or extension of the limit? Also, if not, have we considered basically a custom script for the article? For every reference, we'd have the template'd citation in a comment with some magic processing flag. Then we'd run the script and it'd create plain wikitext equivalents of all the references. No substitutions at all, that way, although the page will still be huge. e.g. something like:
  • <ref name="some-reference"><!-- REF-TEMPLATE: {{cite book |title=Reliable Book |last=Doe |first=John }} -->Doe, John. ''Reliable Book''.</ref>
• It'd be a hassle for maintenance since people would have to run the script every so often to replace with the wikitext rollout of the template, but it's doable. SnowFire (talk) 18:54, 15 July 2025 (UTC)
• I've been giving this some thought, and where I've come down is this: As a general matter, no, we shouldn't do this. An article's citations should be on the article page, and ideally inline when the article is well developed. But for this specific article, I could see an argument that WP:IAR applies if there's good reason for the list to be all on one page rather than split into subpages with list of common misconceptions being a list of lists (although in that case it should probably be renamed to lists of common misconceptions). Is there an IAR argument for that? So far I've seen assertions both ways, but no real reasoning given here. Anomie⚔ 12:12, 16 July 2025 (UTC)

  The primary argument I've seen based on this and the RFCs was that keeping one single article with all of them is a nice thing to have for readers that want to see all this misconceptions in one place. Which to me, is a very very weak argument for evoking IAR on a core content policy (WP:V in relation to sourcing). That might fly at TVTropes, but not Wikipedia. Masem (t) 12:20, 16 July 2025 (UTC)

  Hopefully the people making the argument will come here to make it, instead of letting it be strawmanned and dismissed with a facetious reference to a site that doesn't use sourcing at all. Anomie⚔ 12:36, 16 July 2025 (UTC)

  I would oppose an IAR on this. Consider the situation where a reader has limited access to a computer, and so prints out the article in hard copy.

  Normally, that hard copy would include any relevant citations. But in this case it wouldn’t. The article would not stand on its own… in order to know which sources verify the information, the reader would also need to print out all the sub-articles. Blueboar (talk) 12:52, 16 July 2025 (UTC)

  Personally I don't find that very convincing. If that reader cares about the cites in their printed copy, shouldn't they have paid attention to the notices and printed the subarticles instead? You could use the same reasoning to try to claim we should disable the ability for people to print only the pages they care about, without the list of references at the end that come later in the document. Anomie⚔ 12:18, 17 July 2025 (UTC)

  I don't see much of an argument that articulates that it actually makes the encyclopedia better, it appears to have been done because it was 'liked' and there was some technical issue, but the path chosen then ran over 'core policy' -- so 'not better'. -- Alanscottwalker (talk) 15:13, 16 July 2025 (UTC)

• No I have seen nothing in the arguments here that justifies ignoring our policies on verification and citing sources. - Donald Albury 15:43, 16 July 2025 (UTC)
• Several editors have asked above for an explanation or reason why keeping the article as a single page is desirable. I'll re-iterate what I wrote at the time - I don't expect it will change very many opinions, but here it is:

The current article is THE wikipedia list of commmon misconceptions. Once split, what remains is just several articles in a collection of List of misconceptions about yada yada yada. That is, it loses its gravitas once it loses its singularity.

By way of analogy, The US Academy Awards gives out an award for Best Picture. It also gives out "lesser" awards for categories like Best International Feature Film, Best Animated Short Film, Best Documentary Feature Film, etc. Imagine if the academy decided to eliminate the Best Picture prize and instead split it up into two or three, with no one film getting "best picture". That would be a major change, and my guess is that it would receive roughly zero support. Splitting this article is roughly analagous to eliminating the best picture category for movies.

Full thread is here

Mr. Swordfish (talk) 19:36, 17 July 2025 (UTC)

I don't think "gravitas" is a good reason to ignore our well established policies on verifiablilty, etc.

It still will be "The List", just split into different pages for technical reasons. No different than a book having multiple pages. I don't follow your analogy, we (as Wikipedia) don't really rank things or proclaim importance on topics. We follow the reliable sources. Making an editorial decision based on "rank" and "gravitas" feels like a misstep. JackFromWisconsin (talk | contribs) 21:41, 17 July 2025 (UTC)

We did have the Wikipedia:Books namespace that could do precisely this sort of pagination, but it was not really used. However, Wikibooks still exists and could possibly be used to carry out a similar function. CMD (talk) 03:58, 18 July 2025 (UTC)

• I do not, in general, like the practice of transcluding articles into other articles at all, even via {{excerpt}} or the like. When a reader sees something on that article, they should be able to edit that article text without going elsewhere. So, I think a solution needs to be found that doesn't involve doing that, especially when that also removes references. If that means a split, that means a split; if that means asking about a longer-term solution to the technical limitation from the appropriate people, maybe that can be done as well. Generally, performance/crapflooding limits should be permissive enough that a legitimate user of a site would never run into them or even notice they're present, so that probably indicates a problem in and of itself if that's happening. Seraphimblade ^{Talk to me} 04:13, 18 July 2025 (UTC)

  Yeah, I don't think the difficulties of such cross-page templates is really appreciated by some. Years ago, I had a devil of a time trying to correct an article, and I gave up for months trying to do it. No idea how to find the template, not aware that it was a template I had to find, etc. etc. Alanscottwalker (talk) 10:59, 18 July 2025 (UTC)

• Consider the main page The page in question doesn't seem to merit special treatment. But note that there's already a more prominent page of this sort – the main page. This is assembled from transcluded pages and, by convention, does not include any footnotes or citations. It contains numerous facts and many of them are controversial but we are quite used to the idea that readers will have to drill down to verify them. Andrew🐉(talk) 14:53, 18 July 2025 (UTC)

  The main page is not an article, and I don't think readers expect it to be one. We don't source on non-article pages like Portals and Categories as well. (Well technically it's in the article space but you know what I mean.) CMD (talk) 15:19, 18 July 2025 (UTC)

  We', the Main Page does not have an "edit" tab (at least to ordinary users), this List does. That's quite a difference. Alanscottwalker (talk) 20:13, 18 July 2025 (UTC)

Selective transclusion- close? next step?

I think it is fairly clear that the community consensus is opposed to the selective tranclusion that took place at List of common misconceptions. Can we close this, or is there something else to discuss? Blueboar (talk) 12:36, 18 July 2025 (UTC)

We need to determine the consensus for what to replace it is: the current situation is clearly unacceptable but the status quo ante was broken, so a simple revert is not enough. That discussion of course doesn't have to happen here, but if it isn't here there needs to be a clear pointer to where it actually is. Thryduulf (talk) 12:58, 18 July 2025 (UTC)

OK… to me the obvious solution is to undo the transclusion, and use the original article title for an index or “list of lists” pointing to the various split articles.

To give an example of at least the direction I would go: see what we did at List of Freemasons… the original list article was deemed too lengthy, and so we split it (alphabetically) … we turned the original page into an index page pointing to the split sub-articles. We created a lead section that is repeated on all of the articles - index and sub-articles (and I think we use transclusion to do that part). I think something similar would work for the various misconceptions articles. Blueboar (talk) 13:15, 18 July 2025 (UTC)

If you go back to the RFCs that started this, there is clearly support for splitting into lists (eg lists of lists). The idea of using transclusion was not a topic addressed in the closure of the RFCs (not that it wasn't rejected, just that only a few editors in those RFCs seemed passionate to want the transclusion approach). So it seems just falling back to a list of lists still meets the end point of the RFC closures while maintaining policy complaince. Masem (t) 13:56, 18 July 2025 (UTC)

• List of lists is the usual way to do it and nobody has given a good reason why this example is special. Zero^talk 14:31, 18 July 2025 (UTC)
• List of lists per Zero0000, just reduce the page to plain links to the three sub-articles instead of transcluding them. Dan Leonard (talk • contribs) 18:19, 18 July 2025 (UTC)
• List of lists per Zero and others in prior threads. This is a sensible solution to the original problem with page size and to the same-page inline citation issue. --MYCETEAE 🍄‍🟫—talk 19:06, 18 July 2025 (UTC)
• Enforce plaintext citations only. Nobody else replied to my idea above but if the problem is the template expansion limit, we can just... not use templates. It's fine. It's an explicitly accepted style. It's something we could write a script on to turn template citations into plain text ones as well, and the templated version can be in invisible comments next to it. SnowFire (talk) 06:11, 19 July 2025 (UTC)

  I agree that this would be sensible. Can this be done by substitution of the {{citation}} templates? In other words, by using subst: Andrew🐉(talk) 09:21, 19 July 2025 (UTC)

  This is another sensible solution. Sorry I missed this in long thread. I think there is a view that the list was too long regardless of the technical limitation on template use. I don't have a strong view either way and would defer to others but would accept plaintext refs. (Honestly, I find {{citation}} templates tedious and harder to use but muddle through out of a sense of conformity. It has stopped me from editing on more than one occasion.) --MYCETEAE 🍄‍🟫—talk 15:52, 19 July 2025 (UTC)

  Unfortunately this won't work because of T4700, a bug that recently celebrated its 20th birthday.—S Marshall T/C 17:22, 19 July 2025 (UTC)

• Change the parent page to a simple, plain List of lists. This would be normal for a list that has become too large and needs to be split into several lists. Clean out all of the noinclude tags in the sub-lists and stay with real, maintainable references — GhostInTheMachine ^{talk to me} 10:57, 19 July 2025 (UTC)
• As several others have noted over the years, the lists should probably be deleted; they are a magnet for bad contributions and most of the entries don't have references that support that they are rebutting misconceptions that are common. Quite a few of the "corrections" are, arguably, as misleading as the supposed misconception. Setting that aside for now, the only solution is a list of lists; that is the approach taken for every other article with this problem. A local consensus of XKCD fans who want a giant, bloated, unsourced "List of common misconceptions" cannot override site policy. 217.180.228.155 (talk) 12:58, 19 July 2025 (UTC)

List of lists per Zero. JackFromWisconsin (talk | contribs) 16:30, 19 July 2025 (UTC)

Request for Tenth (?) Opinion at DRN

I didn't get an answer to this question at Village pump miscellaneous, and the Teahouse advised me to come here. I don't mean to be a nuisance, and I don't think that asking for advice at multiple forums after getting no answer is forum shopping. Robert McClenon (talk) 18:55, 13 July 2025 (UTC)

Moved from WP:TEA

I would like a neutral experienced editor to look at a case at DRN and comment on whether they agree with my handling, and whether they have any advice either for me or for the filing editor. The dispute is Wikipedia:Dispute_resolution_noticeboard#COVID-19_Lab_Leak_Theory. I see two-and-one-half questions, one substantive question and two related procedural questions. The substantive question is whether the article's presentation of the lab leak theory is neutrally written to reflect what reliable sources have written. (I am not asking for answers to the substantive question, which is contentious, only how to help an editor who wants an answer to the substantive question.) The procedural questions are how Just-a-can-of-beans should try to discuss their concern that they want changes made to the article, and what advice a neutral mediator should give to Just-a-can-of-beans. (I am assuming that putting a {{NPOV}} tag at the top of page is not the right answer.) Robert McClenon (talk) 18:55, 13 July 2025 (UTC)

I saw that when it was filed. My thoughts (free advice, guaranteed to be worth what you paid for it!) were:

• One of the disputants declined to participate, and therefore the DRN request should get closed as {{DR case status|reject}} per long-standing, ordinary practice.
• DRN exists to solve content disputes. It does not exist to negotiate a settlement in which Template:POV does/doesn't get placed at the top of the article. That is, a reasonable DRN request might sound something like "IMO the article does not adequately reflect Trump's views of COVID's origins, and the other editors will not let me fix that", but a reasonable DRN request does not sound like "The other editors will not let me add a maintenance template to WP:Warn the reader that this article does not adequately reflect Trump's views".
• If the lead disputant wishes to make progress, then the two behaviors most likely to lead to success are:
  1. Finding sources that meet the other editors' standards (e.g., a peer-reviewed review article published in a decent scientific journal).
  2. Moving very slowly. Making only one (1) small (tiny!) change to the body (not the lead!) of the article. For example: Just add one great source that supports some bit of existing content. And then stop and wait a week. If nobody complains, then next week, you can change a couple of unimportant words at the end of the article, or re-use the citation elsewhere. If someone does complain, then you ask that one (1) editor what concerns them and seek a compromise that they will accept. And so forth.

That last item is original WP:BRD, not Wikipedia:What editors mean when they say you have to follow BRD. You have to treat editing in difficult situations less like you're stomping around your home and more like you are sneaking up on an injured wild animal. Do things that help them, including deliberately Wikipedia:Writing for the opponent. Once you have gained their trust (which will take multiple weeks to months, or even a year), then you can try something a little more "risky", like gently touching the sore spot. The goal for each individual edit must always be "What will they realistically accept?" and never "How fast can I get the right POV into this article, and especially the lead?" WhatamIdoing (talk) 22:42, 13 July 2025 (UTC)

Thank you, User:WhatamIdoing, for your comments. I will reply briefly to points 1 and 2.

First, on point 1, I respectfully disagree, and I think that you are mistaken about the long-standing practice of DRN. The filing party listed seven other editors, and one of them declined to take part in the discussion. It has always been the practice of DRN to close a dispute if the one other editor or all of the other editors decline to take part. It has not, in my recollection, been the practice to close a dispute because one editor declines to take part but others are willing to take part. In such cases, my usual practice is to verify whether there is a content disagreement between two or more of the participating editors. I think that it would be a bad practice to decline a case because one editor declined to participate when other editors were ready to discuss. The filing party could then refile, omitting the editors who had declined. That would be stupid bureaucracy. So I did not close the case, but I did not open it either.

Second, on point 2, you are partly restating what I usually say when opening a dispute, which is to ask what each editor wants to change in the article. In the recent past, when I have been asked to resolve a tagging dispute, I have tried to ask what changes to the article the editor applying the tag thought should be made.

I thank you for point 3, which goes somewhat beyond the scope either of the dispute or of DRN, as advice on how to try to edit in contentious situations. At this point I am only asking whether there is anything else that I should say in opening or closing this case.

You didn't tell me whether you thought my handling of the request was reasonable, but maybe I should learn that you try to avoid addressing the actual case in point.

Robert McClenon (talk) 04:12, 14 July 2025 (UTC)

Robert, I always think your actions are reasonable, even when I (infrequently, and not in this case) disagree with them. WhatamIdoing (talk) 05:34, 14 July 2025 (UTC)

WP:NEXIST with regard to sources only mentioned in Primary Sources

This is coming off of an AFD discussion for the cyclist David Gillow, and the Keep side is arguing that because Gillow's personal website does feature background images of newspaper clippings. However, the nature of the website is to advertise Gillow's personal business.

I wanted to bring this up directly at VPP since I think that this is a gray area that imho should be resolved: does NEXIST still apply if the only mention of a potential source is from a promotional, self-published, non-independent or unreliable source, especially in cases where the source cannot be located otherwise? Or an alternative way to phrase this - if only a subject's personal website or non-independent source shows newspaper clippings but there is no verifiable evidence on where such newspapers came from, and searches performed for the headline show no results, is there NEXIST grounds? InvadingInvader (userpage, talk) 17:17, 15 July 2025 (UTC)

It seems likely to me that cases will be rare and are likely to vary, and possibly this should be dealt with on a case by case basis. Wehwalt (talk) 17:47, 15 July 2025 (UTC)

I agree with Wehwalt, there is always going to be far too much individual context to give an answer that is always correct. However as general principles, what matters is the reliability and independence of the actual sources, not the reliability or independence of the discovery method. For example it is far from uncommon to learn about the existence of reliable sources due to mentions in unreliable ones (e.g. books and newspaper articles quoted in internet forum discussions). It's also worth remembering that independent secondary sources are only required to demonstrate notability, primary sources and non-independent sources can be fine for verifiability (indeed in some cases primary sources are more reliable than secondary ones). Thryduulf (talk) 18:11, 15 July 2025 (UTC)

what matters is the reliability and independence of the actual sources, not the reliability or independence of the discovery method. I agree with this as a general matter for WP:NEXIST and other verifiability and notability standards. "Discovery" is a critical piece here. WP:NEXIST points to Wikipedia:Published. If an unusable source mentions or identifies a source that would be usable per the applicable P&G but then no one is able to confirm the existence or content of said source, then it fails verifiability. A similar issue arises with LLMs "hallucinating" plausible sounding but bogus citations. --MYCETEAE 🍄‍🟫—talk 18:40, 15 July 2025 (UTC)

If I were asked to close an AfD where this was an issue, I would be creative and state: “No Determination… AFD is paused… editors have 1 month to look into the potential sources further and report back.” Blueboar (talk) 19:02, 15 July 2025 (UTC)

[if] no one is able to confirm the existence or content of said source, then it fails verifiability. generally yes, although there is a distinction to be made between "we've looked high and low and can confirm with very high confidence that the source doesn't exist" (this is likely to be the case for at least most LLM hallucinations) and "we've looked as hard as we can, but we still can't say whether the source exists or not" (say something claimed to be published in 1940 in French West Africa). In the first case it's a clear WP:V fail, in the second that's a much harder call. Thryduulf (talk) 19:51, 15 July 2025 (UTC)

I agree it requires more care, and I agree with @Blueboar that in the right circumstance it is appropriate to allow more time. I would further distinguish between "we have a plausible title, author, publisher, publication date, and location and we have not been able to get ahold of it" vs. "we have a grainy photo on a personal website where only newspaper headlines are legible, with hard-to-decipher handwritten dates and no other publication information". --MYCETEAE 🍄‍🟫—talk 20:21, 15 July 2025 (UTC)

Is there any reason that, with the necessary legwork, the sources given in the primary source can be found and used instead? Masem (t) 19:17, 15 July 2025 (UTC)

I tried to see the extent to which national newspaper archives exist for Zimbabwe--there is one potentially promising archive with offices in Harare and Bulawayo [3], that charges a fee for access in person. There don't appear to be any digitial archives for pre-21st century Zimbabwean newspapers, regrettably. Another possible route would be to try to contact Gillow himself, since he would appear to have had the snippets on hand when putting together his website, and may be able to provide additional bibliographic information and/or text of the snippets themselves. _signed, Rosguill ^talk 19:25, 15 July 2025 (UTC)

Problem is that the Galloping Gillow website is down. I'm unsure if he is even still living InvadingInvader (userpage, talk) 20:05, 15 July 2025 (UTC)

I have suggested asking the various WikiProjects tagged in the article and Wikipedia:Reference desk. Unfortunately, the website doesn't identify the sources. It's a poor-quality image of a stack of old newspaper clippings, where only the headlines are legible, with no names or dates of publication. --MYCETEAE 🍄‍🟫—talk 19:44, 15 July 2025 (UTC)

Some of them do appear to have the dates, FWIW (one I can tell is "3/7/1978" for example). BeanieFan11 (talk) 19:46, 15 July 2025 (UTC)

Yes, I did see the hand written dates on two of these. One plausibly says "3/7/78". I find them both pretty illegible. --MYCETEAE 🍄‍🟫—talk 19:55, 15 July 2025 (UTC)

If we can't even verify the basic info needed to verify those sources (due to unclear images), much less access then, I would be very wary of using a primary source here. Masem (t) 20:42, 15 July 2025 (UTC)

As a general rule, you should assume that sources aren't actively lying to you, and that unless you have a specific reason to believe that the specific website actually is lying to you (e.g., it's a satire site, it's about a subject who has been accused in other sources of lying). Therefore, when a "promotional, self-published, non-independent" website claims that various news sources exist, you should assume that those news sources exist.

Of course, you can't use the sources until you can read them yourself. You have to WP:SAYWHEREYOUGOTIT, and that means you can't write "The actor's performance was praised by Unread Critic in Unarchived Newspaper", citing the review you haven't read, just because the actor's website says "Dear Unread praised my performance in his review for the Unarchived Newspaper the next morning...". But you should assume that this review exists – or, perhaps more to the point, that it existed. At some point, Wikipedia:Verifiability#Accessibility of a source is a requirement. It's not necessary for you to be able to access the source, but someone has to be able to do so. In case of doubt, an AFD might be suspended to allow time for a search. Particularly determined editors might even broadcast pleas for help through relevant Wikimedia affiliates or social media. But it's also valid to close an AFD with a soft delete and a note saying that we're pretty sure that sources existed, though can't access them, and if anyone is able to get the sources in the future, then a WP:REFUND will be cheerfully granted. WhatamIdoing (talk) 17:14, 16 July 2025 (UTC)

As a historical note, the WP:BFAQ used to recommend that businesses that wanted a volunteer to write an article about them create a "News" section on their websites, listing/linking to news stories about the business. Having a handy list of sources can be a great timesaver for volunteers. So it would be very ironic if we now say "Oh, those terrible self-promotional people: How dare they do exactly what we recommended, by making a handy list of sources that show they qualify for a Wikipedia:Separate, stand-alone article!"

Also, remember that, despite all our complaining about "promotionalism", business articles are among the most popular subjects with our readers. We don't want advertisements – see Wikipedia:Identifying blatant advertising – but we do want accurate information, including information that accurately presents the subject only in a positive light (because not every subject has had negative information published about them). WhatamIdoing (talk) 17:48, 16 July 2025 (UTC)

I think that WP:SELFSOURCE guides us in another direction on anything that might be considered boastful ("unduly self-serving"). And this would actually hold more true today than in this older item we're looking for, as some people are AIing their bios. -- Nat Gertler (talk) 20:24, 17 July 2025 (UTC)

Convention for naming Australian place articles

There is a RFC on the convention for naming Australia place articles at Wikipedia:Australian Wikipedians' notice board#RfC: The convention for naming Australian place articles. Editors are invited to contribute. TarnishedPath^talk 03:20, 19 July 2025 (UTC)

Technical

Notification when certain article is linked

Tracked in Phabricator
Task T66090

Is there any way to get notification when certain article is linked if I'm not author of article? Eurohunter (talk) 22:12, 12 July 2025 (UTC)

Nope. See the Phabricator task about this I've added above. Graham87 (talk) 04:05, 13 July 2025 (UTC)

@Graham87: I didn't find any. Which one? Eurohunter (talk) 08:34, 13 July 2025 (UTC)

On the right, phab:T66090. —CX Zoom[he/him] ^{(let's talk • {C•X})} 08:38, 13 July 2025 (UTC)

Yes, there is a way to (kind of) achieve this, just not through notifications. You could set up a {{Database report}} in your user space that uses a query like this. It shows the current number of incoming mainspace links for a list of articles you specify in the query. It wouldn't take much work to enhance the query to read article links you list on a page for this purpose. Stefen 𝕋ower_{s among the rest!} ^{Gab • Gruntwerk} 20:08, 15 July 2025 (UTC)

Daily page count graphs seem missing as of Sunday morning

Last night the daily page count graphs were coming up as usual, though this morning multiple pages are coming up blank; just the axis lines with no graphed data points. Could someone look at this; I've tried it for presidents Lincoln, Washington, Madison, etc. ErnestKrause (talk) 14:46, 13 July 2025 (UTC)

@ErnestKrause: Are you referring to the "Pageviews" link at top of the page history [4]? It works for me. PrimeHunter (talk) 15:26, 13 July 2025 (UTC)

Yes, that's the one. I've tried it again, and it looks like someone has changed the old dark color format in the graph, in preference to a very, very light blue outline format for the data which is barely visible. Its barely visible in the new format, although if you hover over it with the mouse, then the number of the daily count does come up. Can it be changed back to the old dark color format which did not use this very, very light blue color for format choice. The graphs looked better with the dark outline format for the graphs. ErnestKrause (talk) 15:37, 13 July 2025 (UTC)

@ErnestKrause: It's a normal light blue for me and very easy to see. Have you tried another browser and another screen? PrimeHunter (talk) 16:08, 13 July 2025 (UTC)

There haven't been changes in the code; at any rate. — Alien  3
3 3 07:46, 14 July 2025 (UTC)

Thanks to both Primehunter and Alien for taking a look at it. I've switched to a macintosh now as a test and the macintosh looks fine with no color changes. The other one causing this issue was a 20 inch PC desktop console with the odd color described above. Its a defect I've not seen before and seems to be peculiar to this desktop console at this time. ErnestKrause (talk) 14:07, 14 July 2025 (UTC)

@ErnestKrause: Which browser is it using including version number? Can you try another browser on the same machine? PrimeHunter (talk) 13:52, 15 July 2025 (UTC)

As I recall, it was on a public pc at the library which was running Chrome as its default. It might have been possible to switch to Firefox or Edge, though my first thoughts were to think that Wikipedia had changed or updated its color preferences in the code. That's when I added the comment to start this thread. ErnestKrause (talk) 14:57, 15 July 2025 (UTC)

Wikidata Item and Property labels soon displayed in Wiki Watchlist/Recent Changes

(Apologies for posting in English, you can help by translating into your language)

Hello everyone, the Wikidata For Wikimedia Projects team is excited to announce an upcoming change in how Wikidata edit changelogs are displayed in your Watchlists and Recent Changes lists. If an edit is made on Wikidata that affects a page in another Wikimedia Project, the changelog will contain some information about the nature of the edit. This can include a QID (or Q-number), a PID (or P-number) and a value (which can be text, numbers, dates, or also QID or PID’s). Confused by these terms? See the Wikidata:Glossary for further explanations.

The upcoming change is scheduled for 17.07.2025, between 1300 - 1500 UTC. The change will display the label (item name) alongside any QID or PIDs, as seen in the image below:

These changes will only be visible if you have Wikidata edits enabled in your User Preferences for Watchlists and Recent Changes, or have the active filter ‘Wikidata edits’ checkbox toggled on, directly on the Watchlist and Recent Changes pages.

Your bot and gadget may be affected! There are thousands of bots, gadgets and user-scripts and whilst we have researched potential effects to many of them, we cannot guarantee there won’t be some that are broken or affected by this change.

Further information and context about this change, including how your bot may be affected can be found on this project task page. We welcome your questions and feedback, please write to us on this dedicated Talk page.

Thank you, - Danny Benjafield (WMDE) on behalf of the Wikidata For Wikimedia Projects Team. MediaWiki message delivery (talk) 12:45, 14 July 2025 (UTC)

@Danny Benjafield (WMDE): The screenshot is clearly what page history already looks like on Wikidata, so it doesn't help me understand what kind of change is coming to Watchlist/RecentChanges. Are you sure it's the right image? Nardog (talk) 13:14, 14 July 2025 (UTC)

Hi @Nardog, you're right that's how it currently looks like on Wikidata, but when Wikidata edits are shown on a Wikipedia Watchlist or Recent Changes list, only the Q/PID are shown. The change we are implementing is to bring those labels (like on the Wikidata version) to all other Wikis. - Danny Benjafield (WMDE) (talk) 13:23, 14 July 2025 (UTC)

But a line on page history doesn't include the relevant page name (as all lines are about the same page), whereas a line on Watchlist/RecentChanges typically include the name of the page the change is about. So I doubt the change you're making will actually look like that (and I hope not). Nardog (talk) 14:06, 14 July 2025 (UTC)

Indeed, the only change that will take place to how the changelog is presented on the Watchlist or Recent Changes list will be expanding:

Property:P161 and Q112562404

into

cast member (P161) and Kris Hitchen (Q112562404) respectively.

And the same for all other PID/QIDs. I will try updating the example from a Watchlist and Recent Changes page to keep the article name plus connected Wikidata item in the change log line. Thanks for pointing this out! - Danny Benjafield (WMDE) (talk) 14:55, 14 July 2025 (UTC)

Thanks a lot, that's a neat change! Just curious, if the name associated with the PID or QID changes, will the change be applied retroactively through the watchlist? For example, if the label for P161 changes from "cast member" to "lineup member", how will it show up in older watchlist changes? Chaotic Enby (talk · contribs) 17:25, 14 July 2025 (UTC)

Thanks @Chaotic Enby :) If an Item label (QID) or a Property label (PID) is changed, it will apply soon after or even the next time the Watchlist/Recent changes page is re-loaded. It shouldn't matter how old the changelog is, the label displayed will be whatever is currently set on Wikidata. - Danny Benjafield (WMDE) (talk) 07:24, 15 July 2025 (UTC)

Oh, I guess the announcement gave me the wrong impression that a new kind of change (like page edit, creation, logged action, etc.) was going to be rolled out on WL/RC rather than just labels for Q/PID. Nevermind then. Nardog (talk) 14:54, 14 July 2025 (UTC)

Sorry, just the labels for now. - Danny Benjafield (WMDE) (talk) 07:25, 15 July 2025 (UTC)

@Danny Benjafield (WMDE): For the record, this would have rendered nothing here:

{{#ifeq:{{CONTENTLANGUAGE}}|en||''(Apologies for posting in English, you can help by translating into your language)''}}

PrimeHunter (talk) 14:02, 14 July 2025 (UTC)

@PrimeHunter Great tip, thank you! Danny Benjafield (WMDE) (talk) 14:26, 14 July 2025 (UTC)

I don't think it's explicitly included above, but I note that the toggle for showing Wikidata in the Watchlist has been moved to the Watchlist preferences! That's a great change. CMD (talk) 15:24, 14 July 2025 (UTC)

Yes indeed! There is a checkbox for the filter Wikidata edits found both on the Watchlist and Recent Changes page by clicking on the hamburger button in the active filters menu. Also to be found in User Preferences > Watchlist/Recent changes menu>Advaned options>Show Wikidata edits in your WL/RC page. - Danny Benjafield (WMDE) (talk) 07:31, 15 July 2025 (UTC)

"add template to favorites"

Moved from Template talk:Navbox#"add template to favorites" Izno (talk) 15:20, 14 July 2025 (UTC)

This button appeared this week atop the navboxes, please remove it. It is clutter, not needed, and is easily clicked on by mistake. Any reason for its inclusion? Thanks. Randy Kryn (talk) 11:59, 13 July 2025 (UTC)

Like... all navboxes? I don't see anything on the examples in the {{navbox}} documentation. Could you give a few places where you have seen this? Primefac (talk) 13:11, 13 July 2025 (UTC)

Hi Primefac. Starting at the top and working down to all other navboxes, {{Wikipedia}}, next to the other buttons (next to 'Watchlist'). But, and maybe this makes a difference, I use Monobook. Thanks for asking. Randy Kryn (talk) 13:25, 13 July 2025 (UTC)

Huh, interesting. It looks like it's on every template, not just navboxes (see e.g. {{infobox rugby union biography}}. Primefac (talk) 13:29, 13 July 2025 (UTC)

It's spreading! Soon, to every page, and then... Randy Kryn (talk) 13:32, 13 July 2025 (UTC)

@Randy Kryn and Primefac: This is a new feature, found on all pages in Template: namespace on all WMF wikis. It was deployed on Thursday 3 July 2025, see Wikipedia:Village pump (technical)/Archive 222#We are looking for a pilot for our new feature, Favourite Templates. It shows as an extra tab at the top of the page, but the appearance and position vary according to skin: in Vector (2022 and legacy) also Timeless, it's a sort of white swallowtail flag held vertically, immediately to the right of the "watch" star; in MonoBook and Modern, it's a tab showing "add template to favorites"; Cologne Blue is like Modern except that it's a link in the left sidebar. I don't know where to find it in Minerva Neue.

The text of the MonoBook tab has a bug, in that the text is larger than the text of other tabs - this may be fixed by adding this rule:

/* fix font size in the new "Add template to favorites" tab */
.skin-monobook #ca-favorite .oo-ui-labelElement-label {
  font-size: inherit;
}

to m:Special:MyPage/global.css. --Redrose64 🌹 (talk) 18:10, 13 July 2025 (UTC)

To hide the bookmark icon completely (e.g. if you use an editor that has no way to make use of "favorite templates"), you can add this to your .css:

/* Hide the new (July 2025) "add to favorites" template bookmark icon */
.mw-list-item.ext-templatedata-caction-favorite { 
  display:none;
}

Works for me, anyway, in Vector 2022. – Jonesey95 (talk) 21:28, 13 July 2025 (UTC)

I have created a stub information page at Wikipedia:Favorite templates. Improvements and expansion of that page are welcome. – Jonesey95 (talk) 21:32, 13 July 2025 (UTC)

Redrose64, in all good faith, why not just remove it everywhere from English Wikipedia? What does it do of any consequence for this site? Did Wikipedia editors "vote" to install this extra "feature" or is this a WMF "just accept it" clutter (at least as I experience it, does anyone here like it?). What is the "favorites" that it adds the pages to, each individuals list of internet favorites or something else, and is it going to expand beyone templates? Thanks. Randy Kryn (talk) 23:25, 13 July 2025 (UTC)

I encouraged the WMF developers to create a page somewhere explaining the feature. They did not do so, as far as I know. It is up to volunteers to document it. – Jonesey95 (talk) 01:01, 14 July 2025 (UTC)

@Randy Kryn: I can't "just remove it everywhere from English Wikipedia", as I have neither the knowledge nor the ability. Even if I had both, I still wouldn't have the right to do so, and certainly not on the request of a single individual. None of it was my decision; I was not involved in the process. Have you read the Village Pump thread that I linked? If you do, you will not find my name mentioned at all until after deployment. As an observation, it's not everywhere on English Wikipedia - it's only on Template: pages, although it is on every Template: page - because it's a feature that detects the namespace of the page that you are viewing, and only add the tab for templates.

But really, this is totally outside the scope of this talk page, which is for discussing improvements to Template:Navbox, Module:Navbox, and their various subpages. --Redrose64 🌹 (talk) 06:47, 14 July 2025 (UTC)

Thanks Redrose64. I just read and then went to skimming the long and now archived discussion, and came away with WMF did not have consensus to deploy the tab but did so anyway. It really clutters up the top of navboxes. Since you answered the above I thought you had something to do with it, hopefully WMF will reconsider its use but after the last skin change I don't have much hope of that. This talk page seems a good as place as any to discuss this pretty much undiscussed change which, as far as I can tell, was not known by the main navbox editors (woodensuperman, were you aware of the coming tab addition?). Thanks for answering my enquiry above. Randy Kryn (talk) 10:38, 14 July 2025 (UTC)

@Randy Kryn Not sure why the template editors for any particular template would have to be aware of it since it appears in the toolbar up at the top, not in the template itself. That being said, the implementation in Monobook seems to be half-baked. In Vector it's a small unobtrusive icon, but in Monobook it's a wide tab with a missing top line and a broken mouseover effect. --Ahecht (TALK
PAGE) 17:40, 14 July 2025 (UTC)

@Sannita (WMF) You indicated on 4 July that the Monobook issues would be fixed in a couple of days, but it's now 10 days later and the appearance is still incorrect. The "add template to favorites" text is too high, so not only does it not line up with the other tabs, but it obscures the top border of the tab. The mouseover effect also does not work. Not to mention that the "add templates to favorites" text is very long compared to the other tabs, and should probably be something like "favorite". Maybe a better approach would be to create a monobook version of the text-based tab rather than trying to make an ooui widget look like a text tab. --Ahecht (TALK
PAGE) 17:50, 14 July 2025 (UTC)

@Ahecht Apologies if we didn't still fix the problem. I'll report it (again) to the engineers, and request a new fix. Sannita (WMF) (talk) 18:33, 14 July 2025 (UTC)

@Ahecht Devs told me the problem has already been fixed with the last patch. Maybe, it's a cache problem on your side, try maybe to bypass/clean it and let me know if it works. Sannita (WMF) (talk) 13:28, 15 July 2025 (UTC)

@Sannita (WMF) It's a different appearance bug than the original one, I think. I've done a bypass/clean and turned on safe mode. Here's a screenshot of how it appears in Edge: File:Favorite template monobook.png, with the text placed higher, the missing top border, and the broken mouseover. --Ahecht (TALK
PAGE) 14:26, 15 July 2025 (UTC)

@Ahecht Thanks for the screenshot. We're discussing it and see what we can do. Just a little more patience. Sannita (WMF) (talk) 17:06, 15 July 2025 (UTC)

Also, if you want to follow the work, we opened phab:T399615 to deal with the problem. Sannita (WMF) (talk) 17:34, 15 July 2025 (UTC)

I've made T399615 for that, and written patch 1169707 for the team working on template favoriting. It fixes it for me, but your screenshot shows it more extremely-offset than my own does, so it's possible there's something else in there that might need further tweaking. DLynch (WMF) (talk) 17:35, 15 July 2025 (UTC)

@DLynch (WMF) Manually adding that CSS in the developer console seems to fix it on my end. Thanks! --Ahecht (TALK
PAGE) 19:39, 15 July 2025 (UTC)

Maybe the tab should be omitted if users disable VisualEditor at Special:Preferences#mw-prefsection-editing. PrimeHunter (talk) 18:00, 14 July 2025 (UTC)

The functionality works in the source editor too. Sjoerd de Bruin (talk) 18:34, 14 July 2025 (UTC)

Thanks. When logged out I still see a "Favorites" tab in the template wizard and "Templates you mark as favorites will appear here". Can logged users actually use the feature? PrimeHunter (talk) 20:51, 14 July 2025 (UTC)

Yes. Nthep (talk) 19:58, 15 July 2025 (UTC)

I meant to ask: Can logged out users actually use the feature? If so, how? When logged out, I see no icon on template pages. Where would the favorites come from? If they cannot use the feature then it seems an error that they see "Templates you mark as favorites will appear here". PrimeHunter (talk) 20:31, 15 July 2025 (UTC)

They can't. I saw that T399524 was filed about this, so the text will probably be corrected soon. Matma Rex talk 21:38, 15 July 2025 (UTC)

Thanks. PrimeHunter (talk) 23:13, 15 July 2025 (UTC)

It doesn't show up on the navboxes themselves for me either, and (on Vector 2010) only shows up as an icon similar to the watchlist one, which makes sense as they're similar in function. Monobook doesn't seem to have a watchlist button there, but I would second the idea of shortening it to "favorite" or even "fav" if necessary. Chaotic Enby (talk · contribs) 18:16, 14 July 2025 (UTC)

To Randy Kryn: It has been requested by the community, see meta:Community Wishlist/Focus areas/Template recall and discovery (development project page), meta:Community Wishlist/Wishes/Quickly Add Infobox 2 (new wishlist page), meta:Community Wishlist Survey 2023/Editing/Quickly add favorite and related templates (community wishlist entry from 2023). To Jonesey95: There is a stub description at mediawikiwiki:Help:TemplateData/Template discovery#Favourite templates. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:46, 14 July 2025 (UTC)

Thanks for that link. I don't know why the WMF developers chose not to provide that link in the original discussion. Maybe I missed it. Also, thanks to the many editors who have improved Wikipedia:Favorite templates. – Jonesey95 (talk) 22:41, 14 July 2025 (UTC)

@Jonesey95 When I posted originally here, and when I included the news about the features developed in Tech News, I shared the link to the Community Wishlist focus area and to the documentation (in Tech News only), I guess it wasn't that clear. Maybe next time I'll make the link more prominent. Sannita (WMF) (talk) 22:44, 14 July 2025 (UTC)

@Jonesey95 Would you be opposed to moving the page to the help namespace? To me it reads more like a help page and since the information in it applies to every wiki with the favourite templates feature as opposed to just the English Wikipedia I feel that Help:Favorite templates would have been a more appropriate place for it. Warudo (talk) 10:15, 16 July 2025 (UTC)

Asking "why not just remove it everywhere from English Wikipedia?" without bothering to understand what it does or why it was added is puerile behavior. – SD0001 (talk) 19:33, 14 July 2025 (UTC)

Agree. The feature was added from the community wishlist, and as someone who edits in source mode but sometimes uses the 🧩 button for template insertion, it seems like something I might use in the future. There's plenty of buttons in the MediaWiki UI that not everyone uses, adding one more to the mix is hardly worth a massive outcry, and if the feature displays poorly on some skins it can be fixed.  novov talk edits 03:21, 16 July 2025 (UTC)

Tech News: 2025-29

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• Featured templates, a new feature related to Template Recall and Discovery will be deployed this week to all Wikimedia projects: With this feature, editors will be able to quickly access a list of templates that are likely to be useful. These templates will be displayed in a list, under the "featured" tab of the template discovery interface. Administrators can define the list via the Community Configuration interface. The feature fulfills a request by the community through the Community Wishlist. [5][6]
• View all 31 community-submitted tasks that were resolved last week. For example, the request to add Malayalam fonts in the Wikisource Book Export Tool was resolved and now, the rendering of Malayalam letters in exported Wikisource books are accurate. [7]

Updates for technical contributors

• Detailed code updates later this week: MediaWiki

In depth

• Developers, designers, and all Wikimedians are invited to submit a project idea for the Wikimania Hackathon 2025. Read this Diff blog post for more details.

Meetings and events

• WikiIndaba 2025 scholarship application and program submission is open until 23:59 GMT on July 20. WikiIndaba is a regional conference for African Wikimedians both on the continent and in the diaspora to unite and grow together. Submit your scholarship application and program proposal now!
• WikiCon Brasil 2025 will take place on July 19-20 in Salvador, Bahia, Brazil. The Brazilian community members are encouraged to register and attend!

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 20:05, 14 July 2025 (UTC)

PEIS limit reached at Talk:COVID-19 lab leak theory

The talk page Talk:COVID-19 lab leak theory seems to have its PEIS limit reached possibly in the header. The talk page is filled with users quoting text but {{tq}} and {{tq2}} don't render. It seems like it's even affecting the archival bot's template. Is one of the banners so expensive that it breaks the talk page within the header? Dan Leonard (talk • contribs) 20:58, 14 July 2025 (UTC)

@Dan Leonard: Previewing in isolation and looking at "Parser profiling data" at the bottom shows that {{xreadership|days=90}} uses 1510K and {{Talk:COVID-19 lab leak theory/Sources}} uses 713K. Those two break the 2MB limit together. All the rest only uses 205K in total. PrimeHunter (talk) 21:29, 14 July 2025 (UTC)

I've commented out {{xreadership}} and tweaked the sub-templates of /Sources to be more WP:PEIS efficient. --Ahecht (TALK
PAGE) 21:36, 14 July 2025 (UTC)

Courtesy notification to @TarnishedPath, who placed the {{xreadership}} template. --Ahecht (TALK
PAGE) 21:40, 14 July 2025 (UTC)

@Ahecht, thankyou for drawing this to my attention. I've completely removed the xreadership template. TarnishedPath^talk 23:46, 14 July 2025 (UTC)

Restored file version is incorrect

I ran into something weird, wondering if anyone's seen this before. The history, as best I can tell, is that File:Der Schatz (1923).jpg was uploaded in 2016 as a 640 × 480 image, DatBot replaced it in 2017 with a smaller 365 × 273 image, the original image was F5 deleted, and then today the original version was undeleted. What's odd is that the undeleted original file is showing up as an exact copy of the smaller version, and trying to revert back to it gives the error message "The upload is an exact duplicate of the current version of File:Der Schatz (1923).jpg." Anyone know why this might happen? hinnk (talk) 02:39, 15 July 2025 (UTC)

@Hinnk, Try purging the page cache? JayCubby 16:03, 15 July 2025 (UTC)

I tried that, didn't do anything unfortunately. hinnk (talk) 16:25, 15 July 2025 (UTC)

Able to replicate. The older version is in fact a duplicate JayCubby 16:55, 15 July 2025 (UTC)

Thanks, I ended up submitting a bug report in case there's an underlying issue that might affect other files. Not too worried about this particular file, I should be able to recreate the original. hinnk (talk) 18:41, 17 July 2025 (UTC)

White space size

The illustration shows the (relative) sizes of various Unicode whitespace points. However it does not specify the font. Clearly six-per-em, three-per-em and em should retain their ratios, but even that's not guaranteed. Do we know (or can we find out) the font? If not can we make a new one in a specified font, and if so which should we use? Or am I wrong and the ratios are fixed, at least theoretically? And what about the height-width ratio? All the best: Rich Farmbrough 10:11, 15 July 2025 (UTC).

The SVG code says the font is DejaVu Sans (there is a preview under § "Usage"). LightNightLights (talk • contribs) 12:28, 15 July 2025 (UTC)

The spaces themselves are hard-coded as a path, however, though it might have been generated from DejaVu Sans. Nardog (talk) 12:59, 15 July 2025 (UTC)

There's a hidden text object in the SVG, containing ▕ ▏ (those are U+2595 ▕ RIGHT ONE EIGHTH BLOCK and U+258F ▏ LEFT ONE EIGHTH BLOCK) for the various spaces. If you unhide it, the path lines up with the spaces in between the bars. Anomie⚔ 12:25, 16 July 2025 (UTC)

According to https://web.archive.org/web/20100314135826/https://www.microsoft.com/typography/developers/fdsspec/spaces.htm, there are some suggested ratios (or range of ratios), but no hard rule that each font has to follow. —CX Zoom[he/him] ^{(let's talk • {C•X})} 23:48, 15 July 2025 (UTC)

Images in dark mode

Ever since Wikipedia's introduction of dark mode, some images are not displaying well in dark mode. Here is a (non-exhaustive, obviously!) list of some articles with these images in the infobox and which I have fixed:

• City Journal (before, after, diff)
• DirectX (before, after, diff)
• Gawker (before, after, diff)
• OpenDyslexic (before, after, diff)
• The Living Tombstone (before, after, diff)

Additionally, I have noticed this problem in these articles too but I have not gotten to fix them:

• List of display typefaces (permalink as of posting)
• List of monospaced typefaces (permalink)
• List of sans serif typefaces (permalink)
• List of script typefaces (permalink)
• List of serif typefaces (permalink)

I think it is fair to say that this is a widespread problem, and that we should fix it. I am not sure on the details of how, but I think that we need more awareness on this regardless.

I am also hoping we can ruminate and discuss on how we would be able to fix it. Maybe we need a guide for individual editors to help fix the images? Maybe we need to create edit requests for locked templates in order to fix the images? Can we create some kind of drive to fix it? There are more questions and I am not sure on their answers. LightNightLights (talk • contribs) 21:56, 15 July 2025 (UTC)

A related issue is that image captions displaying colours in a legend can show the wrong colours. CMD (talk) 03:22, 16 July 2025 (UTC)

In general, a parameter like |logo_class= should be used (like this) instead of sending a full File: call to Module:InfoboxImage. It can be added to any infobox that is missing such a parameter. – Jonesey95 (talk) 05:25, 16 July 2025 (UTC)

I believe that I have fixed the "List of ... typefaces" by changing a template. Wikipedia was built around a core assumption of black text on a white background for a couple of decades; fixing all of the dark mode issues will take a considerable amount of work. Much has been done already, but hundreds of thousands of pages, maybe millions, need to be edited for full compatibility. Good thing there is no deadline. – Jonesey95 (talk) 05:36, 16 July 2025 (UTC)

I agree. Hundreds of thousands of pages is still a lot lot, and more awareness of this issue among editors that can learn how to fix it will definitely help, in my opinion. LightNightLights (talk • contribs) 11:51, 16 July 2025 (UTC)

I forgot to look at your diff. It looks good to me. Some inverted Example 3 images look bad, but they do not look good uninverted in light mode either so the problem is inherent in the image. Taking this as an opportunity though, we probably should not apply |class=skin-invert universally and unconditionally, because it changes colors that might have been picked for meaning. See this page of mine for an example. (Disclaiming that I have brought this up before here to developers, which resulted in mw:Recommendations for night mode compatibility on Wikimedia wikis § "When skin-invert does not work".) LightNightLights (talk • contribs) 12:19, 16 July 2025 (UTC)

I thought of that, but a lot of infobox templates currently lack that type of parameter (e.g. Template:Infobox musical artist [permalink], used by The Living Tombstone) and it would take time and template editors to fix them, while the File: call works right now. LightNightLights (talk • contribs) 11:39, 16 July 2025 (UTC)

Incorrect talk page message at Talk:Hamas

While checking the state of my futile edit request I noticed that the talk page says: You are an administrator, so you may disregard the message below. Stop: You may only use this page to create an edit request (screenshot). But of course I'm not an administrator or the edit request would have been unnecessary. Oddly the box containing that first sentence only appears when the screen width is narrow, specifically 639px or less. The offending CSS rule is:

@media screen {
  @media (max-width: calc(639px)) {
    .mw-parser-output table {
      display: block;
      overflow: auto;
      max-width: 100%;
    }
  }
}

Which is apparently overriding the sysop-show class that's meant to hide the box. Ioaxxere (talk) 22:24, 15 July 2025 (UTC)

MediaWiki:Common.css says:

.checkuser-show,
.sysop-show,
.abusefilter-show,
.abusefilter-helper-show,
.patroller-show,
.templateeditor-show,
.extendedmover-show,
.extendedconfirmed-show,
.autoconfirmed-show,
.user-show {
	display: none;
}

That should probably be harder to override. MediaWiki:Group-sysop.css uses !important to override it:

div.sysop-show,
p.sysop-show {
  display: block !important;
}
span.sysop-show,
small.sysop-show {
  display: inline !important;
}
table.sysop-show {
  display: table !important;
}
li.sysop-show {
  display: list-item !important;
}

PrimeHunter (talk) 23:48, 15 July 2025 (UTC)

Only an issue in Minerva skin, it seems. Can't replicate with Vector-2022, but can replicate with Minerva with width <639px. —CX Zoom[he/him] ^{(let's talk • {C•X})} 00:04, 16 July 2025 (UTC)

I can replicate in all tested skins including Vector 2022 when logged out. PrimeHunter (talk) 00:28, 16 July 2025 (UTC)

My bad, sorry. Yes, it is an issue on all skins. —CX Zoom[he/him] ^{(let's talk • {C•X})} 00:37, 16 July 2025 (UTC)

This would be fixed with User:Izno/Sandbox/Ambox and the work in Module:Message box/div and some adjustment in downstream users. I think I might work on that this week. Izno (talk) 01:47, 16 July 2025 (UTC)

Those !important annotations shouldn't be necessary, since a selector like div.sysop-show has a higher specificity than .sysop-show. --Redrose64 🌹 (talk) 07:16, 16 July 2025 (UTC)

!important has the function of being more important than CSS elsewhere in the cascade, but also more important than inline styles, for which there is no solution other than !important. My impression is that sysops want to see content marked up with this class even if there is a style="display: none" somewhere in the local wikitext. (And though there is CSS now that will simply revert the text to the expected value making the element names unnecessary in the Group-sysop.css sheet, that CSS is still pretty new.)

We probably need to update the block in Common.css by adding another class to each selector [in the meantime if we don't want to wait on the actual fix]. Izno (talk) 07:22, 16 July 2025 (UTC)

Ref "name" attribute

The ref "name" attribute with a value is added automatically to the source code? Lets say, I add refferences without the attribute in wikicode and then save it. Juandev (talk) 08:20, 16 July 2025 (UTC)

@Juandev No, "name" is not automatically added. If you use WP:REFTOOLBAR, there is a field for that, called "Ref name" (or you can add the code manually), but I don't see one in visual editor. However, in VE, it seems that if you "Re-use" an un-named ref, VE will name the ref for you. Hope this helps some. Gråbergs Gråa Sång (talk) 09:14, 16 July 2025 (UTC)

VE's naming is a little unhelpful admittedly (":0", ":1", etc), and there's a long-standing task for working out a way to autogenerate better names: T92432. DLynch (WMF) (talk) 16:43, 16 July 2025 (UTC)

@Juandev: The name= attribute is optional. You only need to have one if the ref is used multiple times in the same page, see WP:REPEATCITE. --Redrose64 🌹 (talk) 17:51, 16 July 2025 (UTC)

Inconsistencies with #assessment of dabs after null edits

[8] correctly says both of Lathyrism (disambiguation) and Bell TV are "Disambig" class. If you null-edit the talk page of one of those, it suddenly becomes "" (unknown) class in the database ([9]). If you null edit it again, it regains it. I've done this a few times on-and-off and it seems consistently reproducible. This does not behave the same for all pages: for now it looks like this happens solely to pages that are tagged only with {{WikiProject Disambiguation}}. For pages that have WP:DAB and another project, null editing makes a supplementary "" row appear and disappear. For pages that don't have the WP:DAB tag, they apparently always have a supplementary "" row on top of the correct one, and null-editing changes nothing. Anyone have an idea why? — Alien  3
3 3 09:31, 16 July 2025 (UTC)

Courtesy ping to @MSGJ as they maintain the WP:PIQA ecosystem. —CX Zoom[he/him] ^{(let's talk • {C•X})} 12:00, 16 July 2025 (UTC)

I can reproduce this via [10]. It seems it may be because {{WikiProject Disambiguation}} is adding the assessment twice, once in the meta module and once manually (added by Galobtter in 2018). I have removed the additional call, so we can see if that fixes the problem, although why adding an assessment twice would cause it to disappear I have no idea — Martin (MSGJ · talk) 12:55, 16 July 2025 (UTC)

That made the assessment disappear permanently, so I have reverted my change. Time to study the code in the module ... — Martin (MSGJ · talk) 12:58, 16 July 2025 (UTC)

@MSGJ: found it: the shell calls class_mask with the wrong FQS value: disambig is part of the Full Quality Scale. That false should be a true. Took me an awfully long while to find (followed a red herring and fully checked every step of the execution of class_mask). — Alien  3
3 3 19:18, 16 July 2025 (UTC)

That is not actually the part which is causing the issue, but I can see the logic you have followed. The page assessment on the banner shell does not run on non-articles. The line which needs to be changed is Module:WikiProject banner#L-487. Currently it runs even if class and importance are blank, which is the case for the Disambiguation template. And that blank assessment is overwriting the other one. — Martin (MSGJ · talk) 08:16, 17 July 2025 (UTC)

This is the fix, and I have tested it successfully on Talk:Bell TV using {{WikiProject Disambiguation/sandbox}} — Martin (MSGJ · talk) 08:23, 17 July 2025 (UTC)

Indeed, you're right. Many thanks. — Alien  3
3 3 11:13, 17 July 2025 (UTC)

Okay, will probably deploy the fix later today — Martin (MSGJ · talk) 11:35, 17 July 2025 (UTC)

I applied this change yesterday but I think I need to revert it. On thinking further, PageAssessments are not just for class and importance ratings. They also serve to identify pages with WikiProjects. There are lots of projects which do not use quality or importance assessments, but my change yesterday will be removing them from the database. So instead, can we use a different project name for the manually applied page assessment. Something like this

"Disambiguation": {
 "class": "",
 "importance": ""
}
"Disambiguation2": {
 "class": "Disambig",
 "importance": ""
}

— Martin (MSGJ · talk) 10:35, 18 July 2025 (UTC)

Underscores in displayed titles

Are there any pages in which a space is displayed as an underscore, whether with {{DISPLAYTITLE}} or any other mechanism? If this page had such a displayed title, it might be Wikipedia:Village pump_(technical), for example. Nyttend (talk) 10:50, 16 July 2025 (UTC)

@Nyttend: This search finds 124 articles using DISPLAYTITLE to make underscores: insource:DISPLAYTITLE insource:/DISPLAYTITLE:[^}]*_/. Some of them add it at the ends where it doesn't replace a space. PrimeHunter (talk) 11:42, 16 July 2025 (UTC)

Sleepless in ends with 10 underscores. PrimeHunter (talk) 11:50, 16 July 2025 (UTC)

A list exists at Category:Articles with underscores in the title. * Pppery * _{it has begun...} 15:29, 16 July 2025 (UTC)

Interesting! I had no idea there was a category. I was thinking of some sort of automated replacement project, since underscores are unsightly if they don't belong; I had no idea that someone else had already thought of this. Nyttend (talk) 02:42, 17 July 2025 (UTC)

incategory searching

Tracked in Phabricator
Task T399730

Similar to this discussion from two months ago, an incategory search of Category:Living people (a check I have to perform several times daily, due to the constant addition of draftspace and userspace pages to it) is once again failing to clear and drop pages that were already removed from it hours ago.

The explanation last time was that "the indexing pipeline got stuck today...and no updates were being processed" — so that may have happened again, and I wanted to let people know so that it can be looked into and fixed. Bearcat (talk) 13:50, 16 July 2025 (UTC)

@Bearcat: It shows the time of the searched revision. Add sort=last_edit_desc to see results in descending order of that time, and you only have to examine pages with a newer time than the last time you fixed all pages. At least in theory. In practice, the previous time you made the search it may have missed pages which were added to the category recently in an edit which had not been indexed by that search. The category could also have been added by a template edit without editing the page. But I think it's good enough when it's not important whether a page stays a little longer in the category. PrimeHunter (talk) 14:41, 16 July 2025 (UTC)

There's nothing to "sort" — since the search isn't updating at all, it isn't picking up any new additions since my last cleanup run on the current contents either. But draft or user pages getting added to that category happens at a rate of at least 40 to 50 pages per day, and with over a million articles it's just not possible to manually browse the category for draft or user pages at all — so it's a search that needs to be performed several times a day and can't just wait a week, and we can't just let it slide as "not a problem" if the search is failing to update at all. Bearcat (talk) 15:03, 16 July 2025 (UTC)

Might a watchable subpage of Wikipedia:Database reports with output similar to quarry:query/95644 work better? (Admittedly, sometimes the database mirrors that both that and Quarry pull from sometimes get out of date too - try searching the VPT archives for "replication lag" - but it seems to happen less often.) —Cryptic 18:37, 16 July 2025 (UTC)

@Bearcat You can use Userspace pages from most recent and Draftspace pages from most recent to get the lists directly from the API without having to worry about search indexing. I added a collapsed box to Category:Living people that allows retrieving these lists for any namespace. --Ahecht (TALK
PAGE) 18:48, 16 July 2025 (UTC)

How to fully enable the page title autocomplete

I have the Improved Syntax Highlighting beta feature enabled. By reading through phab:T95100, I discovered if I press Shift+Enter in the middle of typing a wikilink or template, a dropdown of page titles I may be looking for will appear. The problem is that because I have to stop typing and press Shift+Enter every single time I want to use this, it's actually slower than just typing the whole thing manually. Is there any way to force this dropdown to appear automatically every time? Warudo (talk) 15:48, 16 July 2025 (UTC)

Courtesy ping @MusikAnimal as one of the main devs. I vaguely recall discussing automatic autocomplete with them at some point. — Alien  3
3 3 21:20, 16 July 2025 (UTC)

Yes, we plan to make this happen. It's been on my mental to-dos for a while. I've filed phab:T399774. — MusikAnimal ^talk 21:47, 16 July 2025 (UTC)

@MusikAnimal Nice. Thank you for working on this feature.

I have however, noticed some problems with the feature in its current state. First, the autocomplete should still work when substituting a template. Right now, if I type {{subst:a for example and press Shift+Enter, nothing happens, which is strange. There's also a bug with the suggestions. The autocomplete is sensitive to the initial conditions in the sense that if I type one letter, press Shift+Enter and then type the rest, I get different results than what I'd get if I type more letters initially. For example, in my testing, if I type "{{u Shift+Enter nich", {{unichar}} will not appear in the results. However, if I instead type "{{un Shift+Enter ich" then it will appear. Warudo (talk) 22:50, 16 July 2025 (UTC)

For the first one, yes, because CodeMirror currently has no way to know subst:, safesubst: and raw: are all magic words. For the second one, it is the expected behavior (for now) because the search query is not updated given validFor.析石父 (talk) 00:23, 17 July 2025 (UTC)

AbuseFilter variable for page creator

Following this discussion at EF/R, it seems like we don't have an AbuseFilter variable to identify a page's creator, which would be quite useful in cases like the one described there. Are there specific reasons why this isn't a thing, or should I file a Phab ticket? (courtesy ping to @PharyngealImplosive7) Chaotic Enby (talk · contribs) 18:53, 16 July 2025 (UTC)

Note page_first_contributor identifies the page's first contributor/editor, excluding the page creator. – PharyngealImplosive7 (talk) 19:06, 16 July 2025 (UTC)

Do you have an example? page_first_contributor is just the first username in the history, which (ignoring selective deletion, merges, imports, etc.) should be the page creator. Suffusion of Yellow (talk) 23:08, 16 July 2025 (UTC)

@Chaotic Enby and Suffusion of Yellow: If I use page_first_contributor here, the filter for some reason does not match? (I've changed the filter back to using page_first_contributor just to show that it doesn't match) – PharyngealImplosive7 (talk) 23:36, 16 July 2025 (UTC)

Looking at the debug screen, user_name is "Dontontini", and page_first_contributor is null, for some reason. Chaotic Enby (talk · contribs) 23:42, 16 July 2025 (UTC)

Very odd; I wouldn't expect page_first_contributor to be null. Perhaps this does warrant a phab ticket. – PharyngealImplosive7 (talk) 23:46, 16 July 2025 (UTC)

Other filter hits also give me null when debugging that variable... Picking a random one off the abuse log, this one does it too. Do we have any existing filters that depend on this variable? Chaotic Enby (talk · contribs) 23:48, 16 July 2025 (UTC)

As for the public filters, 1060, 1151, and 1318 use it. – PharyngealImplosive7 (talk) 23:52, 16 July 2025 (UTC)

They do seem to keep getting hits, and, taking Special:BlankPage/FilterDebug/logid/41360550 from 1060 (first one I can view), it does seem to correctly flag page_first_contributor (which would be expected given the filter), so it isn't an issue with the debug screen always showing it as null for some reason.

Is there a way to track the hit rate of filters across time, to see if it unexpectedly fell off at some point? Chaotic Enby (talk · contribs) 23:56, 16 July 2025 (UTC)

See below; the problem isn't with the variable but rather because FilterDebugger does not "fill in" missing variables as SoY said. – PharyngealImplosive7 (talk) 00:02, 17 July 2025 (UTC)

page_fist_contributor is a lazy-load variable. At the time of that hit (23:15, 16 July 2025), the filter was not attempting to access page_fist_contributor, so it was never generated. FilterDebugger does not attempt to "fill in" missing variables when debugging filter logs, nor does Special:AbuseFilter/examine for that matter. Suffusion of Yellow (talk) 23:58, 16 July 2025 (UTC)

Ok, that clears it up. Thanks. – PharyngealImplosive7 (talk) 00:01, 17 July 2025 (UTC)

Documented it now, at least. Probably should have done that to begin with... Suffusion of Yellow (talk) 00:30, 17 July 2025 (UTC)

That makes sense for me too – I guess we can go back to using it in 1370? Chaotic Enby (talk · contribs) 00:05, 17 July 2025 (UTC)

Yeah, I guess. – PharyngealImplosive7 (talk) 00:07, 17 July 2025 (UTC)

Curious

When I signed in today I had to put in a verification code, and the email about it said it was because I was "signing in from a new device", even though it's the same device and connection I've been on for years. Maybe it's because there was a power outage earlier that knocked out my net, and thus it's rerouted/geolocating to elsewhere now? - The Bushranger _{One ping only} 20:24, 16 July 2025 (UTC)

@The Bushranger: Your IP address may have changed. --Redrose64 🌹 (talk) 23:33, 16 July 2025 (UTC)

Yeah, it's just weird that it's never done that before. <shrugs> - The Bushranger _{One ping only} 00:54, 17 July 2025 (UTC)

That is because it is new functionality. See EmailAuth. In many cases this can be due to usage of VPN or other shared IP situations. —TheDJ (talk • contribs) 09:41, 17 July 2025 (UTC)

Expand language template won't recognize topic

I've been working through the uncategorized pages that have been tagged from translation from Italian to sort them out into the various topical categories. I have found an issue with certain uses for the expand template:

For example the page 2022–23 FC Crotone season used the template

{{Expand language|topic=|langcode=it|date=January 2025}}

This correctly displayed the banner for the page to be translated and the page correctly appeared in the general category Category:Articles needing translation from Italian Wikipedia, however when I filled in the topic field the page disappeared from the general category and never appeared in the Category:Sports articles needing translation from Italian Wikipedia

On the other hand for different pages, for example Mauro Bolognini, the template was

{{Expand Italian|date=November 2024}}

I added the topic field such that it now reads

{{Expand Italian|date=November 2024|topic=bio}}

And now the page correctly appears in Category:Biography articles needing translation from Italian Wikipedia

After some testing it appears that the problem occurs when

{{Expand language|...}}

is used as opposed to

{{Expand Italian|...}}

While I have no problem going back to change the template on the pages I have already sorted if that is the only way to fix this, I am concerned that this issue means there are plenty of pages using the Expand language template which don't appear on any sort of list and that would be very hard to track down. Giuliotf (talk) 21:13, 16 July 2025 (UTC)

I should also add the the

{{Expand language|...}}

version of the tag appears to be the one used by Wikipedia:Twinkle and a lot of the problematic tags appear to have been added by Twinkle edits Giuliotf (talk) 21:39, 16 July 2025 (UTC)

In the past, the {{Expand language}} template was a meta-template only; that is, other templates like {{Expand Italian}}, {{Expand Catalan}} and others used {{Expand language}} to do the work. As it says on the doc page:

The primary use of this template is to create a new wrapper template for a particular language.

That used to be its only purpose, but at some point, this was altered, and it is now possible to call it directly. This causes more confusion than it is worth, imho, but I guess that was the consensus at the time. In any case, as you have noticed, the individual Expand language templates handle the |topic= param correctly, so your approach is the right one.

Regarding your concern about categorization, do you have an example? Here are a couple of search links that might help:

• all articles calling Expand language
• 3 dozen which use topic param
• 1 which uses topic and lang=it (you would need a different search if it uses lang first, and then topic)

If you find some examples which are uncategorized, please post them here. Hope this helps! Mathglot (talk) 21:58, 16 July 2025 (UTC)

@Mathglot

The Italian article you linked (Cervi Brothers) does not appear in any of the Italian articles needing translation categories, and there are plenty of other examples such as 2022–23 FC Crotone season that I linked above.

@PrimeHunter below suggested that the keyword has not been entered correctly, which appears to be the case for the sports articles in which case there is a problem with the documentation and with the two versions of the command having inconsistent keywords.

Another point is that I've seen other articles (for example Ballando con le Stelle series 10) which used the "Expand Italian" template that had an incorrect keyword that were placed in the general category which seems to be a sensible way of doing it. For the "Expand language" version of the command if an incorrect keyword entered the article is still removed from the general category, but isn't put into another category afterwards; at the very least this command should be updated such that if an incorrect keyword is entered it defaults to the general category Giuliotf (talk) 23:06, 16 July 2025 (UTC)

Add ping: User:Giuliotf. Mathglot (talk) 21:59, 16 July 2025 (UTC)

@Giuliotf: You didn't post the code which failed: {{Expand language|topic=sport|langcode=it|date=January 2025}}. Template:Expand language#Parameters says:

Do not use these parameters for direct transclusion:

• |name= (defaults to 'Expand language'; only needed for transcluding templates; could change css class membership if altered, which could affect rendered appearance of the box)
• |topic= (could interfere with categorization)

I looked at the code and if you do use |topic= anyway then it has to match a category name, in this case "sports" (plural) in Category:Sports articles needing translation from Italian Wikipedia. It works with |topic=sports but there is contradictory documentation about the extra "s". PrimeHunter (talk) 22:04, 16 July 2025 (UTC)

I've just tested this

{{Expand language|topic=sport|langcode=it|date=January 2025}}

with sport singular it doesn't work

{{Expand language|topic=sports|langcode=it|date=January 2025}}

with sports plural does seem to work correctly

{{Expand Italian|date=November 2024|topic=sport}}

with sport singular works correctly

{{Expand Italian|date=November 2024|topic=sports}}

with sports plural doesn't work Giuliotf (talk) 22:22, 16 July 2025 (UTC)

And I've been following this documentation to know the keywords to used Template:Expand Italian, which is what is linked from Category:Articles needing translation from Italian Wikipedia which says to use "sport" singular Giuliotf (talk) 22:25, 16 July 2025 (UTC)

For {{Expand Italian}}) (or any of the individual language templates), it has to do with how coders at the individual templates code the switch statement with selector 'sport' or 'sports'; they all seem to use the singuar, per this search, but the same cannot be said for topic transp, which sometimes must be given that value (e.g., {{Expand German}} or {{Expand Italian}}, but sometimes may use transport for the topic as well (e.g., French, Portuguese). The same variability exists with topic cult. If you find anomalous examples, please list them and they can be brought in line. Mathglot (talk) 23:07, 16 July 2025 (UTC)

None of them appear to use a '#DEFAULT' switch selector, which could be used to detect an invalid topic and return an error instead of doing the categorization differently/wrong. That would have to be added individually, to each Expand FOO template one at a time. Although they wouldn't have to be done all at once, there is common doc for all the individual languages, so we would have to be careful what to say about invalid topics, until they were all done. I looked into the possiblity of unifying all of the individual Expand FOO templates, and while it is possible, it is probably not worth the pretty significant, and very tedious effort to do it. One upside, would be fixing problems like the one you have raised here. But it is doubtful whether it is worth expending that much effort to do it, for a relatively minor improvement from the user's point of view. Then main benefit would be to future maintainers of the template, not users, and that isn't a good enough reason to do it, imho, especially as there are easier methods available right now; i.e., fix the switch statement (add #DEFAULT), fix the doc page, or both. It would be easy to add something to the doc page saying what happens if you pick an invalid topic, and if it doesn't already have that, we should add it.

For the {{Expand language}} template, as PrimeHunter already explained, you just shouldn't use it. Probably an enhancement to that template to catch that case would be an improvement (a general template exists to catch invalid params, and could be used for that.) Mathglot (talk) 23:34, 16 July 2025 (UTC)

For the {{Expand language}} template, |topic= is not an invalid parameter, but it might be supplied with an invalid value. Looking at the wikisource for Template:Expand Italian, it has the following code:

|topic={{#switch: {{{topic}}}
 | bio = Biography
 | geo = Geography
 | gov = Government and politics
 | cult = Culture
 | hist = History
 | mil = Military
 | sci | tech | scitech = Science and technology
 | sport = Sports
 | struct = Building and structure
 | transp = Transport
}}

so {{expand Italian|Football Club Internazionale Milano|topic=sport}} is treated as if it were {{Expand language|otherarticle=Football Club Internazionale Milano|topic=Sports|langcode=it}} and the page is placed in Category:Sports articles needing translation from Italian Wikipedia. This is a subcategory of Category:Articles needing translation from Italian Wikipedia which has 11 subcategories, corresponding to 10 of the 11 possible values for topic; the eleventh is Category:Featured articles needing translation from Italian Wikipedia, which is emitted when |fa=yes is set. There is corresponding, but different, code in Template:Expand French:

|topic={{#switch: {{{topic}}}
 | bio = Biography
 | geo = Geography
 | gov = Government and politics
 | cult
 | culture = Culture
 | hist = History
 | sci | tech | scitech = Science and technology
 | mil = Military
 | sport = Sports
 | transp
 | transport = Transport
 | struct = Building and structure
 | commune = French commune
}}

which means that {{expand French}} allows |topic=culture as an alias for |topic=cult; and also allows |topic=commune, which has no corresponding value in {{expand Italian}}. Compare Template:Expand Neapolitan, where |topic= is silently ignored - it passes a blank value into the |topic= parameter of {{Expand language}}. --Redrose64 🌹 (talk) 10:46, 17 July 2025 (UTC)

Perhaps {{Expand ...}} too could use a consolidation like the former {{lang-xx}} templates. Nardog (talk) 12:19, 17 July 2025 (UTC)

Wikipedia:The 50,000 Destubbing Challenge

Can somebody fix the column/flag icon error. If it's the size causing it, help archive entries added from the contest? ♦ Dr. Blofeld 15:54, 17 July 2025 (UTC)

This looks done now. Izno (talk) 03:05, 18 July 2025 (UTC)

Password Plus and Super Password

Is there a reason the "Display title" feature isn't working properly on Password Plus and Super Password? It should have everything but the "and" italicized, but even with a use of {{displaytitle}} the "and" is still italicized. I tried mucking around with displaytitle and it just kept giving me error messages. Ten Pound Hammer • ^{(What did I screw up now?)} 16:17, 17 July 2025 (UTC)

According to the documentation for {{Infobox television}}, it automatically italicizes the entire page title. You can try adding |italic_title=no to the parameters and then using DISPLAYTITLE: magic word directly. isaacl (talk) 16:37, 17 July 2025 (UTC)

I don't see a recent edit by you (or anyone else) attempting to set displaytitle on that article, so I assume you only previewed? There's a big red warning on preview only that says something else sets it to italicize the whole title. Typically that's an infobox, and - as Isaacl says - here it's two separate transclusions of {{infobox television}}. Either putting it after the infoboxes or (better) adding italic_title=no to their parameters (for both transclusions) works properly. —Cryptic 16:40, 17 July 2025 (UTC)

Yeah, I previewed like five times and kept getting error messages so I just gave up. Looks like it's been fixed though. Ten Pound Hammer • ^{(What did I screw up now?)} 17:36, 17 July 2025 (UTC)

Fixed in Special:Diff/1301011499 Ponor (talk) 16:41, 17 July 2025 (UTC)

italic_title=no seems to force the infobox's header to the article name, ignoring name=. Compare output before, after, and reproducible with just {{Infobox television|name=Password Plus|italic_title=no}} on that page (but, strangely, not when previewing here). Might be better to leave the infoboxes as-is and override the title afterwards after all. —Cryptic 16:56, 17 July 2025 (UTC)

That was odd but I found a way to respect name=.[11] PrimeHunter (talk) 22:53, 17 July 2025 (UTC)

Amazing fix CMD (talk) 04:12, 18 July 2025 (UTC)

Well-spotted. I did look at Module:Infobox and didn't see anything relevant; I didn't think to check which module {{infobox television}} actually called.

I don't think it likely that your fix will survive for long in the face of AWB and bots falling over themselves to remove spaces after open-braces. If they do, using Template:DISPLAYTITLE or its redirect {{displaytitle}} instead of the magic word won't be matched by this misfeature either. Though, they might helpfully unfix that, too. —Cryptic 00:16, 18 July 2025 (UTC)

Infobox TV should probably not be that smart. Izno (talk) 03:11, 18 July 2025 (UTC)

Unusual edits by single purpose contributor

Hi. I’m just puzzled by some new accounts like Special:Contributions/Khlee560. At least on the iPad the diff is empty. Any idea what this about? Johnjbarton (talk) 22:47, 17 July 2025 (UTC)

If you look at contributions, even deleted contributions, the account has done nothing. But if you look at global contributions you find someone who is mostly active on Ko Wikipedia. I'm assuming that's the Korean language wikipedia. I think this is what happens when you view some pages on a different language Wikipedia while logged in, the software automatically creates your account on that wiki. ϢereSpielChequers 23:03, 17 July 2025 (UTC)

Makes sense thanks! Johnjbarton (talk) 01:48, 18 July 2025 (UTC)

@Johnjbarton: Ever since WP:SUL went live way back in May 2008, your account has been automatically created on WMF wikis, often when visiting for the first time when logged in; but sometimes it may occur without a visit. I occasionally receive a notification about an edit to my user talk page for a wiki that I am certain that I have never visited, usually for an Asian language. --Redrose64 🌹 (talk) 08:34, 18 July 2025 (UTC)

Thanks! I think what happened here was I borrowed my Mom's iPad to look at my Watchlist but the filter setup for the iPad Wikipedia App UI is quite different from the web app. So I saw more diffs than I would usually see. I hope to switch back to my computer soon ;-) Johnjbarton (talk) 16:14, 18 July 2025 (UTC)

I just happen to have my mum's iPad (Air 2, if you're interested) right here. Ihe interface is so very different from Windows, I've really only learned how to launch an app... I don't know how to close one, there's no handy "X" icon top right. My nephew says it probably means that I have a whole bunch of apps running silently in the background, soaking up memory, bandwidth and battery. So it may take some days to test your assertion. --Redrose64 🌹 (talk) 20:46, 18 July 2025 (UTC)

@Johnjbarton: I don't know which edits and diff you are referring to. Everybody can make an account and Khlee560 is one of millions with no edits here. Maybe "Show Wikidata edits by default in recent changes" is enabled at Special:Preferences#mw-prefsection-rc, or you enabled Wikidata edits on the Watchlist itself, and you saw something at wikidata:Special:Contributions/Khlee560. @Redrose64: A local account can be created without a visit if a wiki imports the page history of a page you have edited. See meta:Requests for comment/Welcoming policy. Other wikis often import our templates and you have edited many of them. PrimeHunter (talk) 10:04, 19 July 2025 (UTC)

Bot job hanging with no errors on toolforge

Christiebot (GAN maintenance) runs every twenty minutes on toolforge. Over the last three weeks or so it has hung several times; this has never happened before. There are no errors in the error log and the audit trail I keep shows nothing unusual. Running toolforge jobs list shows "Running for 14h15m18s" (for example), and the job will do nothing till it's killed. The fix is to delete the job and reschedule it, but of course that means a delay till someone tells me the bot is not running, and until I'm near a computer. Is there any way to automatically kill a job if it's been running for more than, say, thirty minutes? And is there any way to see what state the job is in so I can tell what's going wrong? I can activate more of the audit code in the bot to try to trace where it is hanging, but that'll be slow and probably time consuming; if there's any way to shortcut that process I'd be glad to know about it. Mike Christie (talk - contribs - library) 14:37, 18 July 2025 (UTC)

Looks like wikitech:Help:Toolforge/Troubleshooting is a good place to start, and it has information on how to follow up with help on that system. — xaosflux ^Talk 14:52, 18 July 2025 (UTC)

I know the other day they had some network filesystem issues, which could make process hang trying to access a file. Anomie⚔ 02:23, 19 July 2025 (UTC)

Thanks, both. I hope it's the network issue, as that would be unlikely to recur. Mike Christie (talk - contribs - library) 11:51, 19 July 2025 (UTC)

Unable to add shape for delhi

Hey, I am trying to add the boundary shape of Delhi in the infobox, but so far I only see the point. I am unable to understand the problem.

I am using Firefox Nightly (142.0a1) on Android 13. I am using mobile website.

Screenshot: https://files.sahil.rocks/htxke6f4.jpg KhubsuratInsaan (talk) 03:34, 19 July 2025 (UTC)

@KhubsuratInsaan: {{maplink|frame=yes|plain=yes|frame-width=300|frame-height=170|frame-align=center|zoom=4|type=shape|title=Delhi|marker=city|stroke-width2=2|stroke-color2=#808080|id=Q9357528}} uses National Capital Territory of Delhi (Q9357528) and produces this from data in https://www.openstreetmap.org/relation/1942586:

Is that what you wan? PrimeHunter (talk) 09:35, 19 July 2025 (UTC)

Oh yes, That is what I wanted. I tried reproducing the map after updating that osm relation to the delhi wikidata, but I am unable to do that and I get a json parsing error. The change that I tried: https://en.m.wikipedia.org/w/index.php?title=Delhi&diff=prev&oldid=1301365134 KhubsuratInsaan (talk) 12:00, 19 July 2025 (UTC)

Proposals

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

Finishing WP:LUGSTUBS2

We had consensus at WP:LUGSTUBS2 way back in March 2024 to draftify a bunch of articles, which was never implemented. Is it finally time to implement it now? * Pppery * _{it has begun...} 14:26, 24 April 2025 (UTC)

Yes! 3df (talk) 18:43, 25 April 2025 (UTC)

I concur here, this should be implemented per the community consensus. Let'srun (talk) 16:55, 26 April 2025 (UTC)

Yes, it's time to just implement it. The things people are discussing below were just suggestions by the closer, not part of the consensus; the key point is that the articles should not be left in mainspace, and even the gentle suggestion by the closer (which was in no way part of the close or consensus, and is in no way binding the way the requirement to remove them from mainspace is) has been met, since more than enough time has passed for people to review any articles that they believe were salvageable. Further steps forward can be determined after that part is implemented, but constantly re-litigating a settled RFC is inappropriate. --Aquillion (talk) 18:26, 19 May 2025 (UTC)

The closing statement by @HJ Mitchell says, in part:

"However, I would urge the proposers not to charge headlong into the draftification process without further thought. A lot of people are uncomfortable with the large number of articles—a list of 1200 people from different eras and different nations is very difficult for humans to parse and I would urge the proponents to break it down into smaller lists by nationality, era, or any other criteria requested by editors who wish to evaluate subsets of articles. I would also urge care to ensure that the only articles draftified are those which clearly meet the criteria outlined, even if that takes longer or even considerably longer—we won't fix mass editing without due care by mass editing without due care. There is merit in the idea of a templated warning being applied to the articles before draftification takes place and in a dedicated maintenance category to give interested editors a chance to review. To that I would add a suggestion to check for any articles that exist in other language versions of Wikipedia."

What's your plan for breaking down the lists, avoiding more "mass editing [including draftifying] without due care", and adding warning templates in advance? WhatamIdoing (talk) 21:33, 26 April 2025 (UTC)

We've left them for a year. If people want to correct the drafts before they're deleted, they are free to. JayCubby 21:44, 10 May 2025 (UTC)

Did you break it down into smaller lists by nationality, era, or any other criteria requested by editors who wish to evaluate subsets of articles? Or is it your idea that this part of the closing summary has magically expired because it wasn't done by your WP:DEADLINE? WhatamIdoing (talk) 22:34, 10 May 2025 (UTC)

Have any editors requested to evaluate subsets? How have they progressed or not? CMD (talk) 14:43, 11 May 2025 (UTC)

@CMD WAID at least has requested that multiple times. The closing summary implicitly rejected it. Thryduulf (talk) 16:31, 11 May 2025 (UTC)

I'm not sure what you mean, I ask as the quote WAID posted explicitly states it. Could you link to which criteria were requested? CMD (talk) 16:47, 11 May 2025 (UTC)

Nationality and era at least, per the closing summary. Thryduulf (talk) 16:48, 11 May 2025 (UTC)

That group is all cricket stubs, so I think that nationality (and therefore language) is going to be the key division. WhatamIdoing (talk) 16:50, 11 May 2025 (UTC)

The closing summary gives them as examples to be requested by editors who wish to evaluate subsets. Are there editors who wish to evaluate subsets, and have they requested these? CMD (talk) 16:59, 11 May 2025 (UTC)

Yes. Thryduulf (talk) 17:06, 11 May 2025 (UTC)

Well that's good news. Could you as I asked earlier link to the requests? CMD (talk) 17:11, 11 May 2025 (UTC)

Firstly, why? Secondly, the discussion that was closed with the summary quoted above, this discussion, and probably other discussions in between the two.

If that is not enough for you, please take this as formal request to break down the list into smaller lists by era and nationality. Thryduulf (talk) 17:16, 11 May 2025 (UTC)

Because that's what the close is looking for in quite plain language? It's a quite late request, but if you genuinely want to look through them I'll give you a couple. CMD (talk) 17:19, 11 May 2025 (UTC)

I really don't understand why this is like pulling teeth? Yes, this is a genuine request to do what has been requested multiple times by multiple people in multiple discussions. Thryduulf (talk) 01:42, 12 May 2025 (UTC)

It is very hard to take that last claim seriously as you refuse to provide any links. Anyway, here are some to start you off. CMD (talk) 02:12, 12 May 2025 (UTC)

Thank you, finally, for the lists but I don't understand why you need explicit links to the discussion we are currently having and a link to the original being referenced many times. The Australian list alone has 170 entries (which is still really too large for managability, hence the requests for nationality and era), so it's going to take a long while to do a Propper search on just them (and I'm just about to go to bed). Please be patient and remember that this could have started over a year ago now. Thryduulf (talk) 02:19, 12 May 2025 (UTC)

I don't need links to the current discussion or the original discussion. I was asking for links to what the close asked for, for people to request specific divisions. If they didn't happen then please stop insisting they did. If the request were not made, that has nothing to do with me. I was barely involved in the prior discussion. CMD (talk) 02:35, 12 May 2025 (UTC)

The "finally" is quite a particularly perplexing comment, these lists were produced less than a day after the first request. CMD (talk) 02:37, 12 May 2025 (UTC)

Thanks. As the Indian group is the largest, I've left a note at the Wikipedia talk:Noticeboard for India-related topics. The other lists should also be sent to other suitable groups. WhatamIdoing (talk) 02:28, 12 May 2025 (UTC)

That was explicitly framed as a suggestion by the closer, not as part of the consensus. It has no weight or force whatsoever. --Aquillion (talk) 18:27, 19 May 2025 (UTC)

I noticed this added up to 957 and there were 1,106 on the original list. The missing ones and their nationalities are below Blue Square Thing (talk) 19:45, 18 May 2025 (UTC)

Missing nationalities (probably – 161 people – some duplicates due to moves)

Abdul Naseri – Afghan Abdul Razaq (cricketer) – Afghan Abhishek Kaushik (cricketer, born 1994) – moved to draft and then deleted, which would seem irregular on all counts Aby John – Vanuatu Adjodha Persaud – Guyana Adnan Butt – Bahrain Adrian Brathwaite – Barbados Adrian Grant (cricketer) – Barbados Aftab Alam (Pakistani cricketer) – Pakistani – moved to Aftab Khan (fielding coach) were sources have been added. Remove from list Afzal Zazai – Afghan Ajmal Khan (cricketer) – Afghan Akash Vashist – India Albert Harding – Trinidad Albert Hassell (cricketer) – Barbados Alex Cooke – Jersey Alexander Clarke (cricketer) – Guyana Alexander Morgan (cricketer) – Jamaica Alfred Browne (cricketer) – Barbados Alfred Low – Jamaica Alfred Motta – Trinidad Alfred Taylor (cricketer) – Barbados Ali Ahmad (cricketer) – Afghan Ali Ahmed (cricketer) – duplicate Alistair Applethwaite – Jamaica Allan Jemmott – Barbados Allan Outridge – Guyana Allan Silvera – Jamaica Allen Kerr (cricketer) – NZ – sources have been added, remove from list Allman Agard – Trindad Altemont Wellington – Jamaica Alton Beckford – Jamaica Aman Deep – Austria Ameet Sampat – Oman Amir Zazai – Afghan Amitava Roy (cricketer) – India Amogh Sunil Desai – India Andre Dwyer – Jamaica Andrew Dewhurst – Jersey Andrew Hutchinson (cricketer) – moved to draft and then deleted, which would seem irregular on all counts Angus Learmond – Guyana Ankur Vasishta – Hong Kong Anthony Andrews (cricketer) – Jamaica Anthony Atkins – Barbados Anthony Campbell (cricketer) – Jamaica Anthony King (Barbadian cricketer) – Barbados Anthony Small (cricketer) – NZ ≠ moved to Tony Small (athlete) – sources have been added so needs to be removed from the list Antonio Whybrew – Guyana Archibald Bell (cricketer) – Guyana Arthur Bonitto – Jamaica Arthur Dare – Guyana Arthur Duff (cricketer) – Jamaica Arthur Fisher (Australian cricketer) – Australia – sources have been added so needs removing from the list Arthur Maingot – Trinidad Arthur McKenzie (cricketer) – Jamaica Arthur Tarilton – Jamaica Arthur Trestrail – Trinidad Asad Khan (cricketer) – Afghan Asadullah (Afghan cricketer) – Afghan Asadullah (Pakistani cricketer) – Pakistan Ashwani Kumar (cricketer) – India – sources have been added so needs removing from the list Aston Powe – Jamaica Attaullah (Afghan cricketer) – Afghan Austin Dummett – Guyana Avelyn Medford – Barbados Azmatullah Nazeer – Kuwait Bakhtarullah Atal – Afghan Bashir Ahmad (Afghan cricketer) – Afghan Bashir Ahmed (cricketer) – India Batin Shah – Afghan Benson Mwita – Tanzania Bernie Thomas – Guyana Bevon Brown – Jamaica Bismillah Zadran – Afghan Brent Robey – moved to draft and then deleted, which would seem irregular on all counts Brian Buchanan (cricketer) – Jamaca Brian Patoir – Guyana Broderick Warner – Trinidad Bruce Eligon – Trinidad Bruce Gordon (cricketer) – South Africa Bruce Inniss – Barbados Buxton Peters – Trinidad Byron Drury (cricketer) – Jamaica Calvin Moore – Guyana Carl André – South Africa Carl Boy – Jamaica Carl Furlonge – Trinidad Carl Gouveia – Guyana Carl Mullins – Barbados Carleton Clarke – Barbados Carlos Maynard – Barbados Carlton Gordon – Jamaica Carlton Reece – Guyana Carlyle Miller – Guyana Castell Folkes – Jamaica Cecil De Cordova – Jamaica Cecil Rogers – Barbados Cecil Shearman – South Africa Celso de Freitas – Guyana Chamara de Soysa – Sri Lanka Chamara Fernando – Sri Lanka Chamara Lasantha – Sri Lanka Chamindu Wickramasinghe – Sri Lanka – sources have been added, needs to be removed from the list. The draft note has already been removed from this article (in June 2024) Champa Sugathadasa – Sri Lanka Chandi Wickramasinghe – Sri Lanka Charles Blades – Barbados Charles Bourne (cricketer) – Barbados Charles Chandler (cricketer) – Jamaica Charles Chapman (cricketer, born 1860) – merged with Charles Chapman (rugby union) (created Nov 2024). Obviously sourced, so remove from list Charles Delbridge – South Africa Charles Delgado – Jamaica Charles Gregory (cricketer, born 1847) – Australia – moved to Charles Smith Gregory; some sourcing added so should probably be removed from the list Charles Hurditch – Jamaica Charles Packer – Barbados Charles Spooner (cricketer) – Barbados Charles Valencia – Jamaica Charles Warner (Trinidadian cricketer) – Trinidad Charles Webb (Barbadian cricketer) – Barbados Charlie Taylor (cricketer) – Barbados Chatterpaul Persaud – Guyana Chester Cumberbatch – Barbados Chetwyn Burnham – Barbados Chongtham Mehul – India Chris Humphrey (cricketer) – Barbados Christiaan Snyman – Namibia Christopher Janik – Singapore – a source added which should probably take this off the list Christopher Simpson (cricketer) – Guyana Clarence Worme – Barbados Clement Browne (cricketer) – Barbados Clement Gaskin – Guyana Cleveland Bailey – Jamaica Cleveland Davidson – Jamaica Clifton Cawley – Jamaica Clifton Folkes – Jamaica Clinton Reed – Barbados Clinton St Hill – Barbados Clive Campbell (cricketer) – Jamaica Clyde Beckles – Barbados Colin Bloomfield (cricketer) – Jamaica Colin Fletcher (cricketer) – Jamaica Colin Payne (cricketer) – Barbados Collette McGuiness – Ireland women (international) Courtenay Daley – Jamaica Courtney O'Connor – Jamaica Cyprian Bloomfield – Jamaica D'Arcy Galt – Trinidad Dale Ellcock – Barbados Dale Mason – Barbados Danniel Ruyange – Uganda Darnley Da Costa – Barbados Dastagir Khan – Afghan Dave Marshall (Barbadian cricketer) – Barbados – sources added; remove from list David Lumsden (cricketer) – South Africa David Martins – Guyana David Sultan – Trinidad Dean Morgan (cricketer) – Jamaica Delroy Morgan – Jamaica – sources added; remove from list Denis Rampersad – Trinidad Dennis Hewitt – Guyana Dennis Thorbourne – Jamaica Denville McKenzie – Jamaica Deonarine Deyal – Trinidad

@WhatamIdoing, they've had more than a year at this point. Time enough. Plus they have more than a half-decade before they are actually deleted. JayCubby 15:09, 11 May 2025 (UTC)

@JayCubby - There is WP:NORUSH KatoKungLee (talk) 18:06, 19 May 2025 (UTC)

So? It is not up to those who don't think there is a need to delete/draftify the articles en-mass to work out which ones those who do believe that is a desirable course of action are referring to, let alone without the latter group having done what was explicitly noted as a prerequisite to deletion/draftification. Thryduulf (talk) 16:33, 11 May 2025 (UTC)

Jay, I agree: You've had more than a year at this point to follow the directions in the closing summary and break it down into smaller lists by nationality, era, or any other criteria requested by editors who wish to evaluate subsets of articles. Time enough? WhatamIdoing (talk) 16:49, 11 May 2025 (UTC)

Something should be done. Mrfoogles (talk) 23:17, 3 May 2025 (UTC)

What something consistent with the close are you proposing? Thryduulf (talk) 23:30, 3 May 2025 (UTC)

Yes, I would support draftify-ing those articles sooner rather than later, especially before Wikipedia reaches the 7 million articles mark. Some1 (talk) 14:04, 11 May 2025 (UTC)

Can I point out that there's a talk page for this at Wikipedia talk:Lugstubs 2 list. I've already gone through a bunch of these articles, mainly New Zealanders, to suggest those that might be kept, those are, in my view, a merge – which retains the page history and is a valid WP:ATD – and those that might be deleted. Some have been improved. I've not gotten to all of them by any means. But that's somewhere that anyone about to make any of these a draft needs to have a look at first please. I've not done any work on these lists for a while as it's so time consuming and I'm not sure when I'll get a chance to look again, but a clear procedure for reviewing these was put in place. Ta Blue Square Thing (talk) 10:55, 12 May 2025 (UTC)

e2a: a quick look through the British and New Zealand ones suggests all are either keeps or redirects – I note a number that have had suitable sourcing added and some with suitable levels of detail, other than the ones that I'd worked through. I imagine the same is true of the Australians as well – an ATD will be available on almost every case if they haven't has sourcing added. I'm not entirely sure that the original list is really that valid from the POV of these subsets if I'm honest. It's certainly not a job that I would like to automate based on the list as it exists Blue Square Thing (talk) 11:07, 12 May 2025 (UTC)

Yes, please. The Village pump is not a good place to post these lists. Anomie⚔ 11:22, 12 May 2025 (UTC)

As an update:

• I've gone through the British list at Wikipedia talk:Lugstubs 2 list#British list and made recommendations for all of them. There are 12 or so which I think could be worked up. I've listed these at Wikipedia talk:WikiProject Cricket in case anyone has an interest
• I'm working through the New Zealanders – 70+ done. There's an interim list at User:Blue Square Thing/sandbox3#NZ. Once I'm done (a few weeks I imagine – I have 22 left) I'll push that list to the same talk page as above
• At Wikipedia talk:WikiProject Cricket The-Pope has broken down the Australian list into state teams, which is really helpful. But these will take a while to get through

Those are the three where sourcing is easiest to come across, so it's easiest to deal with those first Blue Square Thing (talk) 19:17, 13 May 2025 (UTC)

The instructions on the {{Special draft pending}} tag say that when sources have been added, the tag shouldn't be removed (why?), but instead the article should be listed at Wikipedia talk:Lugstubs 2 list for review.

However, so far, over the course of the last year, almost 200 articles have been individually reviewed and listed there (either with a recommendation to redirect or with sources), and this work has been ignored. The editor who wrote these instructions is no longer editing.

Should we:

1. Tell people to just remove the tags when they redirect or add sources? (This would require re-generating the list.)
2. Tell them to remove the tag and to remove the entry from Wikipedia:Lugstubs 2 list?
3. Find some volunteers who will actually follow up on the chosen process? (I believe the process was boldly made up by one editor; I've seen no evidence of discussion, much less consensus.)

What do you think? WhatamIdoing (talk) 16:17, 13 May 2025 (UTC)

I really don't know what is the most effective way to do this. I can see the benefit to removing them as someone works on articles, but it involves removing them from two places. There certainly seems to be evidence that articles have been worked on without notes left on the talk page, so I'm not sure it's reliable to ask people to remove from two places.

It makes sense to redirect as we go though. Ultimately this is a human task – unless there's a really clever way to do it, I don't think it can be automated due to the need to redirect a huge number of the articles – in the original discussion I estimated 75% were redirects

On that subject, there was some discussion about the best way to do the draft/redirect process. MY gut feeling is that it's redundant to send articles to draft, have someone bring the article back to mainspace, and then redirect the article – the draft isn't deleted automatically and that creates more overheads. I think. A straight redirect is better I think

But it's difficult to do this when the tags are still on the articles, I agree. I would have started to do that last March, but for the process that was put in place... It will, fwiw, take some time Blue Square Thing (talk) 19:17, 13 May 2025 (UTC)

If people pulled the template off the page when redirecting/improving, then we should be able to combine (e.g., with grep) the original list against the list of pages that transclude the template, to find which ones are still in need of work/eligible for being moved to the Draft: space. WhatamIdoing (talk) 21:25, 13 May 2025 (UTC)

If that works then it's something that sounds sensible. But we'll obviously need to get the template message changed first Blue Square Thing (talk) 07:05, 14 May 2025 (UTC)

Changing the template message just involves going to Template:Special draft pending and clicking the [Edit] button. However, I don't know how the opponents of these articles would feel about that. What if somebody adds a source and removes the tag, but they think the added source isn't good enough to justify keeping the article in the mainspace? They might prefer more bureaucracy. WhatamIdoing (talk) 18:11, 14 May 2025 (UTC)

I've now managed to work through all the British and New Zealand articles. Of the 50 British ones, seven need to be removed from the list as sources have been added, and the other 43 are probably redirects – although a number of them (at least 12) have significant possibilities (i.e. I know that if I could expend the time on them that they'd almost certainly have sources added). Of the 89 New Zealanders, one needs to be drafted, 40 have had sources added, and 48 can be redirected (with strong possibilities for 10 or so at least). The detail is at Wikipedia talk:Lugstubs 2 list. I'm about to start on the Zimbabweans.

Perhaps someone could let me know what they'd like me to do next? There's a list of 1,106. A great many of them will be redirects or drafts, but at the minute the note added to the top of each page stops me doing anything very much to those articles – one Charles Chapman (cricketer, born 1860) (British but not appearing on the British list for some reason) has been merged with Charles Chapman (rugby union) as they were the same person, but the article still appears on the original list. I have no idea what an automated attempt at this process would do to an article like that, but I can't imagine that any automated process will work, I can't remove the list, I don't think I'm allowed to redirect them, and I'm pretty certain I'm not supposed to remove them from the list.

So, what next? Other than leave it another year and talk about it then if people prefer. Blue Square Thing (talk) 17:58, 18 May 2025 (UTC)

Well, let's ping the people who wanted this work done: @Pppery, @3df, @JayCubby, @Let'srun, @Mrfoogles: You all asked above for someone else to do this work for you. It's being done. How do you want the procedural bits to be handled? If you don't care, please say so. WhatamIdoing (talk) 18:43, 18 May 2025 (UTC)

Speaking only for myself, I'm annoyed by the fact that we had a lengthy discussion that came to a consensus to do something, and then didn't do it, and that we've had articles that have been allegedly pending being moved into draft space for years. I don't care much more about the procedure than that we get out of that state. * Pppery * _{it has begun...} 18:44, 18 May 2025 (UTC)

So if BST removes the tags for the ones they think shouldn't be draftified, and pulls them off the list, then you're okay with that? WhatamIdoing (talk) 18:46, 18 May 2025 (UTC)

Yes. Which says nothing about what anyone else is okay with, of course. * Pppery * _{it has begun...} 18:50, 18 May 2025 (UTC)

Well, I tried to support it being done if someone wanted to do it. To be honest, I don't completely understand the situation, but if it helps I think the ones that @Blue Square Thing describes as probably redirects should probably be redirected? Or if the draft tags don't allow that, drafted. Enough time has gone by in my opinion if they're still unsourced -- don't know whether there was an already-fixed timeline?

If I'm understanding this correctly, I think we should just let people go through and draftify/redirect them all (except the sourced ones), removing the tags. If there are some that sources could be found for, well, new pages can always be created later with the sources. Mrfoogles (talk) 18:57, 18 May 2025 (UTC)

None of these are unsourced articles. The ones on this list were chosen because they:

1. were created by an editor who fell out of favor with the community, and
2. are sourced (only) to specific websites.

The tag was boldly created by an editor and suggests a new/unprecedented process that, e.g., claims that redirecting an article to a suitable list would still leave that redirect subject to draftification and eventual deletion. I suspect that his intention was to personally review any article that others thought was eligible to be left in the mainspace. However, he has since stopped editing, so we can't ask him how he thought this would work out in practice. WhatamIdoing (talk) 19:23, 18 May 2025 (UTC)

Part of the problem is that you have to know where to redirect them to. Which is slightly tricky. Sometimes lists don't exist, which means we draft; sometimes you need to choose a list from options, which is OK but tricky. I can start to do that, but it takes time and is slightly difficult as it tends to rely on having accessed to a paywalled source. But it needs doing – the current situation is starting to get silly and I share the exasperation of Pppery because I could already have dealt with a couple of hundred of these

At least four have already been sent to draft and then the draft deleted. I thought the process we have here guaranteed that they wouldn't be deleted from draft space for five years? (from memory) That doesn't appear to be happening – for whatever reason Blue Square Thing (talk) 19:29, 18 May 2025 (UTC)

They were probably deleted because the people who wanted to delete these didn't set up the procedures correctly. We can ask for a WP:REFUND for those four. WhatamIdoing (talk) 23:55, 18 May 2025 (UTC)

They were probably just draftified independently of the RfC without putting the tag on them.

What about just draftifying everything you (or others) haven't already redirected or otherwise exempted via introducing IRS SIGCOV, then you can get started on deciding which other pages to redirect/exempt from within draft space? JoelleJay (talk) 16:15, 19 May 2025 (UTC)

I was/am interested in working on this myself – I didn’t mean to imply with my comment that it’s somebody else’s problem. 3df (talk) 21:08, 18 May 2025 (UTC)

I concur with Pppery here. Let'srun (talk) 23:32, 19 May 2025 (UTC)

Any that have not already been individually assessed as probably meeting notability criteria (or as being redirectable) should just be draftified. The whole point of their getting privileged draftification treatment was so that interested editors had 10x time to trawl through these articles after they were removed from mainspace: I find that there is a rough consensus in favour of the proposal, and a stronger consensus that they should not be left in mainspace. They don't get to hang around indefinitely in mainspace just because the same editors who staunchly opposed the consensus neglected to show any interest in the non-mandatory close recommendation of making more discretized lists (which are supposed to make it easier for the post-draftified articles to be parsed, not as a way for one editor to adopt a set beforehand and delay its articles' draftification by claiming they "need more time" to run through them individually). We most definitely do not need a second RfC to ratify the first one, and a year is more than enough for any editors who cared to ensure draftification is only applied to eligible articles. The rate-limiting step here cannot be the inaction of the same editors opposing draftification, that would completely defeat the consensus to remove these from mainspace. JoelleJay (talk) 20:25, 18 May 2025 (UTC)

The rate-limiting step appears to be the inaction of the editors supporting draftification.

The immediate question here is, for the (small?) subset that has "already been individually assessed as probably meeting notability criteria (or as being redirectable)", how do we stop them from wrongly getting dumped in the Draft: namespace?

This would be a stupid process:

1. BilledMammal puts a page on his list of pages to dump in the Draft: namespace.
2. Alice reviews one. She decides that it does not meet the GNG and redirects it to a List of Olympic athletes from Ruritania.
3. Bob draftifies everything on the original list, including Alice's new redirect.
4. Chris un-draftifies the redirect, because it's stupid to have a redirect in the Draft: space when Alice has already determined that this athlete doesn't appear to qualify for a separate, stand-alone article and has already redirected it.

What's a non-stupid process that will actually work? WhatamIdoing (talk) 00:04, 19 May 2025 (UTC)

...What are you talking about? We remove them from the draftification list, then draftify the list. JoelleJay (talk) 16:10, 19 May 2025 (UTC)

So your suggested process is:

1. Redirect the article or add suitable sources.
2. Remove the tag that says "do not remove the tag, as this may not prevent draftification".
3. Remove the article's name from Wikipedia:Lugstubs 2 list.
4. Eventually, someone (who?) will move anything that's left on the list to the Draft: namespace.

Right? WhatamIdoing (talk) 19:21, 19 May 2025 (UTC)

I think we should mark all of these with Template:Old prod as well. WhatamIdoing (talk) 19:22, 19 May 2025 (UTC)

No. I am saying any that are already redirected or clearly ineligible can be removed from the list, any that are not are draftified NOW by an admin, per the consensus that these stubs should not remain in mainspace. The accidental draftification of false-positives is of minuscule concern: editors have 5 more years to go through them. JoelleJay (talk) 23:03, 19 May 2025 (UTC)

Why the rush? As @HJ Mitchell pointed out in the close, it is more important to get it right than to do it quickly. There are currently multiple people actively working out what doing it right means. Thryduulf (talk) 23:38, 19 May 2025 (UTC)

I wonder whether the auto-deletion process in the Draft: space has been modified to accommodate this five-year timespan. I suspect that the answer is "no". WhatamIdoing (talk) 00:59, 20 May 2025 (UTC)

One year is not "doing it quickly". If the editors who believed certain articles ought to be exempted just never bothered to address those articles, then that's too bad for them: there was a consensus to remove the articles from mainspace and into a protected draftspace where they could be worked on, and a stronger consensus not to leave them around in mainspace for some indefinite length of time while some editors maybe work on some selection of them. You and WAID contributed like 50 comments in the RfC unsuccessfully trying to kill the proposal, now you're trying to do the same thing to its implementation. At some point this just becomes disruptive. JoelleJay (talk) 03:29, 20 May 2025 (UTC)

Please read this entire discussion where all your complaints have been fully addressed and/or rebutted multiple times. I'm not trying to kill it's implementation, I'm trying to ensure that the damage to the project is minimised by ensuring that the due care the closer found consensus for is actually applied. If that takes longer than you want, then I'm sorry but the community wanted due care rather than haste. Thryduulf (talk) 03:41, 20 May 2025 (UTC)

Yet the consensus was that it is more damaging to the project that these articles remain in mainspace, and it certainly did not include your definition of "due care". JoelleJay (talk) 03:53, 20 May 2025 (UTC)

Instead of talking about hypothetical "editors who believed certain articles ought to be exempted just never bothered to address those articles, then that's too bad for them", how about we talk about "the editors who did address those articles, and who are addressing those articles, and who have been addressing those articles for over a year now, but who have been told that they're not allowed to take the tag off or remove the articles from the list"?

This process has been badly designed, with incomplete documentation, instructions that contradict normal practices, no tools to separate these drafts with their RFC-mandated five-year time period in the Draft: space from the ordinary six-month G13 process, and an implicit dependence on an editor who is not editing any longer. One goal (i.e., boldly redirect articles that editors believe won't qualify) is simple and straightforward under normal circumstances, but it's being stymied by editors who are trying to follow the directions they've been handed, because the tag says nobody's allowed to remove it.

If we want to move forward on this, then we need to figure out things like how (e.g.,) Liz and Explicit identify Draft: pages that are eligible for G13 deletion, and how they could not have their systems screwed up by these pages, which aren't eligible for five years.

We need to get this right. I've no sympathy for people who ignored this for the last year and a half, but now that we've been reminded about it, they think it's an emergency. People have been posting on the designated talk page for well over a year, and their questions and comments have been ignored by you and everyone else who just wants these pages gone. If you don't choose to help, then that's fine, but the result is that sorting out this process is going to take longer. WhatamIdoing (talk) 05:04, 20 May 2025 (UTC)

@WhatamIdoing: The bot SDZeroBot lists pending draft deletions on its subpages User:SDZeroBot/G13 soon and User:SDZeroBot/G13 soon sorting. It ignores all drafts tagged with {{Special draft}} for five years. ✗plicit 05:27, 20 May 2025 (UTC)

How does it determine the date for tagged pages? WhatamIdoing (talk) 06:16, 20 May 2025 (UTC)

The other way in which G13s are found is via User:DreamRimmer bot II. * Pppery * _{it has begun...} 05:31, 20 May 2025 (UTC)

Thanks. @DreamRimmer, is your bot already set up to handle this? WhatamIdoing (talk) 16:33, 20 May 2025 (UTC)

@WhatamIdoing: My bot already ignores all drafts in the Category:All drafts subject to special procedures. – DreamRimmer ■ 17:00, 20 May 2025 (UTC)

Hang on, we were explicitly told not to remove the hatnote and not to redirect. That was supposed to be handled sensibly – multiple reassurances were given at the original RfC and since. If someone were to draft all those with the hatnote remaining, you'd send articles which obviously meet the GNG to draft – there are hundreds that either were in the original process or that need to removed from the list – almost 50% of the New Zealanders for example. That would, in my view, be likely to be used as an argument against any future mass-draftification of articles. Any support that I was able to give to the original RfC was based entirely on the assurances received that redirects would be handled sensibly. I imagine I would feel I had been lied to if they were simply all drafted without any consideration for the process that I've been working my arse off on for periods of the last year Blue Square Thing (talk) 08:48, 20 May 2025 (UTC)

The proposal says

If this proposal is successful: All articles on the list will be draftified, subject to the provisions below: [...]

• Any draft (whether in draftspace, userspace, or WikiProject space) can be returned to mainspace when it contains sources that plausibly meet WP:GNG[d]
• Editors may return drafts to mainspace for the sole purpose of redirecting/merging them to an appropriate article, if they believe that doing so is in the best interest of the encyclopedia[e]

I imagine any resistance to removing hatnotes or redirecting would be due to concerns the article would just be recreated from the redirect without undergoing scrutiny for GNG and without having the hatnote returned. Maybe it would be helpful to have a hidden category for redirects from this list and/or a talkpage banner noting they were originally part of LUGSTUBS2 on them as well as on any pages that are returned to mainspace as GNG-compliant. Anyway, I don't see why we can't just draftify the pages that haven't been worked on by you guys (or that you have found non-notable), while separately addressing redirection/removing hatnotes for those that remain. JoelleJay (talk) 17:45, 20 May 2025 (UTC)

A talk page banner might be more helpful – cats can get deleted easily.

In terms of what to draft and when, it would be more efficient to redirect first where a redirection is possible. In some subsets, this is nearly all articles; in other subsets it will be fewer. It would be possible to work fairly quickly through those I think – over the last day or so I've reviewed all 170 articles on the Australian list. 147 of those can be redirected in the first instance (a number having strong possibilities); 23 need to be kept. None need to be drafted. Of the 89 New Zealanders, one needs to go to draft. The others are all redirects or to be removed from the list and kept. The same won't be true of Pakistanis, for example, where there are a lot fewer lists for redirection.

I'm not entirely sure how it would be possible to identify those that have been worked on btw. I've come across some today which other people worked up but haven't left a note anywhere about Blue Square Thing (talk) 20:09, 20 May 2025 (UTC)

The practical reason why we can't just draftify the pages that haven't been worked on by you guys (or that you have found non-notable) is because you don't actually know which ones haven't been worked on.

I think that an Old prod tag is the best way to flag that history. Use the |nomreason= parameter to link to WP:LUGSTUBS2. WhatamIdoing (talk) 20:39, 20 May 2025 (UTC)

The ones that can be redirected can be put in a new list, removed from the original list, and a banner put on their talk pages. The ones that BST et al have determined should be kept can likewise be put in another list and a banner put on their talk pages. The ones that others have since worked on but which have not been actively endorsed as demonstrably meeting SPORTCRIT can be moved to draft alongside all the other eligible pages for the individualized attention that the community decided should take place in draftspace. JoelleJay (talk) 20:50, 20 May 2025 (UTC)

That makes sense. The banners are a good idea – who will create them? Can I check:

a) that we're talking about dealing with the list at WP:Lugstubs 2 list (1,106) – these are the ones that were tagged with the hatnote? This is not the same list as the one at WP:LUGSTUBS2] (1,182). I can't remember why they're different – I think everyone on the first list is on the second one. From memory I think the query was re-run and some came off it. They had probably been improved to the extent that they dropped off the list

b) where would you like me to create the lists? Wikipedia talk:Lugstubs 2 list is a bit of a mess because I've stuck so much stuff on there and the lists that are on there are messy as well

c) I think the original idea was to re-run the query again first to remove the ones that would have fallen off the list. I wouldn't have a clue how to do that. Is that something someone could do? It might save a bit of time and effort

Once we have the banners made and an idea about where to create the lists, we're good to start moving on this I think. Is it worth discussing a formal timeframe? Blue Square Thing (talk) 07:55, 21 May 2025 (UTC)

Whichever is the most recent agreed-upon list should be used. We can run a new query on it, then look over any pages that no longer qualify through the query to make sure their disqualification is legitimate. I think the three new lists (redirectable, likely notable, all remaining eligible stubs) can just be put in a new talk page section. I don't know anything about making banners or running quarry queries; perhaps @Pppery has background or knows editors who do? JoelleJay (talk) 16:33, 21 May 2025 (UTC)

I have some familiarity with Quarry queries, but it's not clear to me what is being asked for right now. Or, one you have a clear request, you can ask at WP:RAQ (although that's largely a single-person operation too). * Pppery * _{it has begun...} 16:46, 21 May 2025 (UTC)

I think the intent is to just run the same query as before on the current list to see if any other names now need to be removed? JoelleJay (talk) 17:07, 21 May 2025 (UTC)

I think that would be best. It would also be best to actually deal with the ones that have been sorted out before re-running the list. Do you have a link to the query?

I'm going to go edit Template:Special draft pending, and I'll add some instructions to the top of Wikipedia talk:Lugstubs 2 list. Please check those (i.e., in half an hour) and see if that reflects what we have been talking about. WhatamIdoing (talk) 17:16, 21 May 2025 (UTC)

Alternatively, we could use Special:WhatLinksHere on the template. WhatamIdoing (talk) 17:28, 21 May 2025 (UTC)

I looked pretty hard and could not find the exact query BilledMammal used to generate the list at WP:LUGSTUBS2, but it seems to be a close variation on https://quarry.wmcloud.org/query/73984 (the pre-saved results almost but don't quite match the list there). It's probably better to rely on the list as saved rather than trying to reverse-engineer it. * Pppery * _{it has begun...} 17:32, 21 May 2025 (UTC)

I'm 99% certain that the list at WP:Lugstubs 2 list is the list that had the template added to it. I know of at least two articles where editors have removed the template, but that list hasn't been edited since BilledMammal put it there, so it should be reliable Blue Square Thing (talk) 17:49, 21 May 2025 (UTC)

One of the inefficiencies in Wikipedia talk:Lugstubs 2 list#2025 procedure is that, for redirecting non-notable subjects, I think we need to remove the template from the page and the name from the list. But if we are reasonably certain that everything on the list got tagged with the template, I'd love to simplify this to "anything still transcluding the template is getting moved" (after a reasonable but short pause to get those known-non-notable subjects redirected). WhatamIdoing (talk) 17:58, 21 May 2025 (UTC)

I've only found two without the template, and I've looked at getting on to 750 of the articles over the last week. If at all possible it would be better to use those using the template (the other two have easily good enough sourcing I think – Alexander Cracroft Wilson and Chamindu Wickramasinghe) and then conduct a check with the quarry query afterwards or run through and check them some other way. There doesn't seem to have been any mucking around with the list other than the three (not four) which were drafted early and have since been moved back to mainspace e2a: a look at the number of articles with the template, shows that there are six more somewhere where it's been removed. I'll sort out which at some point by comparing the lists Blue Square Thing (talk) 18:07, 21 May 2025 (UTC)

Please see Wikipedia talk:Lugstubs 2 list#2025 procedure. Note that it's instructions, not a signed comment, so you're free to update it. WhatamIdoing (talk) 17:55, 21 May 2025 (UTC)

Can we specify mid (or late) June – my life is complex over the next fortnight :-) I won't do anything until this is generally agreed on btw Blue Square Thing (talk) 18:01, 21 May 2025 (UTC)

Could be July, if you'd like. I picked next month because it'd be nice to have this resolved already, but Wikipedia:There is no deadline – just a target. WhatamIdoing (talk) 18:21, 21 May 2025 (UTC)

23 June. That goes everyone a month. If it goes a bit further than that then fine, but a deadline in this case is probabyla good diea to stop me from prevaricating Blue Square Thing (talk) 19:02, 21 May 2025 (UTC)

That sounds good to me. I've updated the directions to state that date. I've also removed instructions to edit the list itself. We can use the templates themselves to track it. (I assume nobody's spammed the template into other articles; if my assumption is invalid, then we'll have to check the list.) WhatamIdoing (talk) 21:00, 22 May 2025 (UTC)

I've done "a test edit" for one of the names you mentioned at the talk page. Please check this edit and let me know if that looks right to you. In particular, I've left the categories in place and added a {{R to list entry}} tag. WhatamIdoing (talk) 21:07, 22 May 2025 (UTC)

I actually managed to do some myself yesterday morning (the Auckland redirects), but had a ridiculous day at work so wasn't able to leave a note here. It sees to work, although it's slightly trickier that I thought – need to remove the class rating from the talk page and the circular redirect from the list as well. I also added R with possibilities to the ones I did as they're ones that I think have that. Oh, and in some cases we can redirect to a section...

It would be better if we could re-run the querry that BilledMammal used in the fist instance as there are 400+ articles I've not managed to check – the Sri Lankans and Indians. But if we can't do that, I think this is the best option Blue Square Thing (talk) 04:26, 23 May 2025 (UTC)

AIUI the WikiProject banner figures out redirects automatically, so you can ignore those. We should be able to get a bot or an AWB run to handle the circular redirects. (Surely we have a bot that can do this?) WhatamIdoing (talk) 05:06, 23 May 2025 (UTC)

I've started more work on these – it's just the class on the redirect talk page that I'm slightly worried about.

The special draft pending template still says to remove people from the list. Do we actually want to do that or does the template need changing to remove that? Blue Square Thing (talk) 17:04, 24 May 2025 (UTC)

@Blue Square Thing, ignore the class on the redirect's talk page. A while ago, we updated Module:WikiProject banner to auto-detect redirects and ignore whatever the banner incorrectly claims the class is. Eventually, a bot will remove it (but it's basically a WP:COSMETICBOT edit, so it won't happen quickly).

Don't bother removing people from the list. I'll update the template to say that. WhatamIdoing (talk) 17:56, 3 June 2025 (UTC)

Here's a potentially useful option. Many of these articles have a see also section with a link to a list. One potential solution is that if the article still meets the criteria (which will need to rechecked obvs) and if it contains such a link, it gets redirected to the list that's linked; if multiple lists are linked someone tells me and I sort it out (this is rare fwiw)

Fwiw I rather think this has been a lot more complex than everyone expected it would be. I did start working on this in March 2024, after the list was finalised. The original rfc included multiple assurances that redirects would be dealt with sensibly. I think we can do that, but I'm waiting to be told how to do it Blue Square Thing (talk) 04:21, 19 May 2025 (UTC)

Agree that if there is a clear and obvious redirect target then redirecting there is far more appropriate than draftspace for the article, as per WP:ATD. Joseph2302 (talk) 19:12, 19 May 2025 (UTC)

This can be done just as easily after the articles are draftified. JoelleJay (talk) 03:30, 20 May 2025 (UTC)

Yes, it could be. It would mean that the draft article would stay as well however, which is inefficient from a storage post of view. It would involve double the work involved, as rather than simply redirecting the articles I'd have to move them back and then redirect them. Blue Square Thing (talk) 08:33, 20 May 2025 (UTC)

But wouldn't you have to do such move for any articles you end up working on in draftspace anyway? Moving to mainspace and then redirecting is just one more trivial step than what was already expected to happen if this RfC got implemented. JoelleJay (talk) 17:51, 20 May 2025 (UTC)

Given the numbers of articles that will end up as redirects – as above, of the 170 Australians, 23 are keepers right now and the other 147 are all redirects; not a single draft – it would be a lot more efficient for me to just have to do the redirects. I have them sorted in teams anyway, so the redirection notice will essentially be the same. Given that I've ploughed through all of those over the last 28 hours, I don't see why I couldn't manage the redirection process over a similar sort of timeframe for those 170. Having to bring back from draft first, more than doubles the time it would take – I'd have to do all the drafts first to keep the note I'd need to place in the reason box and then go through and do all the redirects by team afterwards. That's really adding to the work – all of it by hand. From a technical efficiency perspective, it must also be better to not have absolutely unnecessary drafts kicking around for five years either. All I need is for someone to work out exactly what process to go through and to have a bunch of people agree it. I'm not sure how long it would take to do work through the full 1,100 and come up with a list to draft, but it wouldn't be that long so long as I'm in the country and able to work at it Blue Square Thing (talk) 20:15, 20 May 2025 (UTC)

I don't see any reason not to redirect most of, if not all of the remaining articles as well, unless I am missing something here? Let'srun (talk) 23:54, 24 May 2025 (UTC)

We don't always have lists to redirect to – so, for Afghan cricketers, for example, I don't believe there's a suitable list. I've managed to redirect the New Zealanders who need redirecting and have started to remove tags from those I think we should keep, but it's a slightly complex process to do by hand. It will take a little time to get it done right Blue Square Thing (talk) 14:04, 25 May 2025 (UTC)

This process is now under way. I'm focussing on removing tags and redirecting. It takes a long time and all has to be done by hand. If anyone can figure out a way to automate any or all of the process it would really help. In particular, I've stopped doing anything to the talk pages – it's just taking so long. Thanks to all the people who have been cleaning them up, but if there were an automated way to do this it would really, really help matters. I'm aware that I'm leaving work for other people to do in the short term. I will try and return to the talk pages if I can do, but sorting out the articles seems like a sensible priority in the relatively little time I'll have to do this

I've not had time to even look at the Indian or Sri Lankan list if anyone wants to help out Blue Square Thing (talk) 09:09, 2 June 2025 (UTC)

I think the fact that redirecting was not actually easy was the entire reason why draftification was chosen in the first place. Frankly, I favoured just straight deleting them and if there's a WP:LUGSTUBS3 that will get my !vote. FOARP (talk) 11:01, 2 June 2025 (UTC)

The assurance that redirection would be handled automatically was the only reason I was able to give any support to the original proposal. Unfortunately BilledMammal is away for at least most of the rest of this year otherwise that might have happened. I appreciate that people wanted to punish Lugnuts by removed their articles entirely, but there are clear ATDs in many cases and redirection would have almost certainly been the result of AfD discussions in the cases where there are realistic ATDs. So I'll keep going. If you could look through the 200+ Indian articles and see if any have had loads of sources added it'd help massively. Thanks Blue Square Thing (talk) 11:32, 2 June 2025 (UTC)

The reason why I prefer straight deleting is because recreation of the content worth keeping (which is minimal) is way easier and cleaner. Redirects are cheap... to create... FOARP (talk) 14:18, 2 June 2025 (UTC)

To be clear, are we redirecting the ones with no substantial edits, or draftifying them? Taking the first on the Indian list, C. R. Mohite, since they were an Umpire what is the redirect target supposed to be? List of Baroda cricketers? But then is it even verified that he played for Baroda rather than just coming from there? Draftify looks like a way easier option.

BTW to me this was never about "punishing" Lugnuts. This was about saving editor time vs a massive time sink with minimal value-creation that was negligently dumped on us. FOARP (talk) 14:28, 2 June 2025 (UTC)

I've redirect the first ten in the list, none of which had any source but ESPNCricinfo and so were straight-forward NSPORTS fails. FOARP (talk) 14:49, 2 June 2025 (UTC)

Thanks for doing what you're doing there. I really appreciate anything that anyone else does to help this process. The key is to find the small number of articles where sources have already been added and that need to be removed. Then redirecting.

Yes, redirect to wherever is most obvious – any that cause significant problems shout and I can check on CricketArchive, which is paywalled unless you know the way around it – so Mohite played 25 matches for Baroda, but the redirect you have is just as good.

Redirects, for me, have other advantages. They make re-creation of the article as a duplicate more difficult and retain cross-wiki links (Mohite is linked from multiple pages, for example). Drafting removes those. Eventually we might get notes added to articles – like on List of Otago representative cricketers for example – which summarise careers and so on. The problem, of course, is that that takes time. More clarity over the process from the get go and a set of lists organised in some way are all things that would make that easier if we do this again. Blue Square Thing (talk) 14:55, 2 June 2025 (UTC)

Honestly, we should just delete these articles and save ourselves the time, and then use the time save to create real articles. But if redirecting is how we're resolving the issue right in front of us today then that's how we're resolving it. I'll do the others in the India list after work. FOARP (talk) 15:21, 2 June 2025 (UTC)

I appreciate anything that you can do with these. I'd be interested in knowing if any had been worked up by someone or the tags removed Blue Square Thing (talk) 07:14, 3 June 2025 (UTC)

None of the first ten anyway. For all the protestations that time was needed, in reality no-one was doing anything nor was there any obvious signs of the intent to do anything. Even if it wasn't intended, the effect of this was simply to suspend the decision for a year with no obvious improvement. FOARP (talk) 08:52, 3 June 2025 (UTC)

I think having them sorted into lists of countries **really** helps. Knowing what sort of sources are available for each country does as well. It would be better to present future lists by country (preferably by team); I think it's much more likely that the process gets done better and quicker if we can do that. Shorter lists will help as well – give me 50 New Zealanders and I can tell you what needs to happen to them within a few weeks. BilledMammal largely not being here to shepherd the process obviously hasn't helped fwiw Blue Square Thing (talk) 10:59, 3 June 2025 (UTC)

CricketArchive, which is paywalled unless you know the way around it

Is there an easier way than inspect>sources>refresh>pause load? That's how I've been doing it the last few years. JoelleJay (talk) 23:06, 2 June 2025 (UTC)

Hitting Esc quick enough also works I believe. Or if you can still find it, I have Opera 12 installed - the last update before they moved the browser to Chromium I think. For some reason it ignores the redirects to the paywall. Obviously it's years out of date now, but it's the only thing I use it for and it seems to work Blue Square Thing (talk) 07:14, 3 June 2025 (UTC)

• Glad to see we're moving on with this. We should add a note at WP:LUGSTUBS2 linking to this discussion. FOARP (talk) 10:45, 2 June 2025 (UTC)
• Picking a random name Arnell Horton (Arnell Stanley Horton), there is more information available about him, but even what was in the stub has not been copied to the notes field on the redirect target. Better to do this slower without losing the information. All the best: Rich Farmbrough 20:18, 2 June 2025 (UTC).
  

  That can also be done after the redirection... JoelleJay (talk) 23:07, 2 June 2025 (UTC)

  I appreciate that we're, at least temporarily, losing information, but there's just so much to do. I'm going to copy the lists of names on to the talk pages of the teams the redirects have been done to so that we know which ones need to be gone back to. I have no idea how long it would take to copy across as we worked through, but I might have two or three half-days available until the deadline and that'll be about it Blue Square Thing (talk) 07:14, 3 June 2025 (UTC)

  I took a look at the Zimbabwe list. Dobbo Townshend is clearly notable. I've redirected a couple more. But most of the other ones don't have clear redirect targets and should probably be PRODded. SportingFlyer T·C 00:07, 4 June 2025 (UTC)

  Thanks. Draft though, surely? It's possible someone might create lists or even find sources? Blue Square Thing (talk) 08:41, 4 June 2025 (UTC)

  The whole point of LUGSTUBS was to draftify these articles in a protected draftspace rather than going through the PROD/AfD process for each individually. JoelleJay (talk) 16:05, 4 June 2025 (UTC)

• Update: All but the British, Indians, and Sri Lankans are just about done. I know what's probably happening to the British articles, so my calculation is that of the 805 articles that have been dealt with (excluding Indians and Sri Lankans), 695 have been redirected to a list of some kind or developed and removed from the list, I've PRODed 7, which leaves 104 to send to draft. It's about 13.7% being drafted or PRODed. I've not calculated how many have been removed from the list after having been improved or as false positives (a handful) – gut feeling says around 75–100, maybe a little less. Sri Lankan lists are scarce, so that will probably increase the percentage of drafts. I'm not sure about the Indian lists Blue Square Thing (talk) 08:41, 4 June 2025 (UTC)

  Indians are all done 65%ish redirect or keep the article fwiw, but I didn't look too hard for places to redirect to. Just the British and Sri Lankans to do now Blue Square Thing (talk) 20:46, 6 June 2025 (UTC)

  Sri Lankans all done – just a 22% redirect rate. I think we now know how to deal with these sorts of articles more effectively if we wanted to do this again Blue Square Thing (talk) 07:55, 7 June 2025 (UTC)

• Update: I have five more articles to work through of British cricketers. All five will either be redirects or ones that can be improved – I'm vaguely hoping one might make DYK actually... I should be done with these by the middle of next week. That should leave around 287 to send to draft Blue Square Thing (talk) 11:47, 11 June 2025 (UTC)
• Final update: I'm done working through the lists. Of the 1,211 which were originally suggested for tagging, either at WP:LUGSTUBS or in the initial identification process, 8 have been PRODed and deleted and 287 remain on the list of articles with tags. That's about 25%. Oddly it's almost exactly what I predicated during LUGSTUBS, but that's more by luck than anything.

The majority of the articles which remain tagged are south Asians, with a few South Africans and the odd other article. That's essentially because we have fewer lists to redirect to. I guess someone should double check them all before sending them to draft – I presume there will be an automated process for it.

If we do this again can I suggest:

• smaller, more targeted lists. It's much easier to do this when you're looking at 50 New Zealanders or 100 Australians. 200 Indians is just about manageable, because so many will be redirects. It will make the process so much easier if they're broken down by country at least. By team is even better. Sorting by surname, where possible, is also so much easier;
• a recognition that some sets of articles will take longer to process because there is more of a chance of sources existing. New Zealanders, Britons, and Australians in particular. These, particularly the first two, are where most of the articles that have been developed are from;
• the ability to redirect and remove tags as we go – this has been the only thing that has made this process workable and was decided upon in May 2025. We could have moved things so much quicker;
• ideally the process could be made more efficient. Do articles that are going to be redirected need to be considered for draft? Yes, they need to be checked and any which are obvious keeps weeded out, but when redirects exist we should probably do that up front. A two stage process where a list is produced, checked and obvious redirects and keeps noted, and the others tagged for draft, perhaps, to allow double checking etc... would be quicker I think – for example, as IP editor dropped a set of 36 names on my talk page last week, all British. I've already identified that 15 or so are obvious keeps with easy sources to add, 7 or 8 need more investigation, and the others could probably be redirected straight away. That's much more effective;
• gut feeling says at least a three month time frame for each set that need to be considered for draft;
• a short pause between sets – I need a fortnight break from this and there will times of the year when people are busier or not around.

So, I assume someone will be along with some kind of automated process to clear up the 287 which remain. There's no way I can do that I'm afraid Blue Square Thing (talk) 11:07, 18 June 2025 (UTC)

I think you've done great work. But I think this would have been a lot less time-crunchy for you if your assessments had taken place while these pages were already in the special draftspace and we had some automated way for mass-moving (and talk page-tagging) those you identified as redirectable. The point of LUGSTUBS was to give editors the chance to evaluate and improve these articles outside of mainspace, over an extended draft-life. So in the future I think it would be beneficial for us to talk to the bot people to see if there are better options than someone manually undraftifying and then tagging and redirecting each eligible page. JoelleJay (talk) 16:59, 18 June 2025 (UTC)

Implement. About darn time. InvadingInvader (userpage, talk) 15:23, 18 June 2025 (UTC)

InvadingInvader have you actually read the whole discussion, or is this a drive-by comment? Blue Square Thing has made an effort to check notability of most of these articles and supplied a sensible list of recommendations for them- so blindly saying "draft them all" seems like a drive-by comment to me, as you haven't provided justification that most/all would benefit from this process. Joseph2302 (talk) 15:38, 18 June 2025 (UTC)

I have PRODded more than a few Lugstubs in the past (admittedly not recently), but I think that a draftification gives a chance and an incentive to actually improve them. Six months should be more than enough time. InvadingInvader (userpage, talk) 16:06, 18 June 2025 (UTC)

The time limit rather depends on the number of articles suggested. It takes a while to work through. And a stubborness to try to get things done in a way that's moderately "right" (spoiler: it's not; I've almost certainly redirected articles that should have been kept because I didn't have time to check Wisden obituaries, for example). It might be different for other sports. A two-part process where articles are selected and then reviewed before tagging for draft would probably be more effective. The same would apply to PRODs and AfD noms fwiw – if I de-PROD I'll often boldly redirect immediately afterwards if I can't see anything quickly that makes me think the article would survive an AfD without the outcome being to redirect Blue Square Thing (talk) 16:14, 18 June 2025 (UTC)

draftification gives a chance and an incentive to actually improve them. Six months should be more than enough time. – I can say as one of the users most active in trying to save notable "Lugstubs", draftification does not give any incentive, nor is six months sufficient time to research hundreds or thousands of foreign, pre-internet subjects. Of the 1,000 draftified in Lugstubs1, less than 2% have been restored in two years. At minimum, over a third of those would turn out notable if someone looked for coverage. But thanks to draftification, we don't have anyone doing that. BeanieFan11 (talk) 16:25, 18 June 2025 (UTC)

No one would be doing that if they were in mainspace, either... JoelleJay (talk) 16:44, 18 June 2025 (UTC)

They get occasionally improved in mainspace. At least in mainspace editors can see them. In draftspace, the only editors aware are the ones who participated at the LUGSTUBS discussion, almost none of whom seem to have much interest in improving them (going off of only a tiny tiny handful having been improved in draftspace in two years). BeanieFan11 (talk) 16:52, 18 June 2025 (UTC)

The drafts are supposed to be put in a special 5-year draftspace. JoelleJay (talk) 16:46, 18 June 2025 (UTC)

Thanks for the list of recommendations. I agree that the original process was broken, and I'm glad that we got that fixed.

One of the things that has struck me is how many editors have been pushing to hide these m:where articles go to die and demanding that other editors deal with everything right now, but who have not done any of the work themselves. It has not felt (to me) like we're all in this together. It has felt like some editors have set themselves up as wiki-rulers and assigned themselves the job of ordering other people to do things they aren't willing to do themselves.

If I could change one thing in any future versions, it would be that people need to help with the work, at least in some small way, and not just issue demands that somebody else do all the work. Wikipedia is a collaborative project. This has felt more adversarial – like dealing with an unreasonable client, rather than working together. Let's do better next time. WhatamIdoing (talk) 17:17, 18 June 2025 (UTC)

Chipmunkdavis broke the lists down into nationalities. That was crucial. Without that there's no way I'd have been able to get even close to the stuff I've done. The-Pope broke the Australians down. Again, that was crucial in helping to crack a large set. Those sorts of things are invaluable and it would have been so much more useful to have had this happen right at the beginning. I think BilledMammal did provide some categories, but they seemed to disappear into the ether Blue Square Thing (talk) 19:18, 18 June 2025 (UTC)

I think that getting those lists organized was one of the most important steps towards success. WhatamIdoing (talk) 19:38, 18 June 2025 (UTC)

There was strong consensus that these articles not remain in mainspace. It has been a year, the burden was on those wanting to keep them to initiate whatever process they felt necessary to reduce false positives. The "work" was always supposed to be taken on by those editors, otherwise we would not have had a consensus to skip the timesink of individual AfDs for the stubs to get draftified. Creating the special draftspace was a compromise to allow such editors to put in that work over an extended period. The only additional effort needed was rerunning the original stub eligibility script. The process would have been much smoother if, per the proposal and consensus, they had just been draftified in the first place and editors interested in demonstrating standalone worthiness had worked on categorizing and tagging for redirection from within draftspace. JoelleJay (talk) 15:12, 19 June 2025 (UTC)

I'm not sure that "strong consensus" is really a fair reading of the close. But anyway, it got done. Lets see if we can take less than 18 months next time Blue Square Thing (talk) 17:34, 19 June 2025 (UTC)

How about just going through normal processes, rather than this which guarantees the loss of many notable subjects and wastes extraordinary amounts of editor time with very little benefit? BeanieFan11 (talk) 17:36, 19 June 2025 (UTC)

AFD and PROD have practical logistics problems, which I summarize here:

• The editors who viscerally dislike the articles don't want to redirect the articles to appropriate lists themselves. (That requires effort, usually – but definitely not always! – entailing reading the first sentence, seeing that it says "for the Foo Team", and replacing the contents with #REDIRECT[[List of players on the Foo Team]], maybe with an {{R to list entry}} tag. Also, it should be somebody else's job, because I shouldn't have to lift a finger to fix a mess created by somebody else.)
• The community objected to a single mass AFD nomination, because the correct outcome depends on the individual. AFD, despite having higher median participation than in previous decades (i.e., four respondents instead of three), believes that it is chronically short of participants and therefore unable to properly address large volumes of nominations on the same subject. The community has also opined that nominating large numbers of similar articles (especially athletes who are all from the same non-English-speaking country) at the same time results in inadequate evaluation of any of them. That means you can send 25 articles a week if they're Al American, Bob British, Chris Chinese, David Danish, Eve Egyptian, Frank French, etc. but not 25 Gabonese athletes this week followed by 25 Hungarian athletes next week. This could be solved by making a list and marking your calendar to nominate four random articles from that list each day, but again: that's work for me, not work exclusively for thee. Also, quite a lot of these are going to end up with a recommendation to blank and redirect to a list, which would not be good for my success rates in the AFD stats department, and people might (legitimately) start yelling at me for using AFD on subjects that should be merged.
• PROD has the same volume restrictions and at least as much possibility of getting yelled at for abuse. Also, mass prodding tends to get mass reverted, especially if there is a significant number of false positives/pages that should be redirected instead of deleted. So the opponents of these articles believe – and I believe that they're correct – that prod is an ineffective route for removal.

The end result of this is that whingeing in the village pump about how no other WP:VOLUNTEER has already done the things that you don't choose to do yourself actually is a "rational" response to the self-imposed and community-imposed restrictions.

One thing I've been thinking about this morning is the math. 140 people commented in LUGSTUBS2. About 60% of them voted in favor of the proposal. What if we had taken the list and had a bot parcel individual articles out to everyone who helped make the decision? Imagine that 1200 articles had been divided between the 140 participants, with instructions to check this one article and either add a source or redirect it to a suitable list? There were less than 10 articles per person in the list. Even at a rate of one a month, this would have been done faster, and without the bus factor risk of having a very small number of people doing nearly all the work. WhatamIdoing (talk) 19:48, 19 June 2025 (UTC)

The point of LUGSTUBS was to get permastubs out of mainspace in bulk without needing to go through and evaluate them individually while still in mainspace. That received strong consensus. The work of determining what to do with them individually was always supposed to be the burden of those who wished to keep them in some form. All that was recommended in the close pre-draftification was reconfirming continued stub eligibility according to the original draft inclusion standards, with breaking them into smaller groups being a suggestion; that is absolutely not the same as obligating anyone to evaluate them manually pre-draftification and certainly not obligating performing editorial actions like redirection (which is usually much more involved than your bulleted example). The proposal was not for a mass AfD or mass prod so your other bullets are strawmen. JoelleJay (talk) 01:52, 20 June 2025 (UTC)

You will note that the close explicitly found consensus against "indiscriminate mass editing", shoving them all into draftspace without any evaluation at all is indiscriminate mass editing. Thryduulf (talk) 01:59, 20 June 2025 (UTC)

(edit conflict) How about, rather than mass removing through either draft or AFD or PROD or whatever process, we actually work to improve them? (And if some are truly non-notable, then take a few to AFD each day.) Crazy idea, I know. But it results in a lot more benefit to the encyclopedia than endlessly arguing then arguing even more about whether the aforementioned arguing is best addressed by this type of mass removal or that type of mass removal... BeanieFan11 (talk) 02:01, 20 June 2025 (UTC)

Because we achieved a consensus that these improvements should take place in draftspace. JoelleJay (talk) 14:04, 20 June 2025 (UTC)

There was a consensus, a very, very narrow one, in this particular discussion on a select group of them. Not for all of them. We should not have more time-wasting RFCs like this in the future – we should actually spend time improving them because it has been proven that a very sizable portion of them are indeed clearly notable. BeanieFan11 (talk) 15:49, 20 June 2025 (UTC)

Joelle, the summary for that allegedly "strong consensus" begins with these words:

"Tl;dr: the proposal passes, but by a narrow margin and with caveats."

Emphasis in the original. The proposal achieved, to again quote the closing statement, "rough consensus". I would not describe it as "strong consensus", and I doubt that most experienced editors would.

This sentence of yours: The work of determining what to do with them individually was always supposed to be the burden of those who wished to keep them in some form is a good description of what I'm identifying as a problem. Why should some editors (e.g., those who don't want to keep articles) be able to impose "the burden" of curating the mainspace on other editors? WhatamIdoing (talk) 02:13, 20 June 2025 (UTC)

Maybe this will be clearer:

• What happened: "We" over here decided that "they" over there will do this work.
• What I'd prefer: "We all" decided that "we all" will do this work.

Less "us-versus-them" attitude. More "we're in this together". WhatamIdoing (talk) 02:16, 20 June 2025 (UTC)

I find that there is a rough consensus in favour of the proposal, and a stronger consensus that they should not be left in mainspace. The burden is on editors wanting to keep content to demonstrate it is verifiably encyclopedic. Lugnuts had imposed the much more serious burden of maintaining tens of thousands of mass-created non-notable BLPs upon everyone else. There is zero presumption of notability for these stub subjects and additionally they currently violate the global consensus requiring them to cite IRS SIGCOV, so the rest of the community is compromising by creating a special draftspace lasting 10x longer than normal just so those editors who want the stubs retained have more time to improve them.

You three have just been trying to interfere with the implementation of a consensus that was against you using the same arguments that were rejected in that consensus. JoelleJay (talk) 14:03, 20 June 2025 (UTC)

• "Stronger" than weak isn't automatically "strong".
• Statements like "The burden is on editors wanting to keep content to demonstrate it is verifiably encyclopedic" are exactly the kind of us-vs-them and "I get to boss you around without lifting a finger to help" thing that I'd like to see less of in the future.
• I don't feel like I've been interfering with anything. I'm the person who figured out how to solve most of the incomplete, broken process so that hundreds of the articles could actually get moved. I believe that constitutes helping implement the LUGSTUBS2 consensus. Do you disagree? BST spent dozens of hours manually reviewing articles and getting most of them boldly redirected. I would describe that as complying with the closing statement's injunction against mass draftification "without further thought" and "without due care", and even helping us "ensure that the only articles draftified are those which clearly meet the criteria outlined, even if that takes longer or even considerably longer". CMD produced the organized lists that made BST's work feasible and which the closing statement "urge the proponents to break it down into smaller lists by nationality, era, or any other criteria requested". I wonder what you did. How did you contribute towards compliance with the RFC's closing statement? Did you do anything in the last few months that I can't see in this discussion?

WhatamIdoing (talk) 17:42, 20 June 2025 (UTC)

I find that there is a rough consensus in favour of the proposal, and a stronger consensus that they should not be left in mainspaceNowhere does this say the consensus was "weak". The only consensus mentioned as "weak" in the close is a finding for a weak consensus to apply this process to Lugstubs beyond this list.

I don't know what broken process you "solved"...?
The close said we should be careful to make sure the articles in question still fit the original eligibility criteria. That explicitly does NOT involve evaluating each article for notability or even redirectability. In fact, the consensus proposal states Editors may return drafts to mainspace for the sole purpose of redirecting/merging them to an appropriate article, if they believe that doing so is in the best interest of the encyclopedia. Articles should've been draftified before redirects were considered; the only reason this wasn't pursued right after @Pppery resurrected the topic was out of respect for the good work BST has been doing and his assurance he'd be done with his redirection effort soon.

Repeatedly muddying the process by insisting editors have to jump through hoops that never existed, or that were even rejected, is disruptive. JoelleJay (talk) 03:16, 21 June 2025 (UTC)

Nowhere does it say that the consensus is "strong". Being stronger than the rough consensus doesn't mean it is actually "a strong consensus". (Compare: a weak acid is stronger than a very weak acid, but still not actually a strong acid.)

My solution for the broken process can be seen at Wikipedia talk:Lugstubs 2 list#2025 procedure and in these changes to the template. The unfinished and abandoned process in place before then would have failed the "make sure the articles in question still fit the original eligibility criteria" requirement, because it had no provision for letting editors communicate that an article did not "still fit the original eligibility criteria", except to post a note on a talk page that was being ignored. WhatamIdoing (talk) 03:30, 21 June 2025 (UTC)

• Whoa, hang on there. At every stage of this (here, here, here, here, here, here, and here at least, probably in other places as well) I've been looking for practical solutions to make this happen. I supported the proposal, with caveats. I have a long record of disagreeing with editors at the cricket project who believed every cricketer should have an article. I'm not sure I find it fair to characterise that as some kind of interference. The inability to boldly redirect and/or remove the special draft pending tag from articles was a major element in stalling the process – and that was never mandated by the RfC either. And bear in mind that Billed Mammal's original intention was to re-run the querry once people had had a chance to churn through and check things – this was all discussed in multiple places throughout the process. We've ended up in about the right place by hook or by crook. We'd have gotten to a similar place if the articles had all been moved to draft immediately fwiw. It just took longer (bad) and half as many clicks (good). I suspect it may be best for someone to hat this now. I don't think we're getting anywhere anymore. Blue Square Thing (talk) 06:10, 21 June 2025 (UTC)

  Just in case there was confusion, by "you three" I was referring to WAID, BF, and Thryduulf. JoelleJay (talk) 18:47, 21 June 2025 (UTC)

  This allegation of interference has been made on multiple occasions, but that doesn't make it any more true now than it was on any of those other occasions. All I've been trying to do is ensure that the implementation matched the actual consensus that was found, not the outcome that some proponents would like to have been found. I would appreciate it if you could now stop making unfounded allegations of bad faith and work with other people to achieve the outcomes that consensus determines are best for the project rather than simply attacking those who don't do exactly what you want them to do at the speed you want them to do it. Thryduulf (talk) 19:13, 21 June 2025 (UTC)

Implement on the 287 subjects who remain on the list with tags, which are the non-notable cricketers who don’t have an obvious redirect target; so that the community can then move on to LUGSTUBS3, which consists of the remaining 4,000 cricketers from the original list. Luis7M (talk) 2:02, 22 June 2025 (UTC)

Immediately starting a discussion on 4000 articles is not the most helpful way to do this, and violates WP:NODEADLINE. Let editors have time to look into articles- as has been done for hundreds of articles here- rather than trying to push them all into drafts pace blindly and in violation of WP:ATD where sensible redirects exist. Joseph2302 (talk) 10:40, 23 June 2025 (UTC)

@Luis7M, we don't need a "LUGSTUBS3". If you read the comment above about what's actually needed, the answer is not a vote over whether to clean up this old mess. What's needed is things like someone to make "smaller, more targeted lists".

Naturally, things like making lists requires actual, hands-on work instead of just bossing other people around. Are you able to do any of this work? WhatamIdoing (talk) 20:44, 23 June 2025 (UTC)

@WhatamIdoing: I don’t boss anyone around. I have created over 800 non-stub sports bios in the last 18 months alone, including +300 Cs, so I consider myself capable of doing “hard-work”.

I will leave the "one by one" analyses to more experienced and driven users like @Blue Square Thing:, but I don't mind making some of those lists. I'm sure none of them can be worse than List of France international footballers (1–4 caps), which took me around 8 brute hours.

Assign me a list (anything except Asia) and consider it done before June is over (without deadlines, I will procrastinate). Kind regards. Luis7M (talk) 22:41, 23 June 2025 (UTC)

Thanks for offering to help out, @Luis7M. The reviewers don't need anything as complicated as List of France international footballers (1–4 caps). What they really need is just a simple, short list posted at Wikipedia talk:WikiProject Cricket, with a note like "Here's 50 ____ cricket players that meet the LUGSTUBS2 criteria, if anyone's willing to sort through them. Ping me when you're ready for the next list" really is enough to help them out significantly. Fill in the blank with whatever you want, e.g., South African players, players on a particular team, etc. You don't even have to get all the ____ players, as they've said that lists of 50 or so at a time are preferable to one huge list.

If you wanted to help with reviewing individual athletes (even just for the easiest cases), then I'm sure someone there could make some recommendations for the fastest methods. They also need editors who are willing to make list articles when no plausible redirect targets exist (e.g., a List of Imperial Lions players, to which non-notable players for the Imperial Lions could be redirected), but this need not be as complex as your French list. WhatamIdoing (talk) 23:30, 23 June 2025 (UTC)

Thanks. It'll depend on how you plan to work. My starting point might be South Africans – a set I mostly redirected where possible because sourcing is less easy. Ideally I'd like them in lists by team. I have no idea how many that would be – a rough list in a sandbox first might be the easiest way to go about it. There will be some overlap where people played for more than one team, but we can deal with that. The teams are slighly complex because of name changes – so Orange Free State and Free State are the same side; both had B teams which played at the highest level as well, so all four grouped in one would be most useful; Transvaal became Gauteng; Natal became KwaZulu-Natal etc... Once I know how easy (or not) that is and how many players are involved we can decide what a sensible approach is from there. There's a list of South African teams in Template:Cricket in South Africa and a list of lists in Template:Lists of South African cricketers – lots of red links so if you're able to produce even partial lists - perhaps from categories - that would be useful as well.

I think BilledMammal had an adapted quarry script that dug out likely relevant cats that would help create team lists, but I'm not sure how to find it and I don't have a copy Blue Square Thing (talk) 05:53, 24 June 2025 (UTC)

@WhatamIdoing: and @Blue Square Thing: something like this? Draft:List of Imperial Lions cricketers. Kind regards. Luis7M (talk) 02:01, 25 June 2025 (UTC)

Yes, that's the sort of thing we're looking for. I assume it's been put together using categories, yes? The list isn't complete because the cats aren't complete: so people like Craig Alexander (cricketer) also played for Lions. But they can be added inonce we have more lists. There's a couple of things we could use doing to the lead – the team also played T20 cricket, for example – and the naming of South African teams is complex. I'm going to try to get some clarity on it, so it might be helpful not to publish it just yet (the (unreferenced) history section at Dolphins (South African cricket team) seems to summarise it quite well, but it doesn't help with how we name teams as we still have KwaZulu-Natal (cricket team).) But, yes, that's the sort of thing we're looking for. Thanks for using the layout and so on that most of our lists follow.

The other franchise teams don't, I believe have any lists: Cape Cobras, Dolphins (South African cricket team), Knights (cricket team), Titans (cricket team), and Warriors (cricket team). Then there are the traditional province sides that you'll see in the navigation box at the bottom of the draft list. Some of them have been around for over a century so the lists will be longer, but cats look like they work to speed up the first step of the process which is a good thing Blue Square Thing (talk) 05:40, 25 June 2025 (UTC)

@Blue Square Thing: Done! Here's what you asked. Draft:List of Cape Cobras cricketers, Draft:List of Dolphins cricketers, Draft:List of Knights cricketers, Draft:List of KwaZulu-Natal cricketers, Draft:List of Titans cricketers, and Draft:List of Warriors cricketers.

I don't have access to CricketArchive, so please add those refs, so that I can then put this articles into the mainspace without risk of AfDs. Kind regards. Luis7M (talk) 15:01, 25 June 2025 (UTC)

Could this book be useful at all? https://www.google.com/books/edition/The_Extraordinary_Book_of_South_African/BC2jf1cWCJEC

Or this one? https://www.perlego.com/book/3494885/cricket-and-society-in-south-africa-19101971-from-union-to-isolation-pdf (available in WP:TWL; apply at https://wikipedialibrary.wmflabs.org/partners/144/ ). WhatamIdoing (talk) 23:43, 25 June 2025 (UTC)

@WhatamIdoing: Well, well, well, guess who is bossing who now? I have made the (partial) lists, so why don't YOU add those refs. It mustn't be that hard. Not to mention that you seem to be much more familizared with them than I am. Kind regards. Luis7M (talk) 13:59, 26 June 2025 (UTC)

I know nothing about cricket, and what I know about these books is that they claim to have information about cricket players in South Africa. You said that not having access to CricketArchive was impeding your work, so I thought I'd see if there were other sources on this subject that you would have access to. WhatamIdoing (talk) 05:39, 28 June 2025 (UTC)

Thanks. I'll try and get to this over the next coupe of days, but it may be the start of next week. Things are slightly crazy just now... Blue Square Thing (talk) 04:39, 26 June 2025 (UTC)

I've worked on Draft:List of Cape Cobras cricketers. Think the list is complete and I've written a lead which tries to explain what the heck is going on. It's complicated and the lead may be too complex. Could people give it a read and suggest any changes please? Once we have an OK lead, we can run that out to the other franchises, with obvious changes Blue Square Thing (talk) 09:44, 30 June 2025 (UTC)

This looks good to me. I appreciate the description of the Wikipedia:List selection criteria in the last paragraph. That should help future editors. WhatamIdoing (talk) 15:33, 30 June 2025 (UTC)

These have all been worked up now – just waiting for the last one to be pushed to mainspace before doing a couple more redirects Blue Square Thing (talk) 08:53, 8 July 2025 (UTC)

@Blue Square Thing: I have created two more: Draft:List of Free State representative cricketers and Draft:List of Gauteng representative cricketers. Kind regards. Luis7M (talk) 14:04, 8 July 2025 (UTC)

Those might take a while. They might need o be partial lists to start with. I'll see what I can do to the leads at least. @Luis7M: the Natal one needs pushing to mainspace please Blue Square Thing (talk) 06:43, 9 July 2025 (UTC)

@Blue Square Thing: I have created two more: Draft:List of North West representative cricketers and Draft:List of Northern Cape representative cricketers. Kind regards. Luis7M (talk) 13:59, 15 July 2025 (UTC)

Thanks. I have KZN Inland pretty much ready to go. Time isn't on my side, so these might need to be leads and verified and then pushed. North West will be easier as the history is shorter – Northern Cape goes all the way back to 1889/90. That will leave Easterns and Northerns to do. I shall be away for some time quite soon, but we'll get those sorted eventually. The previous ones need to be verified and updated properly, but, again, we'll get there with those eventually - might be September time, but that's OK Blue Square Thing (talk) 15:45, 15 July 2025 (UTC)

Done those two and also Northerns and Easterns, so that should be all the main lists done. There will be people need adding and the Northerns list needs double checking, but they'll do at least. Thanks for your help. Blue Square Thing (talk) 13:30, 16 July 2025 (UTC)

Object protection

There have been many edit wars over a single box in an infobox, or a word, or perhaps a paragraph. One notable one is the nearly 2 decade Caesar salad edit war which involved hundreds of editors editing one infobox and changing the origin location to either be Mexican or Italian. The article was protected an uncountably amount of times, likely stopping good faith contributions that otherwise would have made it through. There are other examples, though less notable to Wikipedia. Wikimedia devs should implement object based protection where individual parts of an article can be protected. Admins should have the ability to protect certain infoboxes from being edited. Admins should also have the ability to protect images, sound files, templates, and parts of an article (e.g. on this page, admins can protect the thread "RFC on new temporary account IP viewer (TAIV) user right", only allowing it to be edited by WP:XC users, but still allowing autoconfirmed users to comment on the thread "Finishing WP:LUGSTUBS2"). This allows editors to edit non controversial parts of an article while the parts that are controversial are edited by only good faith editors. 135.180.128.228 (talk) 00:37, 3 July 2025 (UTC)

While the idea is interesting, this is something that should be implemented into the MediaWiki software itself, and can't really be done otherwise. The closest thing that is technically possible is to have, say, the infobox be invoked from a template (which is done on some pages) and have it on another protection level, but nothing would prevent users from replacing the template entirely.

If implemented, this could be especially relevant on topics such as WP:PIA, where some articles only have sections that are relevant to it, but are either unprotected or protected as a whole. Chaotic Enby (talk · contribs) 01:14, 3 July 2025 (UTC)

@Chaotic Enby I said that in the original suggestion, "Wikimedia devs should implement..." in the 4th line. I know Wikipedia is ran on Wikimedia software and thus regular admins, bureaucrats, or stewards can't change it. And for how long Wikipedia has been around, I too am surprised that no one suggested this type of protection before. 135.180.128.228 (talk) 01:47, 3 July 2025 (UTC)

Noted, although I should clarify that this page is intended for concrete on-wiki proposals and, while a good place to gauge consensus for it, might not be the place to work out the technical aspect of the implementation (which would be necessary for it to go forward). It might in fact not be very straightforward to implement it, as Wikipedia:Perennial proposals#Allow watchlisting individual sections of a page mentions a similar technical difficulty. Chaotic Enby (talk · contribs) 02:32, 3 July 2025 (UTC)

The key challenge is that the underlying representation for a MediaWiki page is wikitext, which is designed to be directly edited by humans and easily manipulated by text processing tools. This means there is no inherent concept of subobjects of a page. (Section-based editing and the discussion reply tool are in essence user interface features overlaid on top of the page-based representation model.) Implementing a finer-grained protection model in a way that you discussed would probably require replacing the wikitext editor with one that had access controls managing access to page components. It would be a lot of work, and not only affect editors who currently use the wikitext editor, but also all tools that parse it. I don't believe this is feasible in practice. (On a side note, proposals like this have been made before.) isaacl (talk) 18:14, 7 July 2025 (UTC)

None of the Germanic deity pages have Infoboxs

I have noticed that almost all of the pages for Norse/Germanic deity do not have an Infobox. it also seems that everytime someone tries to add an infobox it is quickly removed, and almost every major Norse/Germanic deity has a section on their talk page (or an archive of the talk page) about a Infobox added and removed at some point.

The Infobox is a very useful tool present on pages for deities in almost every other pantheon and reading Wikipedia is much easier if there is an infobox to read for quick information. the Deity Infobox Template even has a parameter specifically for old Norse names. so I just don't get why some users who work on Germanic mythology pages are so opposed to infoboxs. PharaohCrab (talk) 01:08, 6 July 2025 (UTC)

Do the talkpage sections you found not explain why there is opposition? If there is existing discussion it would be helpful to link when raising the topic. That said, this may not be the right place unless you have a specific proposal. CMD (talk) 01:26, 6 July 2025 (UTC)

if not here then where? PharaohCrab (talk) 01:50, 6 July 2025 (UTC)

There might be an active WikiProject covering the articles you are looking at, sometimes presence/absence discussions have taken place at WT:MOSINFOBOX. If you are workshopping a potential proposal, then WP:Village pump (idea lab). CMD (talk) 02:00, 6 July 2025 (UTC)

There's no consensus to recommend the use of infoboxes for particular kinds of articles (see WP:RECOMMENDIBRFC for that 2024 discussion, which also has a handy table of discussions in 2021–2024 and refers to infoboxes being a contentious topic). From experience on articles about Greek and Roman deities, it's quite understandable that there's opposition to having them on Norse and Germanic ones, but best not wander into the specifics here. NebY (talk) 12:10, 6 July 2025 (UTC)

It's quickly removed because this would be a terrible idea. The problem is that this "quick information" would almost certainly be wrong. Infobox fields work best for non-controversial facts like birthdates, offices held, people involved, etc. But the conception of these deities changed over time, and their older forms have knowledge basically based on speculation from surviving fragments that mention them where 10 different scholars have 11 different opinions. It'd be a perfect formula for well-meaning editors to add information that is superficially sourcable but deeply misleading. SnowFire (talk) 15:59, 8 July 2025 (UTC)

sure, there are a lot of disagreements about Germanic deities but for most there are at least a few things that can be confirmed and more impotently, pages for every other pantheon have a infobox, even some with just as many controversy's PharaohCrab (talk) 17:36, 8 July 2025 (UTC)

There is nothing particularly 'important' about articles on other subjects having infoboxes. Not giving over-simplistic and potentially misleading 'info' to readers, on the other hand, is important. AndyTheGrump (talk) 17:42, 8 July 2025 (UTC)

You can consider yourself one of today's lucky 10,000 for learning something: no, there aren't non-controversial facts safe for the infobox. Questions as simple as what is their name are contested. Even questions like "is this reference to this name in this work and this reference to to the same name later in the work referring to the same entity, or different ones, or a composite character" aren't clear (i.e. "is this 'Bragi' Bragi or Bragi Boddason"). SnowFire (talk) 17:55, 8 July 2025 (UTC)

I remain unconvinced, if the deites name is literally the title it is clearly fine to add to a infobox, even if it isn't you can just add a note or to something the "other names" section, what makes something uncontroversial enough to add to the page itself but not the infobox? and one the honeytrap argument brought up by@NebY, can't you just add some Hidden text letting editors know to be caution in adding to the infobox? I no longer am arguing that they should have infoboxs because no matter how right I think I am, I know I wont be able to convince enough people. but I still don't really understand why so many think that a Infobox shouldn't be used in this one specific case only. PharaohCrab (talk) 13:13, 9 July 2025 (UTC)

Hidden text has no authority and is often ignored. NebY (talk) 15:49, 9 July 2025 (UTC)

See WP:OTHERCONTENT for "pages for every other pantheon" and consider instead that the infoboxes for Greek and Roman deities are a powerful example of the problems described by Snowfire. Once placed, infoboxes are not protected; any parameter can be edited, not just the few things the infobox's creator thinks can be confirmed. The infoboxes become honeytraps for well-meaning new editors eager to contribute by filling in empty parameters, switching images and extending the sparse contents without regard for or perhaps any awareness of WP:V or MOS:IBP. Those new editors are then repeatedly reverted, making their first edits a painful experience and potentially deterring them from ever editing again. The project pays a high price for such infoboxes. NebY (talk) 18:08, 8 July 2025 (UTC)

I feel like the appropriate venue for this is WikiProject Mythology and WikiProject Norse history and culture Dege31 (talk) 17:58, 8 July 2025 (UTC)

Sex, Gender and X (or "Look what I found under the carpet")

Moved from Wikipedia:Administrators' noticeboard § Sex, Gender and X (or "Look what I found under the carpet")

 – Raladic (talk) 04:49, 7 July 2025 (UTC)

I was just browsing some articles and ended up at Sex differences in humans and got rather confused why as the lead of the article appears to have a specific scope in the sexual differences in human physiology based on the lead text, but there was another separate article of Sex differences in human physiology and I ended up in one hornets nest of a mess that was created a long time ago and went unnoticed due to moves and counter-moves, splits, merges and more splits, including history that was entirely forgotten about in the middle which caused another manual split and a whole lot of article renaming that was actually just wrong in many cases, given the content of the articles.

Hold on to your socks as I take you on the journey through time:

• In 2007 the article Sex differences (history) was split into two articles by Lara bran - Sex differences in humans (split) and Gender difference (split) respectively to separate the purely human physiological differences from the social gender ones (see Talk:Gender_difference#split_article for the split moment - split content)
• Then in 2011, it looks like Aronoel didn't realize the intention of the split from 2007 that Sex differences in humans was supposed to be about the physiological parts and Gender difference about the sociological ones and interpreted them as being POV forks (see Talk:Gender_difference#Concerned_about_possible_POV_fork discussion to that effect) and they then moved some content to Gender role, Sex differences in humans and a slew of other articles (see this for reference of the other targets) respectively and then hard redirected the article of Gender difference to Sex differences in humans (which in turn means that the entire article history, and more importantly the Talk page existence of Talk:Gender difference got forgotten since it was no longer an article and unless editors were active since then (or ended up in a wild goose chase that I just was on), would have no idea to even check there
• This is precisely what happened and in 2013 Neelix who had no idea of the entire history of this, given that it was now buried at Talk:Gender difference, which was merely a redirect, and wasn't aware of all the previous context. They then unilaterally created a new POV split (POV split) when they moved Sex differences in humans to Sex differences in human physiology, and creating a new duplicate fork of Gender difference's original intent of talking about the social gender aspects of gender by manually adding social aspects to the now blanked page at Sex differences in humans (here) - while also conflating the terms and just using sex for everything, regardless of what it was about.
• The same user then also went and renamed a LOT of articles that were "Gender topic X" to "Sex differences in X" even though most of these articles talked about the social gender differences. Some select examples of the mess:
  • Gender and education became Sex differences in education (move)
  • Gender and crime became Sex differences in crime (move)
  • Gender and suicide became Sex differences in suicide (move)
  • Gender and religion became Sex differences in religion (move)
  • Sex and psychology became Sex differences in psychology (move) - This one in particular has a whole story of its own as the article at the time discussed a mix of gender and sex aspects after a previous merge of Sex and intelligence and Sex and emotion in 2011 (move) into Sex and psychology), which subsequently had content split out again in a split in 2014 into Sex differences in intelligence (since at that point the whole mess of moves that imposed all the articles at the moment being "Sex differences in X" from 2013 had already happened and no one realized that this caused conflation of Gender and Sex articles respectively)
  • and several more
• Some of these articles were fixed again through various means over time
  • Sex differences in suicide (orig. Gender and suicide) was corrected and moved further to Gender differences in suicide by CoeA a month later (move)
  • Sex differences in religion (orig. Gender and religion) was moved back to Gender and religion in 2016 following a RM (move)

So where does that leave us? In an interesting. The user that created the mess at the center of most of this in 2013 has since been blocked as a sockpuppeteer, but the mess is done and went unnoticed in scope. Some articles have been moved back into correct titles (like the two above), but many are not and should be moved to correct titles if they're talking about the social gender construct (such as education which should go back to Gender and education and so on).

The article Gender role grew in parallel to the other article since the time it received a bunch of the content in 2011 and has some unique content, but also and has several overlaps in content with Sex differences in humans (though the Gender role article explains many of the sections in greater detail), given that the Sex differences in humans article isn't actually exclusively about the physiological differences that had been moved to Sex differences in human physiology, but actually is really about Sex and/or gender differences (as the sections and sub-articles make clear of being quite the mix), but the overlap also wasn't as clear as some sections were pointing to old redirects.

There is also the mess of the manual split from 2013 of Sex differences in humans not containing the history of Gender difference, which leaves an attribution fork as the article incorrectly appears to be novel content without history attribution when some of the content actually came from Gender difference, so a WP:HISTMERGE of Sex differences in humans and Gender difference (and their respective Talk pages) is needed as well to fix this.

Before we have a bunch of distributed RM's/RMTR's/Bold moves of the sub-articles to accurately title each based on their actual topic they discuss, I wanted to raise the whole issue in its entirety so that there's a reference point of both the history that happened as the linkage of what came from where and went to where and then to where is fragmented and just placing a histmerge tag on the two central articles doesn't quite seem to fit this situation (especially since it has a somewhat long history).

Here's my proposal to address and unravel the situation:

• An admin HISTMERGES Sex differences in humans and Gender difference
• The merged article becomes Sex and gender differences in humans, which should become a WP:BCA to explain that there are some differences, some of which may have physiological and some more sociological aspects of gender and sex, and provides a high level entry-point to Sex differences in human physiology, Gender role and the sub-servient sub-articles
• The community decides whether we want WP:CHIMERA articles to sub-breakdown things, like having a Gender differences in humans sister-article for those articles that are exclusively gender related, or if the BCA should be the only center point
• The template Template:Sex differences gets similarly corrected into "Template:Sex and gender differences" for accuracy and consistency, as it already is that and has some articles on sex and some on gender differences and some on both
• The community reviews existing articles in the area to rename them as appropriate to be either:
  • "Gender differences in X" (If the focus is gender)
  • "Sex differences in X" (if the focus is purely physiological)
  • "Sex and gender differences in X" (if the focus is a mix of both)
  • "Gender and X" (if "differences in" doesn't fit as well, such as the religion article)
  • "Sex and X"
  • "Sex, gender and X"
  • or a handful of other names-as appropriate for more case-by-case article names (like Gender disparities in health, Gender and emotional expression, Sexual jealousy..) that can just stay where they are

I hope my explanation of what happened, my recommendation for a path forward and all are cohesive. Please let me know what you think. Raladic (talk) 04:49, 7 July 2025 (UTC)

Before we continue, I must point out that physiology (function) is different from anatomy (structure) and very much of the Sex differences in human physiology article is actually about anatomy, not physiology. For example, the sections "Size and body shape", most of "Skeleton and muscular system", and nearly all of "Respiratory system" I would consider to be anatomy, not physiology. Since the anatomical differences are inextricably linked with physiological differences, this article ought to be merged elsewhere or renamed (perhaps to "Sex differences in human anatomy and physiology"). (I suppose we could try to split it into an article for anatomy and an article for physiology, but that would be difficult and painful.) Toadspike [Talk] 07:31, 7 July 2025 (UTC)

It's complicated. Microanatomy is sometimes lumped with physiology, and P&A is sometimes taught as a single course. It may not be appropriate to blindly follow the lead of academia, but I believe that it is appropriate whether to separate them. -- ~ ~~ — Preceding unsigned comment added by Chatul (talk • contribs) 09:23, 7 July 2025 (UTC)

Seems reasonable to me. If you try to separate this into individual RM discussion, though, I wonder if you'll run into problems with people on both sides of the political issue who don't want to acknowledge a distinction between "sex" and "gender". Anomie⚔ 11:35, 7 July 2025 (UTC)

Gender is a grammatical concept. Is German politically incorrect because it has three genders? What about languages that have more than three?

It's not our job to judge what happens among consenting adults. What matters is what you can document in a RS, not who approves or disapproves. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:08, 7 July 2025 (UTC)

In current English-speaking (and particularly US) society, gender as a grammatical concept is far from anyone's focus. "Gender and sexuality" is a contentious topic here for completely different reasons. Anomie⚔ 12:23, 7 July 2025 (UTC)

Gender as a sociological concept and grammatical gender are two different things entirely (e.g. Mädchen). Chaotic Enby (talk · contribs) 13:13, 7 July 2025 (UTC)

(1) Let's leave linguistic gender out of it, because it's got nothing to do with either social gender constructs or the biology of sex-determination and sexual dimorphism. (2) Let's lump anatomy and physiology together because they're interlinked and both controlled/determined by the pathways that dictate biological sex. (3) Grouping our articles to make it clear when we're talking about biology, when we're talking about sociology, and when we're dealing with the intersection of both, makes a lot of sense. I have no particularly strong feelings on the vocabulary used to do so. (4) Does Wikipedia have some sort of equivalent of a "sticky note", that can be eternally stuck prominently at the top of talk-pages on articles like this, explaining why they have the title and scope that they have, to avoid well-meaning editors creating similar chaos in future? (5) Please forgive me if I've written something contentious in a contentious area; I have no wish to hurt anyone on gender-related issues. Elemimele (talk) 16:26, 10 July 2025 (UTC)

I'd struggle to imagine a less controversial comment, FWIW. —Compassionate727 ^(T·C) 23:12, 10 July 2025 (UTC)

AIUI, a less controversial comment would omit the words biological sex. WhatamIdoing (talk) 06:50, 13 July 2025 (UTC)

Proposal: Remove the Contents link from the sidebar

Considering the amount of pageviews this page gets, I just don't see the value in keeping this page. When looking at the page, it disappoints me that while it does cover most types of articles, it doesn't cover biographies pretty well. Biographies make up a huge portion of our Wikipedia pages, so unless the page is improved to include them, I think it would better to just remove the link. Interstellarity (talk) 12:28, 7 July 2025 (UTC)

I'd support improving the page, would not support removing it. Different people use the different ways to navigate the encyclopedia and its not causing harm. JackFromWisconsin (talk | contribs) 22:21, 7 July 2025 (UTC)

The standard for appearing in the sidebar is much higher than "not causing harm." If it's not pulling its weight, it should be removed. SnowFire (talk) 15:53, 8 July 2025 (UTC)

The number of views is about 3800/day, essentially all of them from desktop, almost none from mobile. WP:Contents and its subpages are an attempt at providing alternative ways to discovering Wikipedia content (not through direct search), a time-honoured traditional approach. I am not sure it is working well for many people and I do not know how well-maintained it is, but if there is no link to this from sidebar or at least the Main Page, it won't work at all. —Kusma (talk) 16:11, 8 July 2025 (UTC)

Contents is indirectly linked on the Main Page, via Contents/Portals. Maybe replace that with a straight link to Contents? Dege31 (talk) 17:30, 8 July 2025 (UTC)

What would be the benefit of the removal? Dege31 (talk) 17:11, 8 July 2025 (UTC)

De-cluttering sidebars/menus generally has one underlying goal: to quit 'distracting' people with something that's not useful/helpful, so that they will be more likely to find/click on something that is useful/helpful. WhatamIdoing (talk) 07:10, 13 July 2025 (UTC)

Support removing the page, as it does not help navigation, nor does it make sense to have 7 million articles condensed into a scrappy and incomplete list in the sidebar. Portals probably do a better job. Pksois23 (talk) 07:31, 18 July 2025 (UTC)

Just to check, the sidebar and its links are only relevant for logged in users right? Taking action/no action would not affect most readers, so the links are mostly there for newer editors (or to try and beguile readers creating accounts into becoming editors)? CMD (talk) 07:53, 18 July 2025 (UTC)

Sidebar is visible for everyone logged in or not Pksois23 (talk) 10:23, 18 July 2025 (UTC)

Where? When I look at Henry de Hinuber logged in, I see the "Main menu" on the left side above "Contents". When I look at it logged out, I see only "Contents". CMD (talk) 10:47, 18 July 2025 (UTC)

It's not the contents of the page, it's the the Contents link under the Main menu menu below Main Page, that links to Wikipedia:Contents. Also whether the main menu displays in the sidebar is a setting you can turn on/off. Pksois23 (talk) 11:08, 18 July 2025 (UTC)

As I said, there is no Main menu when I am logged out. I don't think logged out users can turn settings on and off. CMD (talk) 12:38, 18 July 2025 (UTC)

It's hidden as the three bars left of the Wikipedia logo in the top left. When you click it it should have an option that says move to sidebar. At least on vector 22 it's like this Pksois23 (talk) 12:45, 18 July 2025 (UTC)

Ah thanks, how fascinatingly unintuitive. CMD (talk) 12:47, 18 July 2025 (UTC)

Correct Procedures?

Hey, If a policy/guideline needs to be updated, what is the proper process according to Wikipedia guidelines? Should changes be made directly (Be Bold), or should they first be discussed on the talk page? Is it necessary to ask the community to vote on the changes (support/oppose)? What is the most appropriate way to handle this? I’m not looking to change any policy; I just want to know the correct procedure. Regards Riad Salih (talk) 12:47, 7 July 2025 (UTC)

Hi, while you can technically be bold, it is much better to propose it on the talk page to make sure that it has consensus (as otherwise it might quickly get reverted by anyone who disagrees with the change). If it's a major change, you can use the {{rfc}} template to get broader discussion (and/or link it here or at Wikipedia:Village pump (policy)), but if it's a smaller change, discussing it on the talk page is enough. Chaotic Enby (talk · contribs) 13:10, 7 July 2025 (UTC)

We are allowed to make BOLD edits to policy/guideline pages, but it is strongly preferred that we discuss first.

A minor tweak (say a grammar correction) probably does not need prior discussion, a major change definitely does (and keep in mind that, sometimes, what one editor thinks is a minor tweak another editor will see as a major change). When in doubt, discuss first. Blueboar (talk) 14:46, 7 July 2025 (UTC)

If you are unsure then it's best to err on the side of more discussion. Nobody is going to bite your head off if you opt for a talk page discussion when you could have made the change boldly. Also if you opt for a talk page discussion people will tell you if the change has to be made via RFC or advertised at a village pump. Phil Bridger (talk) 16:47, 7 July 2025 (UTC)

If you're going to be bold, it's important to be transparent, for example leaving word on the talk page what you intend. Wehwalt (talk) 18:01, 7 July 2025 (UTC)

@Riad Salih, please read Wikipedia:Policies and guidelines. WhatamIdoing (talk) 07:11, 13 July 2025 (UTC)

RFC: Adding featured and good content status to the tagline

Should the site tagline display featured and good content status in the following style?

London Beer Flood

A featured article from Wikipedia, the free encyclopedia

List of English words containing Q not followed by U

A featured list from Wikipedia, the free encyclopedia

Archaeological interest of Pedra da Gávea

A good article from Wikipedia, the free encyclopedia

All horses are the same color

From Wikipedia, the free encyclopedia

Dan Leonard (talk • contribs) 19:33, 7 July 2025 (UTC)

Background (tagline)

Apologies for the long text to follow but I think a detailed RFCBEFORE and implementation is necessary for such a highly-visible proposal.

There's been perennial proposals for increasing the visibility of page status, with a fair amount of assent but no proposed directions. Many editors in prior discussions have felt the topicon is too small a notice that doesn't accurately reflect the amount of work put into raising articles to featured status. Other editors think the topicons are opaque to readers, and feel that more prominence will draw editors to these backend projects.

• 15 April 2021: Wikipedia:Village pump (proposals)/Archive 174 § Move good/featured article topicons next to article name closed as no consensus.
  Pinging Jr8825 as proposer.
• 23 October 2021: Wikipedia:Village pump (proposals)/Archive 185 § Make FA and GA icons in articles more noticeable #2
  Missed this one, see note below from proposer Dege31.
• 1 February 2023: Wikipedia talk:Good Article proposal drive 2023 § Proposal 21: Make GA status more prominent in mainspace consensus to have an RfC on increasing visibility.
  Pinging czar as proposer.
• 1 March 2024: Wikipedia:Village pump (proposals)/Archive 211 § Proposal: Remove the topicons for good and featured articles closed as snow keep, article quality important to readers
  Pinging Interstellarity as proposer.
• 14 April 2024: Wikipedia talk:Good article nominations/Archive 31 § Proposal 10: Finish doing some or all of the things we agreed on last time we did this (lol)
  Pinging Thebiguglyalien as proposer.
• 11 January 2025: Wikipedia:Village pump (proposals)/Archive 216 § Good Article visibility requesting the topicons in mobile, which is currently being worked on stale at phabricator:T75299.
  Pinging Iskandar323 as proposer.
• 20 March 2025: Wikipedia:Village pump (idea lab)/Archive 66 § Metadata gadget as the default experience requesting technical feasability of modifying the tagline.
  Discussion opened by myself.

In this most recent discussion at the Idea Lab, I proposed using the tagline-modifying style of the metadata gadget which got some assent. Aaron Liu, WhatamIdoing, and Novem Linguae were helpful in pointing me toward Lua modules and how taglines are built into the software. While it wasn't feasible then, the recent implementation of phabricator:T380122 and addition of "Project-independent assessment" to the banner shell allows us to directly get FA/FL/GA status using Lua. Dan Leonard (talk • contribs) 19:33, 7 July 2025 (UTC)

Implementation (tagline)

I've developed Module:Page assessment raw, a simplified version of Module:Page assessment that uses the newest features in the MediaWiki pageAssessments extension. I wanted to have a duplicate module to reduce the expensive function count (since this will be on every page) and to allow full- or template-protecting the module (for the same reason).

I think the most efficient way to implement this proposal is to fully replace the page MediaWiki:Tagline with a switch-case function to change the tagline based on the output of the Lua module:

{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}
 | FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
 | FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
 | GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
 | From
}} Wikipedia, the free encyclopedia

This example code also uses statistical redirects (suffixed with "linked from tagline") in the same manner as Elli's additions to the current topicons. This allows us to get a good view of how often readers click on these new taglines, and determine whether they're a useful addition to the project. In the month of June, about a third of visitors came to the featured articles page through the topicon. With these new statistical redirects, we can see how many use the tagline. Of course, if this passes, an admin should fully-protect these three redirects. Dan Leonard (talk • contribs) 19:33, 7 July 2025 (UTC)

Survey (tagline)

Notified: Wikipedia talk:Featured articles, Wikipedia talk:Featured lists, Wikipedia talk:Good article nominations, MediaWiki talk:Tagline. Dan Leonard (talk • contribs) 20:00, 7 July 2025 (UTC)

• Support as proposer. Dan Leonard (talk • contribs) 19:33, 7 July 2025 (UTC)
• Support a small change (probably smaller than people expect, considering the banner blindness phenomenon) which could nevertheless increase new editor attraction from people curious enough to click the link. I don't really see any downsides. ~~ AirshipJungleman29 (talk) 20:19, 7 July 2025 (UTC)
• Support. Good articles being invisible on mobile – 65% of our readers – doesn't make sense. Bringing us to some parity with the web version communicates to readers that some verification and vetting effort has been made, especially with the recently increased level of scrutiny required by GAs (and much-discussed at WT:GAN. — ImaginesTigers (talk) 20:23, 7 July 2025 (UTC)

  This sadly won't affect mobile users as the tagline does not appear in Minerva. It would be a good impetus for bugging WMF over at Phabricator to show the tagline though. Dan Leonard (talk • contribs) 20:33, 7 July 2025 (UTC)

  @Dan Leonard: Thanks for telling me that, although it is disappointing. I assume this affects web Minerva, too? If so, do we have any statistics on how many users aren't using Minerva at this point? I'd assume the number is relatively low, and largely our most engaged user base. — ImaginesTigers (talk) 22:31, 7 July 2025 (UTC)

  I don't know where to find skin usage statistics. OVasileva (WMF) made a couple pie charts at commons:Category:MediaWiki skin statistics, but they're of editors, not readers, and don't have details on where the source data is from. It does seem like there's an open task for the tagline to be shown at phabricator:T349117. Presumably if this RFC passes it can also be seen as a request from the English Wikipedia community to finish that request. Dan Leonard (talk • contribs) 22:40, 7 July 2025 (UTC)

  This seems like a different problem - wouldn't adding GA indicators in Minerva solve this? — xaosflux ^Talk 12:33, 9 July 2025 (UTC)

  Other respondents mentioned here that mobile topicons don't seem to have any progress and community work on adding a mobile tagline would probably be easier than adding a mobile topicon, not to mention the engineering needed to have parity with tooltips on mobile. Aaron Liu (talk) 16:18, 9 July 2025 (UTC)

• Support a minor change but a positive one. Anything that (1) raises awareness of our quality content and (2) might conceivably encourage readers to contribute is a good thing. Cremastra (talk) 20:48, 7 July 2025 (UTC)
• Support taglines are harder to miss, so this does seem like an improvement. Would this also remove the topicons, or would a highlighted article end up displaying both? Paprikaiser (talk) 20:51, 7 July 2025 (UTC)

  I think it's worth keeping both, at least for a trial period, to compare clickthrough rates. But maybe I'm just too addicted to pageview stats. Dan Leonard (talk • contribs) 21:00, 7 July 2025 (UTC)

  For the record, I support keeping both. Topicons are cute. Paprikaiser (talk) 21:09, 7 July 2025 (UTC)

• Support per Airship, though I think the current wording is needlessly verbose. I feel it could be more impactful if it said something like "A featured article, meaning it represents the best Wikipedia has to offer" IAWW (talk) 20:55, 7 July 2025 (UTC)

  @It is a wonderful world I'm not sure I understand you. If you think the suggested wording is too verbose, why are you proposing a longer version? Cremastra (talk) 21:07, 7 July 2025 (UTC)

  Sorry, verbose wasn't a good word. I mean the current wording doesn't make the best use of space. Adding "from Wikipedia, the free encyclopedia" is pointless, because the reader obviously already knows this. Those words could be replaced with something different that the reader doesn't already know, like what a "featured article" is. IAWW (talk) 21:23, 7 July 2025 (UTC)

  The tagline "From Wikipedia, the free encyclopedia" has been stable for a while after many thorny discussions, so I think replacing the language wholesale would be much more controversial than just squeezing in "a featured article". See the many subheadings of MediaWiki talk:Tagline/Archive 1 § "that anyone can edit". Dan Leonard (talk • contribs) 21:33, 7 July 2025 (UTC)

  I agree it would probably be tough to reach consensus and it should be a separate proposal to this. IAWW (talk) 22:43, 7 July 2025 (UTC)

• Support As a drafter of a similar RfC that failed to reach consensus, I assume my !vote is no surprise... Dege31 (talk) 20:58, 7 July 2025 (UTC)

  Ah, I thought my RFCBEFORE was complete. Thanks, I've added your discussion to the above list. Dan Leonard (talk • contribs) 21:16, 7 July 2025 (UTC)

• Support I think this is a better way to make the good and featured stand out. If this proposal passes, I recommend removing the topicons. I would also like to implement this change to all the vital articles as well. For example, George Washington would say A level 3 vital and featured article from Wikipedia, the free encyclopedia while an article that is neither good nor featured, but vital like Christianity would say A level 3 vital article from Wikipedia, the free encyclopedia. Interstellarity (talk) 21:07, 7 July 2025 (UTC)

  I'm not sure removing the topicons is necessarily a good plan, since many eyes will skip over the tagline entirely. Cremastra (talk) 21:08, 7 July 2025 (UTC)

  Vital article status uses a very different method of data management so would require a different solution. Dan Leonard (talk • contribs) 21:18, 7 July 2025 (UTC)

  That can be something we can discuss here or maybe the vital article talk page to figure out what level of organization is best. I'll leave a note on the talk page to get opinions on what method is best. Interstellarity (talk) 21:33, 7 July 2025 (UTC)

  Vital article status seems less important, as not only is it less transparent to readers ("is level 1 vital the least or most important?"), but also only relates to the topic itself rather than the quality of the article they are reading. Knowing that what you are reading has been through a formal review process is great to gauge the level of trust you want to give to the article, knowing that the subject has been assessed to be important, less so. Chaotic Enby (talk · contribs) 21:48, 7 July 2025 (UTC)

  Beyond the technical limitation raised by Dan, Wikipedia talk:Vital articles/Archive 25#Proposal for a VA "top icon" rejected a far smaller top icon for vital articles on the basis that unlike article quality, "vital" describes the subject itself which has little use to the reader already here to learn about it. ViridianPenguin🐧 (💬) 22:49, 7 July 2025 (UTC)

• Weak oppose. Current system seems fine. Interestingly, neither icons nor tagline work on mobile web. Example: https://en.wikipedia.org/wiki/Icelandic_Phallological_Museum?useskin=minerva –Novem Linguae (talk) 21:12, 7 July 2025 (UTC)

  At phabricator:T75299, JScherer-WMF explained the current roadblock in showing topicons in Minerva:

  For example, a FA/GA badge with enough context could be an interesting and valuable trust signal for a reader, similar to how warning templates are often used as distrust signals when articles are low quality. On the other hand, I assume that a "protected" badge would be of little interest to anyone who isn't logged in and actively considering contributing to the wiki.

  Another tension in the current proposal is the form of the indicators themselves. As mentioned in the VP discussions about this, there may be a low awareness of FA/GA for casual readers, and an unlabelled icon might not "onboard" casual readers into explaining what FA/GA are and why they're useful.

  While the tagline isn't currently shown in Minerva either, WMF might be more amenable to displaying it as it is likely technically simpler than showing topicons and solves the problem of an unlabelled icon might not 'onboard' casual readers. It's currently tracked, albeit stale, at phabricator:T349117. Dan Leonard (talk • contribs) 21:25, 7 July 2025 (UTC)

• Support I'm already used to seeing it with Wikipedia:Metadata gadget, and, while classes below GA are more subjective, it could be great for our readers to highlight articles that have had a formal review process. Chaotic Enby (talk · contribs) 21:44, 7 July 2025 (UTC)
• Support been waiting a long time for this one. Very much needed! --JackFromWisconsin (talk | contribs) 22:09, 7 July 2025 (UTC)
• Support for GA/FA as long as we also keep the topicons; I think the visual cue is nice. ♠PMC♠ (talk) 22:39, 7 July 2025 (UTC)

  2nd on this. Topicons are still nice and useful. JackFromWisconsin (talk | contribs) 23:32, 7 July 2025 (UTC)

• Support; I agree with AirshipJungleman that it likely won't be noticed by the vast majority of users, but if one percent are intrigued and find out more about the Good & Featured processes, I think that makes it more worthwhile. I also agree with the takes that it'd be more applicable to mobile than a topicon would be, and I think it adds context to the topicons on desktop if people don't realize you can click on them. Generalissima (talk) (it/she) 22:47, 7 July 2025 (UTC)
• Support as the overdue implementation of repeated consensus for greater visibility. Like Chaotic Enby, I would never want this expanded to other article classes because many (myself included) use Rater for an AI-generated classification that works for our technical needs but communicates little to readers. I would have this appear alongside the topicon, both because the aesthetic badge is a big motivator for article writers and to run Dan's click-through experiment. Hoping that even if the topicons are never added to mobile view, at least this expanded tagline can be. ViridianPenguin🐧 (💬) 22:55, 7 July 2025 (UTC)
• As I said in a previous discussion, I don't agree with the premise. I think the current amount of prominence given to the article rating is appropriate, given the way the rating is determined. Thus I do not support changing the tagline in this manner. isaacl (talk) 22:55, 7 July 2025 (UTC)

  Since that comment is in turn referring to another comment, here's the link to isaacl's argument against greater visibility for GA/FA status. ViridianPenguin🐧 (💬) 23:13, 7 July 2025 (UTC)

  To expand slightly on the determination concerns: I appreciate that the good article/featured article review processes are the only ones we have for this type of article rating. However they do not ensure evaluation by subject matter experts with the background knowledge to best evaluate the comprehensiveness and accuracy of the article. I think giving the rating higher prominence would raise reader expectations that an evaluation has been made by subject matter experts. isaacl (talk) 15:10, 11 July 2025 (UTC)

• Support per above. These two ratings are the ones with the least amount of arbitrariness so I don't think this status should have any less prominence. They're already displayed as topicons everywhere except Minerva, which shows the reader interest. If these statuses are any overprominent, there's already consensus for them being so. Aaron Liu (talk) 23:05, 7 July 2025 (UTC)
• Oppose as the tagline should be kept simple. I agree with isaacl that we don't need to give more prominence to article ratings, which are subjective anyway. Some1 (talk) 23:27, 7 July 2025 (UTC)

  I don't see how this isn't simple. Aaron Liu (talk) 23:45, 7 July 2025 (UTC)

  A tagline that changes depending on the article rating isn't simple, and I prefer that the tagline text remains the same for every article, regardless of its rating. Also, it's misleading to state that Example article is "A good article from Wikipedia, the free encyclopedia" when that rating reflects only one editor's review (opinion) of that article. In that instance, the tagline is more misleading than the topicon, especially when most readers won't bother to click on the good article link in the tagline.

  Many editors in prior discussions have felt the topicon is too small a notice that doesn't accurately reflect the amount of work put into raising articles to featured status Seems like this proposal is more for the editors than for the readers. Some1 (talk) 00:32, 8 July 2025 (UTC)

  What's the impact of this small bit of added complexity?

  when that rating reflects only one editor's review (opinion) of that article

  I think that's only an argument for renaming GoodArticle. In my opinion, "good article" signifies only as much value as it should. This also means if a reader thinks "hey this is not good-article quality" they can start something on the talk page. Aaron Liu (talk) 18:20, 8 July 2025 (UTC)

• Support. As long as we can keep the topicons as well, I don't see any downsides to this. – Epicgenius (talk) 00:08, 8 July 2025 (UTC)
• I don't see the harm per se, but more visibility for GA/FA ratings makes more critical the need for participation at WP:FAR and WP:GAR and for those processes to function properly. CMD (talk) 00:38, 8 July 2025 (UTC)
• Support. As I mentioned in the 2023 RFC: I once observed a high school classroom that happened to be teaching research skills on using Wikipedia. The teacher said that the lock icon in the corner meant that it had been reviewed and was safe. Readers have no idea what our esoteric icons mean, so a little explanation of what exactly is verified and what isn't could go a long way towards mutual incentives. This is a smart way to start. czar 02:08, 8 July 2025 (UTC)
• Support I don't see the harm in mentioning the fact that the article has reached good/featured status, and it would certainly help reader to become aware of those statuses and as a compliment to the topicons. Speaking of those icons, why don't we include them in the tagline too so the reader will notice it when reading the tagline and be able to recognize it when reading another article on its tagline or on the corner of said artile. So maybe something like "A good article from Wikipedia, the free Encyclopedia." Here I placed the icon after the phrase introducing the article class since it looked akward to have it immediately following the indefinite article "A" when I tried that first. Gramix13 (talk) 02:52, 8 July 2025 (UTC)

  This thought came to mind for me as well. I like the idea of having a more prominent visual, but I feel like it'd be redundant presuming we're keeping the topicon. My preferred approach to accomplish this would be to move the icon from the top right to directly next to the article title, as was previously proposed. Sdkb ^talk 05:09, 8 July 2025 (UTC)

  Noting that since that 2020 proposal argued for matching the Danish Wikipedia's practice, dawiki has switched to our practice of having the topicon appear in the top-right corner (e.g., da:Israel). ViridianPenguin🐧 (💬) 13:40, 8 July 2025 (UTC)

  Interesting; any idea why? Sdkb ^talk 14:18, 8 July 2025 (UTC)

  Unfortunately not. I checked through their relevant talk pages and Landsbybrønden (village well) archives to no avail in identifying why they switched. ViridianPenguin🐧 (💬) 16:04, 8 July 2025 (UTC)

• Support. An article's good or featured status is a key piece of information that every media-literate reader ought to pay attention to, but our current display is nowhere near prominent enough to make that happen. This is a well-thought-out step in the right direction toward making that happen. I support keeping the topicons, and ultimately moving them next to the article title per the prior proposal. I also continue to hope that phab:T75299 is taken up so that icons display on mobile. Sdkb ^talk 05:07, 8 July 2025 (UTC)
• Strong support and additional request. I have a script that already does this, but this being an automatic thing for other editors would be extremely useful in helping people maintain articles. Possibly, we could also have 'Currently a featured article candidate', 'Former featured article', 'Currently a good article nominee' too; that might be a bit too technical though. 750h+ 05:18, 8 July 2025 (UTC)

  Being a candidate or having former status is mainly relevant for editors, not readers, so I would not support this. Sdkb ^talk 06:03, 8 July 2025 (UTC)

  +1 Graham11 (talk) 07:09, 8 July 2025 (UTC)

  Wikipedia:Metadata gadget? It's a good thing the code is already pretty much there. Chaotic Enby (talk · contribs) 18:25, 8 July 2025 (UTC)

• Comment – If we are to use a redirect like Wikipedia:Featured articles (linked from tagline), we should probably change the tooltip to simply "Wikipedia:Featured articles". Graham11 (talk) 05:34, 8 July 2025 (UTC)
• Support, great idea. I'd also support other measures to improve GA/A/FA visibility, like moving the topicon to be right beside the title. Toadspike [Talk] 09:12, 8 July 2025 (UTC)

  My reaction to much of the opposition is that our readers are not stupid. They know what Wikipedia is. They will not see "good article" and think "this must be a 105% perfect article certified by the leading experts in the field and then fully-protected so no-one can edit the page again". They know that Wikipedia is a wiki written by regular people, many of whom are not experts on the topics they write about, and that Wikipedia articles can generally be edited by anyone, anytime. By calling something a "good article" or "featured article", whether in a tagline or with an icon, we simply argue that this article is better than many others. And while were bashing the names as "hokey" or "bizarre", I must point out that "featured" sounds stupid outside the context of being featured on the main page, while "good" is a simple English word that accurately describes the point of the rating. Toadspike [Talk] 13:34, 12 July 2025 (UTC)

• Oppose The top of many articles, including GA and FA, are already overly cluttered. I would support the reduction of clutter rather than the adding to it. -- LCU ActivelyDisinterested «@» °∆t° 16:01, 8 July 2025 (UTC)

  I understand your point, but this would add practically no clutter, as "From Wikipedia, the free encyclopedia" is still a default tagline. I assume you are generically opposed to the tagline in the first place? Dege31 (talk) 17:17, 8 July 2025 (UTC)

  Yes I would support removing it altogether, rather than adding to it. -- LCU ActivelyDisinterested «@» °∆t° 18:40, 8 July 2025 (UTC)

  I agree with ActivelyDisinterested here Logoshimpo (talk) 05:08, 17 July 2025 (UTC)

• Support. Awareness of the featured article process is partially what inspired me to begin contributing to Wikipedia, and I feel like increasing this awareness wouldn't just inspire more people to edit, but would also inform readers which articles have been more diligently reviewed to eliminate gaps and verification errors. Sad that this won't be visible on mobile but it's a step in the right direction with no glaring downsides. Fathoms Below (talk) 19:50, 8 July 2025 (UTC)
• Support. I can see no downsides to this proposal - anything that helps promote good and featured content, and potentially bring in new editors, is a positive in my book, and this is a pretty nice and yet non-obtrusive way to do so. CoconutOctopus talk 20:40, 8 July 2025 (UTC)
• Comment. It sounds like we are proposing adding a module to every single page load on the entire wiki. Has someone who understands mediawiki caching and performance given some thought about if this will cause stress to the servers or performance issues? –Novem Linguae (talk) 22:48, 8 July 2025 (UTC)
• Notified: WP:VPT. –Novem Linguae (talk) 22:50, 8 July 2025 (UTC)

  mw.title.new().pageAssessments is an WP:EXPENSIVE function, but since it is only called once it usually shouldn't often be an issue considering the per-page limit of 500. The module does access the class rating via iteration (see the for loop at lines 29–33) rather than via random access, which is admittedly inelegant but probably not too inefficient. Sadly, I got what feels like a WONTFIX for random access at phabricator:T396135.
  Regardless, whether the community wants something shouldn't be dependent on whether it is currently feasible. I trust the interface admins and WMF will fix things if the community breaks them.
  This isn't to say I am in any way opposed to a code review of this, which I welcome wholeheartedly. I am sure there is something here that could be made more efficient. Dan Leonard (talk • contribs) 23:10, 8 July 2025 (UTC)

  I tend to agree with the link to WP:DWAP here (which has been relevant for parts of the interface like this before, the link to Category in the footer of each page used to be treated as sufficiently expensive for some reason or another that we couldn't let it vary by number of categories or something like that).

  The only way to get an authoritative answer to this question would be to ask WMF directly I think.

  That aside, I'm actually not really certain this will work the way OP wants it to. Has it been attempted on test Wikipedia? Izno (talk) 23:57, 8 July 2025 (UTC)

  Putting my developer hat on, to my understanding the MediaWiki:tagline is added by a user's skin. As such, running page assessments at that layer is prohibitively expensive since the skin layer is re-rendered every time a user visits a page (as opposed to the parser cache layer where data is computed/rendered every edit and thus can have expensive functions). Unless folks contradict me, to my understanding this will require a significant investment of engineering effort to implement into core-mediawiki (or one of it's extensions) which I'm not sure is worth the outcome.

  Putting on my WP:INTADMIN hat on, I'm not sure I'm completely onboard with using JS (or even Lua) to hack and slash at the existing tagline at pages that we as enwiki are wanting folks to visit. (For context, every time such a thing is implemented folks with bad internet connection will see a flash of unstyled content that often makes the navigating/reading experience worse). Sohom (talk) 00:51, 9 July 2025 (UTC)

  Oh dear, I didn't realize it was part of the skin. What a shame. Guess it'll have to rely on mw:Extension:CustomSubtitle if it's ever finished. I defer to SD0001 below, who wrote the MediaWiki code that makes this possible and seems to think it's potentially possible. Dan Leonard (talk • contribs) 01:01, 9 July 2025 (UTC)

  I don't think it's prohibitively expensive, just a bit expensive. Performance is not affected for logged-out users as for them the entire page html, including the skin, is CDN-cached. For logged-in users, it does result in re-rendering, however note that the Lua .pageAssessments call is just a single SELECT call in the db. Being marked as WP:EXPENSIVE doesn't give the full picture. – SD0001 (talk) 05:35, 9 July 2025 (UTC)

• Tend to oppose, but only for technical reasons. This should be part of MediaWiki (→m:Community_Wishlist/Wishes), not a Lua hack. Then maybe one day even mobile users would get it. Ponor (talk) 23:14, 8 July 2025 (UTC)

  It definitely isn't a Lua "hack". Functionality like retrieving page assessments have been exposed to Lua for use cases like this. It doesn't make much sense to implement everything natively in MediaWiki since most MediaWiki installations don't have a concept of FAs or GAs. – SD0001 (talk) 05:37, 9 July 2025 (UTC)

  Exposing page assessments to Lua is a part of MediaWiki. Aaron Liu (talk) 16:18, 9 July 2025 (UTC)

  It's a hack because it hacks a message that shows at a place convenient for desktop users (⅓), but is not shown to mobile web and app users (⅔). It's not a complete solution, it's a hack. Other than that, there's a javascript gadget that also hacks the message, used by some 1000 active users. Why reinvent the wheel? Ponor (talk) 15:37, 10 July 2025 (UTC)

  Changed my mind, it's a complicated js script. I'd still like to see a solution that every reader can see. Indicators are fine. Ponor (talk) 15:48, 10 July 2025 (UTC)

  Using client-side JavaScript to scrape the talk page and modify the DOM after page load is a very different solution than using a MediaWiki extension's intended functionality to modify pages server-side. Mobile users miss out on a lot of things, including navboxes, sidebars, and even categories. Are categories "hacks" because Minerva chooses to hide them? Dan Leonard (talk • contribs) 15:45, 10 July 2025 (UTC)

  Agree about the gadget, just checked the code: ugh, that's an ugly one. But here, we're saying "this is important, we want everyone to see it", while at the same time we know that two in three readers will not see it. Categories and navboxes are the things at the bottom. Most users rarely go past the lead. So I'd say there is some importance difference. I'm not strongly opposed to "the hack" – I'd simply like to see a better solution. Use different indicators - find better icons? Use icon+text on desktop, icon alone on mobile? Ponor (talk) 16:10, 10 July 2025 (UTC)

  Topicons aren't shown on mobile because it's a difficult implementation and because they're even more opaque to readers (see phabricator:T75299#10512584): on desktop, {{featured article}} at least benefits its readers with the tooltip "This is a featured article. Click here for more information", but touchscreens don't get tooltips. The tagline isn't shown on Minerva either, but it's probably a much simpler implementation and hasn't been done simply as a screen real estate saving measure. If we can get the tagline shown (phabricator:T349117), it'd serve the same purpose as the tooltip serves for desktop users. I do want mobile users to see this, and I think using the tagline is an important first step to getting WMF to increase visibility. Dan Leonard (talk • contribs) 16:19, 10 July 2025 (UTC)

  You cannot see indicators on mobile either. Aaron Liu (talk) 17:37, 10 July 2025 (UTC)

• Oppose What is the point? FAs and GAs are not necessarily better than normal articles, and the reader does not care about who followed internal Wikiprocedures to get something declared FA/GA. Also per Ahecht. Polygnotus (talk) 03:36, 9 July 2025 (UTC)

  While you are technically correct that some articles which haven't been formally reviewed are as good as GAs or FAs, the average GA is certainly better than the average article, which is a stub or not much more. Toadspike [Talk] 07:58, 9 July 2025 (UTC)

  @Toadspike The best kind of correct! Polygnotus (talk) 09:12, 9 July 2025 (UTC)

  They have necessarily underwent quality control, which includes things like "checking whether the sources confirm what the article say"- not exactly obscure, Wikipedia-only procedures. Dege31 (talk) 16:33, 9 July 2025 (UTC)

• Support as an idea. If the current technical implementation is insufficient, then it can still be recognised as something the community supports and perhaps be added at a later point. Even if that is not likely to happen any time soon given other technical priorities, it would be better having than having another RFC every time someone comes up with another way to make FAs/GAs more visible.  novov talk edits 08:26, 9 July 2025 (UTC)

  I agree with the idea that consensus and technical details should be separate. The closer should feel free to find clear consensus that the community wants this (because they do). Then a consultation with a WMF dev good at performance and caching (maybe via a Phab ticket tagged #performance_issue and pinging someone like Krinkle?) and/or a trial should probably be encouraged in the close as a next step, but can leave that part vague / not as strong as the community consensus part. –Novem Linguae (talk) 09:10, 9 July 2025 (UTC)

• Oppose hacking a module in to the tagline for every single page is a poor technical implementation, especially for something that is only needed on an extreme minority of pages. — xaosflux ^Talk 12:29, 9 July 2025 (UTC)

  Also oppose conceptually using the tagline for this purpose; work was already spent on indicators and if wanted I'd prefer improvement to indicators. Indicators are also much more consistent across the Wikipedia's in other languages. — xaosflux ^Talk 12:32, 9 July 2025 (UTC)

  The French, German, and Russian Wikipedias all use different icons (from us and from each other). Of the Wikipedias I regularly visit only Chinese and Norwegian use the same icons we do. Smaller wikis like Alemannisch don't have quality ratings at all. Toadspike [Talk] 13:20, 12 July 2025 (UTC)

  I wonder if it's possible to add code to {{good article}}, {{featured list}} and {{featured article}} that changes the tagline. Cremastra (talk) 14:59, 9 July 2025 (UTC)

  That was my original thought too and I asked the same thing at the idea lab. The MediaWiki extension mw:Extension:CustomSubtitle could allow this with {{#subtitle:A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from Wikipedia, the free encyclopedia}}, but the extension is in beta and hasn't been touched in years. It seems like it uses a deprecated function global $wgOut so would need to be updated. Dan Leonard (talk • contribs) 15:13, 9 July 2025 (UTC)

  Additional oppose reason, as others have called out already, this will not solve the problem of casual readers (who increasingly use minerva) not seeing the rating - as the tagline element isn't even shown on that skin. I'd rather see indicator support added to minerva. — xaosflux ^Talk 14:54, 10 July 2025 (UTC)

• Support A tagline seems much more understandable than cryptic and tiny symbols that we use today. If this proposal passes, I would support the removal of original topicons, as they will be made redundant. I don't know how feasible it is, but I would like WMF develop a way to show the taglines in the minerva skin as well. Ca ^{talk to me!} 15:40, 9 July 2025 (UTC)
• Oppose The tagline is there to provide credit to Wikipedia, not provide extra information such as an assessment from a niche rating project that the vast majority of Wikipedia readers and editors don't participate in. I don't think we should be adding overhead to every single page, including non-article pages, just for increasing the visibility of page status. Not to mention that, to those not familiar with our lingo, "A good article from Wikipedia" sounds incredibly hokey, if not conceited.--Ahecht (TALK
  PAGE) 15:53, 9 July 2025 (UTC)

  And what will the readers do with this information? Nothing. Polygnotus (talk) 15:56, 9 July 2025 (UTC)

  They're assured that the article has been reviewed. Aaron Liu (talk) 16:20, 9 July 2025 (UTC)

  A previous version of the article was reviewed. NebY (talk) 16:51, 9 July 2025 (UTC)

  @Aaron Liu That is not how they will interpret that, but even if it was, what will the readers do with this information? Nothing. Polygnotus (talk) 00:08, 10 July 2025 (UTC)

  It's like the opposite of the unofficial secondary purpose of maintenance tags. Aaron Liu (talk) 00:59, 10 July 2025 (UTC)

  @Aaron Liu You lost me. I am assuming the unofficial secondary purpose of maintenance tags is to give the tagger the feeling they did something useful. Polygnotus (talk) 01:03, 10 July 2025 (UTC)

  It's to inform that there is (more likely to be) a problem with an extract from an article. Aaron Liu (talk) 01:07, 10 July 2025 (UTC)

  That sounds like its the official primary purpose. Polygnotus (talk) 02:03, 10 July 2025 (UTC)

  This is a very controversial opinion. The question of whether cleanup templates' visibility to readers is in conflict with the WP:NODISCLAIMERS philosophy has been a battle on here since the beginning. The official primary purpose, a little fiction we tell ourselves to resolve this, is to categorize articles and flag areas for other editors. Dan Leonard (talk • contribs) 02:12, 10 July 2025 (UTC)

  @Dan Leonard to inform that there is (more likely to be) a problem with an extract from an article doesn't specify who gets informed, it might be the readers or editors or both. Polygnotus (talk) 02:26, 10 July 2025 (UTC)

  I'm just explaining Aaron's comment, which I saw as a joke referencing the TfD battles over cleanup templates and the official policy that they aren't for informing readers. Dan Leonard (talk • contribs) 02:31, 10 July 2025 (UTC)

  Ah. Well I am mostly asleep so any jokes will go over my head. Polygnotus (talk) 02:35, 10 July 2025 (UTC)

  I meant "inform readers" lol. Dan is correct in what I'm talking about, but I did have a point with my joke though in that the tagline would have the inverse purpose. Aaron Liu (talk) 17:39, 10 July 2025 (UTC)

  Readers should absolutely be paying attention to an article's assessed GA/FA status. The fact that something underwent (in the case of FAs) a rigorous review process is a key piece of information as a reader decides to what extent to trust an article (and yes, in an ideal world they'd be verifying everything, but in practice doing that rigorously would take nearly as long as writing the article). It's something we pay attention to even when just reading an article we do not intend to edit. And it's therefore something we should make noticeable enough to readers that they can do the name. Sdkb ^talk 23:30, 9 July 2025 (UTC)

  @Sdkb I think one of the major weaknesses and strengths on Wikipedia is that the writers are completely clueless about the readers. should absolutely be paying attention to an article's assessed GA/FA status. No, of course not. It means only that someone jumped through some hoops. a reader decides to what extent to trust an article In my experience, people don't work like that. it's therefore something we should make noticeable enough to readers that they can do the name. Why should we tell a reader information that is not helpful to them and that they do not know how to interpret. Doesn't make sense to me. Polygnotus (talk) 00:13, 10 July 2025 (UTC)

  GA/FA statuses only reflect the quality of an article at the time it was reviewed. Some (most?) of the articles with GA/FA status haven't been reassessed in several years or have undergone so many changes since achieving their status that their current quality differs significantly from when they were first reviewed. J.K. Rowling, a "Featured article" (which apparently means that it's "[one] of the best articles Wikipedia has to offer"), currently has two large templates on the article, one of which indicates that it has neutrality issues. So again, these article ratings are subjective, and readers do not need to be paying attention to them any more than they need to. Some1 (talk) 00:31, 10 July 2025 (UTC)

  You're conveniently omitting that there is currently an effort to delist the Rowling article. Which illustrates exactly how it should be working: Quality articles that no longer meet standards should be reassessed. Sdkb ^talk 02:42, 10 July 2025 (UTC)

  The J.K. Rowling discussion has been opened for almost a month now (and who knows how long it'll take for that discussion to close), and in the meantime, that FA status is there, misleading readers into thinking the article is still "one of Wikipedia's very best works" despite multiple experienced editors arguing that the article should be delisted. Some1 (talk) 03:31, 10 July 2025 (UTC)

  And plenty of others arguing that it should remain listed (and those editors are arguing that the aforementioned maintenance tags were added in an effort to try to get it delisted). I take no position on whether it should or should not remain an FA, but the active discussion around it, as the example you chose, contradicts the notion that FAs are listed and then never looked at/reevaluated again. People who watch them periodically send them to FAR, and WP:URFA/2020 has been going through every single one systemically. Of course, as in most areas of the encyclopedia, we don't have the editor capacity to monitor everything as closely as we wish, but that's no reason to give up on the project or minimize the value it provides to readers — if they know about it. Sdkb ^talk 17:40, 10 July 2025 (UTC)

  Hence the giant neutrality tag on the top of the article. It's just like a "Disputed" inline tag right after a claim, and here the claim is that this is once of Wikipedia's very best works. Aaron Liu (talk) 17:43, 10 July 2025 (UTC)

  As an editor who has provided a very critical review, I’m not concerned about the time the review has been active. It has been Featured for several years in roughly the same state. A month is pretty normal and I expect it’ll be moved to FARC soon (I’m going to post a follow up review tomorrow, which is how the process works). The moment we start speeding up the process of delisting, you will see (for example) large swathes of gender related content beset by meaningless and inaction able critiques to force delistings. WP:There is no rush. — ImaginesTigers (talk) 09:16, 11 July 2025 (UTC)

  All the common slogans of Wikipedia sound incredibly hokey, if not conceited, to those who are opposed to wikis, the free knowledge movement, ... even the tagline itself, what if someone thinks "no such thing as a free lunch!", we have pages explaining free as in libre vs free as in gratis! This is just a walking on eggshells mentality which is not productive. Dege31 (talk) 16:38, 9 July 2025 (UTC)

  If it's for providing credit, it should say "from Wikipedia contributors", given that Wikipedia/WMF don't own the copyright of article content. Dan Leonard (talk • contribs) 16:39, 9 July 2025 (UTC)

  I don't see how either the FA or GA process is niche. If you were talking about WP:ACLASS, then sure, that would be truly niche. But almost 1% of all articles are already either FAs or GAs. As long as it links to the actual WP:FA and WP:GA pages, it isn't any more niche than the topicons already there, which I'd argue are even more cryptic to the casual reader. Epicgenius (talk) 18:16, 9 July 2025 (UTC)

  Less than 1% is pretty niche. How many Wikipedia articles would you have to read to have a 50:50 chance of stumbling on one of the 0.76% that are GA, FA, or FL? NebY (talk) 18:34, 9 July 2025 (UTC)

  But GAs and FAs are some of the most-frequented articles that readers are likely to bump into. They're not randomly distributed. Cremastra (talk) 18:56, 9 July 2025 (UTC)

  From Wikipedia:Popular pages § Top-100 list, quite a few of our most-viewed articles are GA or FA:

Dan Leonard (talk • contribs) 18:58, 9 July 2025 (UTC)

Thanks - more than I was guessing! NebY (talk) 19:01, 9 July 2025 (UTC)

• Support per above; I have an extension installed which does practically the same thing. To partially address the concerns some users have about the taglines being potentially misleading b/c the GA/FA is super old, the extension says Currently undergoing review of its featured status etc when articles get re-reviewed. ❤HistoryTheorist❤ 04:21, 10 July 2025 (UTC)
  • Upon rereading the discussion, perhaps that might be too much for the average Joe, but it was a nice thought while it lasted. ❤HistoryTheorist❤ 04:23, 10 July 2025 (UTC)
• Support It took me ages to find the tagline. I'd never noticed it, but support anything that lets our readers get more of a sense of relative fidelity of Wikipedia articles. A good thing that the GAR process is alive and kicking: we've been able to remove the icon from the 'worst' articles in recent years. —Femke 🐦 (talk) 07:32, 10 July 2025 (UTC)
• Oppose. We should not be misleading readers into thinking that the article rating is objective or meaningful when it is neither. Thryduulf (talk) 08:19, 10 July 2025 (UTC)

  Ouch. Cremastra (talk) 14:48, 10 July 2025 (UTC)

  Are you arguing the average featured article is not better than the average article? Because that's what article ratings having "no meaning" would mean. The reality is the opposite. The average featured article is way way better. IAWW (talk) 15:29, 10 July 2025 (UTC)

  @It is a wonderful world by what objective measure is the comparison being made? What is the definition of an "average article" and an "average featured article"? The median-length featured article is definitely going to be longer than the median-length non-featured article but length alone is not a reliable indicator of anything other than length (e.g. an article that is two thirds reactions from random celebrities on Twitter is worse than an article one third its length that is purely encyclopaedic). Article ratings are meaningless in that they do not reliably convey to the reader any information about the quality of the current state of the article. Even a featured article rating simply says that someone put a lot of effort into satisfying a small number of other people that they put a lot of effort into the article at some point in the past. There is no requirement for writers or reviewers to be subject matter experts so there is no guarantee it is any more or less accurate than any other cited article. Ratings other than featured are worth less than the paper they are written on. Thryduulf (talk) 17:16, 10 July 2025 (UTC)

  If there's a non-featured article whose quality is better than a featured article, that article should be made a featured article. Aaron Liu (talk) 17:45, 10 July 2025 (UTC)

  That assumes that the current version of every featured article is of sufficient standard to be regarded as one of Wikipedia's best, that is simply not true. If you think the effort in getting a rubber stamp of approval from a self-selecting group of non-experts is worth the time it takes, good on you, but that doesn't make the rubber stamp meaningful to readers. Thryduulf (talk) 19:10, 10 July 2025 (UTC)

  If an article does not meet the standards, you can be the one to delist it. The great bulk of articles do not meet Feature quality standards, therefore articles that do are in fact among the best. Aaron Liu (talk) 19:49, 10 July 2025 (UTC)

  It doesn't matter what objective measure you use. Any measure which tries its best to rigorously define the heuristic concept of article quality will show featured articles are better than non-featured articles in 99% of cases. You can see this by picking random featured articles and random non-featured articles – seriously, just go and try it right now! You don't need to rigorously define "average" and "objective measure" or any other words to see this. IAWW (talk) 17:50, 10 July 2025 (UTC)

  Any measure which tries its best to rigorously define the heuristic concept of article quality will show featured articles are better than non-featured articles in 99% of cases. citation needed. Thryduulf (talk) 19:07, 10 July 2025 (UTC)

  The sentence after: "you can see this by picking random featured articles and random non-featured articles" – go try it IAWW (talk) 19:16, 10 July 2025 (UTC)

  Without some measure which tries its best to rigorously define the heuristic concept of article quality I cannot. Thryduulf (talk) 19:17, 10 July 2025 (UTC)

  If there is no objective measure you can think of (though I'm sure there is), your claim would be unfalsifiable. Aaron Liu (talk) 19:34, 10 July 2025 (UTC)

  Eh? I'm not the one claiming that the average featured article is better than the average article (that's @It is a wonderful world's claim). Thryduulf (talk) 19:44, 10 July 2025 (UTC)

  https://doi.org/10.1609/icwsm.v3i1.13959 empirically derived features of FAs from FAC discussions, and for two articles I've tried it seems to work. Regardless, Wond's claim did not say the measures have to be objective; that's what you introduced. To see whether an article has better quality, we only need to agree in our judgement, no matter whether it is based on subjective criteria or objective criteria. Aaron Liu (talk) 19:53, 10 July 2025 (UTC)

  Reading the abstract of that 2009 study (I don't have time to read more), it seems to only show that articles that were awarded featured status reliably contained the features the FAC process looked for - which is unsurprising, not really relevant to this discussion, says nothing about whether those features do indicate quality (if the featured article criteria required every featured article to contain a sentence about the colour red and every featured article did contain such a sentence, that would indicate that the FAC process is following its own rules, but wouldn't say anything about the article quality) and may or may not still hold true nearly 15 years later.

  To see whether an article has better quality, we only need to agree in our judgement, no matter whether it is based on subjective criteria or objective criteria. true, but no criteria (objective or subjective) were specified let alone agreed - I asked what objective criteria were being used to back up the claim (and still haven't got an answer) because while we could agree to use subjective criteria to verify the claim I do not agree that such would be both relevant and meaningful. Also, it's worth pointing out that putting the article status in the tag line is not agreeing anything with anybody, or telling anybody anything about the average Wikipedia article. It is claiming that this version of this article is an example of Wikipedia's best work. That is not reliably true. Thryduulf (talk) 20:47, 10 July 2025 (UTC)

  Fair point. I still maintain that you should use whatever subjective criteria you should stand behind, but ORES scores also show quality. I strongly disagree that subjective criteria are meaningless. I'm sure we all know the meaning in having "good" article quality, and that is of course subjective. It is meaningless to ask for objective assessments of something being better if we can agree using other criteria that something is better much faster, especially when the selection of such "objective" criteria is, in itself, subjective. All I'm saying is the near-tautology of subjective assessments being able to produce the subjective assessment of "good quality", while you're saying that only objective assessments will suffice, an unfalsifiable claim if you cannot provide an objective measure.
  The topic of "this version" is being discussed elsewhere in this RfC. Aaron Liu (talk) 21:33, 10 July 2025 (UTC)

  I'm sympathetic to your main argument, that labeling articles at some point in time is incompatible with the wiki model. But I think your comments rubber stamp of approval from a self-selecting group of non-experts, even GA only requires that citations exist, an article that is two thirds reactions from random celebrities on Twitter is worse than an article one third its length that is purely encyclopaedic, and ratings other than featured are worth less than the paper they are written on are very dismissive of the work content reviewers do and I don't think you should be surprised you're getting piled on here over them. Dan Leonard (talk • contribs) 19:54, 10 July 2025 (UTC)

  What pile on? It's about even in terms of people who (broadly) agree with me and people who (broadly) disagree. The final statement you quote from me is entirely a matter of opinion, we can agree to disagree regarding that. The quote about reactions relates only to article length not being a reliable metric of quality, I don't understand why you think that is dismissive of the work of content reviewers unless they do regard length as a reliable indicator of article quality? (If they do, that's definitely a black mark for the process).

  The first two are factual statements. Thryduulf (talk) 20:32, 10 July 2025 (UTC)

  By calling the result a "rubber stamp", the first one is an opinion. For the claim to be factual, you would need to show FAC does not disagree with its insiders, which is verily false. Aaron Liu (talk) 21:34, 10 July 2025 (UTC)

  I'm really disheartened by the comments decrying the content review process here. IAWW's review of an article I wrote was one of the most enjoyable editing experiences I've had on here, and it was very comprehensive and involved a text-source integrity check. Reducing his work to a rubber-stamp without citation checks is insulting. Dan Leonard (talk • contribs) 20:30, 11 July 2025 (UTC)

  There are GA reviews like that, but there are also GA reviews like Talk:I-No/GA1. As Stepwise stated below, promoting articles to GA status only requires one person's approval. Some1 (talk) 20:40, 11 July 2025 (UTC)

  Is there a problem with the subject article that makes you think the review was conducted improperly? It obviously has fewer BLP and political considerations than the one I cited so the prose does not need to be checked as closely. Regardless, it still gets a topicon with a "this is a good article" tooltip so I don't see why the modified tagline would be so extreme an addition. Dan Leonard (talk • contribs) 20:51, 11 July 2025 (UTC)

  This is a little off topic, but @Some1, what makes you think that review you linked was not conducted properly? IAWW (talk) 22:47, 11 July 2025 (UTC)

  I don't believe the review was conducted "improperly", but find the differences in the lengths and comprehensiveness of the two GA reviews quite jarring. Some1 (talk) 23:21, 11 July 2025 (UTC)

  The first two are factual statements Ha ha. No they aren't. I'm not sure why you're taking this opportunity to complain about editors who want quality articles, but your second statements is clearly false. Perhaps you should look at the GA criteria, which are loose but set a baseline of acceptable quality content, before making clearly and egregiously incorrect statements, which at this point is approaching disinformation. Cremastra (talk) 01:22, 11 July 2025 (UTC)

  Discussion elsewhere has identified that the GA criteria I was reading and the GA criteria that are actually applied are different, so while I thought that was factual it turns out that it wasn't. The first is though.

  I'm not complaining about editors wanting quality content - far from it - what I'm saying is that article rating labels are not a reliable guide to the quality of the current version of an article. I'm also saying that the FA and GA criteria used to award those labels are not a guarantee that the version of the article reviewed is one of Wikipedia's best, just that it meets those criteria. If you think that is an attack on editors then you haven't been reading what I've actually written. Thryduulf (talk) 01:35, 11 July 2025 (UTC)

  I mean, the GA criteria excerpts the part from the "how the GA criteria should be applied" guideline on spot checks being minimum, so you could say it is in the GA criteria you were reading. That is an interesting state of affairs indeed. Aaron Liu (talk) 15:01, 11 July 2025 (UTC)

  If the GA criteria as written differ from the GA criteria as applied in practice, then we definitely shouldn't be proclaiming GA status in the tagline. Overloading the ordinary word "good" with an insider meaning is confusing enough. Expecting that people will read a set of criteria and then a further guideline to figure out what "good" is supposed to mean is... not really practical. Stepwise Continuous Dysfunction (talk) 18:41, 11 July 2025 (UTC)

  Again, the relevant part of that guideline is quoted in the set of criteria. Aaron Liu (talk) 19:07, 11 July 2025 (UTC)

  Maybe you know that that's the only relevant part of that guideline. Maybe someone would figure that out after reading both. But it's not at all clear. Every time a reader has to investigate a behind-the-scenes Wikipedia page to understand what something means, we've failed. Stepwise Continuous Dysfunction (talk) 19:52, 11 July 2025 (UTC)

  We have explanatory essays that go in depth on the specific meanings of everything. That does not undermine the meaning of what is explained at all. The criteria by itself sufficiently explain what is expected of GoodArticles. Aaron Liu (talk) 20:00, 11 July 2025 (UTC)

  They don't differ, criteria 2 definitely requires sources verify the text. I don't follow the claim that there's a discrepancy here. Dan Leonard (talk • contribs) 20:08, 11 July 2025 (UTC)

  That's a pretty serious claim you're making. Do you have any objective evidence that the process is this fundamentally useless? None of the criteria for good and featured articles, after all, are not length, so if they don't measure anything else, that's pretty serious. You think the process is so bad that even checking the sources doesn't increase the average accuracy, that it's just a rubber stamp? This all sounds pretty unbelievable to me, but maybe I'm wrong. If this is all true, why do you think the average participant of this RfC is ignorant of it? Dege31 (talk) 17:57, 10 July 2025 (UTC)

  I do not have evidence for a claim I am not making. Checking the cited sources do verify the content they claim to verify is extremely valuable but only a small part of what is required to get the FA badge, not required for any other rating (even GA only requires that citations exist) [see later discussion, it turns out the documented GA criteria I based that comment on do not match the GA criteria that are actually applied. Thryduulf (talk) 01:42, 11 July 2025 (UTC)], and something that can be done completely independently of the FA process. My claim is that FA status does not reliably communicate anything useful to readers about the current version of the article. The current version of the article might be better than average, even one of Wikipedia's best, but it might even be below average now. Thryduulf (talk) 19:16, 10 July 2025 (UTC)

  That's no longer true. Funnily, the new GA checks are in some sense more strict that the FA criteria on WP:TSI. All GANs require spot checks (since 2023 or so), whereas only newer FA nominators have their articles spot checked. —Femke 🐦 (talk) 20:27, 10 July 2025 (UTC)

  That's not what is written at WP:GACR6. Thryduulf (talk) 20:56, 10 July 2025 (UTC)

  Well in practice, spot checks are expected. See the guideline Wikipedia:Reviewing good articles#Assessing the article and providing a review. Aaron Liu (talk) 21:04, 10 July 2025 (UTC)

  I'm sure the GA criteria used to include that a spot check was required. Did this get removed? IAWW (talk) 21:06, 10 July 2025 (UTC)

  That's good to know, but if we can't even reliably communicate what the GA criteria actually are to editors who know that "good article" is jargon then it is even less useful information for readers than I previously thought it was. Thryduulf (talk) 21:16, 10 July 2025 (UTC)

  The proposed destination for the modified tagline is Wikipedia:Good articles, which states (emphasis mine)

  A good article (GA) is a Wikipedia article that meets a core set of editorial standards, the good article criteria, passing through the good article nomination process successfully. They are well-written, contain factually accurate and verifiable information, are broad in coverage, neutral in point of view, stable, and illustrated, where possible, by relevant images with suitable copyright licenses.

  Also, I think you may have missed footnote 3 in WP:GACR6, which states "at a minimum, check that the sources used are reliable ... and that those you can access support the content of the article". I think these adequately explain to readers that a good article has had its sources checked for verifiability. Dan Leonard (talk • contribs) 21:23, 10 July 2025 (UTC)

  Right, I see what you mean now. I understand the concern, but personally, with the (re)activation of the good & featured article review process, I don't personally think it's as critical. Would you also support removing the good article and featured article topicons, by the same logic? Dege31 (talk) 23:03, 10 July 2025 (UTC)

  It's not something that bothers me enough to propose myself, especially as some people seem rather attached to them, but I would probably support if someone else were to propose it. Thryduulf (talk) 23:08, 10 July 2025 (UTC)

  @Thryduulf: even GA only requires that citations exist please strike this factually incorrect statement. Cremastra (talk) 01:23, 11 July 2025 (UTC)

  I've struck with a note as it's slightly more complicated than simply being incorrect, see discussion subsquent to my comment about why I made that statement. Thryduulf (talk) 01:42, 11 July 2025 (UTC)

  Thank you. Cremastra (talk) 01:57, 11 July 2025 (UTC)

  There is no requirement for writers or reviewers to be subject matter experts so there is no guarantee it is any more or less accurate than any other cited article. Yes, exactly. Schizophrenia is a Featured Article with almost 4k edits since its FA review back on May 2, 2011 (14 years ago). Who knows if that article is still accurate or up-to-date, but because of its FA status, readers will blindly trust that the article and its content are accurate. Some1 (talk) 18:39, 11 July 2025 (UTC)

  I mean WP:MEDRS the policy is pretty good at tackling that exact problem^{Superscript text} Aaron Liu (talk) 19:08, 11 July 2025 (UTC)

Oppose Per Thryduulf - GA particularly has little to do with quality and is more of an Wikipedia:Esperanza-like process to promote the participants. The GA talkpage currently has an RFC to enforce Quid pro Quo reviewing of articles and to reduce the standard of reviews. GA reviews are in many cases completely subjective and amount to little more than "I like this" or "I don't like this".Nigel Ish (talk) 17:23, 10 July 2025 (UTC)

It is a bit subjective, yes, but there are detailed criteria on how articles should be evaluated for GA. GAs that don't meet the criteria go through GAR. The linked "reduce the standard of reviews" discussion is not about reducing the standard of reviews but about reviewers who make additional comments beyond the standard of the reviews. And the quid prop quo proposal RfC is currently met with a swarm of opposition. Aaron Liu (talk) 17:48, 10 July 2025 (UTC)

At this point this discussion discussion has devolved into GA-bashing by people who apparently don't want any kind of quality control and for who any recognition of hard work is evidence of a social clique. Cremastra (talk) 01:18, 11 July 2025 (UTC)

This user specifically seems to have an axe to grind against the GA process: see their userpage. Cremastra (talk) 05:18, 11 July 2025 (UTC)

As a post I made is linked here, I feel obligated to comment that this is a misrepresentation of what I said. Thebiguglyalien (talk) 🛸 03:42, 11 July 2025 (UTC)

I don't think I'd ever noticed the tagline before, but I've definitely seen the topicons. The fact that they're coloured images makes them more noticeable than small italics, but having linked text in the tagline would probably cover some of that deficit. Maybe I've overestimating the readers, but because "good article" doesn't have a standard colloquial meaning, I think that if a reader did notice that the tagline said that, there wouldn't be any standard meaning to assume. If they wanted to know what it meant, they might click the link and learn more about the internal processes of the encyclopedia. If they didn't, they wouldn't walk away with any wrong assumptions. "Featured article" is a little different - assumptions could be made - but the meaning could vary wildly. Maybe this so-called "featured" article was chosen at random somehow to feature on the main page at some point in the past. I think the topicons make the meaning clearer, appearing to be badges the article has achieved somehow, but I don't think the additional text in the tagline would harm the project (outside of potential technical burden). 207.11.240.2 (talk) 08:59, 10 July 2025 (UTC)

• Oppose - because as written, the tagline is misleading. For instance, the first example listed: London Beer Flood. When you go to the talk page, it is clearly tagged as: London Beer Flood is a featured article; it (or a previous version of it) has been identified as one of the best articles produced by the Wikipedia community. So it is misleading to imply to our readers that the current version they are reading is the FA version. Isaidnoway (talk) 18:28, 10 July 2025 (UTC)

  I think that'd be a good thing. If an article's current state is incongruent with what one expects from being "one of the best articles", readers would be alerted to raise the issues somewhere. This can help ensure quality within FAs. Also, <pedantic>, the banner you quoted says the article or a previous version met the definition, and that the article is a featured article, not that it might be a previous version that is the featured article instead of the current version. Aaron Liu (talk) 20:00, 10 July 2025 (UTC)

  No, what it means is that the FA article could be the current form or an earlier, possibly different, iteration of the article could be the FA. For instance, Michael Jackson was promoted to FA status 17 years ago, and on July 8, 2025, there was a brief edit war over a cleanup tag placed in a section. The article had 16,000+ pageviews that day, so how many readers (hundreds, thousands) read a version (current version) that didn't meet the criteria for a FA, and we shouldn't expect for our readers to try and hunt for a previous version that actually meets the FA criteria. I mean, if we are going to say to our readers with a tagline - the current version you are reading meets the criteria for a FA, but yet editors are squabbling over content that may not reflect what the cited sources actually say, then yeah, go ahead with a misleading tagline. Isaidnoway (talk) 23:54, 10 July 2025 (UTC)

  The article was still designated FA. The definition of FA is that the article or a previous version was reviewed and met criteria, not necessarily the current version even if the FA-designation is the status quo. I'm not saying we should expect our readers to hunt for that previous version; I'm saying that increasing this prominence invites readers who realize the incongruence to challenge. I don't see how the cleanup tag changes anything in your argument's favor here. Aaron Liu (talk) 00:47, 11 July 2025 (UTC)

  invites readers who realize the incongruence to challenge the vast majority of readers will not recognise the incongruence, but will blindly trust that an article that proclaims to be top quality is top quality, even if it contains blatant misinformation. Even editors with years of experience working with featured articles will not always see an incongruence for topics (or even topic areas) they are not familiar with. Thryduulf (talk) 00:55, 11 July 2025 (UTC)

  Not if there's a giant orange banner. Aaron Liu (talk) 00:56, 11 July 2025 (UTC)

  The article had 16,000+ pageviews that day, so how many readers (hundreds, thousands) read a version (current version) that didn't meet the criteria for a FA - Kind of beside the point, but an article doesn't automatically change from "FA quality" to "not FA quality" just because there's a tag (and similarly for GA). Instead it's usually one of two situations:

  1. The tag was justified, and therefore the article was already not up to FA/GA standard beforehand. It can be resolved, or the article brought to WP:FAR/WP:GAR if issues are pervasive enough.
  2. The tag was not justified, nd therefore it changes nothing about the article's rating.

  Though, I can't argue with the fact that the current version of an article that previously passed an FAC or a GAN may not necessarily be up to standard. That's why substandard articles are (and should be) listed at FAR or GAR. Epicgenius (talk) 03:43, 11 July 2025 (UTC)

  On MJ's article, if you or I ran across the maintenance tag, sure, we would know it could be either one of the two situations you listed, but would our readers? If this prominent tagline had been in place on MJ, bragging about this is one of our very best articles, and a reader scrolls down to a section that is tagged with - the content you are about to read may not reflect what the cited sources actually say, they are going to walk away scratching their heads, thinking, this is their very best? Of course, this situation would hold true with the FA icon already present, but I just don't see how adding this prominent tagline (more bragging) is a benefit to our readers, when it has the potential to be misleading. It's bad enough these unnecessary icons are already on the page. Isaidnoway (talk) 06:50, 11 July 2025 (UTC)

• Oppose, per a combination of Ahecht's arguments (scope creep: rating is not what the tagline is for; and "a good article from Wikipedia" sounds bizarre for everybody not familiar with the technical meaning) and Thryduulf's (rating status is far too unreliable for such a highlighting to be responsible). I may add that both arguments apply particularly strongly to "good articles", for which I would oppose this proposal very strongly. Fut.Perf. ☼ 19:20, 10 July 2025 (UTC)
• Oppose per Future Perfect at Sunrise. —Compassionate727 ^(T·C) 23:31, 10 July 2025 (UTC)
• Support - clearly sensible, not least as readers on mobiles do not get to see the FA or GA icons. Whatever the merits or demerits of the GAN and FAC procedures, these articles do have a defined level of quality and it's helpful for readers to know that. Chiswick Chap (talk) 08:56, 11 July 2025 (UTC)

  Did you see above how readers on mobile also do not get to see the 'tagline'? — xaosflux ^Talk 09:25, 11 July 2025 (UTC)

  these articles do have a defined level of quality. No they don't. A previous version of the article was assess as having a defined level of quality, but there is no guarantee that the version of the article the tagline is displayed on bears any resemblance to that version. Thryduulf (talk) 09:53, 11 July 2025 (UTC)

  This is just one of the things where Wikipedia works better in practice than in theory. "There is no guarantee that any of this is true" is correct for all of Wikipedia, yet it is highly trusted and extremely widely used. —Kusma (talk) 10:11, 11 July 2025 (UTC)

  Indeed, but that's completely different to a prominent banner saying "this is our best work" with links saying that our best work has been verified etc, being placed on articles that are anything but our best work. While many people seeing a page that has been very obviously vandalised will realise that it has been vandalised, not everybody will and the more subtle the vandalism (or POV pushing, etc) the fewer people will know not to take the statement at face value. Doubly so if the article's POV has been slanted towards a POV the reader happens to share. Thryduulf (talk) 10:26, 11 July 2025 (UTC)

  Thryduulf, I think you overestimate the amount of change that quality articles, especially FAs, see after their review. Ovalipes catharus has some small additions of references and phrasing tweaks ([12]) since it was promoted in January. Malicious edits would be reverted, which leaves potentially problematic edits down to POV-pushing, addition of inaccurate information, and bad writing. These would probably all be caught by the person who brought it to FA in the first place. Cremastra (talk) 15:00, 11 July 2025 (UTC)

  All those mallicious edits, etc were current revisions before reversion. The person who brought it to FA is not watching it 24/7. Also, changes accumulate over time God of War III was promoted to FA in February 2015, it has since undergone significant changes. Is it still FA quality? I have absolutely no idea. Do I trust a 10-year-old rating? if yes, then it's misleading if I happen to have viewed it one of the many reverted revisions was current. If no, then it's pointless. Thryduulf (talk) 15:48, 11 July 2025 (UTC)

  GAs can see many changes: Western Roman Empire 527 intermediate revisions by more than 100 users so far[13]; Catilinarian conspiracy 68 by 39[14]; Biblical Hebrew 791 by more than 100[15]. FAs too: Ethiopian historiography 192 by >100[16]; Eagle (British comics) 323 by >100[17]; John Lennon >3000 since being TFA on 8 Dec 2010[18] (apologies if I've missed any intervening reviews). NebY (talk) 15:50, 11 July 2025 (UTC)

  Taylor Swift has almost 10,000 intermediate revisions since its promotion to FA status back on October 31, 2016 (9 years ago), and there are complaints on the article's talk page that the article is a mess, outdated, and "completely bloated." Some1 (talk) 18:55, 11 July 2025 (UTC)

  Well, yeah, these intervening 9 years count for almost half of Taylor Swift's career. I wouldn't expect any article, let alone Swift's article, to remain unchanged in that time period.

  As for the article being bloated and outdated, that is less relevant to the topic currently at hand (mentioning FA status in the tagline) and more like a WP:FAR issue. – Epicgenius (talk) 19:58, 11 July 2025 (UTC)

  The fact that there are complaints about the featured article(s) just illustrates that these article ratings are subjective, provide little meaningful information to readers, and don't need to be given more prominence (and in this case, by modifying taglines, of all things). Some1 (talk) 20:17, 11 July 2025 (UTC)

  I don't see how. It simply makes them wiki articles just as mistakes make us human. Aaron Liu (talk) 21:47, 11 July 2025 (UTC)

  these article ratings are subjective,
  There are literally objective criteria (WP:GACR, WP:FACR) that are used to evaluate articles for GA or FA status. So no, it isn't a subjective rating.

  The fact that there are complaints about the article just mean that people have opinions. These may indicate that the article doesn't meet the criteria. They may also be unjustified, however, as Dan Leonard indicates below. – Epicgenius (talk) 21:51, 11 July 2025 (UTC)

  That recent complaint from an unregistered editor is plainly false (the masters buyback is covered in the lead with a link to Taylor Swift masters dispute and extensively in § 2018–2021: Lover, Folklore, and Evermore). I get that FAs sometimes get delisted but choosing one with a drive-by nonsense complaint isn't a very good argument. Dan Leonard (talk • contribs) 20:22, 11 July 2025 (UTC)

  I think it's fallacious to imply that just because an article has reached GA or FA status, it shouldn't undergo changes. It's one thing for an article to be modified significantly after its promotion to FA or GA status. Sometimes, this is even required in order for an article to keep its rating, especially for articles about people who are alive or things that still exist.

  It's another thing entirely for these changes to have significantly degraded the quality of the article, but even a small number of changes by a small number of editors can degrade an article's quality. In short, quantity of changes != quality of changes. – Epicgenius (talk) 16:27, 11 July 2025 (UTC)

  Whatever fallaciousness you might infer, I was not implying that just because an article has reached GA or FA status, it shouldn't undergo changes. I was responding to I think you overestimate the amount of change, began by saying many changes, and didn't discuss their quality or materiality. NebY (talk) 16:50, 11 July 2025 (UTC)

  Whatever fallaciousness you might infer, I was not implying that just because an article has reached GA or FA status, it shouldn't undergo changes.
  If I was mis-attributing that to you, then I apologize. I was speaking primarily in the context of Thryduulf's comment; they claimed that there is no guarantee that the version of the article the tagline is displayed on bears any resemblance to that version. Which may very well be true, but that comment also implied that articles have to remain more-or-less static after their promotion, which is not the case.

  I was replying to your comment about the number of changes to selected GAs/FAs because I was trying to convey the fact that a large number of changes may not necessarily be an indicator of an article's decline in quality. It can be an indication of such a deterioration of quality, but this can also be done by one or few editors who remove large parts of an article. – Epicgenius (talk) 17:19, 11 July 2025 (UTC)

  I wasn't saying that articles have to remain more-or-less static after promotion, and I'm not sure how you read that into my comment. I'm simply saying that because articles are not static, a previous version being assigned a quality rating is not a reliable indicator of the current quality of the article. It might be that there have been a thousand changes but no material change, it could be that there have been ten changes and the article is substantially different (which could mean it is worse, better or about the same quality). It is this changing nature that means the assessments are not a reliable indicator of the quality of the version displayed, so we should not be proclaiming that something is an example of our best work when we have absolutely no idea whether it is or isn't. Thryduulf (talk) 17:50, 11 July 2025 (UTC)

• Support mildly increasing the visibility of our assessment processes. We should also strengthen GAR and FAR to ensure the designations remain meaningful. —Kusma (talk) 10:18, 11 July 2025 (UTC)

  This seems to put the cart before the horse. Shouldn't we ensure that the designations mean something before we increase their visibility? Stepwise Continuous Dysfunction (talk) 18:46, 11 July 2025 (UTC)

  I think they are meaningful. I am using the opportunity to assert that FAR and GAR are important in ensuring that the designations are meaningful. We do not have to improve all processes to perfection before considering something like the present proposal. —Kusma (talk) 19:37, 11 July 2025 (UTC)

  @Stepwise Continuous Dysfunction The designations do mean something and always have. Cremastra (talk) 20:56, 11 July 2025 (UTC)

• Oppose on the grounds that we shouldn't be shoving words that have specialized Wikipedian meanings in front of every reader. "Good" is a particularly bad word to use in this way. Stepwise Continuous Dysfunction (talk) 17:19, 11 July 2025 (UTC)

  Not only is the term "good article" overloading the ordinary word "good", but also, getting that status for an article really only requires the approval of one person. We shouldn't make that look more official than it is.

  I do not think this was intentional, but this proposal amounts to gratifying long-term editors at the cost of confusing readers. Stepwise Continuous Dysfunction (talk) 18:33, 11 July 2025 (UTC)

  It also requires the article surviving challenges to the good article status and the reviewer being in good standing.

  Why not give it a try and see if readers are confused? A lot of people here doubt they will be. Aaron Liu (talk) 19:09, 11 July 2025 (UTC)

  A similar number of people have made very strong arguments that readers will be confused and/or actively mislead. Why should we dismiss those concerns just because some experienced editors with detailed knowledge of the procedures vaugely hope that readers will understand that when shove jargon in their face they will understand both what it means and also that it might not actually mean that? Thryduulf (talk) 19:47, 11 July 2025 (UTC)

  Nobody is claiming readers will know right away what these terms mean, the idea is that they'll be clearer than the status quo of topicons. Czar's story in § Proposal 21: Make GA status more prominent in mainspace shows that readers currently don't understand what these icons mean and actually have serious misunderstandings. A plain-text phrase "good article" or "featured article", with a clear link to these meanings, will hopefully both alleviate confusion and onboard future contributors. Dan Leonard (talk • contribs) 20:14, 11 July 2025 (UTC)

  One reviewer "in good standing" is still just one reviewer. And "good standing" is one more thing that is not explained either at the criteria page, the instructions page, or the guideline (which is a different page than the instructions). Stepwise Continuous Dysfunction (talk) 19:59, 11 July 2025 (UTC)

  It's not a defined thing but empirical, basically the chances of such reviews ending up at GAR. It's not a real thing besides just having reviews that fit the criteria. Aaron Liu (talk) 20:04, 11 July 2025 (UTC)

  "Good" is a pretty good description, better than "featured" but I think the link will be enough for people to cope. —Kusma (talk) 19:39, 11 July 2025 (UTC)

  If "Good article" actually meant something similar to the non-jargon meaning of "this article is good" then you might have a point. So while I applaud your optimism the evidence of how readers currently interact with Wikipedia suggest to me that it is significantly misplaced. Thryduulf (talk) 19:50, 11 July 2025 (UTC)

  Many here that !voted support believe that good articles are good. Aaron Liu (talk) 20:05, 11 July 2025 (UTC)

  That established Wikipedians can have a good faith disagreement about what the phrase "Good article" means is more than enough evidence that it will mislead some readers. Thryduulf (talk) 22:22, 11 July 2025 (UTC)

  Is there a GoodArticle you think is not good? If so, you should nominate that article for Review after starting a discussion about it, no matter how much the article has changed since it was reviewed. By something approaching induction GoodArticles are therefore good articles. I think the only situation where the GoodArticle process fails to produce good articles is if you believe the criteria are not enough to ensure "good", in which case I'd like to know. Aaron Liu (talk) 22:31, 11 July 2025 (UTC)

  My point is that in Wikipedia jargon "Good article" means that a specific revision of an article was judged by one person to meet a set of very specific criteria (that the current version of the article may or may not now meet). To most readers seeing a tagline saying "good article" would indicate that the version of the article has been assessed to be "good" and thus can be relied upon to be neutral, accurate, and at least reasonably comprehensive and thus by implication articles that are not "good" are "bad" and cannot be said to be poses any of those qualities. While it is true that the current version of many Good Articles is indeed good there are also current versions of Good Articles that are not good. There are also plenty of articles where the current version is accurate, neutral and comprehensive but which are not Good Articles simply because nobody has formally assessed it. Thryduulf (talk) 22:45, 11 July 2025 (UTC)

  I think we're going round in circles at this point. I made a similar reply at #c-Aaron_Liu-20250711004700-Isaidnoway-20250710235400.

  there are also current versions of Good Articles that are not good

  (besides what I say in the linked reply) Those are also very few.

  by implication articles that are not "good" are "bad"

  I don't think that's true. The rest are just unreviewed articles, and even not meeting the standard for good doesn't necessarily mean bad. I think this also addresses your last point. Aaron Liu (talk) 01:48, 12 July 2025 (UTC)

  As an editor familiar with the review process you know that "not good" doesn't mean "bad". The same is not true of the average reader who does not know that "Good article" is jargon, let alone what it means.

  Re current versions of Good Articles. If you mean stable versions then there probably are relatively few (but still a large number), however when you include every version that is current at some point it is much larger. There is no way for the casual reader to know whether the version they are seeing is the good version or the vandalised version. Thryduulf (talk) 02:41, 12 July 2025 (UTC)

  Sorry, I meant that I doubt that's what readers'll interpret it is. WIthout "good" it's still "articles".
  I mean at any moment. I don't think aggregating anyone that had any version that was bad is meaningful. And it's not like RC patrol's gone handicapped. Aaron Liu (talk) 02:47, 12 July 2025 (UTC)

  It does mean something similar, and I am indeed optimistic that our readers know that blue text means a link that can be clicked on to obtain clarification. Most of our readers are not using Wikipedia or the WWW for the first time. —Kusma (talk) 23:11, 11 July 2025 (UTC)

  I'd argue that "featured" is a less confusing term than "good" in this context, since it's less generic and actually conveys the connotation that the articles were selected via some process. Stepwise Continuous Dysfunction (talk) 19:55, 11 July 2025 (UTC)

• Support a simple change to address a problem that has come up frequently. Phlsph7 (talk) 09:09, 12 July 2025 (UTC)

  What problem? Thryduulf (talk) 10:46, 12 July 2025 (UTC)

  Visibility of page status as addressed in the discussions listed at Wikipedia:Village_pump_(proposals)#Background_(tagline). Phlsph7 (talk) 13:36, 12 July 2025 (UTC)

  The proposal has indeed come up frequently. Some editors see increased visibility of article ratings as an improvement to the status quo, but if there is a problem with the status quo it is that it overstates the reliability and importance of article ratings, which is not something making them more prominent can solve (indeed rather the opposite). Thryduulf (talk) 17:26, 12 July 2025 (UTC)

• Support as I like the idea of better signaling which of our articles have met a minimum bar for quality. GAs aren't perfect articles, but we show worse articles on the main page every day. Ed ^{[talk] [OMT]} 20:03, 12 July 2025 (UTC)
• Oppose Unnecessary embellishment Logoshimpo (talk) 04:05, 13 July 2025 (UTC)

  An embellishment is defined as ornamental, or decorative detail, to make something more attractive. Is it to your belief that the good article, and featured article processes are likewise embellishments? Dege31 (talk) 01:54, 17 July 2025 (UTC)

  Yes Logoshimpo (talk) 05:07, 17 July 2025 (UTC)

• Oppose unnecessary and potentially misleading use of wikipedia jargon.--Staberinde (talk) 09:31, 15 July 2025 (UTC)

  Could you clarify what you mean by 'unnecessary'? Dege31 (talk) 01:52, 17 July 2025 (UTC)

  There is no noteworthy problem that requires fixing here.--Staberinde (talk) 20:10, 17 July 2025 (UTC)

• Support – for the same reasons I proposed more prominent topicons in 2021. As Wikipedia matures, I think it's increasingly important we 1) focus on raising the quality of existing content and 2) help readers learn how to effectively use and understand the varying quality of articles, especially in the current information landscape. Drawing attention to the main ways we review articles, however flawed they are, is a step in the right direction for both these aims, and by raising awareness of peer review processes it might help improve them. I think it would be even better if the "featured article" or "good article" text linked directly to the article's most recent FAC/FAR/GAN, but perhaps that wouldn't be feasible. I understand the valid concerns about the varying quality of FA/GA status articles, but ultimately it is better than no review at all, I trust that most readers understand Wikipedia is not infallible, and the more we focus on peer reviews the better for raising quality and trust in the project. Jr8825 • Talk 12:26, 15 July 2025 (UTC)
• Support ways to make GA/FA status more prominently visible, including this proposal. My preferred way of going about it would be to have the icon next to the article title, kind of like how (on desktop) the icon is displayed next to the name of another language in the "Languages" list if that version of the article is good or featured (see e.g. Jupiter). Several of the opposing comments sound more to me like arguments to abolish GA/FA (or at minimum the icons) entirely, which I am fairly certain is a proposition that would be overwhelmingly rejected by the community. TompaDompa (talk) 23:35, 16 July 2025 (UTC)

  To your point about opposing comments, I agree. Some of the oppose !votes bring up valid concerns, like Future Perfect at Sunrise's and Isaidnoway's comments that this tagline might not be appropriate for articles that actually need GAR or FAR. However, comments like "GA particularly has little to do with quality and is more of an Wikipedia:Esperanza-like process to promote the participants." and "Yes" (in response to a query about whether the respondent considered the GA/FA processes mere "embellishment") do seem to be rooted in opposition to the GA or FA processes, not to this specific proposal. – Epicgenius (talk) 01:54, 18 July 2025 (UTC)

• Oppose, per several of the arguments made above. If this is intended to bring in more editor participants, we're sending a confusing signal to a group very few of whom are the right target. The terms are opaque and likely to be misleading to our readers, since there are plenty of GAs that are no longer good quality but have not been reassessed yet. Fewer FAs are in that state, but there are some. If the GAR and FAR processes were working as well as we'd like, this would be less of an issue, but we haven't solved that problem yet. Future Perfect at Sunrise puts the case against well. Mike Christie (talk - contribs - library) 00:20, 17 July 2025 (UTC)
• Support trying this out, at least for some period. "The free encyclopedia" will remain on the logo, and the fact that "everyone can edit" is the most well known fact about the website. I believe Wikipedia should try to make GAs/FAs more visible to the common reader, and I think more awareness may also lead to more GAR and FAR helpers. ALittleClass (talk) 02:38, 18 July 2025 (UTC)

Discussion (tagline)

@Dan Leonard: Can we not also have FLC, FAC, GAN? like so...

{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}
 | FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
 | FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
 | GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
 | FAC = A ''[[Wikipedia:Featured article candidates/PAGENAME/archive#|featured article candidate]]'' from
 | FLC = A ''[[Wikipedia:Featured list candidates/PAGENAME/archive#|featured list candidate]]'' from
 | GAN = A ''[[Talk:PAGENAME/GA#|good article nominee]]'' from
 | From
}} Wikipedia, the free encyclopedia

OR, if getting the archive# and GA# might be tedious, we could simply say... Can we not also have FLC, FAC, GAN? like so...

{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}
 | FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
 | FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
 | GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
 | FAC = A ''[[Wikipedia:Featured article candidates|featured article candidate]]'' from
 | FLC = A ''[[Wikipedia:Featured list candidates|featured list candidate]]'' from
 | GAN = A ''[[Wikipedia:Good article nominations|good article nominee]]'' from
 | From
}} Wikipedia, the free encyclopedia

--Vanderwaalforces (talk) 15:42, 11 July 2025 (UTC)

I don't see the point in reader-facing indicators of article nominations. Best to be left for the talk page. Dege31 (talk) 16:10, 11 July 2025 (UTC)

This RFC proposal is intentionally limited to be an extension to the topicons, which already get enough community support to exist. I disagree with this idea (drive-by junk GANs shouldn't be shown to readers) but also just don't think we should overcomplicate the proposal by going beyond what is already represented by topicons. Dan Leonard (talk • contribs) 16:30, 11 July 2025 (UTC)

@Dan Leonard that makes sense. Vanderwaalforces (talk) 19:14, 11 July 2025 (UTC)

Personally, I would better understand those on the oppose side for non-technical reasons, if they could bring in some real data, or real examples, of harm caused by the smaller outreach variants already extant: that is, the topicons, and the talk page assessments. After all, if it is problematic, there should already be evidence. I haven't seen this presented in significant levels. To me, these pitfalls feel remote, and rare. I feel like the potential downsides aren't so big that we can't even do a test run to see how it goes. The large majority of readers read within the confines of the lead paragraphs, so that lessens the potential cumulative impact, too.

Nonetheless, valid concerns. The supporters should also answer: is there will, and capability for scaling up the maintenance of these articles? While this has been ramping up in recent years, this imposes a higher standard.

I've also thought about an idea (this is not a proposal, but fuel for separate discussions, if I, or anyone else, wants to take it further) that maybe takes into account some of the reluctance. It would involve an article losing its reader-facing indicators of GA status or FA status after X years of no review, or Y edits if it's very high activity. That way, there would be a guaranteed minimal level of accountability. Dege31 (talk) 00:38, 12 July 2025 (UTC)

Eh, it’s a cosmetic change to the website so I think it's fine to balk at it subjectively. It is a shame that my proposal can't have any data or examples of how this would improve reader outreach (although there does seem to be some interesting-looking papers on FAs), as any analysis of such data would only be possible post hoc. If this passes I do hope to do a 30 day postmortem to see how many people click on the statistical redirects and see how many new editors participate in the project pages. Dan Leonard (talk • contribs) 00:51, 12 July 2025 (UTC)

As you mention, I don't think there's enough problems to scale up the maintenance yet. Aaron Liu (talk) 01:52, 12 July 2025 (UTC)

Regarding scaling up the maintenance of these articles, I hope that one side benefit of this passing may be that, if GA/FA status confers additional prominence compared to the status quo, there will be both more incentive for editors to pursue that status for articles that deserve it and more editors noticing/sending to FAR/GAR when an article has that status that does not deserve it. Sdkb ^talk 04:43, 15 July 2025 (UTC)

Welcome message for new editors whose initial efforts have been reverted.

A welcome message for new editors whose initial efforts have been reverted is desired. The point is to encourage them to not become not become frustrated. Good faith edits are helpful even when rejected as they make promote further discussion and other improvements. Encourage them to reach out to the editor who reverted them if they need further explanation. Usually that is the editor that is welcoming them. There are no dumb questions. Constant314 (talk) 16:41, 9 July 2025 (UTC)

From Wikipedia:Welcoming committee/Welcome templates:

• {{Welcome-suboptimal}}
• {{Welcome-anon-suboptimal}}
• {{Welcometest}}
• {{Welcome-unregistered-test}}
• {{Welcome-unconstructive}}
• {{Welcome-unregistered-unconstructive}}

Also, all of the Level 1 and single-level warnings at Wikipedia:Template index/User talk namespace are worded fairly cordially and are used very often. Dan Leonard (talk • contribs) 16:46, 9 July 2025 (UTC)

@Constant314, see Wikipedia:Welcoming_committee/Welcome_templates#Specialized. Most address specific issues with the edit. For general good-faith edits that miss the mark, I like Template:Welcome-suboptimal and have added it to my Twinkle menu as a custom welcome. Schazjmd (talk) 16:47, 9 July 2025 (UTC)

Thanks, but "suboptimal" seems judgmental. Is there a way to bring this up directly with the welcoming committee? Constant314 (talk) 16:52, 9 July 2025 (UTC)

The word "suboptimal" doesn't appear in the text and the template should be substituted so I'm not sure what your concern is.

It looks like you use Twinkle for rollbacking and welcoming. Open your Wikipedia:Twinkle/Preferences § welcome and add whatever you want to the option "Custom welcome templates to display". Dan Leonard (talk • contribs) 16:57, 9 July 2025 (UTC)

Thanks for the Twinkle tip. Constant314 (talk) 17:08, 9 July 2025 (UTC)

What is wrong with being judgmental? Sometimes it is necessary to tell someone that their efforts are "suboptimal" or worse. Phil Bridger (talk) 17:18, 9 July 2025 (UTC)

I choose to not be so. Constant314 (talk) 22:49, 9 July 2025 (UTC)

For all kinds of edits? There is a spectrum of problem edits ranging from vandalism that must be removed and oversighted all the way up to meaningless cosmetic changes that do no real harm, but use up editors' time to review them. Do you choose not to notify/warn the user about any of those edits? If you do choose to warn or notify about some edits, where do you draw the line? We cannot ignore edits that degrade the encyclopedia to any degree, and we need to let users know when their edits reduce the quality of the encyclopedia. Donald Albury 00:34, 10 July 2025 (UTC)

For all kinds of edits?

Of course not. Constant314 (talk) 05:45, 10 July 2025 (UTC)

Thanks for the responses. I'm going to remove this page from my watchlist now. Kindly ping me if there are more comments. Constant314 (talk) 20:56, 10 July 2025 (UTC)

Creating an edit filter or automatic new page flag for likely LLM-generated material

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Concurrent and more focused discussion occurring at Wikipedia:Edit filter noticeboard § Edit filters related to logging and blocking AI edits and polling for tagging and warning at § 1325 and 1346 to tag. Dan Leonard (talk • contribs) 22:00, 15 July 2025 (UTC)

---

LLM-generated text, in existing articles and brand-new ones, are disrupting Wikipedia. They have some stylistic hallmarks, including a higher-than-average incidence of emdashes and a extensive use of bolded text outside of the article lead. Some automatic detection and flagging of such edits and articles for review would be useful in making sure none slips by. ꧁Zanahary꧂ 02:34, 10 July 2025 (UTC)

Special:AbuseFilter/1325 Dan Leonard (talk • contribs) 02:55, 10 July 2025 (UTC)

We have things like mw:Help:New filters for edit review/Quality and Intent Filters and User:ClueBot NG, so it seems like a similar tool could be made to identify likely LLM edits. At the very least, it's something that might be good for the WMF to look into. Thebiguglyalien (talk) 🛸 14:57, 11 July 2025 (UTC)

Automated LLM detection isn't really a thing. The error rates are sky high into "flip a coin" levels, a problem that will only get worse as human writing starts to converge with LLM-flavored writing (a real phenomenom). Automatic detection needs to have a low false positive rate to be useful. It's possible we could automatically detect the absolute most blatant tells like "As a large language model" or the words "ChatGPT", but otherwise this can't really be done. SnowFire (talk) 16:37, 11 July 2025 (UTC)

I think a flag for **This formatting** and extensive use of bolded text in the article body would catch a lot of AI-generated articles quickly. ꧁Zanahary꧂ 16:40, 11 July 2025 (UTC)

The problem is not just with catching a lot of AI-generated articles, but how many non-AI-generated articles would also be caught. I have already seen editors who think that the way to write is to use lots of bolded text and em-dashes and to write extensive meaningless drivel rather than get to the point concisely, all hallmarks of LLMs, and can only see the problem getting worse. Life is imitating art. Phil Bridger (talk) 21:48, 13 July 2025 (UTC)

Even if these are not LLM outputs, these issues alone are worth having some filter to catch them. Chaotic Enby (talk · contribs) 22:04, 13 July 2025 (UTC)

An edit filter is not an automatic nuke; it allows edits through and flags them for review ꧁Zanahary꧂ 22:09, 13 July 2025 (UTC)

Funnily enough, "As a large language model" is already in Special:AbuseFilter/1325, alongside some slightly less blatantly obvious signs (the filter is log-only). Chaotic Enby (talk · contribs) 18:18, 11 July 2025 (UTC)

humanizing services also exist to thwart automated advanced services like gptzero. and (no offense to some editors), but some folks just naturally trigger gptzero with the way they write. Bluethricecreamman (talk) 01:29, 14 July 2025 (UTC)

Doesn't seem particularly useful given the error rate. PackMecEng (talk) 22:29, 13 July 2025 (UTC)

The error rate of what? ꧁Zanahary꧂ 22:41, 13 July 2025 (UTC)

As noted above, false positives. PackMecEng (talk) 22:45, 13 July 2025 (UTC)

No, I mean what is the test that you say produces too many false positives? ꧁Zanahary꧂ 22:49, 13 July 2025 (UTC)

Any check out there that looks for the use of a LLM. PackMecEng (talk) 00:08, 14 July 2025 (UTC)

This has already been addressed in replies to the comment above yours. Thebiguglyalien (talk) 🛸 00:15, 14 July 2025 (UTC)

I’m not referring to complex proprietary detectors, I’m proposing a simple filter that flags hallmarks of LLM-generated text (examples above) for review by patrollers. ꧁Zanahary꧂ 00:31, 14 July 2025 (UTC)

Correct, and the level of false positives it would produce would make it useless. So no, it has not been addressed. PackMecEng (talk) 01:21, 14 July 2025 (UTC)

Even in false positives, issues like overused bolding or bulleted lists would still need to be fixed, so logging them alongside AI-generated edits isn't necessarily bad. Furthermore, a moderately high false positive ratio isn't as big of an issue for log-only filters as it is for filters that disallow content entirely. Chaotic Enby (talk · contribs) 01:28, 14 July 2025 (UTC)

high false positive ratio isn't as big of an issue for log-only filters that isn't really true though is it. Because what is the point of the log if its unreliable? I would rather people not harass new or well meaning editors with accusations of LLM editing when it's basically just a vibe at the moment. Again, I am failing to see the value while seeing possible harm. PackMecEng (talk) 01:31, 14 July 2025 (UTC)

We're not proposing a means of positively identifying LLM content, we're proposing a means to find poorly-written content. Thebiguglyalien (talk) 🛸 01:37, 14 July 2025 (UTC)

To clarify, logging edits means that people looking through edit filter hits can have a second look at them – they shouldn't accuse editors just for having their edits show up in the log, without checking the actual edits. We're also looking to target (some of) the issues with LLM editing, which would also be shared by most edits being caught in these filters. Chaotic Enby (talk · contribs) 01:37, 14 July 2025 (UTC)

Sure and I completely understand both of your points and while I appreciate that people should not use those logs to harrass people, that is what they will be used for. On top of that, with them most likely being false positives it provides little value. PackMecEng (talk) 13:27, 14 July 2025 (UTC)

We have logs integrated into the recent changes feed that labels some edits as "very likely bad faith". I'm not aware of any issue with good edits triggering false positives that result in editors being harassed for them. I don't see why a log-only filter (one of hundreds? thousands?) would originate that problem. ꧁Zanahary꧂ 13:30, 14 July 2025 (UTC)

I understand your view on the issue, I just disagree. We have already seen several people dragged to noticeboards over this. So I dont understand how you can say a thing that is activly happening wont happen? PackMecEng (talk) 14:52, 14 July 2025 (UTC)

Special:AbuseFilter/1325 already exists. Do you have any example of patrollers going through this filter's logs and harass[ing] new or well meaning editors with accusations of LLM editing when it's basically just a vibe at the moment? Dan Leonard (talk • contribs) 17:55, 14 July 2025 (UTC)

I think @PackMecEng is correct. If editors believe that AI is bad (and we're pretty much all agreed on that, right?) and they see a note that says "possible AI-generated text", then some of them are going to mindlessly revert it, or demand that the editor prove that it wasn't AI generated (how?). For example, it flagged this edit, which has no AI, but which has a different problem: In trying to update a few numbers, the editor has accidentally duplicated nearly the entire article. Ermenrich was correct to revert it, but how can we identify the real source of the problem, and how can we keep the good parts (if any)?

Note that I wrote about "some of them", not "everyone". Editors are people, and we get about three-quarter million registered accounts making 1+ edits here every year. I think we can safely assume that, out of 750,000 editors, at least one of them will use AI badly, and we can safely assume that, out of 750,000 editors, at least one of them will be a jerk. I would be more comfortable with Special:AbuseFilter/1325 if it labeled the edits with something like "Possible problem needing review" instead of "possible AI-generated text". WhatamIdoing (talk) 02:56, 15 July 2025 (UTC)

Whether AI is or isn't bad is not relevant. Whether text was generated by AI or not is irrelevant. What is relevant is whether the text has problems that need fixing. What is useful for editors is not "this page might have been written by AI" but "this page contains incorrect markup", "this page has excessive bold text", or "this page has a non-encyclopeadic tone". Those are specific problems that can be fixed, and the fix is the same whether the text was generated by a human, by and AI or by some combination. Thryduulf (talk) 03:09, 15 July 2025 (UTC)

It seems to me that whether the reviewing/reverting editor is biased against AI-generated text is very relevant – in terms of whether the reverting editor is likely to "harass new or well meaning editors with accusations of LLM editing".

I assume that the incorrectly tagged diff I linked above is a case of "excessive bold text", except that it actually isn't "excessive" (it's a tiny percentage of a huge accidental duplication, and none of it was AI generated). WhatamIdoing (talk) 03:56, 15 July 2025 (UTC)

Whether someone is or isn't biased against AI-generated text is relevant to whether that person will harass others (whether well-meaning or otherwise) with accusations of LLM editing. However that isn't directly related to whether the text was written using LLMs or not.

My point was that we don't need to know or care whether anything was or wasn't written using an LLM, and so we shouldn't be tagging anything with LLM labels. Much, possibly even most, text written by a drunk author will be bad because it will be badly spelling, incoherent, rambling, etc. We could gather all these heuristics together and tag it as "possibly written by a drunk person", but we don't do that because not only is it not possible to know whether it is correct or not it wouldn't be useful information even if we could. Instead we tag it for the actual problems it has - specific, actionable things. For the minority of drunk-written text that is actually good, we don't tag it as anything as there is no benefit to doing so - we have no reason to care whether the author was drunk or not. There is no reason to doing anything different for text that might (or might not) be written by or with the assistance of LLMs. Thryduulf (talk) 16:06, 15 July 2025 (UTC)

I agree that it would be better to not assign a cause (whether AI or drunkenness) to bad writing. I don't mind potentially bad writing being flagged as needing review, though. WhatamIdoing (talk) 16:15, 15 July 2025 (UTC)

But the superficial hallmarks of LLM-generated text often indicate deeper problems with verifiability that are much more impoerant and much less trivial to detect without the proxy of, say, bolded text sprinkled all over the article body. I don't see the point of concealing this reality by pretending the filter is designed to catch an arbitrary grouping of stylistic problems rather than LLM-generated text. ꧁Zanahary꧂ 16:25, 15 July 2025 (UTC)

If you have a heuristic that suggests there might be a problem with verifiability then use that heuristic to tag edits with "possible verifiability issues" or something like that. The actual issue that needs human attention is verifiability not whether it was LLM-generated or not. With a tag saying "possible verifiability issues" everybody knows what needs to be checked. "Possible LLM use" or similar is neither actionable or relevant. Thryduulf (talk) 17:24, 15 July 2025 (UTC)

The heuristic that links AI-like styling with verifiability problems necessarily implies AI generation between those endpoints. ꧁Zanahary꧂ 17:28, 15 July 2025 (UTC)

Whether it does or doesn't imply AI generation is irrelevant, because who or what wrote the flagged text is irrelevant. The only thing we care about here are the actual actionable problems: verifiability, styling. It doesn't matter in the slightest whether a blob of oddly-phrased and badly formatted text was written by a human, an AI or both it needs the exact same actions taken either way. Thryduulf (talk) 18:03, 15 July 2025 (UTC)

This is true in a vacuum, but at a broader level we need to have barriers for the insertion of LLM-generated content because these problems are so endemic to it and because Wikipedia should be an alternative to LLMs, not an extension of them. Thebiguglyalien (talk) 🛸 18:10, 15 July 2025 (UTC)

No. We need to have barriers to bad content, regardless of how it is generated. We need to have as few barriers as we can to good content, regardless of how it is generated. Thryduulf (talk) 18:13, 15 July 2025 (UTC)

+1. Donald Albury 18:23, 15 July 2025 (UTC)

One of the barriers to good content is the sheer amount of effort those who could usefully be involved in creating it have instead to expend on keeping the bot-crap out. AndyTheGrump (talk) 18:25, 15 July 2025 (UTC)

All the specific triggers proposed in this discussion thus far have been inherent quality issues in themselves. ꧁Zanahary꧂ 18:46, 15 July 2025 (UTC)

Yes, and it is the quality issues that should be flagged, not our guess at whether they were created by man or machine. Thryduulf (talk) 19:15, 15 July 2025 (UTC)

I don't even know what we're arguing about. Can you explain what you are arguing for and against? If there were a group of new articles that frequently had serious problems with source misrepresentation and unencyclopedic tone, and those articles all included an invisible comment that said "This article was made by Team Awesome!", would we have to pretend that articles made by Team Awesome shouldn't be flagged for further review because of their particularly endemic problems with quality—because easy proxies for poor quality ought to be ignored? ꧁Zanahary꧂ 18:44, 15 July 2025 (UTC)

You have completely misunderstood. I'm saying that those articles should be flagged for having unencyclopadic tone, and they should be flagged to be checked for source manipulation. They should not be flagged based on the creator. A tag saying "this article has unencyclopedic tone" lets everybody know what the problem is and it lets the people interested and skilled in fixing unencyclopaedic tone fine the article, a tag saying "created by Team Awesome" does neither of those things. Thryduulf (talk) 19:19, 15 July 2025 (UTC)

On what basis should they be flagged for misrepresenting source before they have been checked for source misrepresentation? ꧁Zanahary꧂ 19:30, 15 July 2025 (UTC)

What I actually said was should be flagged to be checked for source manipulation, i.e. a flag to check whether there is source manipulation or not (and fix it if there is). Thryduulf (talk) 19:53, 15 July 2025 (UTC)

How is this unlike my proposal? ꧁Zanahary꧂ 19:55, 15 July 2025 (UTC)

Because you're proposing to flag for a guess at the cause of the problem, not proposing to flag for the actual problem that needs solving. There is a big difference. Thryduulf (talk) 21:26, 15 July 2025 (UTC)

The difference is purely nominal. We could call it "chocolate backflip surprise" and the effect would still be the very same. ꧁Zanahary꧂ 21:28, 15 July 2025 (UTC)

Anyways, if you want to implement your objection to the identification of LLM generation as the source of these LLM-typical problems, there are two existing filters, helpfully linked for discussion below by Dan Leonard, which you can argue to rename. ꧁Zanahary꧂ 21:30, 15 July 2025 (UTC)

the effect would be the very same except the entire point is that it wouldn't, as I've "spilled all this ink" repeatedly explaining. Thryduulf (talk) 21:37, 15 July 2025 (UTC)

I think we'd better chocolate backflip away from this discussion, as it's proven moot (with two filters nominally meant to catch LLM generation already existing) and is not leading to any mutual understanding. Sorry about the circles. ꧁Zanahary꧂ 21:40, 15 July 2025 (UTC)

A gallon of ink spilled and not a single actionable item. Abuse filters 1,325 (possible AI-generated text) and 1,346 (possible AI-sourced citations) already exist. @Zanahary: do you want to include Markdown syntax into the former as you allude above? @Thryduulf: do you think all existing abuse filters should be renamed to "possible source manipulation" or similar? Dan Leonard (talk • contribs) 20:09, 15 July 2025 (UTC)

Yes, I think markdown should be added, and if possible, so should super above-average emdashery. ꧁Zanahary꧂ 20:26, 15 July 2025 (UTC)

There already seems to be an active discussion on this topic at the edit filter noticeboard: § Edit filters related to logging and blocking AI edits. I recommend making further comments there on including Markdown syntax in an existing or new filter. Dan Leonard (talk • contribs) 20:33, 15 July 2025 (UTC)

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

Proposal: Remove the births and deaths from all years on Wikipedia

• Previous discussion: Wikipedia:Village_pump_(proposals)/Archive_199#RFC:_split_births_&_deaths_from_year_articles

I believe that we should remove the births and deaths (specifically before 1980) from all of our year articles (or at least extend the range to as back as need be) and just link the categories (like for articles on years after 1980). It can be a time-consuming process to determine whether someone they are notable enough to even be included in the births and deaths section. I think it is better to just remove them altogether and just link the categories. Interstellarity (talk) 23:27, 13 July 2025 (UTC)

Would you consider separate lists? For example, instead of having 1900#Births, could we split off a List of births in 1900? WhatamIdoing (talk) 03:58, 15 July 2025 (UTC)

I support this proposal, especially in the case of births. Even in the case of someone very notable, their birth was almost never notable. To put it another way, the birth of notable person is not automatically a notable event. Nor is their death, in most cases. I would limit exceptions to cases where the birth or death actually had a real effect on the world. Zero^talk 12:54, 15 July 2025 (UTC)

Already done. We had a previous RFC on the matter already. InvadingInvader (userpage, talk) 15:51, 15 July 2025 (UTC)

That RFC, which the OP started out by linking, concluded with a consensus to split "large" articles. There was no consensus on what to do with the split material, but deletion explicitly did not get consensus. There was no consensus to split or remove births and deaths from articles that are not "large". While "large" was not explicitly defined, it seems the guidance at WP:SIZESPLIT was what most people seemed to be thinking of when using the term. Thryduulf (talk) 15:56, 15 July 2025 (UTC)

I wouldn't be opposed to doing a split of everything for consistency, to the extent it should be followed. InvadingInvader (userpage, talk) 16:53, 15 July 2025 (UTC)

Proposal for discussion: No-AI Certification in Unblock Requests

Administrators and other editors who work on the "Requests for unblock" queue have observed that many unblock requests appear to be written entirely or largely by AI LLMs. A request may sound sincere and unblockworthy, but because the editor hasn't actually written it, the promises it contains may not reflect the editor's actual intentions. And yet the editors submitting these requests can, as far as I know, validly claim no one ever told them that AI-generated requests are unhelpful.

Would it be worth prominently addressing this concern in Template:Unblock, with language such as Unblock requests should be submitted in the editor's own words. By submitting an unblock request, you certify that you wrote the unblock request yourself and that it was not generated by any form of artificial intelligence or something along those lines?

My apologies if this has been discussed before (could someone point me to the discussion) or would be better discussed elsewhere (in which case I'll re-post there). Thank you, Newyorkbrad (talk) 01:53, 14 July 2025 (UTC)

AI-detection is guesswork with high rates of both false positives and false negatives, so we absolutely should not be rejecting unblock requests just because it looks or feels like it might be AI-generated. That said, I don't have an issue with something like the assertion you suggest as long as we're clear it doesn't apply to AI-assisted translations, spell checking, etc. Thryduulf (talk) 02:19, 14 July 2025 (UTC)

Fair enough. My goal frankly is not just to screen out dubious unblock requests, but more importantly, to facilitate good ones that have a chance of turning blocked users into contributors. Regards, Newyorkbrad (talk) 02:32, 14 July 2025 (UTC)

The first reason you gave about editors making claims isn't compelling to me, because such claims don't excuse an insincere request, no matter how it was written. I'll agree though that helping editors write good requests makes the entire process more effective. isaacl (talk) 03:28, 14 July 2025 (UTC)

Banner blindness may limit impact, but it might help some editors make unblock requests that are more likely to succeed. I've also seen "own words" issues occur when an editor copies a guideline into the unblock request, which invariably leaves others unconvinced the guideline is understood. CMD (talk) 03:40, 14 July 2025 (UTC)

Adding advice to that matter (both in Template:Unblock and Wikipedia:Unblock wizard) could be a great idea. It doesn't require unblock reviewers to guess, but still helps users who might just not know that it isn't ideal. I feel like noting it in the unblock process (rather than in the block template) would make it less susceptible to banner blindness, as editors would be more focused on what is needed to submit their unblock. Chaotic Enby (talk · contribs) 04:10, 14 July 2025 (UTC)

agree with language, but enforcing any AI detection with tools like gptzero would be a hard no for me while they have false positive rates.

at most, an admin should ask for more clarification if they believe there isn't sincerity in changing behavior. Bluethricecreamman (talk) 04:39, 14 July 2025 (UTC)

Maybe the notice should use the phrase "Large Language Model" somewhere in there, while still using the term "Artificial intelligence" as well. That way it stays somewhat consistent, as I see a lot of other policy stuff on wikipedia use the term "Large Language model". Gaismagorm (talk) 01:02, 15 July 2025 (UTC)

@Newyorkbrad, I think it's difficult to conflate "wrote it myself" with "being sincere". Here's a story I was told (c. 2000):

A teenager's parent died. A friend wanted to express his sadness to her in a proper, suitably formal way. Unknown to anyone at the time, he had autism, so he didn't have a strong grasp of the subtleties of certain social forms. So instead of the correct form (which, in the US, is "Please accept my condolences") or the common, informal form ("I'm sorry your father died"), he confused them all by saying: "I apologize for your father's death."

This young man was very sincere. He was actually trying quite hard to say the best, most comforting thing possible. He just needed help figuring out how to express his sincerity.

When someone posts an unblock request, we need a good, shared understanding of what's being said. But I'm not sure that "don't use AI" actually gets us closer to that.

Maybe instead of affirming a bit of boilerplate (which anyone will do, exactly like we all click "I agree" without reading the terms of use first), I think it might be interesting to treat it like a survey and ask:

Did you use any AI such as <names of popular tools> or similar tools to write this? Please check all that apply:

⬚ I used AI/LLM to write a good explanation.

⬚ I used <names of popular tools> only for translation.

⬚ I used machine translation (e.g., Google Translate).

⬚ Yes, but I only used it for spelling and grammar checking.

⬚ No, I wrote this all myself.

Treating it like a survey might help us get accurate responses ("We're trying to see what's most popular") without incentivizing lies ("Say you didn't use AI, or we won't unblock you!"). Mostly, though, I think that the admins need to simply ask about it when an unblock request is posted and the editor's engagement with the request is uncertain. WhatamIdoing (talk) 04:27, 15 July 2025 (UTC)

That could be a good idea, I might add it to the Wikipedia:Unblock wizard's code! Chaotic Enby (talk · contribs) 07:30, 15 July 2025 (UTC)

Since you can't actually "check" boxes in a wikitext-based survey, you'll have to re-write it, but perhaps there's something useful in my example. WhatamIdoing (talk) 15:50, 15 July 2025 (UTC)

You can actually have checkboxes, Wikipedia:Unblock wizard/Sockpuppet has an example! Chaotic Enby (talk · contribs) 15:58, 15 July 2025 (UTC)

Adding some basic please use your own words language seems prudent, and as @Chipmunkdavis pointed out, that could also apply to other common issues with requests. I'd look less favorably on a longer, more explicit "don't use AI" message, both for banner bloat reasons and since we don't want it to backfire by giving people the idea to use AI when they weren't thinking of it previously. Sdkb ^talk 05:29, 15 July 2025 (UTC)

Agreed. ꧁Zanahary꧂ 22:01, 15 July 2025 (UTC)

This goes a bit too far for my comfort. Perhaps just the certification that the request reflects the editor's sincere and honest sentiment, or even a straightforward caution that submissions that are or appear to be written with LLMs, copy–pasted form P&G or prior discussions without editorial or reflection, or otherwise not in the editor's own words and reflective of their sincere commitment are likely to be viewed unfavorably. I'm sure most of these requests that set off admins' BS detectors really are garbage, but I'm uncomfortable with the idea that one can never get an assist, whether from technology or a trusted friend. --MYCETEAE 🍄‍🟫—talk 01:28, 16 July 2025 (UTC)

The most common block templates all link to Wikipedia:Guide to appealing blocks (WP:GAB), which contains a section (WP:NICETRY) that explains, "Write your request yourself; requests that appear to be written with an LLM or AI are likely to be summarily rejected." The fact that blocked editors still regularly submit LLM-generated unblock requests shows that either they are not reading this guidance, or they have read the guidance and are choosing to ignore it. Assuming good faith would require the administrator to assume that the editor did not see it, but either way, LLM-generated unblock requests are a waste of time for both the blocked editor and the reviewing administrator. I support presenting this guidance against LLM-generated unblock requests in a more visible way to ensure that the blocked editor sees it before they submit their request. — Newslinger talk 19:07, 17 July 2025 (UTC)

File:Cooper-Kong.jpg

Moved to Wikipedia:Media copyright questions § File:Cooper-Kong.jpg

 – Chaotic Enby (talk · contribs) 23:48, 15 July 2025 (UTC)

Convention for naming Australian place articles

There is a RFC on the convention for naming Australia place articles at Wikipedia:Australian Wikipedians' notice board#RfC: The convention for naming Australian place articles. Editors are invited to contribute. TarnishedPath^talk 03:20, 19 July 2025 (UTC)

Idea lab

Doing something about WP:RA

Wikipedia:Requested articles is pretty inactive these days. Should we do something about it, and if so, what? See also this relevant discussion. Cheers, GoldRomean (talk) 22:46, 29 June 2025 (UTC)

Could launch an RFC at WP:VPPR with question "What should we do with WP:RA?" and options A do nothing, B mark historical and revert new entries, C delete everything. Or could WP:MFD the entire thing.

I have concerns about WP:RA being a black hole that tricks newbies and attracts spam. To help combat this, in 2021 I changed Wikipedia:Requested articles/Header to recommend making a draft (via the article wizard) instead of requesting an article at WP:RA. –Novem Linguae (talk) 22:50, 29 June 2025 (UTC)

WikiProjects have their own lists which I suspect are more active, although this is highly variable and full of black holes as well. CMD (talk) 00:32, 30 June 2025 (UTC)

On 'spam', see a tangential discussion on seeking page protection for one of the RA subpages. The discussion did not lead to implementing protection.

IMO the project is a useful addition to WP when/if used 'properly', and WikiProject-specific request pages just decentralize. However its probably fair to say the pages are only used by a few hundred users per year, as compared to the millions elsewhere; so may unfortunately be more trouble than its worth to upkeep. Tule-hog (talk) 03:12, 30 June 2025 (UTC)

Agreed. Wouldn't wikiproject-specific pages just have the exact same problems, with the additional issue of making discovery more challenging? -- Avocado (talk) 21:12, 30 June 2025 (UTC)

(Someone correct me) but my guess is though that WikiProject-specific lists are made by participants, rather than people looking to advertise, so there's more evidence of notablity. GoldRomean (talk) 19:14, 1 July 2025 (UTC)

A look at the page history of requested bios [19], for example, shows occasional additions, and mostly a lot of cleanup efforts. Does any smarter or more experienced editor than me know how to get some stats or info for when most of the requests were made? A lot of them seem very old. GoldRomean (talk) 03:35, 30 June 2025 (UTC)

I can try to whip up something with my basic Python knowledge. No guarantees though. Ca ^{talk to me!} 14:15, 1 July 2025 (UTC)

My fairly recent experience looking through RA for something to write about was one of being utterly overwhelmed by the number of options even in any one subpage (and under any given heading on some of the most populous subpages), and not having a clue how to begin narrowing the field.

I wouldn't totally object to shutting it down entirely, but on the flip side, maybe something could be done to make it more useful. For instance, applying a template to every (or every new) entry with links to search various places for reliable sources about the topic. -- Avocado (talk) 21:11, 30 June 2025 (UTC)

The first step to triaging any entry at WP:RA is to determine notability. This means doing google searches and other investigations to determine if there's enough sourcing for the article to pass WP:GNG, or just knowing enough of our WP:SNGs to be able to spot if it passes an SNG. Notability is hard and takes a lot of experience to judge accurately.

A thought occurs to me. I wonder how many of the entries at WP:RA aren't even notable. There's probably a lot of red herrings and rabbit holes there. For example, how many of the companies at Wikipedia:Requested articles/Business and economics/Companies/A-E pass WP:NCORP? I have my suspicions that it's not very many. The one time I tried to write an article about a company on one of these lists, it got sent to AFD and deleted: Wikipedia:Articles for deletion/Lidya (company). I was quite confused as a new user, but on the flip side, it did motivate me to go to WP:NPPSCHOOL and figure out how notability works. –Novem Linguae (talk) 21:41, 30 June 2025 (UTC)

I agree that an initial screening is key to make the list of requested articles into one that is high-yield, and thus useful for interested editors to go through. (Linking it up to corresponding active wikiprojects would be another important aspect, but of course there aren't many of those.) But this needs willing people to do it regularly, and I'm not sure there's a sustainable way to ensure it gets done. There's already a lot of work to patrol the actual articles and edits that are made. isaacl (talk) 04:57, 1 July 2025 (UTC)

Maybe we could require each new entry at WP:RA to have either WP:THREE sources or evidence of meeting a SNG, and have a "triage" zone where they are placed until a volunteer checks the sources? That might mean more work, but would likely reduce the load at RA by a lot, and make it easier to write the articles themselves in the future. Chaotic Enby (talk · contribs) 15:07, 1 July 2025 (UTC)

WP:RA is a ghost town. I don't think there's anyone available to enforce a rule like this on its 333 subpages. We do try to do some quality control on the businesses and companies subpages via pending changes protection, but that's just 5 subpages. –Novem Linguae (talk) 15:35, 1 July 2025 (UTC)

Yeah, the only reasonable way to go at it would be "mark everything as in triage" (or, more drastically, "throw everything away") and start filtering new entries with sources. Although that is still a lot of effort for a project that has brought comparatively little benefits. Chaotic Enby (talk · contribs) 15:37, 1 July 2025 (UTC)

I don't think it's worth it. We'd just end up with three URLs for a spammy suggestion (because the WP:UPE followed the directions) and removing a solidly notable suggestion because the innocent newbie didn't follow the directions.

At least with Wikipedia:Requested articles/Medicine (I'm not familiar with very many of the lists), the suggestions are sometimes good candidates for redirects or list entries. Relatively few are obviously bad suggestions. WhatamIdoing (talk) 06:23, 3 July 2025 (UTC)

I'm guessing it's probably because the majority of company/bios are people looking for self-promo whilst a larger amount of, say, medicine requests, are SME's thinking "hey this topic is pretty important in my field why isn't there an article on it". GoldRomean (talk) 18:42, 3 July 2025 (UTC)

Or people wanting information because someone they know is sick. I don't exactly miss the Wikipedia:Article Feedback Tool (2010–2014), but we got comments that suggest people turn to Wikipedia to get quick answers.

The basic scenario is: someone texts you "We're at the hospital. They think the baby has Scaryitis". You want to know whether your response should be "What a relief" or "I'm so sorry", and you don't want to slog through a lot of details. So when we don't have anything, or when it doesn't provide information about the prognosis, people aren't getting what they want. WhatamIdoing (talk) 01:44, 4 July 2025 (UTC)

Agree, I guess in general just when people see we're missing content on a topic (which probably should be the way RA is intended to be used). GoldRomean (talk) 01:47, 4 July 2025 (UTC)

Me and @Bearian (mostly him) have tried to maintain the crime/law one and revert/remove non notable entries, though it still needs more. As far as I am aware every other one is a ghost town. PARAKANYAA (talk) 22:33, 1 July 2025 (UTC)

I mean having a group of people who "maintain" the pages is nice, extending that to more pages to keep them in a decent state wouldn't be a bad idea, but to retrospectively remove all non notable entries is a mammoth task that I don't really think is possible. If we were to PCP all the pages and then make sure that these requests went through a proper review beforehand I do think that's a way to enforce some rules if we were to make them. Zippybonzo | talk | contribs (they/them) 06:50, 2 July 2025 (UTC)

What does everyone think about an RfC with, say, Option 1: Do nothing/Option 2: Restart, and mark the original as historical or delete/Option 3: Mark historical or delete it all, with more discussions for specific details based on the result (ex. if Option 2, how do we make sure this mess doesn't happen again?) GoldRomean (talk) 23:40, 13 July 2025 (UTC)

I don't see any need for any of this. As much of a mess of any part of the site is where people submit article ideas - AfC is much worse. PARAKANYAA (talk) 01:07, 18 July 2025 (UTC)

Hi @PARAKANYAA, thanks for commenting - would you mind elaborating slightly? Also, I respectively disagree that AfC is much worse; unlike RA, all submissions are reviewed eventually and whilst it may be a mess, it's a somewhat maintained mess, if that makes sense. GoldRomean (talk) 01:46, 19 July 2025 (UTC)

Finding sources fabricated by AI

I'm not sure if this is known already, but sources generated by AI sometimes have the access-date parameter set to the model's knowledge cutoff date. For example, this search query finds articles that contain sources with the access date set to October 1, 2023, which corresponds to GPT-4o's knowledge cutoff date. I think this warrants a deeper investigation; perhaps we can create editfilters tagging this behavior. 🧙‍♀️ Children Will Listen (🐄 talk, 🫘 contribs) 16:17, 6 July 2025 (UTC)

I think that could be very useful EarthDude (talk) 17:38, 6 July 2025 (UTC)

On a quick glance, it looks like some of the results in the query are legitimate, but it only took about 6 minutes to find one clear case of AI-written, low-quality content, so I suspect there are more. -- LWG ^talk 18:05, 6 July 2025 (UTC)

An edit filter would be great though, IMO, since I don't think there's a reason editors beyond October 2023 would add that. Aaron Liu (talk) 18:12, 6 July 2025 (UTC)

There are some legitimate cases when someone might do this, the most common one being xwiki translations. 🧙‍♀️ Children Will Listen (🐄 talk, 🫘 contribs) 18:14, 6 July 2025 (UTC)

Other cases where I've added access dates other than today's date include:

• When I've copied a source from another article or another place in the same article (e.g. merging or moving information from one article to another). In this case I will usually use the original access date.
• When I'm viewing a source on an archive rather than live. Normally I will use the date of the archive but occasionally it will be the date the source was added to the article.
• When I've written an article over several days the date will be the date I accessed that source, which might differ from the date I add that part to Wikipedia (usually only by a few days). For example at List of lakes of Yukon you'll find that the access dates range from 8-11 August despite all being added on the 11th.

In some cases, reference formatting changes may be detected as access dates in the past being added. Thryduulf (talk) 21:38, 6 July 2025 (UTC)

Aren't archival dates supposed to be in |archive-date=? Aaron Liu (talk) 01:34, 7 July 2025 (UTC)

Yes, but when I access a source via an archive rather than directly I will set the access-date and archive-date parameters to be the same. Thryduulf (talk) 06:51, 7 July 2025 (UTC)

Still, that's rare enough that a tag would be good. Aaron Liu (talk) 01:34, 7 July 2025 (UTC)

This RecentChanges filter also catches a lot of LLM additions. These "Newcomer tasks" seem to draw really low quality edits even if it weren't for that. 🧙‍♀️ Children Will Listen (🐄 talk, 🫘 contribs) 20:48, 9 July 2025 (UTC)

Implementing the number of views/edits an article somewhere in the top of the article

I think that we should implement the number of views/edits an article has had whether it's recent or all-time views/edits to the front of the Wikipedia page rather than having to go into page info to see the views/edits. My preference is to put the views in over the edits but am willing to be convinced otherwise. YouTube and many other websites have something similar to this. I also think we could put that date the Wikipedia article was created on the bottom similar to where we put when the page was last edited. I'm opening up a discussion here since I want to figure out something the Wikipedia community can agree on. I look forward to hearing your thoughts below. Interstellarity (talk) 21:28, 7 July 2025 (UTC)

I don't think those counts warrant any prominence. Aaron Liu (talk) 23:53, 7 July 2025 (UTC)

That's the sort of feature that people could do with a userscript if they want to. I agree there's no need for it by default. -- LWG ^talk 00:07, 8 July 2025 (UTC)

I don't think prominently featuring how many views an article gets a la YouTube is a good idea. It would encourage sensationalism and a click-baity style that Wikipedia tries to avoid, unlike the entire rest of the internet.

As for the number of edits, I think there is more potential benefit to featuring that on the main article page. An article with few edits could be interpreted as having gotten less attention and collaboration, therefore being likely to have problems, while an article with many edits could indicate an edit war. I think that's worth considering.

Regarding putting when the page was first created as well as when it was last edited at the bottom, I think that is an excellent idea. It would help people know if an article was created before widespread LLM usage or not, and if it was created before our own articles were scraped and recycled creating a massive and largely underestimated problem with circular referencing. ~ ONUnicorn^{(Talk|Contribs)}problem solving 00:29, 8 July 2025 (UTC)

Note that on the mobile interface, the time of last edit (and the user who made the edit) are displayed by default at the bottom of each article. -- LWG ^talk 00:51, 8 July 2025 (UTC)

There’s a similar thing in the desktop interface as well: This page was last edited on 8 July 2025, at 00:51 (UTC). 2001:8003:B15F:8000:8860:131D:AE7B:4EC5 (talk) 11:59, 8 July 2025 (UTC)

Edit count and date of creation may be misinterpreted. There is not a direct a link between either and quality, but readers do not know this. CMD (talk) 00:43, 8 July 2025 (UTC)

I'm not sure I follow this. Is this something different than the XTools gadget available under preferences on the desktop i.e. XTools: dynamically show statistics about a page's history under the page heading

e.g. Ball shows 2,246 revisions since 2001-07-12 (+17 hours), 1,271 editors, 190 watchers, 10,035 pageviews (30 days), created by: 66.57.42.xxx🐣 · See full page statistics <- a link to XTools

Is the question whether this should be enabled for everyone by default, or is it about the mobile app etc.? Sean.hoyland (talk) 12:29, 8 July 2025 (UTC)

This is a question on it being enabled by default on both mobile and desktop. Interstellarity (talk) 21:17, 8 July 2025 (UTC)

Anybody who wants it can enable it very simply under preferences — GhostInTheMachine ^{talk to me} 16:05, 14 July 2025 (UTC)

Youtube leaves this info visible because it helps to know if a video is popular. Wikipedia articles do not need to do that. Cambalachero (talk) 01:33, 9 July 2025 (UTC)

I dont see logic and purpose behind this, why would the Wikipedia, an encyclopedia, the place of knowledge and articles, would need likes and views metric? I beleive that Wikipedia is not social media. P.S. Some user, including me, can see the page info directly below the title Sys64 message this user 09:35, 11 July 2025 (UTC)

"I want to figure out something the Wikipedia community can agree on." Seems like the community has already agreed on not having these things. How long an article has been around or how many times it has been edited has no intrinsic relationship to how factual and well-written it is. --User:Khajidha (talk) (contributions) 15:21, 14 July 2025 (UTC)

I kinda like this idea. Maybe just making the " This page was last edited on" more visible and at the top of the page instead of lost in the footer is good to start. JackFromWisconsin (talk | contribs) 17:04, 14 July 2025 (UTC)

I dislike the idea of a view-count. It would just encourage a certain sort of person to pursue wikipedian clickbait to see if they can get "their" article more viewed than anyone else's. But a created-on and last-edited date is a good idea, because it can help a reader assess whether the article is up-to-date, and in what view-point it was first written. My only proviso is that a lot of edits are basically meaningless from the point of view of information-value. Drive-by category-merchants, insertion of templates, gnoming typo correction, and bot curational edits should be ignored. On the plus side, Gnomes have the honesty to admit that their edit isn't a big endorsement of the article's up-to-dateness, and bots can probably be set up to mark their edit as minor. Elemimele (talk) 12:02, 15 July 2025 (UTC)

Oppose. It's not a popularity contest. ~WikiOriginal-9~ (talk) 14:49, 15 July 2025 (UTC)

Add image descriptions underneath album covers for articles based on specific albums

Partially as an accessibility feature and mostly as an overall addition to articles regarding albums, I feel it could potentially be useful to add image descriptions to the initial picture of the album cover underneath it. The way I see it, a description would give a brief overview of the album cover’s chosen image similar to an image ID, source of image/photographer/artist and note significance as to why that image was picked. For example, regarding Porter Robinson’s Nurture:

“ Album cover of Nurture. The cover depicts Robinson lying facedown in a field of yellow and white wildflowers. Robinson chose this particular picture due to its bold nature, regarding it as “un-ignorable”.”

[Note: I have not edited Wikipedia before. I am sorry if this is a topic that’s been debated before.] Waffled.on.pancakes (talk) 03:50, 12 July 2025 (UTC)

You seem to be suggesting a combination of alt text and a caption. In the article you link, the image already has alt text "A blonde male, Porter Robinson, laying in a field of grass and flowers." Whether a caption is appropriate, or the information should be covered somewhere else in the article, is a matter for the article's talk page. Anomie⚔ 11:38, 12 July 2025 (UTC)

You can do this. Most album article use the {{Infobox album}} template and it supports the |alt= parameter. The alt text is for accessibility and often shows up as a hovertext. I've added alt text for a number of albums, e.g., the article for Beneath the Remains. A fun game I like to play is to see is how accurately image generator AI comes to producing the album cover based on my description. Jason Quinn (talk) 16:05, 15 July 2025 (UTC)

Alternative notability guidelines for less popular topics that are of encyclopaedic interest?

Namely, women's football. Articles about players and teams are taken to AfD due to "lack of reliable sources" because the sources are unrecognisable or not popular enough. That isn't a problem with the sources themselves, as we have no reason to believe they aren't reporting factual information, but a problem with the general popularity of women's football. If we dismiss sources because they are not "well-known" then we are in danger of erasing a lot of encylopaedic content that is of interest to readers. These alternative notability guidelines would also apply to publications that write about women's football. I used football as an example, but this would extend to women's basketball and other sports that aren't very popular. I don't think it would be necessary for Olympic sports because those competitions and sportsmen get a lot of coverage from the mainstream press.

Also, these alternative (supplemental?) notability guidelines would not be a slippery slope to include all sorts of FRINGE content, but would be limited to women's sports (or a particular sport). Starting small with a targeted topic would ensure that FRINGE topics don't slip through the cracks. TurboSuperA+_(connect) 08:54, 13 July 2025 (UTC)

Given the community time that went into bringing Wikipedia:Notability (sports) in line with standard notability guidelines, I do not suspect there will be significant enthusiasm to begin to recreate exceptions. Sources are a different matter, not directly subject to notability guidelines. Sources are not usually dismissed because they are unpopular, this would somewhat eliminate most sources used. If a source is being treated as unreliable when it should be considered reliable, please raise this at Wikipedia:Reliable sources/Noticeboard. CMD (talk) 09:27, 13 July 2025 (UTC)

You know what? I just might! TurboSuperA+_(connect) 09:28, 13 July 2025 (UTC)

When you do… give us specifics. Choose a few (two or three) sources that you think are the most reliable for covering women’s football… so we can examine and discuss those. Blueboar (talk) 20:45, 14 July 2025 (UTC)

See Wikipedia:Reliable sources/Noticeboard#impetusfootball.org. -- Maddy from Celeste (WAVEDASH) 20:50, 14 July 2025 (UTC)

Commons VP discussion

Hello! There's a discussion at the Commons VP proposing the introduction of a new desk for editors to request that volunteers reach out to media rightsholders to request specific media works be released under Wikimedia-compatible licenses. This is an idea pretty specifically tied to Wikipedia (as requests will be mostly in the interest of adding media to Wikipedia articles), so I am posting here to get more Wikipedian eyes on it. ꧁Zanahary꧂ 20:32, 14 July 2025 (UTC)

Revisiting WP:INACTIVITY

Of the 7 WP:RECALL petitions so far, at least three have some concerns at least adjacent to WP:INACTIVITY - Master Jay, Gimmetrow and Night Gyr (ongoing).

Currently admins are desysopped procedurally if they haven't made any edits/admin actions for 1 year OR have made less than 100 edits in 5 years. According to WP:RESTORATION, adminship is generally restored at WP:BN unless there were 2 years without edits OR 5 years since last tool usage.

Clearly, many editors believe we need to update WP:INACTIVITY but there has been no RFCs attempted on how.

This is a preliminary RFC to ask two main questions -

• Q1: Do the thresholds for procedural desysoppings ( WP:INACTIVITY ) need changing? If yes, to what?
• Q2: On return from inactivity, when do they generally get the tools back? ( WP:RESTORATION )

I'm hoping this narrows solutions down sufficiently that a future yes/no proposal can gauge consensus later.

Soni (talk) 16:53, 16 July 2025 (UTC)

Procedural comment. This is an RFCBEFORE but it has the {{rfc}} header template. Should it be removed? LightNightLights (talk • contribs) 17:02, 16 July 2025 (UTC)

Thank you for the correction. Somehow I had misparsed RFCBefore all these years. I think it's best described as a "preliminary RFC" than RFCBefore, and should retain the RFC tag. This discussion will likely involve wide community input, even if I'm not presenting multiple options for !voting. Soni (talk) 17:07, 16 July 2025 (UTC)

Then it's not an RfC. That's not how RfCs work. It's a terrible idea to do an RfC at this stage without work shopping anything. There's no rush and adding an RfC tag, which ultimately will lead to a demand for a closure, is more of a waste of time at this point. voorts (talk/contributions) 17:09, 16 July 2025 (UTC)

I am fairly confident I have seen multiple RFCs over the years that are effectively "Let's workshop here". Therefore I believe an RFC tag is appropriate, but I may be mistaken. I have no strong feelings on an RFC tag either way, the main intent is just to ask the "Do the thresholds need changing" question. Soni (talk) 17:14, 16 July 2025 (UTC)

Well if half of the editors say "yes increase" and the others say "yes decrease", all with equally valid arguments, twe'll have gotten precisely nowhere. It's alwaus better to have concrete proposals to !vote on IMO. voorts (talk/contributions) 17:18, 16 July 2025 (UTC)

I don't think so. I think that if we find the community evenly divided on increase vs decrease, that the reasonable conclusion is that we're doing things just about right.

The bigger risk is a multi-way split (e.g., change rules to X, change rules to not-X, change rules to X+Y, change rules to not-Y...). WhatamIdoing (talk) 19:13, 16 July 2025 (UTC)

I think there is a trend of being very bureaucratic about how a request for comments discussion should proceed. Yes, it's true: requests for comments are time-consuming. But so are discussions amongst a select group of people all in agreement about a certain direction, which fails to take into account broader concerns when a larger group of people are involved. We shouldn't force all discussions into one progression. Sometimes it's better to get broad input at a preliminary stage to stake out the scope of further discussion. isaacl (talk) 18:21, 16 July 2025 (UTC)

I agree. And FTR, at last check, we've been running only two new RFCs per day (it was usually three new RFCs each day ~pre-pandemic). So we probably have some capacity for the occasional "unnecessary" or "premature" RFC. WhatamIdoing (talk) 19:14, 16 July 2025 (UTC)

Soni, thank you for stepping up and starting a discussion on this (many people have lobbied for a discussion but nobody's actually carried it out). I don't have an answer to Q2 (I don't neccesarily think an RfA should be needed, though), but the minumum edit threshold for procedural desysopings definitely needs upped, although I need to see other's opinions before forming my own on what the exact number should be. — ^EF⁵ 17:09, 16 July 2025 (UTC)

many people have lobbied for a discussion but nobody's actually carried it out See Wikipedia:Village pump (policy)/Archive 203#Admin inactivity rules workshopping from two months ago. Anomie⚔ 11:47, 17 July 2025 (UTC)

That proposal was mainly centred around WP:GAMING and WP:RECALL, neither of which are the emphasis of this discussion. I do not plan to use this discussion to inform what changes, if any, RECALL should take. I do want us to get a better idea on what we want our procedural policies on desysopping to look like.

So far we have a promising idea from User:Patar knight that can probably be workshopped further. Reduce the edit count criterion altogether, and focus on how to effectively use just admin tool usage. It probably needs proper wording from someone who understands this well. Soni (talk) 12:34, 17 July 2025 (UTC)

Yeah, that discussion was focused on GAMING. ^EF⁵ 12:50, 17 July 2025 (UTC)

Seems to me that all three things were being discussed there. The second bullet in the initial post specifically targeted WP:INACTIVITY. You also brought in WP:RECALL from the start, and gaming has also been mentioned here (although without links to WP:GAMING yet). Anomie⚔ 13:00, 17 July 2025 (UTC)

Yeah that discussion led nowhere because it was not focused enough. Which is why this one mainly focuses on WP:INACTIVITY. RECALL was mentioned primarily to explain the initial context, but I very much plan for this workshopping to be centred, above all, around what our activity standards and expectations should be. Soni (talk) 13:17, 17 July 2025 (UTC)

Just to clarify, while we both support some kind of tool usage requirement, it was Levivich who suggested removing the edit count altogether while I merely suggested a possible system for doing so. Personally, I think requiring admins to have community involvement beyond just using the tools is a good thing and would keep the edit activity requirements, which had broad community support at WP:ADMINACTIVITY2022. For exact numbers, it would probably be useful to have stats similar to what Worm That Turned did for the 2022 RFC at User:Worm That Turned/Admin activity to see what has changed since 2022, with perhaps an additional query for how back 5/10 logged admin actions go back. -- Patar knight - ^chat/_{contributions} 16:27, 17 July 2025 (UTC)

After going through the discussion I think 150 edits (#2) and fewer than five admin actions yearly (#1) would be a good compromise for Q1. ~150 yearly edits shouldn't be hard if they are active. 5 admin actions would show that admins still use, and have a need, for the toolset (although whether five admin actions is "having a need" is debatable). I also like Patar knight's idea below of using a sort of yearly "resume" of admin actions so admins can prove they are still active. — ^EF⁵ 14:46, 18 July 2025 (UTC)

• Other than some editors kvetching about the "unfairness" of desysops of some admins who haven't used their tools for several years, is anyone else calling for change? To those editors, I say: get over it. Being an admin is a privilege, not a right, and if you don't use it, you should lose it. voorts (talk/contributions) 17:10, 16 July 2025 (UTC)

  @Voorts, I think that what's missing – and what I think you might be able to supply – from these conversations is a description of the practical benefits to Wikipedia when we remove the tools from inactive admins.

  Imagine that an admin reliably makes one edit per month. In five years, that will be 60 edits, and they'll fail the five-year rule. This is the rule we've set, and I'm okay with it, but how does Wikipedia benefit from having one fewer person who could take an admin action?

  I think an agreed-upon idea about the benefits would help us match our rules to our goals. If we say, "Look, the principle is that completely abandoned accounts are at risk for getting hacked, and low-activity accounts are corrosive to community spirit because they make some non-admins jealous (even though very few of them would admit to that very human emotion)", then we should be able to get this settled a little more firmly. But if we don't identify (or can't agree upon) a purpose for the WP:INACTIVITY rules, then I don't think these conversations will ever stop. WhatamIdoing (talk) 19:34, 16 July 2025 (UTC)

  Many many many editors have already supplied rationales for inactivity rules, including the security one you cited and that those admins quickly become out of touch with community norms. The burden of persuasion here is on editors who want to change policy, not those who are fine with the status quo. voorts (talk/contributions) 20:32, 16 July 2025 (UTC)

  I've seen the security one, and it makes sense to me. I've seen the "out of touch" one (e.g., in this discussion).

  But – are those the real reasons? Because humans often begin with "Ugh, no!" or "Obviously yes", and then later seek out rational-sounding reasons to make them look smart when they're really just dressing up their intuitive or irrational response.

  I'm not trying to persuade anyone that the policy needs to be changed (or kept the same). I'm trying to figure out whether the policy achieves our goals.

  Consider the idea of "admins aren't out of touch with community norms". Is that best measured as "doesn't surprise people by taking admin actions that don't match the formal, written rules"? If so, then inactive admins are fine, because they're taking no actions, and therefore no actions that disagree with the written rules. Maybe it means "if taking an action, makes the same decision as 90% of other admins would". If so, we need to get rid of some active – and IMO some of our best – admins, but most inactive admins are fine. Maybe it means "Is a person who is familiar and active, because emotionally if I have to be rejected by my community, it needs to be done by someone whom I can respect and who feels like they're really part of the community, instead of someone who feels like an outsider or an unknown person". In that case, we might want higher activity levels, or at least to tell admins to avoid emotionally laden or socially fraught admin actions (e.g., blocking "the regulars") until they've been highly active again for months.

  But without an idea of what that phrase means to people, and whether that's their genuine reason or just the one that's socially acceptable for public consumption, it's impossible to know whether what we have works. WhatamIdoing (talk) 21:22, 16 July 2025 (UTC)

• The recalls listed above as relating to inactivity were all closely tied to accountability (or lack of) in different ways. Procedural inactivity desysoppings are set at a very low bar deliberately, being technical and explicit, and adjusting the bar (even if it is merited for other reasons) would for the purposes of the diffuse concept of community discussion likely shift the grey area to whatever the new technical bar is. A change in requirements would further catch lower-activity admins who are engaged with the community, which is not something that I've seen expressed as desirable by any editor in discussions surrounding these Recalls. The recalls are not the best place to base a new discussion on inactivity from, as many of the suggestions that WP:INACTIVITY be updated were coming from those in opposition to these Recalls as something others may want to do, and so themselves don't represent belief that INACTIVITY needs changing/updating. CMD (talk) 17:16, 16 July 2025 (UTC)
• All I know for sure is that this gives weight to the idea that ADMINRECALL may need to eventually raise the signature threshold if it's going to be used as a place to get around community created activity guidelines, that's simply not what that venue was created for. I'm not advocating for any of those who lost the tools to keep them, but it leaves a bad taste in my mouth when we're using recall for a purpose I'd argue it wasn't intended for. Also noting that the Master Jay case was about more than their activity. Hey man im josh (talk) 17:35, 16 July 2025 (UTC)

  I do not necessarily disagree with any of those points, just that this discussion is specifically to judge whether the activity thresholds currently are sufficient or not. What precisely should RECALL change, is a separate question. Either we believe the current procedural thresholds are strong enough, or we'll raise/lower it accordingly. Soni (talk) 17:47, 16 July 2025 (UTC)

  used as a place to get around community created activity guidelines I think that's an unfair assessment of what's occurred in these cases. The inactivity policy is one thing. Making a token edit once in a while to keep the user right and then going back into dormancy is another. You could increase the length of time or change the requirements, but they'll always be game-able. Also, all of those petitions were swiftly completed. Increasing the signature requirement would have a negligible effect IMO. voorts (talk/contributions) 19:01, 16 July 2025 (UTC)

  the Master Jay case was about more than their activity As was Gimmetrow, whose single (and last ever) admin action to avoid being ineligible to automatically get the bit back after their incoming 100/5 inactivity desysop was to block a vandalism only account that used an anti-LGBTQ slur for 3 hours, which is far outside community norms. They later failed to response to a query that mentioned that block and their inactivity on their talk page, which led to the recall. -- Patar knight - ^chat/_{contributions} 19:57, 16 July 2025 (UTC)

  (To clarify: The part about "far outside community norms" is that the block was only for three hours; it was later extended to an indef by someone familiar with the particular WP:LTA.) WhatamIdoing (talk) 21:28, 16 July 2025 (UTC)

  If we are re-litigating this: The edit in question (admin-only) added the text Fucķing [r slur] to a mainspace article, and told an LGBTQ editor to fuck off [anti-LGBTQ slur] in the edit summary. I don't blame anyone for not knowing it was an LTA. But ignoring everything else, that one edit is indef-able many times over. They intentionally placed the three hour block to allow time to look at other edits, as if you need more evidence to indefinitely block an account. (I very much hope the search was not for mitigating evidence; what would possibly make that acceptable?) All in all, I'd call that "far outside community norms". HouseBlaster (talk • he/they) 00:12, 18 July 2025 (UTC)

• In response to Q1, I'd propose a revision to Criterion 1 of Inactivity and change Has made neither edits nor administrative actions for at least a 12-month period to Has made no administrative actions for at least a 24-month period. Thoughts? Iggy pop goes the weasel (talk) 17:53, 16 July 2025 (UTC)

When you edit this page, the edit notice says:

This Village Pump is for developing ideas, not for consensus polling. Rather than merely stating support or opposition to an idea, try to be creative and positive. If possible, suggest a better variation of the idea, or a better solution to the problem identified.

That has not been done here. In addition to this, not enough background has been provided via links to previous discussions (where some of the changes being proposed above were rejected and arguments provided for why it was a bad idea). When was the most recent RfC on this issue? 1 year ago? 5 years ago? Having said that, I agree with CMD who said:

Procedural inactivity desysoppings are set at a very low bar deliberately, being technical and explicit, and adjusting the bar (even if it is merited for other reasons) would for the purposes of the diffuse concept of community discussion likely shift the grey area to whatever the new technical bar is.

I disagree with CMD in the last part of what he says here:

A change in requirements would further catch lower-activity admins who are engaged with the community, which is not something that I've seen expressed as desirable by any editor in discussions surrounding these Recalls.

In my view, some editors really do want to cut a big swathe through admins and get rid of the inactive ones. There is demonstrable opposition to that, but recall (unfortunately) allows for persistent drip-drip actions against individual admins. Over and above that, in my view, what needs changing is the dynamic between WP:INACTIVITY and WP:ADMINACCT (admin accountability). Simply remove the ability of people to demand that admins respond to people who come to their talk page to complain about their activity levels. Let INACTIVITY deal with activity levels, and let ADMINACCT deal with responses to actual admin actions. I am sure that a properly phrased wording could separate these two concepts so that they don't conflict any more (arguably, they don't conflict at the moment, but clearly some people need it spelling out). On a personal level, as someone who has been more active and engaged with the community than I have been in years (though that activity will likely tail off, as I will (need to!) be very busy with other matters again soon), I would like to see INACTIVITY remain stable. I will also repeat what I have said elsewhere. Try and make this a positive thing about retaining inactive admins rather than fiddling with the paperwork.

That said: Q1: No change (current thresholds are fine). Q2: No need to change the current provisions of WP:RESTORATION. Carcharoth (talk) 18:03, 16 July 2025 (UTC)

• If you believe there is a faction of editors that want to cut a big swathe through admins, please provide evidence. Recall has generated a lot of hypothetical concerns, but as for the "persistent drip-drip actions", the supposed persistency has resulted in just 3 (and it is likely one third of those won't even be certified). CMD (talk) 02:27, 17 July 2025 (UTC)

• (edit conflict) @Soni: Please don't hold policy RfCs in VPI. As it says at Wikipedia:Village pump, Idea lab is where we incubate new ideas before formally proposing them; and as the editnotice also states, this Village Pump is for developing ideas, not for consensus polling. Basically, draft up an RfC here, open it up for amendments, then once people agree that it's ready to put to the broader community, transfer it to WP:VPP observing WP:RFCST. --Redrose64 🌹 (talk) 18:04, 16 July 2025 (UTC)

  Yeah today's been a bad day for reading comprehension for me, my apologies. I think the simplest solution is for this discussion to be moved to WP:VPP, but I will let others actually make these changes. Soni (talk) 18:11, 16 July 2025 (UTC)

• Right, activity level doesn't have anything to do with ADMINACCT. If someone comes to an admin's talk page asking what their favorite color is, does the admin have to explain that too? ~WikiOriginal-9~ (talk) 18:07, 16 July 2025 (UTC)
• I'm confused: Is this an RfCBefore discussion or a big RfC discussion? Aaron Liu (talk) 18:10, 16 July 2025 (UTC)

As I stated in a previous discussion, I feel the community wants its admins to have some ongoing connection with the community, and uses recent edits as a metric to determine this. However, I also previously stated that the community has desired to balance the volunteer nature of the role against this, and to allow for healthy breaks in activity. Thus if there is a consensus to change the activity thresholds, I think the best way to avoid increasingly fractal discussion on how much activity is enough is to shift the emphasis to one of security: remove administrative privileges with a much smaller inactivity threshold (such as on the order of a few months) to limit security concerns, but make it very easy to restore on request (as it is now, but perhaps with tweaks to make it even simpler, particularly for those who have recently been active). If someone has concerns about admin accountability, or with ongoing familiarity of community norms, they should make a case based on specific evidence, not just levels of activity.

Regarding accountability during hiatuses: I don't think the admin role should be one that locks editors into perpetually being active on Wikipedia. I think it's reasonable for questions to be answered upon a return to activity. If administrative privileges are removed based on a short period of inactivity due to security concerns, then there is only a limited time when issues of misuse of privileges may occur. isaacl (talk) 18:15, 16 July 2025 (UTC)

• As I see it, the primary reason to (at least temporarily) de-sys-op admins who have been inactive is that the policies, guidelines and procedures they are supposed to be familiar with may have been amended while they were away. Thus they will be prone to making mistakes. They will need time to get up to speed on these changes. That said… once they are “up to speed”, there should be a quick and easy way to re-sys-op them. Blueboar (talk) 18:37, 16 July 2025 (UTC)

  Though I understand this point of view, I do think that part of trusting an editor sufficiently to grant them administrative privileges is to trust them to reacquaint themselves with community norms as needed. Some admins with lengthy absences have commented in these recent discussions about their returns. Perhaps we need to do more to impress this upon all administrators. isaacl (talk) 19:07, 16 July 2025 (UTC)

  I am doubtful of this "policies might have changed" rationale. After all, we see highly active admins (and non-admins) who are apparently unfamiliar with the rules they're enforcing. Admins, being more experienced editors, tend to have a good grasp of the long-term community POV on something (e.g., science is good and altmed is bad), but they don't actually track the drip-drip-drip of changes to policies and procedures with any more assiduity that anyone else. WhatamIdoing (talk) 19:41, 16 July 2025 (UTC)

• Since the format is a bit unclear, it is best to workshop what we really want to ask here before moving on to a full RfC at WP:VPP. One aspect I've seen brought up during recall petitions is the question of how WP:ADMINACCT applies to low activity admins, and that is something that should be discussed in an RfC on activity thresholds. Chaotic Enby (talk · contribs) 19:24, 16 July 2025 (UTC)

  Why wouldn't it still apply? If you are an admin and you do something using your tools, you need to answer for it. If you use your tools once every few years as a token edit, then go dormant again, and someone questions you on it and you aren't either watching your watch page or decide not to answer, those are both conscious choices. Why is giving a break to people who haven't been a part of our community in any meaningful ways for years so pressing? voorts (talk/contributions) 19:34, 16 July 2025 (UTC)

  I'm not saying it shouldn't apply, and, to the contrary, I do think that it should apply in full to any admin actions. However, I've often seen it brought up (and criticized) as an argument in recall petitions, and I was surprised it wasn't discussed here. Since we're still in the workshopping phase, I figured it would warrant a mention. Chaotic Enby (talk · contribs) 19:38, 16 July 2025 (UTC)

  The key question to me is should administrators be able to take a complete break from Wikipedia? If the community consensus is yes, then it's reasonable for them not to respond to questions during their break. If no, then I think that administrative privileges should be removed based on a relatively short threshold of inactivity, since that matches community expectations (no administrative privileges for someone taking a break), with an easy restoration of privileges upon request. isaacl (talk) 21:45, 16 July 2025 (UTC)

  Is the story here something like "If Alice Admin usually only makes one edit a month, and she deletes an article today, then she might not check her User_talk: page for another month, which would violate the ADMINACCT requirement to respond promptly and civilly to queries about their Wikipedia-related conduct and administrative actions"? WhatamIdoing (talk) 19:44, 16 July 2025 (UTC)

  Roughly, although the cases brought up in recall petitions usually focused on specific issues about which admins didn't respond, rather than the possibility that they might not due to their activity level. Chaotic Enby (talk · contribs) 19:46, 16 July 2025 (UTC)

  In the past, I'm pretty sure that we had a rule saying that if an admin knew that they weren't going to be available for a few days (e.g., the day before leaving on a trip), they shouldn't take any admin actions, or if they did, they should try to leave a note to help other admins with appeals ("Any admin: It's okay to overturn this without talking to me first"). I wonder if that rule still exists. WhatamIdoing (talk) 21:33, 16 July 2025 (UTC)

  At the risk of sounding like Captain Barbossa, I don't recall it being a "rule." I think it was more of a guideline or suggestion. Joyous! Noise! 23:22, 16 July 2025 (UTC)

Thanks for starting this discussion, Soni. I'd support just dropping the edits part of the inactivity requirement (100 edits in 5 years) altogether, and instead just require the admin actions part (1 in a year... but not necessarily just logged actions). I think that change, alone (dropping the edits requirement, but not changing the admin action requirement, at least at this time), ought to be put to an RFC. If that's approved by the community, we can skip a long discussion about how many edits are enough edits. If it's approved, the community can later decide to increase the admin actions requirement if 1/year turns out not to be enough for whatever reason. Levivich (talk) 20:10, 16 July 2025 (UTC)

The issue is that non-logged actions can be very difficult to measure. Closing a TBAN proposal at ANI is pretty clearly a non-logged action that we can check for, but what about, say, looking at deleted edits to identify patterns of abuse? Chaotic Enby (talk · contribs) 20:36, 16 July 2025 (UTC)

If there's no logged action in a year, the admin could be prompted to edit some new subpage of Wikipedia:Inactive administrators to provide an example of edits that show use of the tools, perhaps with a short explanation if necessary, for bureaucrats to assess. If say an admin says they looked at deleted edits in the context of abuse, it's not unreasonable to require them to point to an edit in which they comment on the user being investigated/discussed or a revert of that user. -- Patar knight - ^chat/_{contributions} 21:05, 16 July 2025 (UTC)

Actually a great idea, and it would also help with WP:ADMINACCT! Chaotic Enby (talk · contribs) 21:13, 16 July 2025 (UTC)

Agree, great idea. The automatic inactivity notice that's already posted on admins' talk pages could be modified to say something like "if this notice is in error and you have made an admin action within the past year, please post at [link]". Crats can review that page before the switch is thrown. I bet this would be a very, very rare occurrence and result in very little additional work. Levivich (talk) 21:21, 16 July 2025 (UTC)

Frankly, we could do with having some additional work. Useight (talk) 17:00, 17 July 2025 (UTC)

I'd be fine with just a "1 logged admin action per year" requirement. Keep it simple. Levivich (talk) 19:13, 17 July 2025 (UTC)

That's a pretty good idea Iggy pop goes the weasel (talk) 21:29, 16 July 2025 (UTC)

I'd sign up for that idea. Buffs (talk) 23:16, 16 July 2025 (UTC)

This feels much more in spirit of admin accountability without too much emphasis on arbitrary thresholds. I definitely prefer this as a lighter weight "Adminship is easy to remove and restore" than any alternatives. Soni (talk) 04:18, 17 July 2025 (UTC)

I have never found non-logged actions can be very difficult to measure to be a strong argument. If we have a user making so few administrative actions that they can only point to edits exercising administrative authority requiring the use of non-edit user rights to retain their tools (our current inactivity rules not being particularly onerous), it remains pretty questionable to me that they should need the full kit. Izno (talk) 22:35, 16 July 2025 (UTC)

I agree that if we ask for admin actions, we should ask for logged ones (perhaps including editing protected pages). Admins using the tools in a hidden but beneficial way without ever doing anything logged are probably a myth and not worth making the process more complicated, even by a tiny bit. —Kusma (talk) 07:12, 17 July 2025 (UTC)

I appreciate the initiative. However, I think it's not a well-formed question for Q1. Q2 is fine as it's a yes/no question. I would recommend an RfC along those lines, but give some new thresholds like:

1. Change the thresholds
   1. Desysop at 1 year with no edits/admin actions or 100 edits in 5 years (0/1, 100/5)
   2. Desysop at 0/1, 50/2
   3. Current thresholds or 0 admin actions in 2 years or 10 in 5 years
2. No change

• etc

Set up some sort of threshold to assess from. Admins can make the assessment regarding whether people want a change and roughly where that consensus lies. 90% of the people could choose something in 1. showing there is significant desire for a change or conversely 60% of the people could choose option 2 and, regardless of the debate within the options under 1, no change should occur. Buffs (talk) 20:47, 16 July 2025 (UTC)

Before we can have a reasonable discussion about whether we should increase the activity requirements, we need to have some clear comments/proposals, etc detailing why they should be changed that clearly set out what the problem that changing the requirements is intended to solve, what is the evidence that this is actually a problem, and how changing the activity requirements will solve that problem. I don't recall seeing any of that in the recent discussions. Thryduulf (talk) 21:01, 16 July 2025 (UTC)

I agree. For example, @Levivich has an interesting idea. It makes intuitive sense to me (if you're not using the tools, you don't need the tools). But what problem does this solve? Is the problem it solves the same as the (social/emotional) problem that the community has with inactive admins? WhatamIdoing (talk) 21:36, 16 July 2025 (UTC)

WP:INACTIVITY should be amended to make it clear that the spirit of the law is more important than the letter of the law (just like with all other Wikipedia procedures), and that rights gaming is applicable to retaining admin rights. Admins should have the tools if the community supports them having the tools and they should not have the tools if the community does not support them having the tools. Right now, the barometer for whether the community supports tool-possession is RfA or AELECT. If someone can pass those, there is consensus for them to have the tools. If they cannot pass those, there is not consensus for them to have the tools. The problem here is that the tools are seen as a permanent entitlement of status rather than a tool for service, and that not being an admin is some kind of downgrade or lower class. Thebiguglyalien (talk) 🛸 21:41, 16 July 2025 (UTC)

• Also noting that there are some comments here without bullet points or indents, which is messing up the formatting of the discussion. Thebiguglyalien (talk) 🛸 21:41, 16 July 2025 (UTC)

  It's reasonable to use a new paragraph for comments that aren't a direct reply to a previous comment. isaacl (talk) 21:49, 16 July 2025 (UTC)

rights gaming is applicable to retaining admin rights is something I do not think has consensus, but if we want to make that part of some question it seems reasonable.

We set a number deliberately. If we want to change that number to some number that we actually believe indicates real activity, we should (and I would personally welcome an adjustment to the numbers, but ~consensus gathering activity~). Taking potshots at admins who aren't here all the time isn't the way to do that. NB that I don't think all three of the admins above even fall into the category of "sent to admin recall solely because of inactivity", and I think we see the results of that with how quickly (or slowly) the admins have reached 25 signatures at recall.

Another approach to stopping what is perceived as gaming is to remove the "next month you're being desysoped" messages. Those are likely to be the primary cause of the once-a-year / couple-a-month edits. If people really want to keep their tools, they can do their own homework.

An appropriate change the opposite direction might be to forbid admin recall solely on the basis of inactivity directly in WP:RECALL. There's got to be something more than "the hard rule you've been provided for keeping your hat is the hard rule you're meeting". Our default position should be to trust administrators, because they earned that trust via RFA.

But I'm sure all of this was all argued in the last RFA review mess that has now spawned this growing pain. Izno (talk) 22:58, 16 July 2025 (UTC)

• Soni, I think it would be useful at the top of this discussion to have links to previous RFCs and discussions we have had on this subject. We don't need to reinvent the wheel and I think this discussion would benefit from seeing ideas that have already been proposed in the past that didn't pass a vote. We are not starting from scratch here, we've gone through other RFCs on this matter. Thank you. Liz ^{Read! Talk!} 22:10, 16 July 2025 (UTC)

  @Liz Do you have a list of such RFCs and discussions you think should be listed? Soni (talk) 04:02, 17 July 2025 (UTC)

  There's the two RFCs in the footnotes from WP:INACTIVITY. There's some failed RFCs here in 2019 [20] and 2015 [21] from what I recall. Not sure if there were other RFCs here in the archives, elsewhere, or other discussions. -- Patar knight - ^chat/_{contributions} 05:18, 17 July 2025 (UTC)

  There was another attempt at "workshopping" just two months ago at Wikipedia:Village pump (policy)/Archive 203#Admin inactivity rules workshopping. Anomie⚔ 12:02, 17 July 2025 (UTC)

• For Q1: In my opinion, yes. Change criterion #1 from: Has made neither edits nor administrative actions for at least a 12-month period to Has not made any logged administrative actions for at least a 12-month period. Change criterion #2 from: Has made fewer than 100 edits over a 60-month period to Has made fewer than 100 edits over a 30-month period. Some1 (talk) 22:56, 16 July 2025 (UTC)
• Q1: no. Q2: whenever. Think of this, instead, as being in a volunteer organization in a leadership role. If you've put in the time to be trusted as a "lead" in something, typically speaking, you've been filtered for sanity and dedication to doing the right thing. There are obviously exceptions (and sociopaths exist in any org). But you're not going to make someone re-prove themselves from the ground up if they step away for a year or two. Life freaking happens.
  Sure, you'll expect that they get back up to speed with current procedures, but that's something that "leads" are already used to doing, and know if they make a mistake, they apologize and fix it. That said, you probably should be cautious when someone comes back from absence; "trust but verify," because egos are a thing. And that could (and should) factor in. But the amount of assuming-bad-faith from some of the commenters here is incredible. When someone steps away from the project, it's not someone "cheating" on the project. It's someone doing something else to help the world. Or perhaps getting their crap together in real life. Or perhaps landing a new job. Or having a baby. Or just a really long bout of depression. Anything other than, "Well, they forgot everything about how to Wikipedia. Now we have to assume they're an idiot that can't be trusted." That's just not generally how people work. That's not how volunteer-driven orgs work. In fact the ones I work with now specifically carve out at least a year of inactivity before you're truly considered inactive.
  And just like in volunteer organizations, if someone's inactive, the assumption is that anyone can undo their actions. And I get where people are coming from: the faceless immediatism of the internet creates a bias toward seeing other editors as faceless while expecting of them the same immediatism. Giving into that fosters a situation where, eventually, only those truly dedicated to being an admin will be admins, and that should scare the living daylights out of anyone who pays attention to business or politics in the real world.
  --slakr^\ talk / 06:51, 17 July 2025 (UTC)

  @Slakr, I hadn't thought of comparing it to real-world/face-to-face volunteer work before, but I think you're entirely right. Orgs that depend on volunteers don't treat those who come back after a break like they are ignorant, untrustworthy or like they have been unfaithful to the group. A return to activity is really treated as a situation that should be celebrated. You make sure their old friends know. You introduce them to the new folks. You brief them on any important changes and if there's something that might sound like any sort of reflection on them, you explain ("Oh, we got a new accounting firm, and they insist that two people always be present when the mail is opened. It's a bit of a pain, but they said that they always recommend it after discovering a thief stealing checks from one of their other clients..."). You don't treat them like they need to prove themselves again, unless you actually want them to quit. WhatamIdoing (talk) 07:30, 17 July 2025 (UTC)

• • As someone who has both volunteered and managed volunteers, I cannot think of many meatspace volunteering positions where you have the power to kick out other volunteers and tear up their work, and where those exist they generally don't get handed to people who have just returned to the organisation after a long absence. In my experience working with volunteers, that would be an absolutely terrible idea. Caeciliusinhorto (talk) 20:01, 17 July 2025 (UTC)

@Slakr: Thank you, this is a good way to think about returning admins. But we do see a huge amount of bad faith displayed towards admins returning from inactivity and asking for the bit back. There is strong feeling in parts of the community that they should prove themselves first. I think those parts of the community have got it wrong and that their attitude is making it harder for people to volunteer to do admin work again, but I don't think we can just ignore them. See the NaomiAmethyst resysop discussion we had a few months ago. Perhaps it would be easier to have formal criteria for resysopping (but we'd still need a way to deal with the people who consider meeting the formal criteria to be WP:GAMING). —Kusma (talk) 13:42, 18 July 2025 (UTC)

• Q1, maybe?, Q2, no, outside of a clause for recall for WP:GAMING As a person who has spent a fair bit of time working in security (simply out of the principle of least privilege), I'm always for make the desysop window tighter but allow for restoration with some activity. That being said, I'm not going to strongly advocate for desysopping faster since I do recognize that folks do take extended vacay, and often drop away from time to time. I think our priority there should be to build robust pathways for folks to reintegrate back into the admin corp, something that we severely lack at the moment. I don't necessarily think our WP:RESTORATION policy is bad, but I would advocate for enshrining recalling for WP:GAMING into the admin activity metrics, purely since I see it as a "I will follow the letter of the law, not the spirit" activity that Wikipedians just should not engage in. Sohom (talk) 18:14, 17 July 2025 (UTC)

Updated Admin Activity Stats

Someone suggested that we should have an updated version of User:Worm That Turned/Admin activity for 2025, to get an idea of how many admins would currently be hit by "Last admin action" rule, among other things. Is there someone who can generate such a table relatively easily? I don't know what kind of querying will allow that. Soni (talk) 23:48, 17 July 2025 (UTC)

I believe it was @Patar knight who suggested it. I re-ran my old scripts and added a bit. User:Worm That Turned/Adminship term length/new for anyone who wants the data. Worm^TT(talk) 10:41, 18 July 2025 (UTC)

Oh and just noting - ~100 of our admins haven't made 50 edits in the past 2 years, ~200 haven't made 50 edits in the past year, and ~250 admins haven't taken any admin action (defined as appearing in delete / protect / block) in the past year... we have about 850 admins. Worm^TT(talk) 11:11, 18 July 2025 (UTC)

Thanks for these stats, but I think there is an error. Looking at my entry, it states my most recent admin action was 2025-06-25, 5 actions go back to 2025-06-25 but 10 actions go back to 2025-07-15. The relevant dates should be 2025-07-16, 2025-06-25 and 2025-06-17 respectively. Thryduulf (talk) 12:26, 18 July 2025 (UTC)

Putting the data in a spreadsheet, there doesn't appear to be a problem with the edits but there are 548 entries where the most recent action is older than the 5th and/or 10th most recent and/or the 5th most recent action is older than the 10th most recent. Thryduulf (talk) 12:53, 18 July 2025 (UTC)

Thanks @Thryduulf I'll have a look Worm^TT(talk) 12:57, 18 July 2025 (UTC)

@Thryduulf, I see the bug, will regenerate. Though I will say I get slightly different dates for you, as 5 events in this log go back to 2025-07-04, and ten between the three logs go back to 2025-06-25... so those will be the numbers that should come out the other end. Give me a few mins. Worm^TT(talk) 13:16, 18 July 2025 (UTC)

Hopefully all correct now :) Worm^TT(talk) 13:59, 18 July 2025 (UTC)

Thanks, this is great. Would it be possible to add other logged admin actions such as User rights/Edit Filter Modification which are already options at Special:Logs? -- Patar knight - ^chat/_{contributions} 08:53, 19 July 2025 (UTC)

Wow, that's way less activity than I imagined. I'm now thinking like 100 edits and 10 admin actions per year. The people who have the power to sanction me need to be at least as active as I am. The idea that I'm at constant risk of being sanctioned by people who make less than 50 edits a year is upsetting. Levivich (talk) 14:33, 18 July 2025 (UTC)

But you aren't at constant risk of being sanctioned by people who make less than 50 edits a year. Sure, there are lots of people who have the technical ability to sanction you, but if they have less than 50 edits a year, they do not have the social standing to block you and make it stick; if they wrongly block you they are probably going to be desysopped. Your claim The people who have the power to sanction me need to be at least as active as I am is also obviously nonsensical. In practice, you are far more likely to be blocked by an active power user than by a near-inactive one. —Kusma (talk) 14:56, 18 July 2025 (UTC)

Somehow "don't worry, it won't stick" doesn't make me feel better :-) As for being desysopped for bad blocks? Think about admins who have been desysopped for bad blocks (anyone), and then ask yourself: how many bad blocks of how many editors over how many years did it take before they were finally desysopped? It was never "1", was it? Yeah, no, people who make like 50 or 100 edits a year shouldn't have access to these tools. They should be pulled for inactivity and they can get them back when they regain activity levels. I am now also thinking that WP:RESTORATION should require compliance with activity requirements before restoration (rather than just the expression of an intent to comply). Levivich (talk) 17:13, 18 July 2025 (UTC)

People have been desysopped after a single bad undelete that showed they were out of touch. The people who aren't desysopped for bad blocks are usually highly active and their blocks are against newbies, not against noticeboard regulars. Desysopping people who never use the block button has no effect on the number of bad blocks at all. But forcing people to make admin actions will mean more bad admin actions. Not really seeing the benefit there.

We need less suspicion towards returning admins, not more. If asking for activity before resysop helps to make it a more friendly process, we can try it. —Kusma (talk) 17:57, 18 July 2025 (UTC)

I can think of one admin who was desysopped (by arbcom) over one undeletion and that's the only example, I think, in at least 5 years? Is it more common than that? But I don't want to get sidetracked by that; I think we'd both agree that it should take more than one bad undeletion or one bad block to be desysopped--everyone makes mistakes.

I do share your concern that upping the minimum tool use will cause bad tool use. Part of me thinks "yeah, let it happen so we can desysop those people." As a side note, I'm shocked to see there are admins who apparently have used the tools less than 5 or 10 times ever, and I think that's concerning. I do strongly believe admin tools should be "use it or lose it." I'd support a two-prong requirements: minimum edits and minimum logged actions, rather than one or the other.

These lines in the sand (20 edits/yr or 50 or 100) seem very arbitrary. It's not like if you make 100 edits in a year you'll be great but if you make 50 you'll be totally out of your depth. It's hard to find a logical place to draw a line, although it has to be drawn somewhere. One logical place to draw the line is at the same place as some other suffrage or similar requirements. WP:TWL requires 10/month, which is 120/year. Maybe it'd be good to have one site-wide line for "active" that applies everywhere: RFA/AELECT, ACE, TWL, and admin inactivity. 120 edits/year or 10/month seems reasonable to me. Maybe admin req's should be 2x that, the logic being that an admin should be more active than a regular editor?

And then having return-to-activity-first-then-restoration I think would help eliminate some of the drama we've seen surrounding return to activity predictions. Levivich (talk) 18:23, 18 July 2025 (UTC)

Admins are trusted with the tools so they can carry out admin actions. How is it that there can be any admins that have not carried out a single admin actions in the last 5 years? -- LCU ActivelyDisinterested «@» °∆t° 10:18, 19 July 2025 (UTC)

The stats are interesting. Thanks, WTT. I was having a quick look over them, though do not have time to comment in any detail. I did want to pick up on Levivich's comment about wanting admins to be as active as they are. Forgive me for asking, but do any of these feelings come from the quote on your user page (which I looked at today)? And as another comment, the activity numbers you are coming up with for other areas are interesting. I wonder why, historically, they are so different? Is it possible to see how many admins would fail to meet your increased requirements (e.g. the Twinkle ones)? Carcharoth (talk) 19:31, 18 July 2025 (UTC)

No, the quote on my userpage has nothing to do with inactive admins. Levivich (talk) 17:38, 19 July 2025 (UTC)

@Worm That Turned Is the script you are using something that can be widely shared? I don't know if there's any info in there that shouldn't be leaked, but otherwise having the script be open source/editable by others seems like a positive. Soni (talk) 07:50, 19 July 2025 (UTC)

Very interesting, thanks WTT. How many edits that can only be made by an admin don't make the logs, I wonder? Valereee (talk) 14:15, 19 July 2025 (UTC)

Should vital articles only be open seasonally?

WP:Vital articles has been around for ~16 years now. Every month, there is a huge volume of discussions, across several subpages over whether X article should be a level 5 vital article, a level 4 vital article, if a person is better sorted as in psychology or politics... I stopped counting how many words have been expended over the last month at 3 tomats, without even making it out of level 5 discussions.

Is it time to say—we've got it close enough. Whatever small benefit an article gets from being rated the correct amount of "vital" is minimal, subjective, and the article it is replacing will generally be an edge case anyway that we probably want to prioritize to a similar extent (the 9,000th most vital vs 11,000th). That benefit certainly doesn't justify the volume of discussion. 16 years in, we are far into diminishing returns.

As some articles may become more "vital"" over time, e.g. Elon Musk or ChatGPT, there may be some value in periodically check in. One option I mention in the subject line is to have reassessments open for one month or so a year. Other options may be better. Rollinginhisgrave (talk | contributions) 05:26, 17 July 2025 (UTC)

If the volunteers who are engaged in that process feel like it is a reasonable use of their time, then why not let them? They're not bothering anyone else with their activity. People who think that it's pointless can just ignore it. WhatamIdoing (talk) 07:32, 17 July 2025 (UTC)

In addition to this, the nature of the vital articles project is that people who aren't interested in other aspects of Wikipedia contribute. If participation is forced to be limited, there's not going to be an uptick in content creation or AfD participation. They'll just leave. (Also, the lowest, most active, level of the project is a very, very long way from being as stable and nebulous as the top three or four levels. Talking in the realm of decades.) J947 ‡ ^edits 09:49, 17 July 2025 (UTC)

It's possibly not a good thing to have a project running mostly independently of actual content work, especially as it creates a guide to content development priority (and this guide is used sometimes, for example in WP:The Core Contest). Seasonality may not work or be useful for other reasons, but it's strange that there were one or two sockfarms and a great deal of LOUTSOCKING in the vital articles discussions, discussions which go on to affect ~50,000 talkpages. CMD (talk) 12:18, 17 July 2025 (UTC)

Essentially, our goal is actually to write an encyclopedia, which seems trite to say. I genuinely believe that editor time is our most valuable resource. I don't buy the claim that editing time isn't, at least in part, a zero sum game, where reductions in editing in one area will increase editing in other areas. And even if as J947 says we won't gain any new editing in other areas, it will stop being a honeypot for new editors who would otherwise contribute more substantively. Rollinginhisgrave (talk | contributions) 22:34, 17 July 2025 (UTC)

• Oppose: per Whatamidoing. Not harming anyone for the project to be open. Would you close anything else simply because the discussion ran several tomats? _pbp 13:38, 17 July 2025 (UTC)

  This is the Idea Lab, which is not a place to vote on any proposals, but a place to discuss and refine ideas. —Kusma (talk) 13:43, 17 July 2025 (UTC)

  This idea shouldn't go any further. I'm sick and tired of proposals to limit or disband the VA project. There's never been any consensus to limit or disband it, why beat a dead horse? _pbp 18:53, 17 July 2025 (UTC)

  When was the last time it was brought up? Levivich (talk) 19:07, 17 July 2025 (UTC)

  Purplebackpack89 I don't intend to disrespect VA, I just would like to have a discussion of what completion could look like for the project. I did check the VP archives, and there wasn't much discussion (except for this silly proposal) and nothing of the type I'm proposing here. Rollinginhisgrave (talk | contributions) 22:45, 17 July 2025 (UTC)

It's an interesting concept to have only periods of vital article stuff, but it might be best to just leave it to the status quo. I think a seasonality would only enforce a status quo that doesn't need to be enforced. InvadingInvader (userpage, talk) 19:44, 17 July 2025 (UTC)

People make nominations as they occur to them. This is not a seasonal thing. A seasonal nomination process would cause us to forget many of the nominations that we came across. Additionally, some nominations take 4 or 5 months to resolve.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 21:17, 17 July 2025 (UTC)

Some nominations will be lost, but it's important not to let perfect be the enemy of good. Rollinginhisgrave (talk | contributions) 22:38, 17 July 2025 (UTC)

If I understand you correctly, you're arguing that time spent making proposals to the vital articles list is not proportionally useful to Wikipedia at this point. Compared to something like editing articles, this is true. However, Wikipedia is all volunteer work, and I don't think that if VA were to be closed for some period of the year, the people discussing at it would instead start editing for a proportional amount of time; that's definitely more involved. ALittleClass (talk) 02:46, 18 July 2025 (UTC)

ALittleClass Looking at the above, the idea appears dead on arrival. Purely for my own interest, if you wouldn't mind answering: I see proposals like this crash every so often when proponents speculate that editors will react to something in a good way, and opponents speculate that editors will react to something in a bad way. So long as we are kind of guessing which way it will go, the best outcome always seems to me to test it, through a trial in the least destructive manner. For instance, close VA for a minimal amount of time (2 weeks, a month) and see if the regulars activity picks up in other areas. Is that approach attractive to you? Is there anything that would make that approach attractive to you? Perhaps this would be more appropriate discussed on your user talk page. Thanks, Rollinginhisgrave (talk | contributions) 04:44, 18 July 2025 (UTC)

To offer my perspective on this: Despite being a fairly active participant in discussions (and also one that sought to improve the articles) for a good while there, I'm now trying to distance myself from vital articles outside of occasional proposals or votes. If proposals were limited to only happening at a specific time of year, I would feel even less inclined to be involved. λ NegativeMP1 04:00, 18 July 2025 (UTC)

Spinning thoughts here, there is some potential merit to a rotating area of focus. Stick a proposal a week into some central area so the small number of regulars can get it done one way or another. Things linger because 50,000 articles is so incredibly diffuse that there isn't enough participation to meet even the low standards of approval/rejection. CMD (talk) 05:23, 18 July 2025 (UTC)

Sure, whatever the editors interested in vital articles agree upon is fine. In general, editors working on initiatives are free to choose their own ways of working, as long as it doesn't impose any additional work or have any negative effect on others. isaacl (talk) 16:07, 18 July 2025 (UTC)

Hard disagree, we don't have it close enough (especially at level 5). Currently, I'd say past level 3, we have a random brainstorming of articles. I've recently been working on getting some statistics for the 50,000 articles (Wikipedia talk:Vital articles#Dataset with statistics for the full project, and think that now that we are approaching a raw 50,000, we can start sorting out things with a quantitative approach. Currently would like to start moving the API calls and list I created into some sort of bot, but am still thinking about how I'd implement that as the API calls take several days to get data for all the articles. Once we have a set list, we could in theory just update that as we go, but statistics for ALL the articles will quickly become out dated and need to be refreshed. We will need a lot of time/activity to actually chew through and refine the list we currently have.

On another note, why would we ever limit discussion like this? Should we make Good article nominations seasonal? Such a closure would kill momentum, new users periodically come to vote there, and if it wasn't in the "season" they likely wouldn't wait around a year. I am reasonably active there, and this proposal would kill all enthusiasm I have for it. Honestly, this proposal is not really in the spirit of Wikipedia:Five pillars, in that it is a rule that would limit how/when people can edit. Seems like it would just be enforcing the status quo, making it hard to make changes. It is already harder to move articles between levels in the vital list then it is to delete them, like seriously it would be less effort to delete a level 4 article then to get it completely removed from the list. GeogSage ^{(⚔Chat?⚔)} 17:39, 19 July 2025 (UTC)

Developing the Scope of a third LUGSTUBS RFC (LUGSTUBS 3)

So far, LUGSTUBS 1 is 1896-1912 Olympians, and LUGSTUBS 2 is a bunch of Cricketeers. LUGSTUBS 3 is something often mentioned in a ton of discussions, but never fully proposed. I experimented with a little bit of @BilledMammal's Quarry queries for a LUGSTUBS Mini dedicated to 1928 Summer and Winter, but my knowledge of coding is very limited. Quarry records however do show that Billed has been developing some Lugstub proposals.

I wanted to kind of officially (for lack of a better term) centralize discussions on where a third Lugstubs RFC should target, and after noticing @Oaktree b suggested a mass draftification of Olympians based on how often they make it to AFD, I think we should consider centering it on there. I think that the five year countdown is sufficient for draftspace, maybe even three years if there is enough community consensus momentum, and using a similar quota to the LUGSTUBS 1 criteria, that being Never won an Olympic medal, Referenced only to Olympedia or Sports Reference, and No significant contributions from editors other than Lugnuts. I think that moving on to the 1920s and 1930s is a good place to start evaluating for a potential query. For the sake of consensus, future Lugstubs proposals might best be grouped into groups of about two decades worth of Olympic Games. I think that draftification is best, but require a re-move back to the mainspace come with at least one additional example of SIGCOV, unless the page is being turned into a redirect. I think that there should be a highlight on redirection as well since that does seem to be a popular alternative for many, but install the caveat that de-redirecting include some SIGCOV be added. Open to hearing other feedback as well - that's why I'm putting this in the idea lab first without a VPPR.

Feel free to ping anybody you may also think as well would be interested in keeping an eye on this or have some input. InvadingInvader (userpage, talk) 18:54, 17 July 2025 (UTC)

• Given that your attempts to "target" these "non-notable Olympians" is seeing speedy keep after speedy keep after keep after keep, I don't think a "LUGSTUBS 3" is appropriate or necessary. BeanieFan11 (talk) 19:50, 17 July 2025 (UTC)

  OTOH, if people are still irritated about how the LUGSTUBS2 proponents refused to do anything except complain about how the other volunteers didn't drop everything and do what they were told, or by these failed AFDs, then a LUGSTUBS3 might result in quite the opposite conclusion. I doubt that it would reverse the NOLYMPICS decisions, but it might result in a WP:NODEADLINE grandfathering rule. WhatamIdoing (talk) 20:10, 17 July 2025 (UTC)

  Keep in mind that BilledMammel, who organized the queries from LUGSTUBS and LUGSTUBS2 has been on a wiki-break for almost a year, and if he was still here I think that the process resulting from LUGSTUBS2 would've been much smoother and quicker. Even so, I think both LUGSTUBS and LUGSTUBS2 have been net-benefits to the project. In addition, just because you opposed these proposals doesn't mean they wren't beneficial to the project. Grandfathering is a terrible idea (and also against policy) considering there are WP:BLP1E and others issues with many of the LUGSTUBS still in mainspace, and I seriously doubt a proposal to do so would lead anywhere considering WP:NODEADLINE is just a essay. I do think that it is a bit premature to organize a RFC without getting more consensus but I'm quite skeptical of using WikiProjects as a solution when it comes to this stuff, seeing as in general they will have the bias of thinking all (or the vast majority) of the content in their topic area is notable. Let'srun (talk) 00:28, 18 July 2025 (UTC)

  I was not previously aware of Mammal being on wiki break. Thanks for the notification! InvadingInvader (userpage, talk) 01:05, 18 July 2025 (UTC)

  Let'srun, I'm not hoping for a grandfather outcome. I'm warning that if we push too hard or too fast, we might end up with one. One of the community's historical responses to somebody demanding that other volunteers do work that the demanders are refusing to do themselves is to declare that nobody ever has to do that work.

  (Also: A lot of our advice is "just an essay". Wikipedia:The difference between policies, guidelines and essays is not always important.) WhatamIdoing (talk) 03:13, 18 July 2025 (UTC)

  If I recall LUGSTUBS2, it was I who was demanded to do work, and I've not seen evidence the demander actually used the work like they stated they intended to. If LUBSTUBS2 had simply played out, there would have been very little work anyone needed to do. CMD (talk) 15:16, 18 July 2025 (UTC)

• InvadingInvader, the editors who cleaned up LUGSTUBS2 have repeatedly said that if someone would please just drop small-ish lists on the WikiProject's talk page, they'd be happy to clean them up. So I wonder why, given this fact, you are still talking about a long WP:BUREAUCRATIC process that, in practice, will look a lot like this:
  1. another pre-RFC discussion (because we have talked about exactly this at least twice in the last couple of months, right?)
  2. a month-long RFC
  3. waiting for someone at Wikipedia:Closure requests to write a summary
  4. probably a Wikipedia:Close challenge
  5. nothing happening for months because nobody does the simple, practical thing that actually helps and has been repeatedly requested (i.e., making a few lists of articles that should be prioritized for review), because actually doing what's needed is Somebody else's problem and I'm not willing to do anything except vote that those other lazy WP:VOLUNTEERS do what I think should be done and then complain when they didn't do it fast enough to suit me
  6. complaining that "they" didn't do it fast enough to suit me
  7. somebody (but not me, because I'm not helpful, supportive, or collaborative) actually doing the thing that's needed
  8. the pages finally get reviewed and process (by those other lazy WP:VOLUNTEERS, not by me, of course)
• as opposed to a quicker, simpler process that you could do yourself, right now, which is:
  1. Make a list of a few dozen (related) articles that you believe need to be reviewed.
  2. Post it on a relevant WikiProject's talk page and nicely ask the editors there to deal with it.
  3. Repeat as needed, until you no longer believe any sports-related articles require reviewing.
• I really think you should give a lot more thought to trying out this faster and easier process, because I think that it will be a lot more functional and effective. WhatamIdoing (talk) 20:08, 17 July 2025 (UTC)

  If you decide to have another big RFC, though, I suggest you offer these suggested votes:

  1. Support in practice – I'm willing and able to put hours of my own time into editing articles to make this happen. (Expect to be contacted by organizers if the proposal succeeds.)
  2. Support in theory – It'd be nice if somebody else did this work, but realistically speaking, I won't do any of the work myself.
  3. Oppose (for any reason)

  WhatamIdoing (talk) 20:28, 17 July 2025 (UTC)

  I might actually try that. Thanks for the idea! I'll take a look at it. InvadingInvader (userpage, talk) 20:33, 17 July 2025 (UTC)

  If you get stuck, feel free to drop by my talk page. I can't do much with Quarry queries (though you can always Wikipedia:Request a query from people who can), but I'm willing to help you sort out a process for making and distributing lists. WhatamIdoing (talk) 03:14, 18 July 2025 (UTC)

  I wouldn't be opposed to something like that (I assume you're referring to suggestion that starts Make a list of...) – if you come up with something like, 50 articles and say "try to find sourcing or they'll be taken to AFD in [this number of] weeks", I could live with that, as long as the list is of Olympians from a country I am good at researching. In other words, that would be for the United States, Canada, Hungary, Romania, and Bosnia and Herzegovina (to a lesser extent, Guam, Switzerland, Australia and Iceland). There's also a few editors I have in mind that are excellent at researching Olympians for Norway, China / Hong Kong / Taiwan, and Egypt, respectively, although I'm not sure how interested they would be in doing something like that. BeanieFan11 (talk) 15:31, 18 July 2025 (UTC)

  I see no reason to complicate this. If a RFC were to be organized, leave the options open to simply support or oppose. The organizer of the RfC should have determined an implementation plan (including contacting other users for assistance) should the proposal succeed beforehand, and as such there is no WP:BURDEN on any volunteer. Let'srun (talk) 00:33, 18 July 2025 (UTC)

  BURDEN says that any editor can demand that a person adding a fact also add one (1) inline citation for that fact. It doesn't say anything about the problems of human nature, such as complaining that other people haven't yet the thing that you want done, but that you don't want done badly enough to do it yourself, and that you didn't determine an implementation plan or identify any volunteers for either before or during the RFC. "Splitting" the support votes would help the organizer develop that implementation plan. WhatamIdoing (talk) 03:09, 18 July 2025 (UTC)

  That plan can be determined in the pre-RfC process, which will allow for a much easier implementation process if the proposal achieves consensus. It is inappropriate to create any type of split which will simply be weaponized by users who wish to keep the mass-created articles, such as yourself. Let'srun (talk) 04:08, 18 July 2025 (UTC)

• For those of us who weren't around for LUGSTUBS and LUGSTUBS 2, would anyone care to throw a link or some explanation into the opening post of this conversation to provide context? -- LWG ^talk 16:01, 18 July 2025 (UTC)
  • Simple explanation: a user named Lugnuts made lots of sports stubs (some notable, some not, though I would say more are notable than not), some users like InvadingInvader dislike the stubs, and thus made "LUGSTUBS" and "LUGSTUBS2" proposals to move ~2,000 Lugnuts articles to draftspace, both of which narrowly passed. Now the suggestion is to do more of the that. BeanieFan11 (talk) 16:07, 18 July 2025 (UTC)

    That's a very poor explanation that will not really help LWG understand the situation. It somehow misses that the "user named Lugnuts"'s article creations were poor enough that their autopatrolled was removed, they were community topic banned from making new articles, and the community found out it had to put a huge time investment into cleaning up everything. Later related conduct then led to Lugnuts being indefinitely banned by ARBCOM. Your explanation also misses that Lugnuts' final statement was that their articles had copyvio and factual issues, which possibly untrue, but does lean into the already known issue that thousands of articles likely needed cleaning up. CMD (talk) 17:14, 18 July 2025 (UTC)

    I can say with near-certainty that the "copyvios" / errors are not true, and the ban was more for conduct issues than creation of stubs, but IDK... BeanieFan11 (talk) 17:17, 18 July 2025 (UTC)

  @LWG: You can see the discussions at WP:LUGSTUBS and WP:LUGSTUBS2. Let'srun (talk) 17:36, 18 July 2025 (UTC)

Time value of money

Almost all sums of historic money have a current equivalent value in brackets after them. These values are usually out-of-date. Can we have a tag to automatically convert monetary values into a value for the current year? This would ensure all values have the same conversion rate (I acknowledge that Discount Curves can be debated, but a good starting point might be an official or government-related price index stored in WikiData). Further parts of this thought-process would be how to select the modern currency (and thus discount curve to use) but that could be defaulted by the language of the article if the user hasn't specified the ccy in the tag. 80.44.75.196 (talk) 19:23, 18 July 2025 (UTC)

We have Template:Inflation, is that what you're thinking of? Schazjmd (talk) 19:29, 18 July 2025 (UTC)

Thank you. I clearly haven't seen it used at all (or figured out the best key word to search for). Perhaps one of the bots can update static conversions to suggest people make more use of it? It would be v. useful to occur more often. 80.44.75.196 (talk) 20:17, 18 July 2025 (UTC)

I recently changed all of the manual conversion dollar amounts in Klondike Gold Rush to template:USDCY, which calls template:Inflation. I like the template because I can see how the converted figure is reached, in the template documentation. When it's just a figure in parentheses that an editor adds, I don't know where they got the figure from. (The Klondike manual conversions didn't even say what year the inflated dollar amount was for, so that was unhelpful.) I don't know enough about bots to know if one could take on the task. Schazjmd (talk) 20:26, 18 July 2025 (UTC)

Editing unnamed subsections

At the top of an article, editors can choose to either edit the unnamed lead section or edit the entire document. It would be nice to have a similar option at the section level. For example, when a ==Top-level== section has text before its first ===Sub-section===, there is no way to edit that unnamed subsection without editing the entire section. It would be nice to have two options: the existing button to edit the entire ==Top-level== section and another button to edit the text that comes between the ==Top-level== section title and the first ===Sub-section=== title. This button could also be used to add introductory text before the first ===Sub-section== when there is none. YBG (talk) 02:35, 19 July 2025 (UTC)

WMF

Official Wikipedia Roblox game and Generative AI use

I considered whether to add this as a subsection to the above RFC on WMF AI development, but decided not to as I didn't want to further bloat that discussion. Regardless, just earlier today I came across a post on instagram from the official Wikipedia instagram account (facebook link for boomers who don't have instagram) showcasing a new Wikipedia Roblox game. The post was made almost two weeks ago so I'm not sure whether it has already been discussed before, but this is a continuation of the use of generative AI (the cover image for the game page, which is also included in the instagram and facebook posts is almost certainly AI) which has quite openly been discussed and decried by many users in the community. I also think that this is a different issue, though, as rather than this use of AI being even remotely justifiable as trying to improve the quality of the 'pedia, the use of generative AI images in what is basically marketing materials really only serves to costs while providing a worse product. I also echo users concerns about the WMF's environmentalism when they say things like The Wikimedia Foundation believes that a long-term commitment to sustainability is an essential component of our work towards the Wikimedia mission and vision here, but then use generative AI to create images for their Roblox game.

I'm aware that most folks on here are certainly not the demographic targeted by this sort of post, but in the end it still reflects on us, so I wonder what folks think. Weirdguyz (talk) 00:45, 17 June 2025 (UTC)

I would have added a link to the Roblox game as well, but roblox.com is on the blacklist, so ¯\_(ツ)_/¯ Weirdguyz (talk) 00:47, 17 June 2025 (UTC)

https://www.roblox.com/games/99320538920886/Wikispeedia-the-Wikipedia-Speedrunning-Game * Pppery * _{it has begun...} 01:06, 17 June 2025 (UTC)

the WMF, last week: Bringing generative AI into the Wikipedia reading experience is a serious set of decisions, with important implications, and we intend to treat it as such.

I guess the skibidi brainrot market technically is not the "Wikipedia reading experience" Gnomingstuff (talk) 01:45, 17 June 2025 (UTC)

I guess the skibidi brainrot market technically is not the "Wikipedia reading experience", exactly! I'm aware that most folks on here are certainly not the demographic targeted by this sort of post, I think is the most important part. We don't know what folks who are actually in that segment want/use. The Future Audiences team is creating short-lived experiments to understand what kind of content the younger generation want. It obviously will be considered borderline by folks who are not the target demographic (which will be a large portion of the community base). I don't support Roblox's exploitative marketplace nor am I supporter of AI image generation, but I do recognize that these explorations are necessary to understand and figure out what kind of media for consuming Wikipedia is popular among the younger crowd (damn, that makes me sound old). Whether or not the WMF invests significantly more resources into that direction and decides to rewrite MediaWiki in Roblox-lang (I believe it is a flavour of Lua?) is up for debate and something that we should (and rightfully does) have a say on. Sohom (talk) 06:04, 17 June 2025 (UTC)

Do my eyes deceive me, are you saying Roblox may be incubating a generation of Wikipedia coders? I might change my mind on that game. CMD (talk) 06:13, 17 June 2025 (UTC)

The games on Roblox are written using a abridged version of Lua called Luau, so maybe yes :) Sohom (talk) 06:25, 17 June 2025 (UTC)

Oh my gripe is certainly not with the fact that they've made a Roblox game, bringing in the younger generations is paramount to the continuation of our goal (I say this as one of the younger (relatively...) generations). My issue is solely with the generative AI used in said pursuit, because the only argument in favour of it is that it is cheaper than paying an actual artist. The quality of the work is worse than if you got an actual artist to make something, the environmental impact is a genuine measurable concern, and the number of people who will see the use of generative AI and be turned off the WMF and Wikipedia is not insubstantial. Weirdguyz (talk) 06:23, 17 June 2025 (UTC)

If only we had a repository of free images they could have used instead, or a cohort of editors who might be willing to create and donate actual human work for this. Fram (talk) 07:16, 17 June 2025 (UTC)

We don't really have any Roblox characters on commons (for better or for worse) that could have been used. Sohom (talk) 08:06, 17 June 2025 (UTC)

This is my stance as well. That, and the fact that it's terrible optics -- Wikimedia has already gotten a significant amount of negative PR for using generative AI in the "paused" summary feature. Gnomingstuff (talk) 15:47, 17 June 2025 (UTC)

It there is a desire to productively engage on questions regarding the use of generative AI/llms/similar, it is probably not worth it in terms of both time and in terms of effective collaboration to respond to each individual use of gen AI. What is likely more effective is generating engagement with the processes behind them. In this case, the relevant initiative is meta:Future Audiences. You can see their stance on gen AI at meta:Future Audiences/FAQ: "The Wikimedia Foundation view of conversational/generative AI specifically is that we (Wikimedians, Mediawiki software developers, and WMF staff) have developed and used machine-assisted tools and processes on our projects for many years, and it is important to keep learning about how recent advances in AI technology might help our movement; however, it is equally important not to ignore the challenges and risks that commercial AI assistants may bring not just to our model of human-led knowledge creation and sharing, but to the entire ecosystem of digital knowledge." I stated somewhere during the discussion of meta:Future Audiences/Generated Video that there have been some flawed risk considerations, for example that "Experiment" (quoting to indicate this is the terminology they use, not a scare quote) page has a subsection on the risks of associating Wikipedia with TikTok, but nothing on associating Wikipedia with generative AI. (I might add that the first two bullet points at meta:Future Audiences seem to pose contradictory lessons, possibly worth digging into.) Now, what I haven't figured out and what perhaps we haven't worked out as a community is how to effectively channel feedback about broader themes rather than individual activities, and then perhaps more importantly how we remain continually engaged on that end. Say that the RfC on a statement on AI comes to a consensus, what happens next? It's quite a hard question as to how something as amorphous as en.wiki can be represented in these processes. The Future Audiences team has meetings every month, is an attendee there from en.wiki going to be representative? Should we be proactively trying to figure out statements here for such meetings in advance? How would that be most collegial/effective? A further complication is that the WMF is also not a monolith, the meta:Reading/Web team for example which is looking into the gen AI Simple Article Summaries is a different team with its own projects. Should we use this noticeboard to figure out statements that can be transferred to meta, or does that fall down as meta threads are also a discussion? We sometimes contribute to community wishlists, we have individual members who engage, but do we as a community have an overall approach? I'm rambling slightly, and I know some would prefer we did not have to engage, but we do have to and given the historical difficulties in communication maybe we could think of some ideas to create something a little more sustained. CMD (talk) 07:57, 17 June 2025 (UTC)

I think engaging is the only way forward for folks on the teams to know what the communities take on this matter is. Not engaging never was (and still is not) the answer especially if the expectation is for the WMF to reflect the views of the community.

I can/will try to be around during the next call for Future Audiences whenever that is but I don't think "proactively trying to figure out statements here for such meetings in advance" is the way to go in these kinds of situations, rather the idea would be for the enwiki representative to act as a steward/helpful member who is able to vouch for and provide context for the team's decisions while also guiding the team to not make major policy missteps and provide stewardship on where and when to ask feedback.

(Unrelatedly, is mw:Future Audiences/Generated Video about AI generated videos or just using generative text-to-speech software (which has been around for a while) ? My understanding was the latter, the former would be concerning) Sohom (talk) 08:29, 17 June 2025 (UTC)

My understanding is that the short videos were mostly AI generated, in that the AI did the writing and the voicing (so to speak). I don't recall if the AI chose the images, or whether the final cut was done manually. CMD (talk) 08:37, 17 June 2025 (UTC)

@Sohom Datta & @Chipmunkdavis: to create these videos, we use AI to do an initial cut of selecting some images and text from a target article + "hook" (which either comes from DYK or we write ourselves) and summarize the text into a 30-secondish-length video. Members of our social media team then review and make changes to this first draft (ensuring that the summarization of facts from the article is correct and has the appropriate tone, selecting different images from the article or Commons if needed, etc.) before posting. The narration is indeed generative text-to-speech, though we've also gotten some of our staff to supply narration for a few of these. This use of AI helps us greatly reduce the time/cost to make these videos. We're also very happy to feature community-created content on these channels and have published several (example from the folks at Wikimedia Armenia). These take more time & effort, but in the longer term we'd love to get a bigger ratio of community faces to "fun fact" explainers on these channels, so if you or anyone you know is interested in creating some short video content, please get in touch! Maryana Pinchuk (WMF) (talk) 14:34, 17 June 2025 (UTC)

Creating an AI generated image for social media doesn't bother me. As I said in another WMF related thread, enwiki only has so much political capital, and we should use it wisely, i.e. making a stink only about issues that are truly worth it. –Novem Linguae (talk) 10:59, 17 June 2025 (UTC)

This is definitely true and we shouldn't be getting pissy everytime the WMF does anything outside of "make enwiki better". Is "AI" (read: chatgpt and LLMs) bad? 100% without a doubt. But if its used on a platform like Roblox, then I really don't care. Roblox is a cesspool anyway. Trying to connect with Gen Alpha and introduce them to Wikipedia (preferably as editors) is a good goal and is something that the WMF should be working on. JackFromWisconsin (talk | contribs) 04:02, 20 June 2025 (UTC)

Hi @Weirdguyz, member of the Future Audiences team here! TBC, the cover image for the Roblox game was created by the lovely humans in our Brand Studio team, not AI. The game itself also doesn't involve any generative AI imagery. I can understand the confusion, though, given the (for lack of a better word) "robo-blocky" nature of the Roblox aesthetic. Maryana Pinchuk (WMF) (talk) 14:15, 17 June 2025 (UTC)

@MPinchuk (WMF) any secrets you can let us in on, is the cover character one of the team? CMD (talk) 14:25, 17 June 2025 (UTC)

@Chipmunkdavis Ha, I don't think it's meant to look like any specific person... just a cool Roblox guy Maryana Pinchuk (WMF) (talk) 14:37, 17 June 2025 (UTC)

@MPinchuk (WMF): Forgive me for being cynical, but I have both seen too many AI-generated images, and played too much Roblox myself (I am quite familiar with the visual style of Roblox, going back over a decade...) to truly believe that generative AI didn't play even a small part in the creation of the cover image without any evidence. Just to illustrate what concerns me most, the design on the bottom of the shoe that can be seen exhibits many of the hallmarks of generative AI images, where it knows vaguely what it is meant to look like, but cant quite get the details correct, so it ends up with lines and structures that don't really go anywhere or don't match correctly. If any insight into the design process for the image could be shown that would be wonderful, but I completely understand that there are limitations to what can be made public. Weirdguyz (talk) 15:05, 17 June 2025 (UTC)

@Weirdguyz My apologies, I misunderstood your original question (I thought your concern was about whether we used AI in the design of the game itself, which we didn't) and I didn't address what the process looked like for making the Roblox marketing image specifically. For us, the team responsible for making the Roblox game, the process was: we needed a cover image to use in Roblox and in the social media posts about it that would convey the feel of the game and match the Roblox aesthetic, so we asked our Brand team (who are professional designers who make other marketing materials for our social channels) to help us. They provided a few different ideas, we workshopped which ones we liked and then chose the final design concept together, which Brand then refined and finalized. Honestly, I don't have insight into exactly what tools were used to create or refine the image, and the designer is currently out of office, but it met our needs of conveying gameplay, looking Roblox-y, and being the right size & resolution for social channels.

(Also: cool to hear that you're an avid Roblox player! Have you had a chance to play our game? Any thoughts/feedback? We're currently working on some refinements to help with stickiness and learning, i.e., adding some knowledge quizzes to the gameplay – would love to also get your feedback on those changes once those are out in a few weeks.) Maryana Pinchuk (WMF) (talk) 18:22, 18 June 2025 (UTC)

@MPinchuk (WMF) Very confusing. Why does the WMF think the community wants it to develop Roblox stuff? If that isn't the case, why does the WMF think Roblox players, who are between 7 and 13 years old are a good demographic to target? Why in this way? How much money and time did this cost? How many billable hours? How will the return on investment be calculated? This seems like a massive waste of time for unclear (no) benefit. And Roblox is truly evil. https://www.youtube.com/watch?v=_gXlauRB1EQ Polygnotus (talk) 16:09, 19 June 2025 (UTC)

7-13 year kids today will one day become 16-17+ year old who might edit Wikipedia (or atleast have a positive association with Wikipedia from a early age). Even if the community did not explicitly ask for a Roblox game, there is implicit consensus on allowing the WMF to experiment and try to attract contributors to the project. I assume this is being thought of as a Gateway drug instead of a thing unto itself. Sohom (talk) 19:11, 19 June 2025 (UTC)

Also this is explicitly important thing to do since more and more companies keep summarizing our info and conveniently forget to link to us decreasing the ability to convert folks into editors. Sohom (talk) 19:14, 19 June 2025 (UTC)

@Sohom Datta: 7-13 year kids today will one day become 16-17+ year old who might edit Wikipedia Agreed. But then it would possibly be more efficient (and cheaper) to reach out to them when they are 16-17+? Even if the community did not explicitly ask for a Roblox game, there is implicit consensus on allowing the WMF to experiment Maybe. But when I experiment I don't just randomly smash rocks together to see what happens; I have a hypothesis that I want to prove or disprove to build on underlying knowledge I have acquired over the years. And since I don't start every experiment at zero it is reasonable to ask things like: "What were your assumptions? Why? How will you determine if this was a success?". I assume this is being thought of as a gateway drug A debunked theory is perhaps not the greatest comparison; but I get what you mean.

Also this is explicitly important thing to do since more and more companies keep summarizing our info and conveniently forget to link to us decreasing the ability to convert folks into editors. That genie is out of the bottle. It would be weird to suddenly start demanding attribution. And using an LLM effectively "whitewashes" the use of licensed and copyrighted material. Polygnotus (talk) 21:38, 19 June 2025 (UTC)

If you know of an effective way to reach 16-17yos, please suggest it as I'm pretty sure anything slightly likely to work will have a good chance of being tried out. I believe the team tracked retention after the first play and stickiness of repeat players as metrics for the initial deployment, although I can't find the report. CMD (talk) 02:48, 20 June 2025 (UTC)

@Chipmunkdavis I think that the entire assumption that the kind of people we want are unaware of Wikipedia's existence by the time they have reached 18 is flawed (in the western world). Kinda difficult to keep a "compendium of all human knowledge" a secret from nerds; especially when Wikipedia is usually the top result for any search query on Google.

If you know of an effective way to reach 16-17yos, please suggest it Wikipedia contributors are a very specific kind of people. Marketing companies exist who specialize in this kinda thing.

I think the main problem is not brand recognition, but the fact that Wikipedia is shit at converting readers to editors and our tendency to bite even good-faith newbies. The whole set of uw- templates has depersonalized communication and has made human connection even more infrequent. Another problem is that we encourage children who are new to Wikipedia to do vandalfighting which results in them reverting a lot of goodfaith contributions. Polygnotus (talk) 03:16, 20 June 2025 (UTC)

I would guess the assumption is more that finding a way to better show the backend (in this case, the web between articles) might make people more interested. This is not a new discussion, and no-one has really figured out a 'solution'. New ideas are much more helpful that saying a current one might not be maximally effective. CMD (talk) 03:20, 20 June 2025 (UTC)

@Chipmunkdavis New ideas are much more helpful that saying a current one might not be maximally effective. That makes little sense. There are many situations in which an old well-known solution to a problem is superior to whatever new stuff you can come up with. Dismissing all ideas that aren't "new" is unhelpful at best.

Saying that a new bad idea is a bad idea is helpful because people can stop wasting time and money and ideally it would prevent us from making the same or similar mistakes over and over again. And if you read carefully you'll see I also explained why the idea is bad and provided both superior alternatives and advice that could be used to ensure that future plans would be better. Polygnotus (talk) 03:37, 20 June 2025 (UTC)

I did not find your explanations convincing, especially as part of it seemed to rely on there not being any hypothesis. The advice going forward was also quite generic. We don't have an "old well-known solution" here. Nobody has dismissed all ideas that aren't "new". If I was to start somewhere my thinking is that a good part of the issue may be "known", and that the WMF should be doing way more regarding monitoring and evaluating affiliate actions to figure out what is "known". CMD (talk) 03:44, 20 June 2025 (UTC)

@Chipmunkdavis I did not find your explanations convincing I can explain stuff, but I can't understand it for you. We don't have an "old well-known solution" here. Yes we do, and I mentioned it already. Nobody has dismissed all ideas that aren't "new". See straw man. Polygnotus (talk) 03:48, 20 June 2025 (UTC)

It's not a strawman, it's a direct reply to your statement immediately above. CMD (talk) 03:50, 20 June 2025 (UTC)

@Chipmunkdavis Compare Nobody has dismissed all ideas that aren't "new" with my comment. Polygnotus (talk) 03:52, 20 June 2025 (UTC)

Is the underlying assumption here that I did not do that when actually writing the reply? "Dismissing all ideas that aren't "new" is unhelpful"->"Nobody has dismissed all ideas that aren't "new"" is almost as close as can be. If the discussion is going to be claims that a direct reply is a strawman coupled with swipes about understanding, then it is not going to be lead to any productive outcome. CMD (talk) 03:58, 20 June 2025 (UTC)

@Chipmunkdavis I do not know what you do or don't do. I do not work at one of those 3 letter agencies and therefore all I know about you is what you have written on your userpage, which is not much. Perhaps we both like chipmunks? You seem to interpret the sentence Dismissing all ideas that aren't "new" is unhelpful at best. as "You are dismissing all ideas that aren't "new" which is unhelpful at best." but that was not the intended meaning. If it was I would've written that. In my experience most goodfaith people who disagree with me either misunderstand me or do not have (access to) the same information. Especially in cases like this, where it is unlikely that goodfaith people have wildly diverging opinions. Polygnotus (talk) 04:04, 20 June 2025 (UTC)

I interpreted "Dismissing all ideas that aren't "new" is unhelpful at best" as being related to something written prior in the conversation, but not necessarily by me ("You"). My reply "Nobody" was a general reference to all participants of the conversation, not just my comments. I don't think the Roblox experiment will be successful either, but it is relatively small, and does not impede editing or the direct experience of Wikipedia. If I had a better idea that fits the mandate of the Future Audiences team, I would raise it with them. Alas, I do not and right now only have my critical comments about the inherent conflict in their core findings and my related former comment about how their risk assessments have a substantial gap. I don't think either of these would impact the Roblox experiment anyway, and am quite happy for WMF to run relatively safe experiments even if they fail. (My shameful secret is that I have no unique affinity for chipmunks, as inherently valuable as they are, I'm simply stuck in decades of path dependency.) CMD (talk) 04:13, 20 June 2025 (UTC)

@Chipmunkdavis Are you familiar with Minecraft's redstone? The kinda kids who built computers out of them are the kind we want. But they'll probably already know of Wikipedia. I strongly believe that focusing on user retention makes more sense than focusing on user acquisition at this point.

Cheek pouch says: The cheek pouches of chipmunks can reach the size of their body when full. Polygnotus (talk) 04:19, 20 June 2025 (UTC)

I hope we can establish the casual redstoners who just built a door as well as the ones who run Pokemon in Minecraft. I find that cheek pouch statement hard to believe. CMD (talk) 05:23, 20 June 2025 (UTC)

@Chipmunkdavis Same. Cheek_pouch#Chipmunks lists 3 refs. Polygnotus (talk) 05:55, 20 June 2025 (UTC)

In marketing speak, there are brand awareness campaigns and remarketing campaigns. Its primary utility, which is to maintain the brand awareness, which to many people would seem inefficient as it is typically more spray (for awareness) than pray (for returns). As a brand awareness campaign, it is a long shot, but if a few years down the road and some new editors go 'yeah, Roblox! There was that Wikipedia game. I played that.' we know it had done it's work. For the efficiency that you sought, it would usually be remarketing campaigns where the marketers know that what audience to tap on, and what marketing message to design for (i.e. remember the Wikipedia game in Roblox? Here's how you can contribute to Wikipedia.). There is no guarantee that the older kids know Wikipedia in the same homogeneous manner(s) than that of the brand awareness campaigns. – robertsky (talk) 06:38, 20 June 2025 (UTC)

it doesn't whitewash diddly squat. jp×g🗯️ 06:02, 7 July 2025 (UTC)

@JPxG Not sure what you mean. If X commits copyright infringement of Y's book, by publishing the exact same text without permission, Y can go to a court and get X convicted of copyright infringement.

If X trains an AI model on 100.000 books, including the book written by Y, Y cannot go to a court and get X convicted of copyright infringement. So the copyright infringement has been whitewashed (made untraceable). Hope that helps. Polygnotus (talk) 06:16, 7 July 2025 (UTC)

Because it didn't occur? jp×g🗯️ 18:29, 8 July 2025 (UTC)

@JPxG It was in response to Sohom. Sohom wrote: Also this is explicitly important thing to do since more and more companies keep summarizing our info and conveniently forget to link to us decreasing the ability to convert folks into editors.. So my reaction is in response to that, and not about this WMF/Roblox thing. Polygnotus (talk) 18:32, 8 July 2025 (UTC)

It's so sad to see the reputation of Wikipedia, built over so many years by volunteers working every day, squandered by the WMF's bad decisions without even consulting the community Ita140188 (talk) 12:27, 18 June 2025 (UTC)

citation needed Donald Albury 13:22, 18 June 2025 (UTC)

yeah its not like Wikipedia has a great reputation. Polygnotus (talk) 16:10, 19 June 2025 (UTC)

Would love to see proof of our reputation being tarnished in any way by this. This roblox game has literally nothing to do with the editing process over here yet people are treating it like a thermonuclear bomb. Its a silly kids game. Thats it. Its not that deep. JackFromWisconsin (talk | contribs) 04:07, 20 June 2025 (UTC)

@MPinchuk (WMF): Great job! Any chance the game will be open-source?

Roblox has a lot of young people who also enjoy learning to code. Since the WMF isn't making the game for profit, you might end up with a competitive advantage by allowing the same people who like the game to contribute to it.

For the record, I do not care if generative AI is used to create cover art for the game. Chess (talk) (please mention me on reply) 22:26, 19 June 2025 (UTC)

Chess: Thanks for asking! Everything we produce is open source. Please see this GitLab repo. Johan (WMF) (talk) 12:05, 23 June 2025 (UTC)

I am on Roblox, and I'm currently on a 17 day edit streak and well on my way to EC. I think, yeah, we should have this game, and it should be about building things, and others can edit your builds, like here! Starfall2015 ^{let's talk} _profile 08:04, 24 June 2025 (UTC)

Hi Starfall2015, if you have ideas for how the game could be built further, I'm sure they would welcome your thoughts at meta:Talk:Future Audiences/Roblox game. CMD (talk) 09:12, 24 June 2025 (UTC)

• A lot the comments here are quite negative and insistent, so I think I ought to say that I don't really care if you guys slop an image for some Roblox game. Who cares? Has anyone in this thread actually volunteered to make a replacement image? Wikipedia has disproportionate representation of post-retirement college professors and stern librarians and elite programming wizards, which is great for basically every encyclopedic pursuit, but I don't think we are really subject matter experts on skibidi ohio sigma mewmaxxing to rizz quirked up aoomer shawties, or whatever the hell it is teens do on roblox. jp×g🗯️ 06:09, 7 July 2025 (UTC)

  That's because Wikipedia shouldn't do Roblox in the first place. This is supposed to be an encyclopedia not a bad imitation of Reddit or Tiktok Ita140188 (talk) 07:53, 7 July 2025 (UTC)

  Roblox is not part of Wikipedia. It is a separate website -- hope this helps. jp×g🗯️ 18:19, 8 July 2025 (UTC)

Information Page About U4C

Maybe this isn't a right place to ask, because maybe this isn't considered a WMF question, but a Wikimedia question or something. Is there an information page about the U4C? In particular, is there a list of cases decided by the U4C, just as I can look at cases decided by the English Wikipedia ArbCom? I assume that that information is somewhere on Meta, but I don't know where to start looking on Meta. Sometimes there is more than one right place to ask a question. If this isn't a right place to ask, is it a right place to ask where to ask? Robert McClenon (talk) 03:38, 9 July 2025 (UTC)

I spent a couple minutes just now poking around meta:Universal Code of Conduct/Coordinating Committee, and I couldn't find a "list of cases" page. So this is a good question and I look forward to hearing the response. –Novem Linguae (talk) 03:49, 9 July 2025 (UTC)

meta:Universal Code of Conduct/Coordinating Committee/Cases * Pppery * _{it has begun...} 03:52, 9 July 2025 (UTC)

Thanks. My eyes checked the body text, the sidebar, and the navbar, but completely missed the tabs. –Novem Linguae (talk) 04:03, 9 July 2025 (UTC)

Some questions have answers. Thank you, @Novem Linguae and Pppery: . Robert McClenon (talk) 04:28, 9 July 2025 (UTC)

ToneCheck updates!

Hello everyone!

Last week, a summary of ongoing discussions over ToneCheck was published at Wikipedia talk:Edit check/Tone Check#Summary of discussions so far. While many participants in previous discussions have already been pinged there, it can be a good opportunity for new folks to dive in, if you are interested in learning about the current development status and giving feedback on the direction the feature is taking.

Feel free to participate on the discussion page there! Chaotic Enby (talk · contribs) 08:19, 9 July 2025 (UTC)

Wikimedia Foundation Bulletin 2025 Issue 13

Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on June 27. Please help translate.

---

The Wikimania Hackathon 2025 inviting project ideas.

Upcoming and current events and conversations
Let's Talk continues

• Wikimania Hackathon 2025: The Wikimania Hackathon 2025 is inviting you to submit your project idea.
• WikiWomen* Summit 2025: The WikiWomen* Summit 2025 will take place in a hybrid format on 5th August, the pre-conference day of Wikimania 2025. Register now.
• WikiIndaba 2025: The scholarship applications and program submissions are open until 23:59 GMT on July 20.
• WikiCon Brasil 2025: WikiCon Brasil 2025 will take place on July 19-20 in Salvador, Bahia, Brazil.
• WikiConvention francophone 2025: The WikiConvention 2025 will take place in Cotonou, Benin, October 2-5. The call for submissions is open until July 15.

Annual Goals Progress on Infrastructure
See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on MediaWiki.org

• Tech News: Temporary accounts have been rolled out on 18 large and medium-sized Wikipedias, including German, Japanese, French, and Chinese; The CampaignEvents extension has been enabled on all Wikipedias. More updates from Tech News week 27 and 28.
• AbuseFilter: AbuseFilter maintainers can now match against IP reputation data in AbuseFilters. IP reputation data is information about the proxies and VPNs associated with the user’s IP address. This data is not shown publicly and is not generated for actions performed by registered accounts.
• Favorite Templates: A new feature related to Template Recall and Discovery will be deployed to all Wikimedia projects: a template category browser will be introduced to assist users in finding templates to put in their “favourite” list. The browser will allow users to browse a list of templates which have been organised into a given category tree. The feature has been requested by the community through the Community Wishlist.
• Wikipedia App: We have launched an A/B test of tabbed browsing in the Wikipedia iOS app. This feature allows users to open multiple articles in separate tabs, making it easier to switch between topics, explore, and return to previous reading spots. The test is currently running in Arabic, English, and Japanese in selected regions. We’re collecting feedback and plan to make the feature more widely available soon.
• MediaWiki: The MediaWiki Platform team has introduced a unified Built-in Notifications system, as part of MediaWiki 1.44, that makes it easier for developers to send, manage, and customize notifications across the platform.

Annual Goals Progress on Volunteer Support
See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog · WikiLearn News · list of movement events

• Hubs: Personal, consistent and deeply human: How CEE Hub support the region organizations.
• Legal: Good intentions make for bad law in Utah, we argue in our amicus brief in the Netchoice v. Brown case.
• Wikimedia Organizations: The Wikimedia Foundation and a group of experienced co-authors with affiliate background have drafted the paper Towards a Healthy Ecosystem of Wikimedia Organizations. This paper aims to be presented as a proposal for the movement at Wikimania in August 2025 in Nairobi. Share your feedback before July 29.
• Advocacy: We have created The Wikipedia Test: a public policy tool and a call to action to help ensure regulators consider how new laws can negatively affect online communities and platforms that provide services and information in the public interest.
• Wikimedia Research Showcase: The next showcase will center around the theme of "Examining the Impact of LLMs on Knowledge Production Communities" and will take place on July 16 at 16:30 UTC.
• Administrative Update to Our Privacy Policies: Following personnel changes, we are removing the name of our former point of contact serving the European Economic Area and the UK for questions and requests related to personal data in the privacy policy and donor privacy policy.

Board and Board committee updates
See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter

• Affiliations Committee: New resolution from AffComm on User Group recognition interval period.

Other Movement curated newsletters & news
See also: Diff blog · Goings-on · Planet Wikimedia · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l’actualité de la Wikimedia (fr) · Wikimag (fr) · Education · GLAM · The Wikipedia Library · Milestones · Wikidata · Central and Eastern Europe · other newsletters

Subscribe or unsubscribe · Help translate

For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!

MediaWiki message delivery 18:54, 15 July 2025 (UTC)

End-of-year donation banner in July

Why did I start getting the end-of-year donation banner when it's still July? 174.138.212.166 (talk) 20:37, 16 July 2025 (UTC)

See this thread above. You were presumably part of a test group. Sdkb ^talk 20:41, 16 July 2025 (UTC)

WikiCite is back – Save the Date

August 29–31, 2025 Bern, Switzerland & Online

After several years of silence, WikiCite is coming back — and it’s doing so with a fresh, hybrid format and a clear goal: to reconnect communities, institutions, and individuals working with open citations, bibliographic data, and the Wikidata/Wikibase ecosystem.

Whether you're a Wikimedian, a librarian, a developer, or simply passionate about the future of open knowledge, this is your chance to participate in shaping the next chapter of WikiCite.

Event Overview

Day 1 – Friday, August 29

In-person in Bern, Switzerland

Institutional sessions and showcases with invited speakers. All talks will be recorded and shared online.

Day 2 – Saturday, August 30

Fully online via live video conferencing

Technical discussions, community talks, and cross-timezone engagement.

Day 3 – Sunday, August 31

Online and community-driven

Interactive workshops, do-a-thons, and “Ideas for Tomorrow” closing sessions.

Key Topics

The event will explore major developments and shared challenges in the WikiCite ecosystem, including:

• Federated Ontologies and Wikibase Federation – Coordination across decentralized Wikibase instances and aligning schemas across platforms
• Wikidata and Library Catalog Integration – Case studies from ETH Zürich and Swiss institutions on using Wikidata for authority data and bibliographic infrastructure
• Open Citations and Structured Bibliographic Metadata – Linking scientific publications, cultural heritage, and research outputs using Wikidata
• Tooling and Technical Infrastructure – New tools for querying, editing, and visualizing WikiCite data (e.g. LOTUS, Scholia, SPARQL evolution)
• Scalability and the Graph Split – Discussions on the Blazegraph replacement, SPARQL federation, and long-term architecture of Wikidata
• Data Quality and Disambiguation – Examples like the “Swiss homonyms cleanup” and strategies for maintaining data integrity
• Collaborative Models and Governance – How libraries, Wikimedia chapters, and research institutions are collaborating to co-maintain the bibliographic graph
• Community and Innovation – Lightning talks, interactive do-a-thons, Wikidata games, and open proposal slots for emerging ideas

Who should attend?

• Wikidata contributors and WikiCite supporters
• Librarians, archivists, researchers, digital humanists
• Developers and data engineers
• Institutions interested in structured, open bibliographic metadata
• Anyone curious about Wikidata and open citations

Want to join? Let us know

Register (non-binding, helps us plan): https://meta.wikimedia.org/wiki/WikiCite_2025/Participants

Program: https://meta.wikimedia.org/wiki/WikiCite_2025/Programme

Event info: https://meta.wikimedia.org/wiki/WikiCite_2025

Ilario (talk) 13:50, 18 July 2025 (UTC)

Miscellaneous

It is we, the Grammar Police; will ye allow us to proceed?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No, we will not allow this. Wikipedia is not a place to advocate for language change. WP:SNOW close. Anomie⚔ 01:38, 5 July 2025 (UTC)

---

OK, so there are many hundred articles out there wherein, outside quotations, the object form of pronouns is used as complement of the copula (be), instead of the subject form, which is wrong (or not acceptable) in formal English, the variety (or type) of English in which we write here. What I mean are such constructions as "pretending/claims/wants to be him", "to be her", "was her", "will be them", …, instead of "to be he", "was she" and "will be they".
I came across that first in the Billy the Kid article, fairly recently (days ago), where it reads that "a number of men claimed to be him".

The problem here is that, as you gentlemen may already know, to be is not an action verb, but a copulative one, one that refers to the existence or state of something; if there is no action, there is no object. "That'll be us" and "Who is him?" are as wrong as "Us'll be that" and "Him is my friend", because, with be (dissimilar to others), pronouns use the same form on both sides "I am the writer" → "The writer is I", not *"The writer is me" (since *"Me am the writer" would be wrong).

One complication is that such basic error/confusion of common Indo-European grammar is widespread in English (as it is in French, the tongue that has had great impact and influence over ours, for worse and for better).
Being so common, being the default used whenever and wherever non-formal English is written or spoken, one could use such ubiquity to argue against changing anything, after all we are not writing research papers or legal documents here, but only a compendium of knowledge, right?

With that in mind, I do wish to alter, with Your permission (O Community), that reality in our texts, to straighten those deviations from the Encyclopedia's formal tone. If we won't let go of the venerable, old, die-hard pronoun whom, which lives on for ever and ever despite many attempts against its life over the last centuries (especially today), unlike the Dutch's (wien, which they have forsaken altogether long ago, even in High Speech), then I say we ought not forsake the be-rule briefly reviewed above, either.

What I plan to do is to use AutoWikiBrowser (and regular expressions) to find and replace all those incorrect instances with correct forms. Of course, per the Manual of Style and per basic decency, no text within any sort of quotation ("normal", <block>, inline, in-ref, etc.) shall be replaced; quotees may speak their minds however they will. (Edit: Names of artworks must also be left untouched; great example: It's Not Them. It Couldn't Be Them. It Is Them!) I shall be careful and efficiently review everything before publishing. There won't be many hundreds of edits, I suppose, due to the exclusion of quotations and artworks (which, thankfully, account for a significant fraction of the instances), and due to her being both a possessive (most instances; excluded) and the object form (target) of she, so nothing too massive or disruptive.

Do you think that could be good, or do you deem it unnecessary and advise me not to bother with it?

Shall I proceed?

Überpedantically,
The Officer-Trainee of the G.P.,
Bytekast^{[ TLK : CON : LOG ]} 02:00, 4 July 2025 (UTC)

I'm not aware of any accepted guideline prescribing the use of the Predicate nominative. Therefore this would be a controversial change, and you shouldn't use AWB to impose it en masse across all articles.

See also https://www.merriam-webster.com/grammar/it-is-i-or-it-is-me-predicate-nominative-usage-guide WhatamIdoing (talk) 02:22, 4 July 2025 (UTC)

I think such a guideline should be included, or mentioned explicitly, in the MOS, as it is in accordance with the traditional formal usage of English. People wouldn't find it surprising or out-of-place to see such wording in an encyclopedic text. I tell you we will have nothing to lose, but only more respect to gain as a fully (rather than 98%) proper encyclopedia.
Bytekast^{[ TLK : CON : LOG ]} 02:30, 4 July 2025 (UTC)

I would find it surprising, I think, to read "a number of men claimed to be he." That construction is unfamiliar to me. I know "this is she" for phone calls and "it was he who did the thing", but hearing "I want to be he when I grow up" would sound strange to me. (Of course, 'up' is a preposition, so perhaps it would more properly be "I want to be he when I have upwardly grown.") Maybe I don't have much experience reading material styled at the highest levels of formality, but that probably just means that most EnWP readers don't either. I ain't got no problem with that there sitch. I don't find tonal fastidiousness inherently respectable. 207.11.240.2 (talk) 13:08, 4 July 2025 (UTC)

Its also unfamiliar to me and sounds terribly unnatural. I would object to such a change anywhere. I'm of the opinion that there isn't a rigorous way to formally define "correct" English, and that attempting to chase prescriptivist perfectionism leads to uncommon, unidiomatic, and unhelpful (to general readers) constructions like "to be he". Not to mention the multiple varieties of English represented on enwiki and their idiosyncrasies. No thank you. fifteen thousand two hundred twenty four (talk) 15:01, 4 July 2025 (UTC)

It is unnatural and strange to the both of you, as well to millions of speakers, because you and they are not used to it! One doesn't see it often. It's just like whom: people don't see or use it often enough; they need to be accustomed to it through exposure (more and more of it!). We could change that feeling of unnaturalness by doing what I intend to do! Also, formal English tends to have a consistent grammar everywhere, differing only in spelling, vocabulary, and pronunciation.

But I understand and agree that, if it'll turn out to be too distracting to our readers, maybe making them frown in puzzlement, setting them away from an article's content (knowledge) even if for a second, then it shouldn't be done.
Bytekast^{[ TLK : CON : LOG ]} 16:41, 4 July 2025 (UTC)

"they need to be accustomed to it through exposure ... We could change that feeling of unnaturalness by doing what I intend to do!" – some may agree, some may disagree, but Wikipedia's purpose isn't to be a catalyst for linguistic change and attempting to use it as such would be advocacy. fifteen thousand two hundred twenty four (talk) 16:51, 4 July 2025 (UTC)

Oh! Hadn't thunk of it that way. Anyway, I was just talking about minor (narrowspread?) consequences, unlikely side effects. The goal here, my only one, is to abide by the "use formal English" rule of Wikipedia, to broaden its scope, yet again grow its reach, by ridding our articles of phrasings like "it was them who did it" and "claimed to be her, but weren't", because they are inherently informal and traditionally incorrect (it's a misusage of be, mistaking it for other verbs that take an object, which should have no place in an encyclopedia).
Bytekast^{[ TLK : CON : LOG ]} 17:14, 4 July 2025 (UTC)

While others would likely posit that no mistake or misuse has occurred. I would, and do. We may fundamentally disagree on this, which is fine, but other editors may be more amenable. fifteen thousand two hundred twenty four (talk) 17:31, 4 July 2025 (UTC)

What's more important here, what I am focusing on in advancing my intention, is propriety and impropriety in the context of formal standard English, which is the variety or register we use here in our texts. (I am 60% a descriptivist myself, by the way.) Outside such contexts, it is absolutely okay to break the be-rule, the whom-rule, among others. In fact, it'd be awkward and improper if, for example, Mario were to say "It's I, Mario!", since he's an Italian immigrant (English is only his second language) from a children's videogame (colloquial context).
Bytekast^{[ TLK : CON : LOG ]} 17:41, 4 July 2025 (UTC)

To be clear I find "pretending/claims/wants to be him", "to be her", "was her", "will be them" perfectly acceptable for formal English. I would guess I'm a fair distance north of your 60%. fifteen thousand two hundred twenty four (talk) 17:59, 4 July 2025 (UTC)

Does anyone else agree with this user? Do you share their opinion? If so, I'll drop my case, regardless of what I think.

Please be honest and do not say you agree with the user just to shoo off this poor annoying pedant, your humble colleague.

I disagree, because formal language is all about communicating precisely and logically, by means of following good (sensible), old rules; moreover, among all major European languages, only English and French misuse the to be verb in that way. (Maybe that gives it legitimacy tho, since those are two great world languages?!)

In any case, at times — I lastly add — even formal language doth surrender: it cedes when the overwhelming majority of language users disagree with it (consciously or not), and then we ultimately take over it and overrule it. There have been many such cases. I think you see this as one of them, do you not?
Bytekast^{[ TLK : CON : LOG ]} 18:27, 4 July 2025 (UTC)

To be honest, I'm having trouble following all the details here (TIL that copulative verbs are a thing). It would be useful if you could provide a few specific examples (before and after) from articles of changes you propose making. RoySmith (talk) 11:37, 4 July 2025 (UTC)

I provided some examples in the text (like Billy the Kid). For you, here are some perfect, real-life (or real-wikipedia) examples taken from random articles, according to my search:

• Grand Duchess Maria Nikolaevna of Russia: "However, it was later proven that Anastasia did not escape and that those who claimed to be her were imposters." → "[...] who claimed to be she were imposters." (That is an article about royalty, so it follows that we should maintain a high tone in it and in the others of its kind.)
• The Stranglers of Bombay#Plot: "To appease them, Henderson agrees to appoint a man to investigate, and Lewis believes it will be him." → "[...] and Lewis believes it will be he." (to appease them = action, doing something; will be he = existence, nothing being done)
• Uber (Reference number 121): "Hiltzik, Michael (June 10, 2016). 'Column: How sleazy is Uber? This federal judge wants to know'. Los Angeles Times. Retrieved July 22, 2022. 'As it turns out, it was them.' " → Unchanged! It's a quotation from a newspaper.
• Marilyn Manson#Columbine High School shooting: "He argued the media should be blamed for the next school shooting, as it was them who propagated the ensuing hysteria and 'witch hunt'." → "[...] as it was they who propagated [...]" (Indirect quotation [paraphrasis] in encyclopedic text, so it should keep the formal tone.)
  Bytekast^{[ TLK : CON : LOG ]} 16:41, 4 July 2025 (UTC)

Another option is to use the person's name in such places. Consider "However, it was later proven that she did not escape and that those who claimed to be Anastasia were imposters." WhatamIdoing (talk) 17:23, 4 July 2025 (UTC)

Hmm, yes, seems like a good way to work around and avoid wording perceived to be excessively formal. By the way, we (the Grammar Police... and @Jruderman) are discussing the possibility of leaving those instances, like that one ("those who claimed to be her were imposters"), unchanged, and only changing the likes of "it was them who caused the hysteria" (should be "they": *"them who caused" seems too informal, no? *"them caused it"? I'm not having it!)
Bytekast^{[ TLK : CON : LOG ]} 17:29, 4 July 2025 (UTC)

I would write it was they who propagated rather than it was them who propagated (though I am not sure I would see the latter as an error to be fixed were I not primed by this discussion), but I find those who claimed to be she jarring and archaic-sounding, and Lewis believes it will be he worse – if you asked a random sample of readers to identify the grammatically correct choice out of Lewis believes it will be he and Lewis believes it would be him I would be surprised if a single one said the former. Caeciliusinhorto (talk) 22:12, 4 July 2025 (UTC)

I recommend against making these changes: Wikipedia:Manual_of_Style#Contested_vocabulary says Avoid words and phrases that give the impression of straining for formality, that are unnecessarily regional, or that are not widely accepted. This falls within both "straining for formality" and "not widely accepted". Jruderman (talk) 16:43, 4 July 2025 (UTC)

Well, what about our usage of whom? Many would say that it's overly formal, outdated, old-fashioned, others would say it is formal but not much. It is effectively dead and unused in informal and colloquial Englishes, yet here we are, properly using it, as an encyclopedia should. Maybe we will get rid of it by the 2060s or 2100s (or hopefully the 2550s), but not yet.

I think you are focusing more on the likes of "to be him", "will be them"? Because those seem to be the strangest or most formally strained, right? But, say, is "it was they who saw it all" really that unnatural and bad to read? I'd say not as much as "it is I"; I'd put it on the same level as whom: formal but not much.

So what about a compromise: I'll change the "is–are/was–were"-type phrasings, but not the "bare be" ones?
Bytekast^{[ TLK : CON : LOG ]} 17:23, 4 July 2025 (UTC)

As a trained linguist (PhD, Univ. of Florida, 1974) (although not a practicing one), I will note that many of the so-called rules of English grammar were introduced by overly-pedantic grammarians who were trying to make English grammar perfect by making it more like Latin. Such rules were never rooted in how native speakers spoke English, and trying to force people to use English in a way that feels unnatural to them is just wrong. I therefore oppose efforts to force Wikipedia to use pedantic rules that feel unnatural to most speakers of English. Donald Albury 18:52, 4 July 2025 (UTC)

Such rules aren't merely 'pedantic', they are outright wrong. They neither reflect contemporary English, nor reflect past usage. They aren't 'rules of English', they are rules of a fictitious language. The English-language Wikipedia was, is, and shall be written in actual English. AndyTheGrump (talk) 21:21, 4 July 2025 (UTC)

I'm opposed to the proposed change, and to the thinking behind it. I would revert a change from "pretending to be him" to "pretending to be he" in a heartbeat. The latter sounds wrong because it is wrong. That is now how contemporary English-speakers speak or write. Language is created by those who use it, and evolves over time. Prescriptive grammar is useful for educating new generations but must yield when the language changes.--Srleffler (talk) 18:54, 4 July 2025 (UTC)

I would revert any instances of "pretending to be him" being changed to "pretending to be he" in a heartbeat too, on the grounds that it is grammatically incorrect. Also: "whom" is not dead in colloquial English. Hawkeye7 (discuss) 20:44, 4 July 2025 (UTC)

It is true that the writing of Wikipedia aims to be formal, but this is not the only goal. This is why we have a Manual of Style. Due to the nature of the project, sometimes, we diverge from the formal rules. In this case, the best question is: do other general purpose encyclopedias adhere to this grammar rule? Do contemporary formal works often adhere to this grammar rule? If it is found that they use the less formal construction, no overhaul of articles is necessary. Dege31 (talk) 20:51, 4 July 2025 (UTC)

Someone should probably point out before this exercise in misplaced pedantry goes too far that the Village Pump is no place to be making such decisions anyway. In the extremely unlikely circumstance that anyone were to want to enact a policy or guideline regarding this peculiar act of prescriptivism, it would at minimum require an RfC, broadly advertised, and would almost certainly belong in the WP:MOS. And meanwhile, since this discussion has no bearing on content not discussed here (or indeed content that is discussed here), it can safely be ignored, and edits imposing such weird constructions reverted per usual, in the interests of communicating with those who customarily read actual English. AndyTheGrump (talk) 21:33, 4 July 2025 (UTC)

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

Request for Tenth (?) Opinion at DRN

I would like a neutral experienced editor to look at a case at DRN and comment on whether they agree with my handling, and whether they have any advice either for me or for the filing editor. The dispute is Wikipedia:Dispute_resolution_noticeboard#COVID-19_Lab_Leak_Theory. I see two-and-one-half questions, one substantive question and two related procedural questions. The substantive question is whether the article's presentation of the lab leak theory is neutrally written to reflect what reliable sources have written. The procedural questions are how Just-a-can-of-beans should try to discuss their concern that they want changes made to the article, and what advice a neutral mediator should give to Just-a-can-of-beans. Thank you for any advice or comments. Robert McClenon (talk) 02:52, 11 July 2025 (UTC)

Moved to WP:Teahouse

A bit confused on DYK workflow and Gladys Cromwell

Moved to Wikipedia talk:Did you know

— Preceding unsigned comment added by RoySmith (talk • contribs) 20:57, 11 July 2025 (UTC)

De facto banned phrase

Hello, sorry if this is the wrong page to ask this on. I recently heard about an ungrammatical phrase which is functionally banned on Wikipedia as a consequence of one contributor making near-constant edits to replace the phrase on any article it appears on. I've trying to remember the specific clause for weeks and it's been driving me nuts. All I remember was that it was two words. A truly stupid amount of gratitude to anyone who has any further information. C4RD14C4K (talk) 12:45, 14 July 2025 (UTC)

Could it be "comprised of"? _🐾 Nyakase (talk) ^🐾 12:49, 14 July 2025 (UTC)

That's what came to my mind too. Jason Quinn (talk) 22:25, 16 July 2025 (UTC)

We also have the mainspace article comprised of, about the usage controversy around the phrase more generally; it has a section about the campaign to remove it from Wikipedia. Caeciliusinhorto-public (talk) 11:05, 18 July 2025 (UTC)

Ancient apocalypse issue

Ancient Apocalypse could be more scientific or not, but my complaint is about the addition of one specific article in the 'See also:' section. The first article listed is: Archaeology and racism. This was added as if Hancock's theories were racist. But Graham Hancock is simply researching a lost ancient civilization—and he never claimed they were white. White people were evolving in what is now Ukraine. The rest of the Europeans at that time were brown-skinned, as were North Africans and, probably, the ancient members of that hypothetical lost civilization. So, where exactly is the racism? Explain it to me. Wyatt Abernathy (talk) 21:15, 16 July 2025 (UTC) P.S.: Apologies if this isn’t the appropriate place to raise this point.

Given the final paragraph currently in Ancient Apocalypse#Reception, the "See also" link seems supported to me. Whether you personally agree or disagree with the sources cited in that paragraph, there's enough of a connection. Anomie⚔ 12:34, 17 July 2025 (UTC)

The idea that the Egyptians, Mesopotamians, ancient Chinese,Indus valley peoples, etc weren't smart enough to comd up with their civilizations on their own seems pretty racist to me. --User:Khajidha (talk) (contributions) 15:31, 17 July 2025 (UTC)

And the OP is bludgeoning at the talk page now. Doug Weller talk 16:34, 17 July 2025 (UTC)

How corporate authorship shaped two decades of glyphosate safety discourse (including on Wikipedia)

Hello!

A recent article discusses how a ghostwritten research article, published in Regulatory Toxicology and Pharmacology has influenced the discourse on glyphosate safety, including within Wikipedia articles: [22]. It may be of interest for people here!

Factsory (talk) 10:06, 18 July 2025 (UTC)

Please join in at Talk:Roundup_(herbicide)#Revert_of_an_edit_adding_a_reliable_source rather than starting another thread here. SmartSE (talk) 11:03, 18 July 2025 (UTC)

That's a different matter. The article is of general interest for the community as it mentions how a dubious information can spread on Wikipedia. Factsory (talk) 11:50, 18 July 2025 (UTC)

Maybe the new source is "dubious"? This Monsanto thing has been rumbling on for a decade and it's far less clear-cut (especially regards the underlying science) than is now being made out.[23] Bon courage (talk) 13:58, 18 July 2025 (UTC)

If the paper was cited extensively in academia and policy documents, to the point it has a "broad uptake", it should be expected that it would influence Wikipedia coverage too as it follows reliable sources. Ideally, if there is a change in the uptake going forward, material on Wikipedia will adjust to reflect this. Our citation process in a way allows us to adjust as scientific papers do if work it was based on is found to be fraudulent, as we could search for all the places a retracted paper is used as a source and reassess. CMD (talk) 14:07, 18 July 2025 (UTC)

Yes, Wikipedia is meant to be a summary of accepted knowledge (even if it's Wrong™) as published in reliable sources, not ferreting out the Truth™ like an investigative bureau of some sort. Bon courage (talk) 14:14, 18 July 2025 (UTC)

Dead external links

When you see InternetArchiveBot fixing dead links, very often it is not dead, rather has been moved to a new location. For example Special:Diff/1296609254/1301099038 now fixed Special:Diff/1301099038/1301201736. There are efforts to systematize this work at WP:URLREQ, it's a semi-automated, slow, complex and difficult. Chipping at the edges. It's mostly up to the community to replace dead links with live. The best way is monitor your watchlist for edits by InternetArchive bot. If something looks suspiciously dead - like the home page of an active organization - it likely can easily be replaced with a live link. -- GreenC 16:38, 18 July 2025 (UTC)