Jump to content

Wikipedia:Village pump (all)

Page protected
From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPA)

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.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections
post, watch, search
Discuss existing and proposed policies
post, watch, search
Discuss technical issues about Wikipedia
post, watch, search
Discuss new proposals that are not policy-related
post, watch, search
Incubate new ideas before formally proposing them
post, watch, search
Discuss issues involving the Wikimedia Foundation
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

Should WP:Demonstrate good faith include mention of AI-generated comments?

Using AI to write your comments in a discussion makes it difficult for others to assume that you are discussing in good faith, rather than trying to use AI to argue someone into exhaustion (see example of someone using AI in their replies "Because I don't have time to argue with, in my humble opinion, stupid PHOQUING people"). More fundamentally, WP:AGF can't apply to the AI itself as AI lacks intentionality, and it is difficult for editors to assess how much of an AI-generated comment reflects the training of the AI vs. the actual thoughts of the editor.

Should WP:DGF be addended to include that using AI to generate your replies in a discussion runs counter to demonstrating good faith? Photos of Japan (talk) 00:23, 2 January 2025 (UTC)[reply]

  • 100% Yes and sooner rather than later. Machine-generated material is not produced in "good faith" — it inherently wastes the time of actual editors. Having to sort through machine-generated responses is unacceptable and a growing problem. Passing off your a machine-generated response as your own, no matter how obvious or not it is, is not acceptable. :bloodofox: (talk) 00:39, 2 January 2025 (UTC)[reply]
Update: I have recently had to respond to not one but two different instances of AI-generated slop on our articles and related talk pages (Talk:Herla#AI_Generated_Content & Talk:Böksta_Runestone#Clarification_on_Image_Caption_–_"Possibly_Depicting"_vs._"Showing"). This is a complete waste of my time and the time of any other involved human . I find it outright insulting. We need something done to either stop this or at least reduce and provide consequences for this when it happens. Some kind of disclaimer about not posting AI-generated nonsense to Wikipedia before allowing posting would also help. I did not sign up to Wikipedia around 20 years ago to sort through someone's prompt-generated garbage trained on who knows what (in fact, often trained on Wikipedia itself!). :bloodofox: (talk) 05:27, 1 March 2025 (UTC)[reply]
Agreed. It's only going to become more common, so it's pressingly important that we figure out how to manage it until we have the guidance and the tools to deal with it properly. Technology is moving faster and unless we clarify what the new rules are, people will just assume the WP community is prepared, or worse, take advantage. I believe keeping good faith is part of what makes this place special, and the users are a part of that, but keeping that principal should not come at the cost of driving away everyone that wants to improve the project but aren't sure how to deal with, or identify, bots. Thanks and cheers. DN (talk) 06:15, 1 March 2025 (UTC)[reply]
I don't think that putting a sentence in a "backstage" page is going to do any good. If nothing else, the odds are stacked against it. About 1,000 registered editors (and who knows how many IPs) make their first edit each day. That page gets about 150 page views per day. Even if we assume, to simplifying the math, that every single page view reads the whole thing and every single page view is a newly registered editor, that would still leave 85% of new editors not seeing this rule.
Putting this sentence there, and then expecting it to change people's behavior is like drawing chalk lines across an unlit rural road, and then wondering why the trucks didn't yield to you the middle of the night.
Your first example is irrelevant to this discussion, because it was article content and not discussion. Your second example has other problems: You are assuming it's AI-generated, but the comment accurately quotes the Swedish-language Wikipedia, which is not a typical ability of AI tools, and accurately describes the edits that the new editor made, which is also not a typical ability of AI tools. There are also misspellings, typos, and awkwardnesses ("storys", "sometimes seen as kind of as gods(Skaði)") that AI tools wouldn't produce, but non-native English speakers would. Ergo, I doubt that this is "AI slop" or "AI-generated crap".
More importantly for that second example, the editor says that the uncited caption is phrased overly strongly ("showing a Norse god") and recommends softening it to "possibly depicting a Norse god". You have demanded a source for the softer claim, but you aren't demanding a source for the existing claim. You should be treating the old, uncited caption as having been formally WP:CHALLENGED. Instead, one of you has reverted everything and declared that nobody should be talking to this editor because it's all just AI garbage.
Frankly, I think you're wrong in your guess that AI was used to generate these comments, and I think you and @Skyerise have been rude, and I think the other editor is actually correct that if we don't have a source saying that this old image definitely does show a Norse god on skis, then Wikipedia shouldn't have an uncited caption making that claim. We do have a policy about this, and the policy is that anyone wanting to keep old uncited claims has to add a source for it.
Perhaps the question the rest of us should be asking is: Do we want to have a policy that says editors get to ignore core content policies like WP:CHALLENGE if they instead claim that the editors telling them that they're wrong are using AI? WhatamIdoing (talk) 20:54, 2 March 2025 (UTC)[reply]
This is a funny response: You'd know it was AI-generated slop with at most mild adjustment immediately if you were at all familiar with the material. And then there are the usual LLM-generated text give-aways: the structure of the response and lack of references or citations (the fear among LLM-makers of lawsuits is omnipresent, after all). And that's another big problem: Prompt-generated text can be convincing to non-experts like yourself. The text caption matter is a red herring: it is clearly covered by WP:PROVEIT (and I've removed it).
That said, while you made this wall of text defending the use of generative AI-users on the site wasting my time and the time of other editors, you could have been proposing solutions to a rising tide of AI-spew that those of us here contributing to articles increasingly need to mop up. :bloodofox: (talk) 02:27, 3 March 2025 (UTC)[reply]
No. As with all the other concurrent discussions (how many times do we actually need to discuss the exact same FUD and scaremongering?) the problem is not AI, but rather inappropriate use of AI. What we need to do is to (better) explain what we actually want to see in discussions, not vaguely defined bans of swathes of technology that, used properly, can aid communication. Thryduulf (talk) 01:23, 2 January 2025 (UTC)[reply]
Note that this topic is discussing using AI to generate replies, as opposed to using it as an aid (e.g. asking it to edit for grammar, or conciseness). As the above concurrent discussion demonstrates, users are already using AI to generate their replies in AfD, so it isn't scaremongering but an actual issue.
WP:DGF also does not ban anything ("Showing good faith is not required"), but offers general advice on demonstrating good faith. So it seems like the most relevant place to include mention of the community's concerns regarding AI-generated comments, without outright banning anything. Photos of Japan (talk) 01:32, 2 January 2025 (UTC)[reply]
And as pointed out, multiple times in those discussions, different people understand different things from the phrase "AI-generated". The community's concern is not AI-generated comments, but comments that do not clearly and constructively contribute to a discussion - some such comments are AI-generated, some are not. This proposal would, just as all the other related ones, cause actual harm when editors falsely accuse others of using AI (and this will happen). Thryduulf (talk) 02:34, 2 January 2025 (UTC)[reply]
Nobody signed up to argue with bots here. If you're pasting someone else's comment into a prompt and asking the chatbot to argue against that comment and just posting it in here, that's a real problema and absolutely should not be acceptable. :bloodofox: (talk) 03:31, 2 January 2025 (UTC)[reply]
Thank you for the assumption of bad faith and demonstrating one of my points about the harm caused. Nobody is forcing you to engage with bad-faith comments, but whether something is or is not bad faith needs to be determined by its content not by its method of generation. Simply using an AI demonstrates neither good faith nor bad faith. Thryduulf (talk) 04:36, 2 January 2025 (UTC)[reply]
I don't see why we have any particular to reason to suspect a respected and trustworthy editor of using AI. Cremastra (u — c) 14:31, 2 January 2025 (UTC)[reply]
I don't think the replies above look like anyone is automating this discussion using a chat bot. However let's maybe ease off on the "FUD" talk. Frankly when people start trying to sell magic beans, doubt is a good thing. Meanwhile it remains very uncertain what functionality these chat bots will actually be able to develop. And as for fear, I don't think those of us who dislike chatbots being used on Wikipedia are afraid of them. They're just kind of disruptive. Simonm223 (talk) 21:00, 3 March 2025 (UTC)[reply]
I'm one of those people who clarified the difference between AI-generated vs. edited, and such a difference could be made explicit with a note. Editors are already accusing others of using AI. Could you clarify how you think addressing AI in WP:DGF would cause actual harm? Photos of Japan (talk) 04:29, 2 January 2025 (UTC)[reply]
By encouraging editors to accuse others of using AI, by encouraging editors to dismiss or ignore comments because they suspect that they are AI-generated rather than engaging with them. @Bloodofox has already encouraged others to ignore my arguments in this discussion because they suspect I might be using an LLM and/or be a bot (for the record I'm neither). Thryduulf (talk) 04:33, 2 January 2025 (UTC)[reply]
I think bloodofox's comment was about "you" in the rhetorical sense, not "you" as in Thryduulf. jlwoodwa (talk) 11:06, 2 January 2025 (UTC)[reply]
Given your relentlessly pro-AI comments here, it seems that you'd be A-OK with just chatting with a group of chatbots here — or leaving the discussion to them. However, most of us clearly are not. In fact, I would immediately tell someone to get lost were it confirmed that indeed that is what is happening. I'm a human being and find the notion of wasting my time with chatbots on Wikipedia to be incredibly insulting and offensive. :bloodofox: (talk) 04:38, 2 January 2025 (UTC)[reply]
My comments are neither pro-AI nor anti-AI, indeed it seems that you have not understood pretty much anything I'm saying. Thryduulf (talk) 04:43, 2 January 2025 (UTC)[reply]
Funny, you've done nothing here but argue for more generative AI on the site and now you seem to be arguing to let chatbots run rampant on it while mocking anyone who doesn't want to interface with chatbots on Wikipedia. Hey, why not just sell the site to Meta, am I right? :bloodofox: (talk) 04:53, 2 January 2025 (UTC)[reply]
I haven't been arguing for more generative AI on the site. I've been arguing against banning it on the grounds that such a ban would be unclear, unenforceable, wouldn't solve any problems (largely because whether something is AI or not is completely irrelevant to the matter at hand) but would instead cause harm. Some of the issues identified are actual problems, but AI is not the cause of them and banning AI won't fix them.
I'm not mocking anybody, nor am I advocating to let chatbots run rampant. I'm utterly confused why you think I might advocate for selling Wikipedia to Meta (or anyone else for that matter)? Are you actually reading anything I'm writing? You clearly are not understanding it. Thryduulf (talk) 05:01, 2 January 2025 (UTC)[reply]
So we're now in 'everyone else is the problem, not me!' territory now? Perhaps try communicating in a different way because your responses here are looking very much like the typical AI apologetics one can encounter on just about any contemporary LinkedIn thread from your typical FAANG employee. :bloodofox: (talk) 05:13, 2 January 2025 (UTC)[reply]
No, this is not a everyone else is the problem, not me issue because most other people appear to be able to understand my arguments and respond to them appropriately. Not everybody agrees with them, but that's not an issue.
I'm not familiar with Linkedin threads (I don't use that platform) nor what a "FAANG employee" is (I've literally never heard the term before now) so I have no idea whether your characterisation is a compliment or a personal attack, but given your comments towards me and others you disagree with elsewhere I suspect it's closer to the latter.
AI is a tool. Just like any other tool it can be used in good faith or in bad faith, it can be used well and it can be used badly, it can be used in appropriate situations and it can be used in inappropriate situations, the results of using the tool can be good and the results of using the tool can be bad. Banning the tool inevitably bans the good results as well as the bad results but doesn't address the reasons why the results were good or bad and so does not resolve the actual issue that led to the bad outcomes. Thryduulf (talk) 12:09, 2 January 2025 (UTC)[reply]
In the context of generating comments to other users though, AI is much easier to use for bad faith than for good faith. LLMs don't understand Wikipedia's policies and norms, and so are hard to utilize to generate posts that productively address them. By contrast, bad actors can easily use LLMs to make low quality posts to waste people's time or wear them down.
In the context of generating images, or text for articles, it's easy to see how the vast majority of users using AI for those purposes is acting in good faith as these are generally constructive tasks, and most people making bad faith changes to articles are either obvious vandals who won't bother to use AI because they'll be reverted soon anyways, or trying to be subtle (povpushers) in which case they tend to want to carefully write their own text into the article.
It's true that AI "is just a tool", but when that tool is much easier to use for bad faith purposes (in the context of discussions) then it raises suspicions about why people are using it. Photos of Japan (talk) 22:44, 2 January 2025 (UTC)[reply]
LLMs don't understand Wikipedia's policies and norms They're not designed to "understand" them since the policies and norms were designed for human cognition. The fact that AI is used rampantly by people acting in bad faith on Wikipedia does not inherently condemn the AI. To me, it shows that it's too easy for vandals to access and do damage on Wikipedia. Unfortunately, the type of vetting required to prevent that at the source would also potentially require eliminating IP-editing, which won't happen. Duly signed, ⛵ WaltClipper -(talk) 14:33, 15 January 2025 (UTC)[reply]
You mentioned "FUD". That acronym, "fear, uncertainty and doubt," is used in precisely two contexts: pro-AI propagadizing and persuading people who hold memecoin crypto to continue holding it. Since this discussion is not about memecoin crypto that would suggest you are using it in a pro-AI context. I will note, fear, uncertainty and doubt is not my problem with AI. Rather it's anger, aesthetic disgust and feeling disrespected when somebody makes me talk to their chatbot. Simonm223 (talk) 14:15, 14 January 2025 (UTC)[reply]
That acronym, "fear, uncertainty and doubt," is used in precisely two contexts is simply
FUD both predates AI by many decades (my father introduced me to the term in the context of the phrase "nobody got fired for buying IBM", and the context of that was mainframe computer systems in the 1980s if not earlier. FUD is also used in many, many more contexts that just those two you list, including examples by those opposing the use of AI on Wikipedia in these very discussions. Thryduulf (talk) 14:47, 14 January 2025 (UTC)[reply]
That acronym, "fear, uncertainty and doubt," is used in precisely two contexts is factually incorrect.
FUD both predates AI by many decades (indeed if you'd bothered to read the fear, uncertainty and doubt article you'd learn that the concept was first recorded in 1693, the exact formulation dates from at least the 1920s and the use of it in technology concepts originated in 1975 in the context of mainframe computer systems. That its use, eve in just AI contexts, is limited to pro-AI advocacy is ludicrous (even ignoring things like Roko's basilisk), examples can be found in these sprawling discussions from those opposing AI use on Wikipedia. Thryduulf (talk) 14:52, 14 January 2025 (UTC)[reply]
Not really – I agree with Thryduulf's arguments on this one. Using AI to help tweak or summarize or "enhance" replies is of course not bad faith – the person is trying hard. Maybe English is their second language. Even for replies 100% AI-generated the user may be an ESL speaker struggling to remember the right words (I always forget 90% of my French vocabulary when writing anything in French, for example). In this case, I don't think we should make a blanket assumption that using AI to generate comments is not showing good faith. Cremastra (u — c) 02:35, 2 January 2025 (UTC)[reply]
  • Yes because generating walls of text is not good faith. People "touching up" their comments is also bad (for starters, if you lack the English competency to write your statements in the first place, you probably lack the competency to tell if your meaning has been preserved or not). Exactly what AGF should say needs work, but something needs to be said, and AGFDGF is a good place to do it. XOR'easter (talk) 02:56, 2 January 2025 (UTC)[reply]
    Not all walls of text are generated by AI, not all AI generated comments are walls of text. Not everybody who uses AI to touch up their comments lacks the competencies you describe, not everybody who does lack those competencies uses AI. It is not always possible to tell which comments have been generated by AI and which have not. This proposal is not particularly relevant to the problems you describe. Thryduulf (talk) 03:01, 2 January 2025 (UTC)[reply]
Someone has to ask: Are you generating all of these pro-AI arguments using ChatGPT? It'd explain a lot. If so, I'll happily ignore any and all of your contributions, and I'd advise anyone else to do the same. We're not here to be flooded with LLM-derived responses. :bloodofox: (talk) 03:27, 2 January 2025 (UTC)[reply]
That you can't tell whether my comments are AI-generated or not is one of the fundamental problems with these proposals. For the record they aren't, nor are they pro-AI - they're simply anti throwing out babies with bathwater. Thryduulf (talk) 04:25, 2 January 2025 (UTC)[reply]
I'd say it also illustrates the serious danger: We can no longer be sure that we're even talking to other people here, which is probably the most notable shift in the history of Wikipedia. :bloodofox: (talk) 04:34, 2 January 2025 (UTC)[reply]
How is that a "serious danger"? If a comment makes a good point, why does it matter whether ti was AI generated or not? If it doesn't make a good point, why does it matter if it was AI generated or not? How will these proposals resolve that "danger"? How will they be enforceable? Thryduulf (talk) 04:39, 2 January 2025 (UTC)[reply]
Wikipedia is made for people, by people, and I like most people will be incredibly offended to find that we're just playing some kind of LLM pong with a chatbot of your choice. You can't be serious. :bloodofox: (talk) 04:40, 2 January 2025 (UTC)[reply]
You are entitled to that philosophy, but that doesn't actually answer any of my questions. Thryduulf (talk) 04:45, 2 January 2025 (UTC)[reply]
"why does it matter if it was AI generated or not?"
Because it takes little effort to post a lengthy, low quality AI-generated post, and a lot of effort for human editors to write up replies debunking them.
"How will they be enforceable? "
WP:DGF isn't meant to be enforced. It's meant to explain to people how they can demonstrate good faith. Posting replies to people (who took the time to write them) that are obviously AI-generated harms the ability of those people to assume good faith. Photos of Japan (talk) 05:16, 2 January 2025 (UTC)[reply]
The linked "example of someone using AI in their replies" appears – to me – to be a non-AI-generated comment. I think I preferred the allegedly AI-generated comments from that user (example). The AI was at least superficially polite. WhatamIdoing (talk) 04:27, 2 January 2025 (UTC)[reply]
Obviously the person screaming in all caps that they use AI because they don't want to waste their time arguing is not using AI for that comment. Their first post calls for the article to be deleted for not "offering new insights or advancing scholarly understanding" and "merely" reiterating what other sources have written.
Yes, after a human had wasted their time explaining all the things wrong with its first post, then the bot was able to write a second post which looks ok. Except it only superficially looks ok, it doesn't actually accurately describe the articles. Photos of Japan (talk) 04:59, 2 January 2025 (UTC)[reply]
Multiple humans have demonstrated in these discussions that humans are equally capable of writing posts which superficially look OK but don't actually accurately relate to anything they are responding to. Thryduulf (talk) 05:03, 2 January 2025 (UTC)[reply]
But I can assume that everyone here is acting in good faith. I can't assume good faith in the globally-locked sock puppet spamming AfD discussions with low effort posts, whose bot is just saying whatever it can to argue for the deletion of political pages the editor doesn't like. Photos of Japan (talk) 05:09, 2 January 2025 (UTC)[reply]
True, but I think that has more to do with the "globally-locked sock puppet spamming AfD discussions" part than with the "some of it might be [AI-generated]" part. WhatamIdoing (talk) 07:54, 2 January 2025 (UTC)[reply]
All of which was discovered because of my suspicions from their inhuman, and meaningless replies. "Reiteration isn't the problem; redundancy is," maybe sounds pithy in a vacuum, but this was written in reply to me stating that we aren't supposed to be doing OR but reiterating what the sources say.
"Your criticism feels overly prescriptive, as though you're evaluating this as an academic essay" also sounds good, until you realize that the bot is actually criticizing its own original post.
The fact that my suspicions about their good faith were ultimately validated only makes it even harder for me to assume good faith in users who sound like ChatGPT. Photos of Japan (talk) 08:33, 2 January 2025 (UTC)[reply]
I wonder if we need some other language here. I can understand feeling like this is a bad interaction. There's no sense that the person cares; there's no feeling like this is a true interaction. A contract lawyer would say that there's no meeting of the minds, and there can't be, because there's no mind in the AI, and the human copying from the AI doesn't seem to be interested in engaging their brain.
But... do you actually think they're doing this for the purpose of intentionally harming Wikipedia? Or could this be explained by other motivations? Never attribute to malice that which can be adequately explained by stupidity – or to anxiety, insecurity (will they hate me if I get my grammar wrong?), incompetence, negligence, or any number of other "understandable" (but still something WP:SHUN- and even block-worthy) reasons. WhatamIdoing (talk) 08:49, 2 January 2025 (UTC)[reply]
The user's talk page has a header at the top asking people not to template them because it is "impersonal and disrespectful", instead requesting "please take a moment to write a comment below in your own words"
Does this look like acting in good faith to you? Requesting other people write personalized responses to them while they respond with an LLM? Because it looks to me like they are trying to waste other people's time. Photos of Japan (talk) 09:35, 2 January 2025 (UTC)[reply]
Wikipedia:Assume good faith means that you assume people aren't deliberately screwing up on purpose. Humans are self-contradictory creatures. I generally do assume that someone who is being hypocritical hasn't noticed their contradictions yet. WhatamIdoing (talk) 07:54, 3 January 2025 (UTC)[reply]
"Being hypocritical" in the abstract isn't the problem, it's the fact that asking people to put effort into their comments, while putting in minimal effort into your own comments appears bad faith, especially when said person says they don't want to waste time writing comments to stupid people. The fact you are arguing AGF for this person is both astounding and disappointing. Photos of Japan (talk) 16:08, 3 January 2025 (UTC)[reply]
It feels like there is a lack of reciprocity in the interaction, even leaving aside the concern that the account is a block-evading sock.
But I wonder if you have read AGF recently. The first sentence is "Assuming good faith (AGF) means assuming that people are not deliberately trying to hurt Wikipedia, even when their actions are harmful."
So we've got some of this (e.g., harmful actions). But do you really believe this person woke up in the morning and decided "My main goal for today is to deliberately hurt Wikipedia. I might not be successful, but I sure am going to try hard to reach my goal"? WhatamIdoing (talk) 23:17, 4 January 2025 (UTC)[reply]
Trying to hurt Wikipedia doesn't mean they have to literally think "I am trying to hurt Wikipedia", it can mean a range of things, such as "I am trying to troll Wikipedians". A person who thinks a cabal of editors is guarding an article page, and that they need to harass them off the site, may think they are improving Wikipedia, but at the least I wouldn't say that they are acting in good faith. Photos of Japan (talk) 23:27, 4 January 2025 (UTC)[reply]
Sure, I'd count that as a case of "trying to hurt Wikipedia-the-community". WhatamIdoing (talk) 06:10, 5 January 2025 (UTC)[reply]
  • The issues with AI in discussions is not related to good faith, which is narrowly defined to intent. CMD (talk) 04:45, 2 January 2025 (UTC)[reply]
    In my mind, they are related inasmuch as it is much more difficult for me to ascertain good faith if the words are eminently not written by the person I am speaking to in large part, but instead generated based on an unknown prompt in what is likely a small fraction of the expected time. To be frank, in many situations it is difficult to avoid the conclusion that the disparity in effort is being leveraged in something less than good faith. Remsense ‥ 论 05:02, 2 January 2025 (UTC)[reply]
    Assume good faith, don't ascertain! Llm use can be deeply unhelpful for discussions and the potential for mis-use is large, but the most recent discussion I've been involved with where I observed an llm post was responded to by an llm post, I believe both the users were doing this in good faith. CMD (talk) 05:07, 2 January 2025 (UTC)[reply]
    All I mean to say is it should be licit that unhelpful LLM use should be something that can be mentioned like any other unhelpful rhetorical pattern. Remsense ‥ 论 05:09, 2 January 2025 (UTC)[reply]
    Sure, but WP:DGF doesn't mention any unhelpful rhetorical patterns. CMD (talk) 05:32, 2 January 2025 (UTC)[reply]
    The fact that everyone (myself included) defending "LLM use" says "use" rather than "generated", is a pretty clear sign that no one really wants to communicate with someone using "LLM generated" comments. We can argue about bans (not being proposed here), how to know if someone is using LLM, the nuances of "LLM use", etc., but at the very least we should be able to agree that there are concerns with LLM generated replies, and if we can agree that there are concerns then we should be able to agree that somewhere in policy we should be able to find a place to express those concerns. Photos of Japan (talk) 05:38, 2 January 2025 (UTC)[reply]
    ...or they could be saying "use" because "using LLMs" is shorter and more colloquial than "generating text with LLMs"? Gnomingstuff (talk) 06:19, 2 January 2025 (UTC)[reply]
    Seems unlikely when people justify their use for editing (which I also support), and not for generating replies on their behalf. Photos of Japan (talk) 06:23, 2 January 2025 (UTC)[reply]
    This is just semantics.
    For instance, I am OK with someone using a LLM to post a productive comment on a talk page. I am also OK with someone generating a reply with a LLM that is a productive comment to post to a talk page. I am not OK with someone generating text with an LLM to include in an article, and also not OK with someone using a LLM to contribute to an article.
    The only difference between these four sentences is that two of them are more annoying to type than the other two. Gnomingstuff (talk) 08:08, 2 January 2025 (UTC)[reply]
    Most people already assume good faith in those making productive contributions. In situations where good faith is more difficult to assume, would you trust someone who uses an LLM to generate all of their comments as much as someone who doesn't? Photos of Japan (talk) 09:11, 2 January 2025 (UTC)[reply]
    Given that LLM-use is completely irrelevant to the faith in which a user contributes, yes. Of course what amount that actually is may be anywhere between completely and none. Thryduulf (talk) 11:59, 2 January 2025 (UTC)[reply]
    LLM-use is relevant as it allows bad faith users to disrupt the encyclopedia with minimal effort. Such a user posted in this thread earlier, as well as started a disruptive thread here and posted here, all using AI. I had previously been involved in a debate with another sock puppet of theirs, but at that time they didn't use AI. Now it seems they are switching to using an LLM just to troll with minimal effort. Photos of Japan (talk) 21:44, 2 January 2025 (UTC)[reply]
    LLMs are a tool that can be used by good and bad faith users alike. Using an LLM tells you nothing about whether a user is contributing in good or bad faith. If somebody is trolling they can be, and should be, blocked for trolling regardless of the specifics of how they are trolling. Thryduulf (talk) 21:56, 2 January 2025 (UTC)[reply]
    A can of spray paint, a kitchen knife, etc., are tools that can be used for good or bad, but if you bring them some place where they have few good uses and many bad uses then people will be suspicious about why you brought them. You can't just assume that a tool in any context is equally harmless. Using AI to generate replies to other editors is more suspicious than using it to generate a picture exemplifying a fashion style, or a description of a physics concept. Photos of Japan (talk) 23:09, 2 January 2025 (UTC)[reply]
No -- whatever you think of LLMs, the reason they are so popular is that the people who use them earnestly believe they are useful. Claiming otherwise is divorced from reality. Even people who add hallucinated bullshit to articles are usually well-intentioned (if wrong). Gnomingstuff (talk) 06:17, 2 January 2025 (UTC)[reply]
It's rarely productive to get mad at someone on Wikipedia for any reason, but if someone uses an LLM and it screws up their comment they don't get any pass just because the LLM screwed up and not them. You are fully responsible for any LLM content you sign your name under. -- LWG talk 05:19, 1 February 2025 (UTC)[reply]
No. When someone publishes something under their own name, they are incorporating it as their own statement. Plagiarism from an AI or elsewhere is irrelevant to whether they are engaging in good faith. lethargilistic (talk) 17:29, 2 January 2025 (UTC)[reply]
  • Comment LLMs know a few tricks about logical fallacies and some general ways of arguing (rhetoric), but they are incredibly dumb at understanding the rules of Wikipedia. You can usually tell this because it looks like incredibly slick and professional prose, but somehow it cannot get even the simplest points about the policies and guidelines of Wikipedia. I would indef such users for lacking WP:CIR. tgeorgescu (talk) 17:39, 2 January 2025 (UTC)[reply]
    That guideline states "Sanctions such as blocks and bans are always considered a last resort where all other avenues of correcting problems have been tried and have failed." Gnomingstuff (talk) 19:44, 2 January 2025 (UTC)[reply]
    WP:CIR isn't a guideline, but an essay. Relevantly though it is being cited at this very moment in an ANI thread concerning a user who can't/won't communicate without an LLM. Photos of Japan (talk) 20:49, 2 January 2025 (UTC)[reply]
    I blocked that user as NOTHERE a few minutes ago after seeing them (using ChatGPT) make suggestions for text to live pagespace while their previous bad behaviors were under discussion. AGF is not a suicide pact. BusterD (talk) 20:56, 2 January 2025 (UTC)[reply]
    ... but somehow it cannot get even the simplest points about the policies and guidelines of Wikipedia: That problem existed with some humans even prior to LLMs. —Bagumba (talk) 02:53, 20 January 2025 (UTC)[reply]
  • No - Not a good or bad faith issue. PackMecEng (talk) 21:02, 2 January 2025 (UTC)[reply]
  • Yes Using a 3rd party service to contribute to the Wikipedia on your behalf is clearly bad-faith, analogous to paying someone to write your article. Zaathras (talk) 14:39, 3 January 2025 (UTC)[reply]
    Its a stretch to say that a newbie writing a comment using AI is automatically acting in bad faith and not here to build an encyclopedia. PackMecEng (talk) 16:55, 3 January 2025 (UTC)[reply]
    That's true, but this and other comments here show that not a few editors perceive it as bad-faith, rude, etc. I take that as an indication that we should tell people to avoid doing this when they have enough CLUE to read WP:AGF and are making an effort to show they're acting in good faith. Daß Wölf 23:06, 9 January 2025 (UTC)[reply]
  • Comment Large language model AI like Chat GPT are in their infancy. The culture hasn't finished its initial reaction to them yet. I suggest that any proposal made here have an automatic expiration/required rediscussion date two years after closing. Darkfrog24 (talk) 22:42, 3 January 2025 (UTC)[reply]
  • No – It is a matter of how you use AI. I use Google translate to add trans-title parameters to citations, but I am careful to check for Google's output making for good English as well as reflecting the foreign title when it is a language I somewhat understand. I like to think that I am careful, and I do not pretend to be fluent in a language I am not familiar with, although I usually don't announce the source of such a translation. If an editor uses AI profligately and without understanding the material generated, then that is the sin; not AI itself. Dhtwiki (talk) 05:04, 5 January 2025 (UTC)[reply]
    There's a legal phrase, "when the exception swallows the rule", and I think we might be headed there with the recent LLM/AI discussions.
    We start off by saying "Let's completely ban it!" Then in discussion we add "Oh, except for this very reasonable thing... and that reasonable thing... and nobody actually meant this other reasonable thing..."
    The end result is that it's "completely banned" ...except for an apparent majority of uses. WhatamIdoing (talk) 06:34, 5 January 2025 (UTC)[reply]
    Do you want us to reply to you, because you are a human? Or are you just posting the output of an LLM without bothering to read anything yourself? DS (talk) 06:08, 7 January 2025 (UTC)[reply]
    Most likely you would reply because someone posted a valid comment and you are assuming they are acting in good faith and taking responsibility for what they post. To assume otherwise is kind of weird and not inline with general Wikipedia values. PackMecEng (talk) 15:19, 8 January 2025 (UTC)[reply]
  • No The OP seems to misunderstand WP:DGF which is not aimed at weak editors but instead exhorts stronger editors to lead by example. That section already seems to overload the primary point of WP:AGF and adding mention of AI would be quite inappropriate per WP:CREEP. Andrew🐉(talk) 23:11, 5 January 2025 (UTC)[reply]
  • No. Reading the current text of the section, adding text about AI would feel out-of-place for what the section is about. —pythoncoder (talk | contribs) 05:56, 8 January 2025 (UTC)[reply]
  • No, this is not about good faith. Adumbrativus (talk) 11:14, 9 January 2025 (UTC)[reply]
  • Yes. AI use is not a demonstration of bad faith (in any case not every new good-faith editor is familiar with our AI policies), but it is equally not a "demonstration of good faith", which is what the WP:DGF section is about.
It seems some editors are missing the point and !voting as if every edit is either a demonstration of good faith or bad faith. Most interactions are neutral and so is most AI use, but I find it hard to imagine a situation where AI use would point away from unfamiliarity and incompetence (in the CIR sense), and it often (unintentionally) leads to a presumption of laziness and open disinterest. It makes perfect sense to recommend against it. Daß Wölf 22:56, 9 January 2025 (UTC)[reply]
Indeed most kinds of actions don't inherently demonstrate good or bad. The circumspect and neutral observation that AI use is not a demonstration of bad faith... but it is equally not a "demonstration of good faith", does not justify a proposal to one-sidedly say just half. And among all the actions that don't necessarily demonstrate good faith (and don't necessarily demonstrate bad faith either), it is not the purpose of "demonstrate good faith" and the broader guideline, to single out one kind of action to especially mention negatively. Adumbrativus (talk) 04:40, 13 January 2025 (UTC)[reply]
  • Yes. Per Dass Wolf, though I would say passing off a completely AI-generated comment as your own anywhere is inherently bad-faith and one doesn't need to know Wiki policies to understand that. JoelleJay (talk) 23:30, 9 January 2025 (UTC)[reply]
  • Yes. Sure, LLMs may have utility somewhere, and it might be a crutch for people unfamiliar with English, but as I've said above in the other AI RfC, that's a competence issue. This is about comments eating up editor time, energy, about LLMs easily being used to ram through changes and poke at editors in good standing. I don't see a case wherein a prospective editor's command of policy and language is good enough to discuss with other editors while being bad enough to require LLM use. Iseult Δx talk to me 01:26, 10 January 2025 (UTC)[reply]
    Good faith is separate from competence. Trying to do good is separate from having skills and knowledge to achieve good results. Adumbrativus (talk) 04:40, 13 January 2025 (UTC)[reply]
  • No - anyone using a washing machine to wash their clothes must be evil and inherently lazy. They cannot be trusted. ... Oh, sorry, wrong century. Regards, --Goldsztajn (talk) 01:31, 10 January 2025 (UTC)[reply]
    Using a washing machine still results in washed clothes. Using LLMs results in communication failures because the LLM-using party isn't fully engaging. Hydrangeans (she/her | talk | edits) 04:50, 27 January 2025 (UTC)[reply]
    And before there's a reply of 'the washing machine-using party isn't fully engaging in washing clothes'—washing clothes is a material process. The clothes get washed whether or not you pay attention to the suds and water. Communication is a social process. Users can't come to a meeting of the minds if some of the users outsource the 'thinking' to word salad-generators that can't think. Hydrangeans (she/her | talk | edits) 05:00, 27 January 2025 (UTC)[reply]
  • No - As long as a person understands (and knows) what they are talking about, we shouldn't discriminate against folks using generative AI tech for grammar fixes or minor flow improvements. Yes, AI can create walls of text, and make arguments not grounded in policy, but we could do that even without resorting to generative AI. Sohom (talk) 11:24, 13 January 2025 (UTC)[reply]
To expand on my point above. Completely AI generated comments (or articles) are obviously bad, but using AI should be thrown into the same cross-hairs as completely AI generated comments. Sohom (talk) 11:35, 13 January 2025 (UTC)[reply]
@Sohom Datta You mean shouldn't be thrown? I think that would make more sense given the context of your original !vote. Duly signed, ⛵ WaltClipper -(talk) 14:08, 14 January 2025 (UTC)[reply]
  • No. Don't make any changes. It's not a good faith/bad faith issue. The 'yes' arguments are most unconvincing with very bizarre analogies to make their point. Here, I can make one too: "Don't edit with AI; you wouldn't shoot your neighbor's dog with a BB-gun, would you?" Duly signed, ⛵ WaltClipper -(talk) 14:43, 13 January 2025 (UTC)[reply]
  • Yes. If I plug another user's comments into an LLM and ask it to generate a response, I am not participating in the project in good faith. By failing to meaningfully engage with the other user by reading their comments and making an effort to articulate myself, I'm treating the other user's time and energy frivolously. We should advise users that refraining from using LLMs is an important step toward demonstrating good faith. Hydrangeans (she/her | talk | edits) 04:55, 27 January 2025 (UTC)[reply]
  • Yes per Hydrangeans among others. Good faith editing requires engaging collaboratively with your human faculties. Posting an AI comment, on the other hand, strikes me as deeply unfair to those of us who try to engage substantively when there is disagreement. Let's not forget that editor time and energy and enthusiasm are our most important resources. If AI is not meaningfully contributing to our discussions (and I think there is good reason to believe it is not) then it is wasting these limited resources. I would therefore argue that using it is full-on WP:DISRUPTIVE if done persistently enough –– on par with e.g. WP:IDHT or WP:POINT –– but at the very least demonstrates an unwillingness to display good faith engagement. That should be codified in the guideline. Generalrelative (talk) 04:59, 28 January 2025 (UTC)[reply]
  • I appreciate your concern about the use of AI in discussions. It is important to be mindful of how AI is used, and to ensure that it is used in a way that is respectful of others.

I don't think that WP:DGF should be amended to specifically mention AI. However, I do think that it is important to be aware of the potential for AI to be used in a way that is not in good faith. When using AI, it is important to be transparent about it. Let others know that you are using AI, and explain how you are using it. This will help to build trust and ensure that others understand that you are not trying to deceive them. It is also important to be mindful of the limitations of AI. AI is not a perfect tool, and it can sometimes generate biased or inaccurate results. Be sure to review and edit any AI-generated content before you post it.

Finally, it is important to remember that AI is just a tool. It is up to you to use it in a way that is respectful and ethical. |} It's easy to detect for most, can be pointed out as needed. No need to add an extra policy JayCubby

  • Questions: While I would agree that AI may be used as a tool for good, such leveling the field for those with certain disabilities, might it just as easily be used as a tool for disruption? What evidence exists that shows whether or not AI may be used to circumvent certain processes and requirements that make Wiki a positive collaboration of new ideas as opposed to a toxic competition of trite but effective logical fallacies? Cheers. DN (talk) 05:39, 27 January 2025 (UTC)[reply]
    AI can be used to engage positively, it can also be used to engage negatively. Simply using AI is therefore not, in and of itself, an indication of good or bad faith. Anyone using AI to circumvent processes and requirements should be dealt with in the exact same way they would be if they circumvented those processes and requirements using any other means. Users who are not circumventing processes and requirements should not be sanctioned or discriminated against for circumventing processes and requirements. Using a tool that others could theoretically use to cause harm or engage in bad faith does not mean that they are causing harm or engaging in bad faith. Thryduulf (talk) 08:05, 27 January 2025 (UTC)[reply]
    Well said. Thanks. DN (talk) 08:12, 27 January 2025 (UTC)[reply]
    As Hydrangeans explains above, an auto-answer tool means that the person is not engaging with the discussion. They either cannot or will not think about what others have written, and they are unable or unwilling to reply themselves. I can chat to an app if I want to spend time talking to a chatbot. Johnuniq (talk) 22:49, 27 January 2025 (UTC)[reply]
    And as I and others have repeatedly explained, that is completely irrelevant to this discussion. You can use AI in multiple different ways, some of which are productive contributions to Wikipedia, some of which are not. If someone is disruptively not engaging with discussion then they can already be sanctioned for doing so, what tools they are or are not using to do so could not be less relevant. Thryduulf (talk) 02:51, 28 January 2025 (UTC)[reply]
    This implies a discussion that is entirely between AI chatbots deserves the same attention and thought needed to close it, and can effect a consensus just as well, as one between humans, so long as its arguments are superficially reasonable and not disruptive. It implies that editors should expect and be comfortable with arguing with AI when they enter a discussion, and that they should not expect to engage with anyone who can actually comprehend them... JoelleJay (talk) 01:00, 28 January 2025 (UTC)[reply]
    That's a straw man argument, and if you've been following the discussion you should already know that. My comment implied absolutely none of what you claim it does. If you are not prepared to discuss what has actually been written then I am not going to waste more of my time replying to you in detail. Thryduulf (talk) 02:54, 28 January 2025 (UTC)[reply]
    It's not a strawman; it's an example that demonstrates, acutely, the flaws in your premise. Hydrangeans (she/her | talk | edits) 03:11, 28 January 2025 (UTC)[reply]
    If you think that demonstrates a flaw in the premise then you haven't understood the premise at all. Thryduulf (talk) 03:14, 28 January 2025 (UTC)[reply]
    I disagree. If you think it doesn't demonstrate a flaw, then you haven't understood the implications of your own position or the purpose of discussion on Wikipedia talk pages. Hydrangeans (she/her | talk | edits) 03:17, 28 January 2025 (UTC)[reply]
    I refuse to waste any more of my time on you. Thryduulf (talk) 04:31, 28 January 2025 (UTC)[reply]
    Both of the above users are correct. If we have to treat AI-generated posts in good faith the same as human posts, then a conversation of posts between users that is entirely generated by AI would have to be read by a closing admin and their consensus respected provided it didn't overtly defy policy. Photos of Japan (talk) 04:37, 28 January 2025 (UTC)[reply]
    You too have completely misunderstood. If someone is contributing in good faith, we treat their comments as having been left in good faith regardless of how they made them. If someone is contributing in bad faith we treat their comments as having been left in bad faith regardless of how they made them. Simply using AI is not an indication of whether someone is contributing in good or bad faith (it could be either). Thryduulf (talk) 00:17, 29 January 2025 (UTC)[reply]
    But we can't tell if the bot is acting in good or bad faith, because the bot lacks agency, which is the problem with comments that are generated by AI rather than merely assisted by AI. Photos of Japan (talk) 00:31, 29 January 2025 (UTC)[reply]
    But we can't tell if the bot is acting in good or bad faith, because the bot lacks agency exactly. It is the operator who acts in good or bad faith, and simply using a bot is not evidence of good faith or bad faith. What determines good or bad faith is the content not the method. Thryduulf (talk) 11:56, 29 January 2025 (UTC)[reply]
    But the if the bot operator isn't generating their own comments, then their faith doesn't matter, the bot's does. Just like how if I hired someone to edit Wikipedia to me, what would matter is their faith. Photos of Japan (talk) 14:59, 30 January 2025 (UTC)[reply]
    A bot and AI can both be used in good faith and in bad faith. You can only tell which by looking at the contributions in their context, which is exactly the same as contributions made without the use of either. Thryduulf (talk) 23:12, 30 January 2025 (UTC)[reply]
    Not to go off topic, but do you object to any requirements on users for disclosure of use of AI generated responses and comments etc...? DN (talk) 02:07, 31 January 2025 (UTC)[reply]
    I'm not in favour of completely unenforceable requirements that would bring no benefits. Thryduulf (talk) 11:38, 31 January 2025 (UTC)[reply]
    Is it a demonstration of good faith to copy someone else's (let's say public domain and relevant) argument wholesale and paste it in a discussion with no attribution as if it was your original thoughts?
    Or how about passing off a novel mathematical proof generated by AI as if you wrote it by yourself? JoelleJay (talk) 02:51, 29 January 2025 (UTC)[reply]
    Specific examples of good or bad faith contributions are not relevant to this discussion. If you do not understand why this is then you haven't understood the basic premise of this discussion. Thryduulf (talk) 12:00, 29 January 2025 (UTC)[reply]
    If other actions where someone is deceptively appropriating, word-for-word, an entire argument they did not write, are intuitively "not good faith", then why would it be any different in this scenario? JoelleJay (talk) 16:57, 1 February 2025 (UTC)[reply]
    This discussion is explicitly about whether use of AI should be regarded as an indicator of bad faith. Someone deceptively appropriating, word-for-word, an entire argument they did not write is not editing in good faith. It is completely irrelevant whether they do this using AI or not. Nobody is arguing that some uses of AI are bad faith - specific examples are neither relevant nor useful. For simply using AI to be regarded as an indicator of bad faith then all uses of AI must be in bad faith, which they are not (as multiple people have repeatedly explained).
    Everybody agrees that some people who edit using mobile phones do so in bad faith, but we don't regard simply using a mobile phone as evidence of editing in bad faith because some people who edit using mobile phones do so in good faith. Listing specific examples of bad faith use of mobile phones is completely irrelevant to a discussion about that. Replace "mobile phones" with "AI" and absolutely nothing changes. Thryduulf (talk) 18:18, 1 February 2025 (UTC)[reply]
    Except the mobile phone user is actually doing the writing. Hydrangeans (she/her | talk | edits) 19:39, 1 February 2025 (UTC)[reply]
    I know I must be sounding like a stuck record at this point, but there are only so many ways you can describe completely irrelevant things as completely irrelevant before that happens. The AI system is incapable of having faith, good or bad, in the same way that a mobile phone is incapable of having faith, good or bad. The faith comes from the person using the tool not from the tool itself. That faith can be either good or bad, but the tool someone uses does not and cannot tell you anything about that. Thryduulf (talk) 20:07, 1 February 2025 (UTC)[reply]
    That is a really good summary of the situation. Using a widely available and powerful tool does not mean you are acting in bad faith, it is all in how it is used. PackMecEng (talk) 02:00, 28 January 2025 (UTC)[reply]
    A tool merely being widely available and powerful doesn't mean it's suited to the purpose of participating in discussions on Wikipedia. By way of analogy, Infowars is/was widely available and powerful, in the sense of the exercise it influenced over certain Internet audiences, but its very character as a disinformation platform makes it unsuitable for citation on Wikipedia. LLMs are widely available and might be considered 'powerful' in the sense that they can manage a raw output of vaguely plausible-sounding text, but their very character as text prediction models—rather than actual, deliberated communication—make them unsuitable mechanisms for participating in Wikipedia discussions. Hydrangeans (she/her | talk | edits) 03:16, 28 January 2025 (UTC)[reply]
    Even if we assume your premise is true, that does not indicate that someone using an LLM (which come in a wide range of abilities and are only a subset of AI) is contributing in either good or bad faith. It is completely irrelevant to the faith in which they are contributing. Thryduulf (talk) 04:30, 28 January 2025 (UTC)[reply]
    But this isn’t about if you think its a useful tool or not. This is about if someone uses one are they automatically acting in bad faith. We can argue the merits and benefits of AI all day, and they certainly have their place, but nothing you said struck at the point of this discussion. PackMecEng (talk) 13:59, 28 January 2025 (UTC)[reply]
Yes. To echo someone here, no one signed up here to argue with bad AI chat bots. If you're a non native speaker running through your posts through ChatGPT for spelling and grammar that's one thing, but wasting time bickering with AI slop is an insult. Hydronym89 (talk) 16:33, 28 January 2025 (UTC)[reply]
Your comment provides good examples of using AI in good and bad faith, thus demonstrating that simply using AI is not an indication of either. Thryduulf (talk) 00:18, 29 January 2025 (UTC)[reply]
Is that an fair comparison? I disagree that it is. Spelling and grammar checking doesn't seem to be what we are talking about.
The importance of context in which it is being used is, I think, the part that may be perceived as falling through the cracks in relation to AGF or DGF, but I agree there is a legitimate concern for AI being used to game the system in achieving goals that are inconsistent with being WP:HERE.
I think we all agree that time is a valuable commodity that should be respected, but not at the expense of others. Using a bot to fix grammar and punctuation is acceptable because it typically saves more time than it costs. Using AI to enable endless debates, even if both opponents are using it, seems like an awful waste of space, let alone the time it would cost admins that need to sort through it all. DN (talk) 01:16, 29 January 2025 (UTC)[reply]
Engaging in endless debates that waste the time of other editors is disruptive, but this is completely irrelevant to this discussion for two reasons. Firstly, someone engaging in this behaviour may be doing so in either good or bad faith: someone intentionally doing so is almost certainly WP:NOTHERE, and we regularly deal with such people. Other people sincerely believe that their arguments are improving Wikipedia and/or that the people they are arguing with are trying to harm it. This doesn't make it less disruptive but equally doesn't mean they are contributing in bad faith.
Secondly this behaviour is completely independent of whether someone is using AI or not: some people engaging in this behaviour are using AI some people engaging in this behaviour are not. Some people who use AI engage in this behaviour, some people are not.
For the perfect illustration of this see the people in this discussion who are making extensive arguments in good faith, without using AI, while having not understood the premise of the discussion - despite this being explained to them multiple times. Thryduulf (talk) 12:13, 29 January 2025 (UTC)[reply]
Would you agree that using something like grammar and spellcheck is not the same as using AI (without informing other users) to produce comments and responses? DN (talk) 22:04, 29 January 2025 (UTC)[reply]
They are different uses of AI, but that's not relevant because neither use is, in and of itself, evidence of the faith in which the user is contributing. Thryduulf (talk) 22:14, 29 January 2025 (UTC)[reply]
You are conflating "evidence" with "proof". Using AI to entirely generate your comments is not "proof" of bad faith, but it definitely provides less "evidence" of good faith than writing out a comment yourself. Photos of Japan (talk) 03:02, 30 January 2025 (UTC)[reply]
No, it provides no evidence of good or bad faith at all. Thryduulf (talk) 12:54, 30 January 2025 (UTC)[reply]
Does the absence of AI's ability to demonstrate good/bad faith absolve the user of responsibility to some degree in that regard? DN (talk) 23:21, 6 February 2025 (UTC)[reply]
I'm not quite sure I understand what you are asking, but you are always responsible for everything you post, regardless of how on why you posted it or what tools you did or did not use to write it. This means that someone using AI (in any form) to write a post should be treated and responded to identically with how they should be treated and responded to if they had made an identical post without using AI. Thryduulf (talk) 04:10, 7 February 2025 (UTC)[reply]
  • No per WP:CREEP. After reading the current version of the section, it doesn't seem like the right place to say anything about AI. -- King of ♥ ♦ ♣ ♠ 01:05, 29 January 2025 (UTC)[reply]
  • Yes, with caveats this discussion seems to be spiraling into a discussion of several separate issues. I agree with Remsense and Simonm223 and others that using an LLM to generate your reply to a discussion is inappropriate on Wikipedia. Wikipedia runs on consensus, which requires communication between humans to arrive at a shared understanding. Putting in the effort to fully understand and respond to the other parties is an essential part of good-faith engagement in the consensus process. If I hired a human ghost writer to use my Wiki account to argue for my desired changes on a wiki article, that would be completely inappropriate, and using an AI to replace that hypothetical ghost writer doesn't make it any more acceptable. With that said, I understand this discussion to be about how to encourage editors to demonstrate good faith. Many of the people here on both sides seem to think we are discussing banning or encouraging LLM use, which is a different conversation. In the context of this discussion demonstrating good faith means disclosing LLM use and never using LLMs to generate replies to any contentious discussion. This is a subset of "articulating your honest motives" (since we can't trust the AI to accurately convey your motives behind your advocacy) and "avoidance of gaming the system" (since using an LLM in a contentious discussion opens up the concern that you might simply be using minimal effort to waste the time of those who disagree with you and win by exhaustion). I think it is appropriate to mention the pitfalls of LLM use in WP:DGF, though I do not at this time support an outright ban on its use. -- LWG talk 05:19, 1 February 2025 (UTC)[reply]
  • No. For the same reason I oppose blanket statements about bans of using AI elsewhere, it is not only a huge over reach but fundamentally impossible to enforce. I've seen a lot of talk around testing student work to see if it AI, but that is impossible to do reliably. When movable type and the printing press began replacing scribes, the handwriting of scribes began to look like that of a printing press. As AI becomes more prominent, I imagine human writing will begin to look more AI generated. People who use AI for things like helping them translate their native writing into English should not be punished if something leaks through that makes the use obvious. Like anywhere else on the Internet, I foresee any strict rules against the use of AI to quickly be used in bad faith in heated arguments to accuse others of being a bot.
GeogSage (⚔Chat?⚔) 19:12, 2 February 2025 (UTC)[reply]
Hesitantly support. I agree that generative AI and LLMs cause a lot of problems on Wikipedia, and should not be allowed. However, I think that a blanket ban could have a negative impact on both accessibility and the community as a whole. Some people might be using LLMs to help with grammar or spelling, and I'd consider it a net positive because it encourages people with english as a second language to edit wikipedia, which brings diverse perspectives we wouldn't otherwise have. The other issue is that it might encourage people to go on "AI Witch hunts" for lack of a better term. Nobody likes being accused of being an LLM and it negatively impacts the sense of community we have. If there is also a policy against accusing people of using an LLM without evidence, I would likely agree without any issue Mgjertson (talk) 15:53, 6 February 2025 (UTC)[reply]
We do have a policy against accusing people of using an LLM without evidence: WP:AGF. I don't think we should ban the use of LLMs, but because using an LLM to write your comments can make it harder for others to AGF, LLMs should be used with caution and their use should be disclosed. LLMs should never be used to gain the upper hand in a contentious discussion. -- LWG talk 21:17, 6 February 2025 (UTC)[reply]
@LWG We do have a policy against accusing people of using an LLM without evidence: WP:AGF this proposal would effectively remove that. Thryduulf (talk) 21:42, 6 February 2025 (UTC)[reply]
The only "evidence" required at the moment is "my personal belief". WhatamIdoing (talk) 22:33, 6 February 2025 (UTC)[reply]
This may be interpreted as a good example for both sides of the argument. Editors have and will always need to make personal judgements that affect how they participate in the topic or project, if at all. If we want to maintain faith in the project and encourage participation the core principles and policies should at least appear strong enough to adapt to AI. Some people don't mind it, others see it as spam, because it's subjective and based on "personal belief". DN (talk) 20:13, 4 March 2025 (UTC)[reply]

[tangent] If any of the people who have used LLMs/AI tools would be willing to do me a favor, please see the request at Wikipedia talk:Large language models/Archive 7#For an LLM tester. I think this (splitting a very long page – not an article – by date) is something that will be faster and more accurately done by a script than by a human. WhatamIdoing (talk) 18:25, 29 January 2025 (UTC)[reply]

  • Yes. The purpose of a discussion forum is for editors to engage with each other; fully AI-generated responses serve no purpose but to flood the zone and waste people's time, meaning they are, by definition, bad faith. Obviously this does not apply to light editing, but that's not what we're actually discussing; this is about fully AI-generated material, not about people using it grammar an spellchecking software to clean up their own words. No one has come up with even the slightest rationale for why anyone would do so in good faith - all they've provided is vague "but it might be useful to someone somewhere, hypothetically" - which is, in fact, false, as their total inability to articulate any such case shows. And the fact that some people are determine to defend it regardless shows why we do in fact need a specific policy making clear that it is inappropriate. --Aquillion (talk) 19:08, 2 February 2025 (UTC)[reply]
  • No - AI is simply a tool, whether it's to spellcheck or fully generate a comment. Labeling all AI use as bad faith editing is assuming bad faith. ミラー強斗武 (StG88ぬ会話) 07:02, 3 February 2025 (UTC)[reply]
  • Yes unless the user makes it innately clear they are using AI to interact with other editors, per DGF, at least until new policies and guidelines for protecting our human community are in place. Wikipedia's core principals were originally designed around aspects of human nature, experiences and interactions. It was designed for people to collaborate with other people, at a time before AI was so readily available. In it's current state, I don't see any comments explaining how Wikipedia is prepared to handle this tool that likely hasn't realized it's full potential yet. I might agree that whether or not a person chooses to use AI isn't an initial sign of good or bad faith, but that is irrelevant to the core issue of the question as it relates to Wiki's current ability interpret and manage a potentially subversive tool.The sooner the better, before it's use, for better or worse, sways the community's appetite one way or the other. Cheers. DN (talk) 01:01, 7 February 2025 (UTC)[reply]
  • No - A carefully curated and reviewed-by-the-poster AI generated statement is not a problem. The AI is being used as a tool to organize thoughts, and just because the exact wording came from an AI does not mean it does not contribute usefully to the discussion. The issue is not the use of the AI, the issue is in non-useful content or discussion, which, yes, can easily happen if the AI statement is not carefully curated and reviewed by the poster. But that's not the fault of the AI, that's the fault of the human operating the AI... and nothing has changed from our normal policy. This reply is not written by AI, but if it had been, it wouldn't have changed the points raised as relevant. And if irrelevant statements are made... heck, humans do that all the time too! Said comments should be dealt with the same way we deal with humans who spout nonsense. Fieari (talk) 06:23, 13 February 2025 (UTC)[reply]
  • No - Outside of a few editors here I feel like most of the responses on both sides are missing what WP:DGF is about. First off, it is a postive rule about what editors should do. It is also a short rule. Expanding on this is unlikely to improve the rule. Additionally, beginning to talk about things an editor should not do because they imply a departure from godo faith opens the door to many other things that are not the best editing but are also not really what DGF is about. WP needs better guidleines on AI but this guideline does not need to be modified to encompass AI. — Preceding unsigned comment added by Czarking0 (talk • contribs) 07:30, 16 February 2025 (UTC)[reply]
  • Yes Wikipedia was designed for humans. Until our structures are changed to accomodate AI, there needs to be reasonable safety measures to prevent abuse of a system that was designed for humans only. AI can impact every area of Wikipedia with great potential for distortion and abuse. This proposal is reasonable and needed. -- GreenC 19:51, 17 February 2025 (UTC)[reply]
  • Yes but possibly with included clarification on the distinction between AI generated replies and the use of AI as a tool for spellcheck or translation. But someone who just asks an AI to spit out a list of talking points/generate an entire argument to support their predetermined position is not acting in good faith or seriously engaging in the discussion. I also think it is better to be cautious with this, then amend the rules later if needed, than the reverse. Vsst (talk) 06:22, 24 February 2025 (UTC)[reply]
  • No-ish While I can see the possible issues with someone saying to ChatGPT "here's what I want to say, please give me a response that's as convincing as possible" I definitely don't think that this is a clear sign of bad faith. It is not likely to be productive, since ChatGPT isn't likely to be able to make a good policy-based argument here, but I could absolutely see someone doing this who genuinely wants to improve the encyclopedia and thinks the changes they are having ChatGPT argue for really good changes.
Which is to say, if we ban AI-generated comments we definitely shouldn't ban them as an WP:AGF issue. Someone AI-generating their comments doesn't mean they're not acting in good faith. "Good faith" is a very low standard and just means they're not actively WP:NOTHERE, which is why it's what everyone is supposed to assume as a baseline. It's very common to think that someone is acting in good faith but that they're wrong, their arguments are bad, and the changes they want would be harmful. Loki (talk) 22:56, 28 February 2025 (UTC)[reply]
  • Weak support. But I'd prefer it to be added in a way that more broadly states that your opinions should be carefully considered, should be based on the responses/views of others (if there are any), and that you should understand your view well enough to be able to debate it civilly with others if they respond with questions or concerns. This isn't limited to LLM generated comments - it would also cover things like deliberately misusing essays, etc. I disagree with others that it's not a clear sign of bad faith. If someone is unable to articulate their view on a topic themselves based on policies, guidelines, or properly used essays, then they are not acting in good faith by contributing to the discussion. This would also not make it "default" bad faith to use a LLM for spell check, or grammar, or similar - because the person using the LLM in that manner would, by definition, be articulating their ideas to the LLM and having them edited in minor ways. -bɜ:ʳkənhɪmez | me | talk to me! 21:03, 2 March 2025 (UTC)[reply]
    @Berchanhimez, this proposal is to add a line to Wikipedia:Assume good faith. At some level, it's a proposal to say "You are a bad person if you use AI on talk pages". I wonder if you'd be more satisfied with a line in Wikipedia:Talk page guidelines that says something like "AI chat bots can be helpful with cleaning up grammar and spelling errors, but don't use them to completely generate a comment on a talk page." WhatamIdoing (talk) 21:11, 2 March 2025 (UTC)[reply]
    Well, yes, it would be better to do that. But in any case, I don't think people should have to assume good faith of someone who is using an LLM to generate their ideas in the first place. -bɜ:ʳkənhɪmez | me | talk to me! 22:01, 2 March 2025 (UTC)[reply]
    Why? What is it about LLMs that means we need to throw out one of the most fundamental principles (arguably the most fundamental principle) of interaction? How will this assumption of bad faith regarding something that cannot be proven either way improve the project? Thryduulf (talk) 23:39, 2 March 2025 (UTC)[reply]
    I don't support any of that, because my support for AGF in general is because what it says is relatively weak. I don't think that the average editor (which includes IP editors) has a fully thought out policy-based justification for the average edit, and I don't think that's a reasonable expectation. I do think that it's reasonable to expect that editors think their edit is good and will make the wiki better, which is what AGF actually means. Loki (talk) 23:57, 2 March 2025 (UTC)[reply]
    I don't necessarily mean that an editor has to be aware of all policies. But they should at least be understanding of their position enough to be able to understand objections to it that may be based on policies they were unaware of, and be willing to constructively discuss. A user that is using a LLM to generate their arguments, whether the LLM generates "proper" arguments or not, is not going to be able to understand the criticism of their arguments, because they don't understand their arguments in the first place. -bɜ:ʳkənhɪmez | me | talk to me! 20:08, 3 March 2025 (UTC)[reply]
    A user that is using a LLM to generate their arguments [...] is not going to be able to understand the criticism of their arguments, because they don't understand their arguments in the first place. I don't think this is universally true. It is going to be true for some people but some people are going to understand the arguments (e.g. because they've read and understood the LLM output before posting it, blended the LLM output with their own words, been very careful with their prompting, or some combination). Whichever it is, it gives absolutely no indication of the faith in which the user is contributing. Thryduulf (talk) 20:30, 3 March 2025 (UTC)[reply]
    @Berchanhimez, I wonder if you'd take a look at Talk:Böksta Runestone#Clarification on Image Caption – "Possibly Depicting" vs. "Showing". It appears to be a case of a non-native English speaker deciding to "use a LLM for spell check, or grammar, or similar" and getting insulted by editors for using an LLM to translate his own words – and the accusations keep coming, even after he's told them that he's stopped using an LLM for translation and is writing everything himself. WhatamIdoing (talk) 19:58, 3 March 2025 (UTC)[reply]
    The accusations of LLM use there seem to be based on the format the user chose to present their arguments in, which is comparable to a LLM (breaking points out into individual sections with titles, for example). I would agree with you that, if a LLM was used there, it's not to the point of generating the arguments involved, which should be fine. I believe that editors responding as if it was definitively LLM generated when it is at best unclear can be dealt with through normal civility policies. -bɜ:ʳkənhɪmez | me | talk to me! 20:05, 3 March 2025 (UTC)[reply]
    The user admitted his response was generated from an LLM, although WhatamIdoing (talk · contribs) attempted to convince us otherwise. None of us signed up here to attempt interface with someone's LLM outputs. :bloodofox: (talk) 20:08, 3 March 2025 (UTC)[reply]
    No that is not what happened. WAID said it wasn't obvious to her that the initial message was LLM-generated - that's not the same as trying to convince you (or anyone else) that it is or is not. Then later the the other editor said they had stopped using LLMs but you refused to believe them. Thryduulf (talk) 20:33, 3 March 2025 (UTC)[reply]
    You're wrong: "I don't think this editor is using WP:LLM tools", "Have you ever seen a chatbot correctly..." — etc. All attempts to convince us that the user wasn't using generative AI. However, as two users, including myself, pointed out, it was obviously LLM-produced text, which the editor admitted. I'm not here to play games with prompt outputs and I'm certainly not litigating the matter with editors like yourself who openly claim that anyone who refuses to interact with prompt outputs is a victim of anti-AI propaganda. :bloodofox: (talk) 20:39, 3 March 2025 (UTC)[reply]
    What is it with proponents of policies that compel them to tell falsehoods? Anybody can read the what was on that page and see that it does not accord with what you are saying here. You are refusing to engage with someone because they previously used a technology you dislike, regardless of everything else, even though they are no longer using that technology while asserting that it is everybody else who is contributing in bad faith. Thryduulf (talk) 20:49, 3 March 2025 (UTC)[reply]
    Translation: "Those darn users who refuse to sift through my prompt-generated AI spew. Darn their FUD!" :bloodofox: (talk) 21:24, 3 March 2025 (UTC)[reply]
    Looks like they used it for translation and grammar/spell. Both recently affirmed as okay to do. I mean your comments and actions are kind of the exact reason we should not carve out an exception to AGF. PackMecEng (talk) 22:43, 3 March 2025 (UTC)[reply]
    I would agree that one editor's actions and words shouldn't encapsulate or be used diagnose the entirety of the issue, so it seems best to avoid repeating or following that train of thought. Cheers. DN (talk) 20:43, 4 March 2025 (UTC)[reply]
    I took the invitation to read the page for myself, and I think that accusing people of telling falsehoods is inappropriate here, since what happened on that page is pretty much as described by bloodofox. From what I read bloodofox could have and should have been more civil, but they have not told falsehoods. With that said, bloodofox, I also would suggest that we WP:DROPTHESTICK in that specific case, as the user who was correctly accused of using an LLM has since made what I would consider an very honest good-faith response in which they clarified their use of an LLM and agreed to your request to refrain from using it in that way in the future. When someone receives your criticism humbly and agrees to change their behavior accordingly, the correct response is to welcome and encourage them, not continue to condemn them. -- LWG talk 22:57, 3 March 2025 (UTC)[reply]
    I think that Bloodofox is making a material misstatement when he says his response was generated from an LLM. The user says that the first two (=not all) comments were LLM translated.
    Haven't we had multiple conversations in which everyone says that of course LLMs shouldn't create your list of reasons, but it's fine for non-native English speakers to use LLMs to translate their own original thoughts?
    And yet here we are, with an editor explicitly saying that he used ChatGPT only to get his English grammar correct, and we have an editor insisting that this is "AI generated". WhatamIdoing (talk) 17:35, 4 March 2025 (UTC)[reply]
    I don't speak for anyone else here, but even if it's only being used as a translator, it would seem relevant to disclose that information from the start, if for no other reason than transparency in order to avoid miscommunication if the the AI makes a mistake. It could be something as simple as checking a box on the signature control panel. Cheers. DN (talk) 19:33, 4 March 2025 (UTC)[reply]
    Such a requirement would have to come way to make people aware of it before they post for the first time, and would need to come with some assurances that other commenters will not fly off the handle at you for being honest (both for saying you've used AI when you have and for saying you have not used AI when you haven't) - something we currently cannot give. Thryduulf (talk) 19:49, 4 March 2025 (UTC)[reply]
    Are you specifically referring to IP accounts? DN (talk) 19:54, 4 March 2025 (UTC)[reply]
    No, and I don't know why I would be. For any such rule or guidance to be of any benefit whatsoever it needs to apply equally to all editors. Thryduulf (talk) 20:08, 4 March 2025 (UTC)[reply]
    Your first sentence was a bit confusing. DN (talk) 20:10, 4 March 2025 (UTC)[reply]
    If you want people to type "I used an LLM to translate this" (or "I used Google Translate to translate this") in their comments, then you have to tell them to type that before they post the comment. We don't want:
    • A: Posts hand-written but machine translated comment.
    • B: Pitches fit because the comment uses the The Cognitive Style of PowerPoint, which they believe is proof of using ChatGPT.
    • A: Why didn't anyone tell me that machine translation is banned?
    • B: You were just supposed to magically know that you have to type the secret code 'This is 100% original text from me, and I used ChatGPT to correct my grammar errors' when you post anything that has ever been touched by an LLM.
    It does not matter whether User 'A' (or 'B') is logged in. What matters is whether we blame them later for doing something most people think is reasonable, but that we never told them is a problem. WhatamIdoing (talk) 21:07, 4 March 2025 (UTC)[reply]
    @WhatamIdoing This is not nearly so bad as you make it out to be. The answer is to insert a line into a guidelines saying that AI-generated text and translation must be disclosed and then for B to not pitch a fit. This is how literally all our guidelines work (except very, very serious ones). Cremastra (talk) 21:18, 4 March 2025 (UTC)[reply]
    "Insert a line into a guideline", when we know that Wikipedia:Nobody reads the directions? No. That's a path towards A not having any clue about the desired behavior, and B showing up to pitch a fit about how you are Violating the Holy Guideline™ 😱.
    If you want newcomers to do this, you have to put the message where they will see it. That means in the user interface.
    An abuse filter that says newcomer + more than 100 words = warn about undisclosed AI use might work most of the time.
    A line in the editing environment would probably work approximately as well as the one that says "Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable through citations to reliable sources." (See Wikipedia:Copyright problems and related pages if you want to estimate how well that does/n't work.) WhatamIdoing (talk) 22:58, 4 March 2025 (UTC)[reply]
  • No - The proposal here is not "should we stop people from using AI to generate comments" but "should we modify WP:DGF to address use of AI to generate comments. Those are not the same. There's a very easy answer to the latter: No, that's a section best stated simply, without overcomplicating it with specific cases. The other, underlying question which seems to be the basis for much of the drama and ad hominems in this thread (the second time in as many days I've seen ad hominems from the same people on the same subject). The problem is figuring out where to draw a line amid discussions where so many of the loudest participants seem determined to avoid nuance. Nobody wants users to tell an LLM "give me an argument to keep this article using Wikipedia policies" with no additional information, copy/pasting the output. The problem is, it's hard to figure out where to draw a line that doesn't also preclude or stigmatize, say, using an LLM as a to help them overcome interpersonal/communicative differences ranging from straight translation and fixing typos to softening language or checking logical consistency in the user's own arguments. With all of those, there are valid and inappropriate uses, and I'm yet to see a proposal that adequately takes both into consideration. That doesn't even get into the difficulty with detecting/proving this behavior, meaning the only people who will be punished are the newbies who don't realize how reactive some part of this community is on LLM issues. We fundamentally need loosey-goosey language around this, acknowledging its uses are extremely varied.
    Speaking as someone who frequently opposes these blanket rules but is also not a fan of people copy/pasting chatgpt content into talk pages, here's some draft text I could probably get behind (though for WP:TPYES or WP:SEMIAUTO rather than WP:AGF): "LLMs are powerful tools that can assist editing and communication on Wikipedia, but use caution when using them on talk pages. As a collaborative project, talk pages are where contributors converse with one another to determine how to improve an article. Avoid copy-pasting LLM-generated text without justification, and use caution when relying on an LLM to generate ideas, arguments, or evidence in talk page discussions. A pattern of overreliance on LLM-generated content may be viewed as disruptive to the deliberative process." FWIW. — Rhododendrites talk \\ 18:24, 4 March 2025 (UTC)[reply]
    That proposed text is the most constructive proposal by far that I've seen around LLMs and I could support something like that as guidance somewhere, perhaps with the addition of something around the benefits of concision. As you say WP:AGF is definitely not the right place for it, and I'm not certain WP:SEMIAUTO is either. WP:TPYES is the best of the locations you mention, but maybe we should have a central single page of guidance (not hard and fast rules) about the interaction of LLMs and Wikipedia?. Thryduulf (talk) 19:44, 4 March 2025 (UTC)[reply]
    A central page might be a good idea, but it would be a consensus-building challenge if these discussions are any indication. I know what I suggested above doesn't go far enough for some folks, but maybe it could work as a starting point to move from [no rules at all] to [some rough guidance]. — Rhododendrites talk \\ 19:52, 4 March 2025 (UTC)[reply]
    I also could get behind this proposal, though I would like to also see something to the effect of "to avoid misunderstanding, it is best to disclose LLM use up front and ideally share the prompts used to generate any LLM text you contribute to a discussion." -- LWG talk 19:58, 4 March 2025 (UTC)[reply]
    That's not bad, but to the extent I have a concern with LLMs it's very similar to Berchan's, which is to say that I'm not really convinced that someone who has asked an LLM to generate arguments can really respond to counterarguments in the way we'd expect, and I'd ideally like any guideline about it to mention that specifically.
    Or I guess more broadly, I think that any guideline about this shouldn't just say that editors should "use caution" with LLMs, it should tell them what to be cautious about. Loki (talk) 20:00, 4 March 2025 (UTC)[reply]
No. I don't think it would be possible to adequately express the objection, and we would be left with an even bigger problem than the one we had been trying to resolve. I suppose I'm invoking WP:CREEP in a sense. Apart from expressing the general sentiment that everyone should assume and demonstrate good faith, it is not an entity like vandalism (for example) that can easily be identified. We need to treat each case on an individual basis and, perhaps by consensus, decide if that specific action was done in bad faith and if this other specific action was justified. There are so many scare stories about AI, and how it will nuke sites like Wikipedia, that it is easy to assume bad faith where it is involved. As someone said above, AI itself is not the problem—its application is the problem. As with vandalism, that can can only be policed on a case-by-case or person-by-person basis. Spartathenian (talk) 11:55, 13 March 2025 (UTC)[reply]

RfC: Amending ATD-R

Should WP:ATD-R be amended as follows:

−
A page can be [[Wikipedia:BLANKANDREDIRECT|blanked and redirected]] if there is a suitable page to redirect to, and if the resulting redirect is not [[Wikipedia:R#DELETE|inappropriate]]. If the change is disputed via a [[Wikipedia:REVERT|reversion]], an attempt should be made to reach a [[Wikipedia:Consensus|consensus]] before blank-and-redirecting again. Suitable venues for doing so include the article's talk page and [[Wikipedia:Articles for deletion]].
+
A page can be [[Wikipedia:BLANKANDREDIRECT|blanked and redirected]] if there is a suitable page to redirect to, and if the resulting redirect is not [[Wikipedia:R#DELETE|inappropriate]]. If the change is disputed, such as by [[Wikipedia:REVERT|reversion]], an attempt should be made to reach a [[Wikipedia:Consensus|consensus]] before blank-and-redirecting again. The preferred venue for doing so is the appropriate [[WP:XFD|deletion discussion venue]] for the pre-redirect content, although sometimes the dispute may be resolved on the page's talk page.
Notified: Wikipedia talk:Articles for deletion, Wikipedia talk:Deletion policy, Wikipedia talk:Deletion process, Wikipedia talk:Redirect, Wikipedia talk:Redirects for discussion, Wikipedia talk:WikiProject Redirect. voorts (talk/contributions) 00:24, 25 January 2025 (UTC)[reply]

Support (Amending ATD-R)

  • As proposer. This reflects existing consensus and current practice. Blanking of article content should be discussed at AfD, not another venue. If someone contests a BLAR, they're contesting the fact that article content was removed, not that a redirect exists. The venue matters because different sets of editors patrol AfD and RfD. voorts (talk/contributions) 01:54, 24 January 2025 (UTC)[reply]
  • Summoned by bot. I broadly support this clarification. However, I think it could be made even clearer that, in lieu of an AfD, if a consensus on the talkpage emerges that it should be merged to another article, that suffices and reverting a BLAR doesn't change that consensus without good reason. As written, I worry that the interpretation will be "if it's contested, it must go to AfD". I'd recommend the following: This may be done through either a merge discussion on the talkpage that results in a clear consensus to merge. Alternatively, or if a clear consensus on the talkpage does not form, the article should be submitted through Articles for Deletion for a broader consensus to emerge. That said, I'm not so miffed with the proposed wording to oppose it. -bɜ:ʳkənhɪmez | me | talk to me! 02:35, 24 January 2025 (UTC)[reply]
    I don't see this proposal as precluding a merge discussion. voorts (talk/contributions) 02:46, 24 January 2025 (UTC)[reply]
    I don't either, but I see the wording of although sometimes the dispute may be resolved on the article's talk page closer to "if the person who contested/reverted agrees on the talk page, you don't need an AfD" rather than "if a consensus on the talk page is that the revert was wrong, an AfD is not needed". The second is what I see general consensus as, not the first. -bɜ:ʳkənhɪmez | me | talk to me! 02:53, 24 January 2025 (UTC)[reply]
  • I broadly support the idea, an AFD is going to get more eyes than an obscure talkpage, so I suspect it is the better venue in most cases. I'm also unsure how to work this nuance in to the prose, and not suspect the rare cases where another forum would be better, such a forum might emerge anyway. CMD (talk) 03:28, 24 January 2025 (UTC)[reply]
  • Support per my extensive comments in the prior discussion. Thryduulf (talk) 11:15, 24 January 2025 (UTC)[reply]
  • Support, although I don't see much difference between the status quo and the proposed wording. Basically, the two options, AfD or the talk page, are just switched around. It doesn't address the concerns that in some cases RfD is or is not a valid option. Perhaps it needs a solid "yes" or "no" on that issue? If RfD is an option, then that should be expressed in the wording. And since according to editors some of these do wind up at RfD when they shouldn't, then maybe that should be made clear here in this policy's wording, as well. Specifically addressing the RfD issue in the wording of this policy might actually lead to positive change. P.I. Ellsworth , ed. put'er there 17:26, 24 January 2025 (UTC)[reply]
Moving to oppose. P.I. Ellsworth , ed. put'er there 17:23, 28 February 2025 (UTC)[reply]
  • Support the change in wording to state the preference for AFD in the event of a conflict, because AFD is more likely to result in binding consensus than simply more talk. Robert McClenon (talk) 01:04, 25 January 2025 (UTC)[reply]
  • Support Per Thryduulf's reasoning in the antecedent discussion. Jclemens (talk) 04:45, 25 January 2025 (UTC)[reply]
  • Support. AfD can handle redirects, merges, DABifies...the gamut. This kind of discussion should be happening out in the open, where editors versed in notability guidelines are looking for discussions, rather than between two opposed editors on an article talk page (where I doubt resolution will be easily found anyways). Toadspike [Talk] 11:48, 26 January 2025 (UTC)[reply]
  • Support firstly, because by "blank and redirect" you're fundamentally saying that an article shouldn't exist at that title (presumably either because it's not notable, or it is notable but it's best covered at another location). WP:AFD is the best location to discuss this. Secondly, because this has been abused in the past. COVID-19 lab leak theory is one example; and when it finally reached AFD, there was a pretty strong consensus for an article to exist at that title, which settled a dispute that spanned months. There are several other examples; AFD has repeatedly proven to be the best settler of "blank and redirect" situations, and the best at avoiding the "low traffic talk page" issue. ProcrastinatingReader (talk) 18:52, 26 January 2025 (UTC)[reply]
  • Support, my concerns have been aired and I'm comfortable with using AfD as a primary venue for discussing any pages containing substantial article content. Utopes (talk / cont) 22:30, 29 January 2025 (UTC)[reply]
  • Support - So as I see it, the changes proposed are simply to say that disputes should be handled at AfD in preference over the talk page, which I agree with, and also to acknowledge that a dispute over a BLAR could consist of something other than a reversion, which it can. Sounds like a good wording adjustment to me, and it matches what I understand to be already existing wikipedian practice anyway. I agree that it may be a good idea to expressly state in policy that a BLAR should not be deleted at RfD, ever... a BLAR could be retargetted at RfD, but if a BLAR is proposed for deletion it needs to go to AfD instead... but that's not at issue in this proposal, so it's off topic for now. Fieari (talk) 06:13, 13 February 2025 (UTC)[reply]
  • Support. I've made use of ATD-R, but it did occur to me that it is something of a back door option. If a redirect is reverted, that means we have a controversial article which must be brought before wider scrutiny. You can't achieve that on the article talk page, unless the redirect supporter concedes the point, and so it must go to AFD. Having said that, I see no reason to amend the words "via a reversion". Spartathenian (talk) 14:02, 13 March 2025 (UTC)[reply]

Oppose (Amending ATD-R)

  • Oppose. The status quo reflects the nuances that Chipmunkdavis has vocalized. There are also other venues to consider: if the page is a template, WP:TFD would be better. If this is long-stable as a redirect, RfD is a better venue (as I've argued here, for example). -- Tavix (talk) 17:13, 24 January 2025 (UTC)[reply]
    The intent here is to address articles. Obviously TfD is the place to deal with templates and nobody is suggesting otherwise. voorts (talk/contributions) 17:28, 24 January 2025 (UTC)[reply]
    The section in question is about pages, not articles. If the proposed wording is adapted, it would be suggesting that WP:BLAR'd templates go to AfD. As I explained in the previous discussion, that's part of the reason why the proposed wording is problematic and that it was premature for an RfC on the matter. -- Tavix (talk) 17:35, 24 January 2025 (UTC)[reply]
    As a bit of workshopping, how about changing doing so to articles? -- Tavix (talk) 17:46, 24 January 2025 (UTC)[reply]
    Done. Pinging @Consarn, @Berchanhimez, @Chipmunkdavis, @Thryduulf, @Paine Ellsworth, @Tavix. voorts (talk/contributions) 22:51, 24 January 2025 (UTC)[reply]
    Gentle reminder to editor Voorts: as I'm subscribed to this RfC, there is no need to ping me. That's just an extra unnecessary step. P.I. Ellsworth , ed. put'er there 22:58, 24 January 2025 (UTC)[reply]
    Not everyone subscribes to every discussion. I regularly unsubscribe to RfCs after I !vote. voorts (talk/contributions) 22:59, 24 January 2025 (UTC)[reply]
    I don't. Just saving you some time and extra work. P.I. Ellsworth , ed. put'er there 23:03, 24 January 2025 (UTC)[reply]
    considering the above discussion, my vote hasn't really changed. this does feel incomplete, what with files and templates existing and all that, so that still feels undercooked (and now actively article-centric), hence my suggestion of either naming multiple venues or not naming any consarn (speak evil) (see evil) 23:28, 24 January 2025 (UTC)[reply]
    Agree. I'm beginning to understand those editors who said it was too soon for an RfC on these issues. While I've given this minuscule change my support (and still do), this very short paragraph could definitely be improved with a broader guidance for up and coming generations. P.I. Ellsworth , ed. put'er there 23:38, 24 January 2025 (UTC)[reply]
    If you re-read the RFCBEFORE discussions, the dispute was over what to do with articles that have been BLARed. That's why this was written that way. I think it's obvious that when there's a dispute over a BLARed article, it should go to AfD, not RfD. I proposed this change because apparently some people don't think that's so obvious. Nobody has or is disputing that BLARed templates should go to TfD, files to FfD, or miscellany to MfD. And none of that needs to be spelled out here per WP:CREEP. voorts (talk/contributions) 00:17, 25 January 2025 (UTC)[reply]
    If you want to be fully inclusive, it could say something like "the appropriate deletion venue for the pre-redirect content" or "...the blanked content" or some such. I personally don't think that's necessary, but don't object if others disagree on that score. (To be explicit neither the change that was made, nor a change to along the lines of my first sentence, change my support). Thryduulf (talk) 00:26, 25 January 2025 (UTC)[reply]
    Exactly. And my support hasn't changed as well. Goodness, I'm not saying this needs pages and pages of instruction, nor even sentence after sentence. I think us old(er) farts sometimes need to remember that less experienced editors don't necessarily know what we know. I think you've nailed the solution, Thryduulf! The only thing I would add is something short and specific about how RfD is seldom an appropriate venue and why. P.I. Ellsworth , ed. put'er there 00:35, 25 January 2025 (UTC)[reply]
    Done. Sorry if I came in a bit hot there. voorts (talk/contributions) 00:39, 25 January 2025 (UTC)[reply]
    Also, I think something about RfDs generally not being appropriate could replace the current footnote at the end of this paragraph. voorts (talk/contributions) 00:52, 25 January 2025 (UTC)[reply]
    @Voorts: That latest change moves me to the "strong oppose" category. Again, RfD is the proper venue when the status quo is a redirect. -- Tavix (talk) 01:00, 25 January 2025 (UTC)[reply]
    I'm going to back down a bit with an emphasis on the word "preferred". I agree that AfD is the preferred venue, but my main concern is if a redirect gets nominated for deletion at RfD and editors make purely jurisdictional arguments that it should go to AfD because there's article content in its history even though it's blatantly obvious the article content should be deleted. -- Tavix (talk) 01:22, 25 January 2025 (UTC)[reply]
    this is a big part of why incident 91724 could become a case study. "has history, needs afd" took priority over the fact that the history had nothing worth keeping, the redirect had been stable as a blar for years, and the ages of the folks at rfd (specifically the admins closing or relisting discussions on blars) having zero issue with blars being nominated and discussed there (with a lot of similar blars nominated around the same time as that one being closed with relatively litte fuss, and blars nominated later being closed with no fuss), and at least three other details i'm missing
    as i said before, if a page was blanked relatively recently and someone can argue for there being something worth keeping in it, its own xfd is fine and dandy, but otherwise, it's better to just take it to rfd and leave the headache for them. despite what this may imply, they're no less capable of evaluating article content, be it stashed away in the edit history or proudly displayed in any given redirect's target consarn (speak evil) (see evil) 10:30, 25 January 2025 (UTC)[reply]
    As I've explained time and time again it's primarily not about the capabilities of editors at RfD it's about discoverability. When article content is discussed at AfD there are multiple systems in place that mean everybody interested or potentially interested knows that article content is being discussed, the same is not true when article content is discussed at RfD. Time since the BLAR is completely irrelevant. Thryduulf (talk) 10:39, 25 January 2025 (UTC)[reply]
    if you want to argue that watchlists, talk page notifs, and people's xfd logs aren't enough, that's fine by me, but i at best support also having delsort categories for rfd (though there might be some issues when bundling multiple redirects together, though that's nothing twinkle or massxfd can't fix), and at worst disagree because, respectfully, i don't have much evidence or hope of quake 2's biggest fans knowing what a strogg is. maybe quake 4, but its list of strogg was deleted with no issue (not even a relisting). see also quackifier, just under that discussion consarn (speak evil) (see evil) 11:03, 25 January 2025 (UTC)[reply]
    I would think NOTBURO/IAR would apply in those cases. voorts (talk/contributions) 02:41, 25 January 2025 (UTC)[reply]
    I would think that as well, but unfortunately that's not reality far too often. I can see this new wording being more ammo for process wonkery. -- Tavix (talk) 02:49, 25 January 2025 (UTC)[reply]
    Would a footnote clarifying that ameliorate your concerns? voorts (talk/contributions) 02:53, 25 January 2025 (UTC)[reply]
    Unless a note about RfD being appropriate in any cases makes it clear that it strictly limited to (a) when the content would be speedily deleted if restored, or (b) there has been explicit consensus the content should not be an article (or template or whatever), then it would move me into a strong oppose. This is not "process wonkery" but the fundamental spirit of the entire deletion process. Thryduulf (talk) 03:35, 25 January 2025 (UTC)[reply]
    ^Voorts, see what I mean? -- Tavix (talk) 03:43, 25 January 2025 (UTC)[reply]
    See what I mean this attitude is exactly why we are here. I've spent literal years explaining why I hold the position I do, and how it aligns with the letter and spirit of pretty much every relevant policy and guideline. It shouldn't even be controversial for blatantly obvious the article content should be deleted to mean "would be speedily deleteable if restored", yet on this again a single digit number of editors have spent years arguing that they know better. Thryduulf (talk) 03:56, 25 January 2025 (UTC)[reply]
    both sides are on single digits at the time of writing this, we just need 3 more supports to make it 10 lol
    ultimately, this has its own caveat(s). namely, with the csd not covering every possible scenario. regardless of whether or not it's intentional, it's not hard to look at something and go "this ain't it, chief". following this "process" to the letter would just add more steps to that, by restoring anything that doesn't explicitly fit a csd and dictating that it has to go to afd so it can get the boot there for the exact same reason consarn (speak evil) (see evil) 10:51, 25 January 2025 (UTC)[reply]
    Thanks. That alleviates my concerns. -- Tavix (talk) 23:45, 24 January 2025 (UTC)[reply]
  • oppose, though with the note that i support a different flavor of change. on top of the status quo issue pointed out by tavix (which i think we might need to set a period of time for, like a month or something), there's also the issue of the article content in question. if it's just unsourced, promotional, in-universe, and/or any other kind of fluff or cruft or whatever else, i see no need to worry about the content, as it's not worth keeping anyway (really, it might be better to just create a new article from scratch). if a blar, which has been stable as a redirect, did have sources, and those sources were considered reliable, then i believe restoring and sending to afd would be a viable option (see purple francis for an example). outside of that, i think if the blar is reverted early enough, afd would be the better option, but if not, then it'd be rfd
    for this reason, i'd rather have multiple venues named ("Suitable venues include Articles for Deletion, Redirects for Discussion, and Templates for Discussion"), no specific venue at all ("The dispute should be resolved in a fitting discussion venue"), or conditions for each venue (for which i won't suggest a wording because of the aforementioned status quo time issue) consarn (speak evil) (see evil) 17:50, 24 January 2025 (UTC)[reply]
  • Oppose. The proper initial venue for discussing this should be the talk page; only if agreement can't be reached informally there should it proceed to AfD. Espresso Addict (talk) 16:14, 27 January 2025 (UTC)[reply]
  • Oppose as written to capture some nuances; there may be a situation where you want a BLAR to remain a redirect, but would rather retarget it. I can't imagine the solution there is to reverse the BLAR and discuss the different redirect-location at AfD. Besides that, I think the intention is otherwise solid, as long as its consistent in practice. Moving forward it would likely lead to many old reversions of 15+ year BLAR'd content, but perhaps that's the intention; maybe only reverse the BLAR if you're seeking deletion of the page, at which point AfD becomes preferable? Article deletion to be left to AfD at that point? Utopes (talk / cont) 20:55, 27 January 2025 (UTC), moving to support, my concerns have been resolved and I'm happy to use AfD as a primary venue for discussing article content. Utopes (talk / cont) 22:29, 29 January 2025 (UTC)[reply]
  • Oppose - the first part of the new wording makes it more vague than before. "If the change is disputed via a reversion" was clear. "If the change is disputed, such as by reversion" is vague. What other ways of dispute other than reversion are there? I am assuming "reversion" here implies reversion to pre-redirect content. If the intent of the change in wording to is incorporate scenarios where an editor prefers a redirect target of "Article B" instead of "Article A", or a dab page, or sees no appropriate target, where it is not a reversion, but a bold edit or an RfD nomination, then the accompanying phrase "before blank-and-redirecting again." does not make sense.
I oppose the second part of the new wording as well. The current wording gave editors an equal choice of forum - talk page vs XfD. Why should XfD be the preferred venue, and the talkpage be the forum only "sometimes". I see what Berchanhimez says. If an editor wants to revert and add a {{mergeto}} as a better alternative to BLAR, and all parties are agreeable to in the talk page, why force them to go to XfD. Although, I won't go as far as Espresso Addict in saying the talk page "should" be the proper initial venue, the current wording of giving equal choice of venu goes better with me, than forcing a preference. If editors do not agree on a talk page, it is understood one of them, or a neutral party will take to AfD/XfD.
I support the third part of the change, courtesy Thryduulf, of "appropriate deletion discussion venue for the pre-redirect content" which resolves Tavix's concern of AfD/TfD/MfD.
Note that I haven't touched upon RfD at all, or the prior heated discussions around it, because I don't see the current or new wordings addressing anything about Rfd. It would require a separate RfC to resolve the RfD concerns.
In summary, retain current wordings for part 1 and part 2. Go ahead with new wordings for part 3. Jay 💬 16:37, 28 February 2025 (UTC)[reply]
The first part was intended to make clear that if someone doesn't revert, but nonetheless contests the BLAR, they should still bring it to the appropriate non-RfD XfD. The second part doesn't limit anyone from going to talk to discuss things first. It merely makes clear that if something can't be resolved, it should go to the appropriate XfD. voorts (talk/contributions) 19:02, 28 February 2025 (UTC)[reply]
  • Oppose per editor Jay above pretty much word for word, an eloquent positional description! I'm slayed and swayed, and that doesn't happen much. P.I. Ellsworth , ed. put'er there 17:23, 28 February 2025 (UTC)[reply]
  • Oppose; while we'd like consistency with the WP:BRD cycle, we'd also like less bureaucracy and less work distracting from building the encyclopedia, so it should be rewritten to explicitly prefer the talk page over XFD. ミラP@Miraclepine 04:19, 1 March 2025 (UTC)[reply]
  • Oppose in strongest possible terms. XFD is a process-heavy, red-tape-filled procedure that is used solely for two reasons; first, because deletion is impossible for regular editors to implement or reverse; and second, because the WMF requires that we have a way to remove things from where ordinary editors can see them. A blank-and-redirect meets neither of these criteria - it is inappropriate to send it to XFD. I would in fact support language specifically discouraging taking such disputes to AFD, where they waste time and energy and involve far more bloated red tape than such discussions ought to have, while also creating a bias towards retaining newly-added disputed material that goes against WP:BRD, WP:BURDEN, and WP:ONUS. Making it possible to send a redirect to AFD implies that an editor can add something on which there is no consensus, then respond to any attempts to remove it by demanding a hearing at AFD, leading to it being retained if discussions there fail to reach a consensus; this is inappropriate and against our other practices and policies, which normally result in new additions that fail to obtain a consensus getting removed. If anything we should therefore prohibit sending redirects to AFD in situations where an actual deletion is not being requested, or make it clear that if the article is newly-created and was redirected prior to being sent to AFD, an AFD outcome of no consensus leads to it remaining a redirect, such that editors cannot abuse AFD to turn WP:BURDEN on its head like this. --Aquillion (talk) 12:19, 13 March 2025 (UTC)[reply]

Discussion (Amending ATD-R)

  • not entirely sure i should vote, but i should probably mention this discussion in wt:redirect that preceded the one about atd-r, and i do think this rfc should affect that as well, but wouldn't be surprised if it required another one consarn (speak evil) (see evil) 12:38, 24 January 2025 (UTC)[reply]
  • I know it's not really in the scope of this discussion but to be perfectly honest, I'm not sure why BLAR is a still a thing. It's a cliche, but it's a hidden mechanism for backdoor deletion that often causes arguments and edit wars. I think AfDs and talk-page merge proposals where consensus-building exists produce much better results. It makes sense for duplicate articles, but that is covered by A10's redirection clause. J947 ‡ edits 03:23, 25 January 2025 (UTC)[reply]
    BLARs are perfectly fine when uncontroversial, duplicate articles are one example but bold merges are another (which A10 doesn't cover). Thryduulf (talk) 03:29, 25 January 2025 (UTC)[reply]
    It is my impression that BLARs often occur without intention of an accompanying merge. J947 ‡ edits 03:35, 25 January 2025 (UTC)[reply]
    Yes because sometimes there's nothing to merge. voorts (talk/contributions) 16:01, 25 January 2025 (UTC)[reply]
    I didn't say, or intend to imply, that every BLAR is related to a merge. The best ones are generally where the target article covers the topic explicitly, either because content is merged, written or already exists. The worst ones are where the target is of little to no (obvious) relevance, contains no (obviously) relevant content and none is added. Obviously there are also ones that lie between the extremes. Any can be controversial, any can be uncontroversial. Thryduulf (talk) 18:20, 25 January 2025 (UTC)[reply]
    BLARs are preferable to deletion for content that is simply non-notable and does not run afoul of other G10/11/12-type issues. Jclemens (talk) 04:46, 25 January 2025 (UTC)[reply]
  • I'm happy to align to whatever consensus decides, but I'd like to discuss the implications because that aspect is not too clear to me. Does this mean that any time an redirect contains any history and deletion is sought, it should be restored and go to AfD? Currently there's some far-future redirects with ancient history, how would this amendment affect such titles? Utopes (talk / cont) 09:00, 29 January 2025 (UTC)[reply]
    see why i wanted that left to editor discretion (status quo, evaluation, chance of an rm or histmerge, etc.)? i trust in editors who aren't that wonk from rfd (cogsan? cornsam?) to see a pile of unsourced cruft tucked away in the history and go "i don't think this would get any keep votes in afd" consarn (speak evil) (see evil) 11:07, 29 January 2025 (UTC)[reply]
    No. This is about contested BLARs, not articles that were long ago BLARed where someone thinks the redirect should be deleted. voorts (talk/contributions) 12:42, 29 January 2025 (UTC)[reply]
    then it might depend. is its status as a blar the part that is being contested? if the title is being contested (hopefully assuming the pre-blar content is fine), would "move" be a fitting outcome outside of rm? is it being contested solely over meta-procedural stuff, as opposed to actually supporting or opposing its content? why are boots shaped like italy? was it stable as a redirect at the time of contest or not? does this account for its status as a blar being contested in an xfd venue (be it for restoring or blanking again)? it's a lot of questions i feel the current wording doesn't answer, when it very likely should. granted, what i suggested isn't much better, but shh
    going back to that one rfd i keep begrudgingly bringing up (i kinda hate it, but it's genuinely really useful), if this wording is interpreted literally, the blar was contested a few years prior and should thus be restored, regardless of the rationales being less than serviceable ("i worked hard on this" one time and... no reason the other), the pre-blar content being complete fancruft, and no one actually supporting the content in rfd consarn (speak evil) (see evil) 13:54, 29 January 2025 (UTC)[reply]
    Well that case you keep citing worked out as a NOTBURO situation, which this clraification would not override. There are obviously edge cases that not every policy is going to capture. IAR is a catch-all exception to every single policy on Wikipedia. The reason we have so much scope creep in PAGs is becaude editors insist on every exception being enumerated. voorts (talk/contributions) 14:51, 29 January 2025 (UTC)[reply]
    if an outcome (blar status is disputed in rfd, is closed as delete anyway) is common enough, i feel the situation goes from "iar good" to "rules not good", at which point i'd rather have the rules adapt. among other things, this is why i want a slightly more concrete time frame to establish a status quo (while i did suggest a month, that could also be too short), so that blars that aren't blatantly worth or not worth restoring after said time frame (for xfd or otherwise) won't be as much of a headache to deal with. of course, in cases where their usefulness or lack thereof isn't blatant, then i believe a discussion in its talk page or an xfd venue that isn't rfd would be the best option consarn (speak evil) (see evil) 17:05, 29 January 2025 (UTC)[reply]
    I think the idea that that redirect you mentioned had to go to AfD was incorrect. The issue was whether the redirect was appropriate, not whether the old article content should be kept. voorts (talk/contributions) 17:41, 29 January 2025 (UTC)[reply]
    sure took almost 2 months to get that sorted out lol consarn (speak evil) (see evil) 17:43, 29 January 2025 (UTC)[reply]
    Bad facts make bad law, as attorneys like to say. voorts (talk/contributions) 17:45, 29 January 2025 (UTC)[reply]
    Alright. @Voorts: in that case I think I agree. I.e., if somebody BLAR's a page, the best avenue to discuss merits of inclusion on Wikipedia, would be at a place like AfD, where it is treated as the article it used to be, as the right eyes for content-deletion will be present at AfD. To that end, this clarification is likely a good change to highlight this fact. I think where I might be struggling is the definition of "contesting a BLAR" and what that might look like in practice. To me, "deleting a long-BLAR'd redirect" is basically the same as "contesting the BLAR", I think?
    An example I'll go ahead and grab is 1900 Lincoln Blue Tigers football team from cat:raw. This is not a great redirect pointed at Lincoln Blue Tigers from my POV, and I'd like to see it resolved at some venue, if not resolved boldly. This page was BLAR'd in 2024, and I'll go ahead and notify Curb Safe Charmer who BLAR'd it. I think I'm inclined to undo the BLAR, not because I think the 1900 season is particularly notable, but because redirecting the 1900 season to the page about the Lincoln Blue Tigers doesn't really do much for the people who want to read about the 1900 season specifically. (Any other day I would do this boldly, but I want to seek clarification).
    But let's say this page was BLAR'd in 2004, as a longstanding redirect for 20 years. I think it's fair to say that as a redirect, this should be deleted. But this page has history as an article. So unless my interpretation is off, wouldn't the act of deleting a historied redirect that was long ago BLAR'd, be equivalent to contesting the BLAR, that turned the page into a redirect in the first place, regardless of the year? Utopes (talk / cont) 20:27, 29 January 2025 (UTC)[reply]
    I don't think so. In 2025, you're contesting that it's a good redirect from 2004, not contesting the removal of article content. If somebody actually thought the article should exist, that's one thing, but procedural objections based on RfD being an improper forum without actually thinking the subject needs an article is the kind of insistence on needless bureaucracy that NOTBURO is designed to address. voorts (talk/contributions) 20:59, 29 January 2025 (UTC)[reply]
    I see, thank you. WP:NOTBURO is absolutely vital to keep the cogs rolling, lol. Very oftentimes at RfD, there will be a "page with history" that holds up the process, all for the discussion to close with "restore and take to AfD". Cutting out the middle, and just restoring article content without bothering with an RfD to say "restore and take to AfD" would make the process and all workflows lot smoother. @Voorts:, from your own point of view, I'm very interested in doing something about 1900 Lincoln Blue Tigers football team, specifically, to remove a redirect from being at this title (I have no opinion as to whether or not an article should exist here instead). Because I want to remove this redirect; do you think I should take it to RfD as the correct venue to get rid of it? (Personally speaking, I think undoing the BLAR is a lot more simple and painless especially so as I don't have a strong opinion on article removal, but if I absolutely didn't want an article here, would RfD still be the venue?) Utopes (talk / cont) 21:10, 29 January 2025 (UTC)[reply]
    I would take that to RfD. If the editor who created the article or someone else reversed the BLAR, I'd bring it to AfD. voorts (talk/contributions) 21:16, 29 January 2025 (UTC)[reply]
    Alright. I think we're getting somewhere. I feel like some editors may consider it problematic to delete a recently BLAR'd article at RfD under any circumstance. Like if Person A BLAR's a brand new article, and Person B takes it to RfD because they disagree with the existence of a redirect at the title and it gets deleted, then this could be considered a "bypassal of the AfD process". Whether or not it is or isn't, people have cited NOTBURO for deleting it. I was under the impression this proposal was trying to eliminate this outcome, i.e. to make sure that all pages with articles in its history should be discussed at AfD under its merits as an article instead of anywhere else. I've nommed redirects where people have said "take to AfD", and I've nommed articles where people have said "take to RfD". I've never had an AfD close as "wrong venue", but I've seen countless RfDs close in this way for any amount of history, regardless of the validity of there being a full-blown article at this title, only to be restored and unanimously deleted at AfD. I have a feeling 1900 Lincoln Blue Tigers football team would close in the same way, which is why I ask as it seems to be restoring the article would just cut a lot of tape if the page is going to end up at AfD eventually. Utopes (talk / cont) 21:36, 29 January 2025 (UTC)[reply]
    I think the paragraph under discussion here doesn't really speak to what should happen in the kind of scenario you're describing. The paragraph talks about "the change" (i.e., the blanking and redirecting) being "disputed", not about what happens when someone thinks a redirect ought not to exist. I agree with you that that's needless formalism/bureaucracy, but I think that changing the appropriate venue for those kinds of redirects would need a separate discussion. voorts (talk/contributions) 21:42, 29 January 2025 (UTC)[reply]
Fair enough, yeah. I'm just looking at the definition of "disputing/contesting a BLAR". For this situation, I think it could be reasoned that I am "disputing" the "conversion of this article into a redirect". Now, I don't really have a strong opinion on whether or not an article should or shouldn't exist, but because I don't think a redirect should be at this title in either situation, I feel like "dispute" of the edit might still be accurate? Even if it's not for a regular reason that most BLARs get disputed 😅. I just don't think BLAR'ing into a page where a particular season is not discussed is a great change. That's what I meant about "saying a redirect ought not to exist" might be equivalent to "disputing/disagreeing with the edit that turned this into a redirect to begin with". And if those things are equivalent, then would that make AfD the right location to discuss the history of this page as an article? That was where I was coming from; hopefully that makes sense lol. If it needs a separate discussion I can totally understand that as well. Utopes (talk / cont) 21:57, 29 January 2025 (UTC)[reply]
In the 1900 Blue Tigers case and others like it where you think that it should not be a redirect but have no opinion about the existence or otherwise of an article then simply restore the article. Making sure it's tagged for any relevant WikiProjects is a bonus but not essential. If someone disputes your action then a talk page discussion or AfD is the correct course of action for them to take. If they think the title should be a red link then AfD is the only correct venue. Thryduulf (talk) 22:08, 29 January 2025 (UTC)[reply]
Alright, thank you Thryduulf. That was kind of the vibe I was leaning towards as well, as AfD would be able to determine the merits the page's existence as a subject matter. This all comes together because not too long ago I was criticized for restoring a page that contained an article in its history. In this discussion for Wikipedia:Articles for deletion/List of cultural icons of Canada, I received the following message regarding my BLAR-reversal: For the record, it's really quite silly and unnecessary to revert an ancient redirect from 2011 back into a bad article that existed for all of a day before being redirected, just so that you can force it through an AFD discussion — we also have the RFD process for unnecessary redirects, so why wasn't this just taken there instead of being "restored" into an article that the restorer wants immediately deleted? I feel like this is partially comparable to 1900 Lincoln Blue Tigers football team, as both of these existed for approx a day before the BLAR, but if restoring a 2024 article is necessary per Thryduulf, but restoring a 2011 article is silly per Bearcat, I'm glad that this has the potential to be ironed out via this RfC, possibly. Utopes (talk / cont) 22:18, 29 January 2025 (UTC)[reply]
There are exactly two situations where an AfD is not required to delete article content:
  1. The content meets one or more criteria for speedy deletion
  2. The content is eligible to be PRODed
Bearcat's comment is simply wrong - RfD is not the correct venue for deleting article content, regardless of how old it is. Thryduulf (talk) 22:25, 29 January 2025 (UTC)[reply]
Understood. I'll keep that in mind for my future editing, and I'll move from the oppose to the support section of this RfC. Thank you for confirmation regarding these situations! Cheers, Utopes (talk / cont) 22:28, 29 January 2025 (UTC)[reply]
@Utopes: Note that is simply Thryduulf's opinion and is not supported by policy (despite his vague waves to the contrary). Any redirect that has consensus to delete at RfD can be deleted. I see that you supported deletion of the redirect at Wikipedia:Redirects for discussion/Log/2024 September 17#List of Strogg in Quake II. Are you now saying that should have procedurally gone to AfD even though it was blatantly obvious that the article content is not suitable for Wikipedia? -- Tavix (talk) 22:36, 29 January 2025 (UTC)[reply]
I'm saying that AfD probably would have been the right location to discuss it at. Of course NOTBURO applies and it would've been deleted regardless, really, but if someone could go back in time, bringing that page to AfD instead of RfD seems like it would have been more of an ideal outcome. I would've !voted delete on either venue. Utopes (talk / cont) 22:39, 29 January 2025 (UTC)[reply]
@Utopes: Note that Tavix's comments are, despite their assertions to the contrary, only their opinion. It is notable that not once in the literal years of discussions, including this one, have they managed to show any policy that backs up this opinion. Content that is blatantly unsuitable for Wikipedia can be speedily deleted, everything that can't be is not blatantly unsuitable. Thryduulf (talk) 22:52, 29 January 2025 (UTC)[reply]
Here you go. Speedy deletion is a process that provides administrators with broad consensus to bypass deletion discussion, at their discretion. RfD is a deletion discussion venue for redirects, so it doesn't require speedy deletion for something that is a redirect to be deleted via RfD. Utopes recognizes there is a difference between "all redirects that have non-speediable article content must be restored and discussed at AfD" and "AfD is the preferred venue for pages with article content", so I'm satisfied to their response to my inquiry. -- Tavix (talk) 23:22, 29 January 2025 (UTC)[reply]
Quoting yourself in a discussion about policy doe not show that your opinion is consistent with policy. Taking multiple different bits of policy and multiple separate facts, putting them all in a pot and claiming the result shows your opinion is supported by policy didn't do that in the discussion you quoted and doesn't do so now. You have correctly quoted what CSD is and what RfD is, but what you haven't done is acknowledged that when a BLARed article is nominated for deletion it is article content that will be deleted, and that article content nominated for deletion is discussed at AfD not RfD. Thryduulf (talk) 02:40, 30 January 2025 (UTC)[reply]
  • I requested closure at WP:CR, but that was a week ago. Fortunately, I changed the "do not archive" date to two more weeks before the bot does something. Is one closer sufficient? If so, why hasn't the closure been done yet? George Ho (talk) 02:02, 28 February 2025 (UTC)[reply]
    Is one closer sufficient? Yes. This discussion is not that complicated. If so, why hasn't the closure been done yet? First, there's a backlog and closers try to close older discussions first. Second, see WP:NORUSH. Third, see WP:VOLUNTEER. voorts (talk/contributions) 02:08, 28 February 2025 (UTC)[reply]
    Well, we'll agree to disagree then. From what I learned so far, having two or more closers is more efficient and quicker than waiting for just one who usually understands the policies very lot. Usually, a two-person closure is (unofficially) reserved mostly for more complex cases. Nonetheless, I think it would resolve backlogs. But your wishes and decision then. George Ho (talk) 02:42, 28 February 2025 (UTC)[reply]
    I close a lot of discussions. It is much faster to read a discussion and write a close than it is to work on a close, send it to another person for additions/edits, wait for them to send it back, ad nauseam. voorts (talk/contributions) 02:53, 28 February 2025 (UTC)[reply]
    For example, this discussion would probably take me about half an hour to an hour to read, then write a close I'm happy with. If I then had to have a back-and-forth with another editor until we were both happy with the close, things would take much longer. voorts (talk/contributions) 02:54, 28 February 2025 (UTC)[reply]
    Or, if we decided to write it together over google docs or something simultaneously, we'd both have to first read the discussion, schedule a time to chat or post messages back and forth on wiki to determine that we're on the same page (and if we're not, then neither of us should probably close it), and then actually write the close. voorts (talk/contributions) 02:56, 28 February 2025 (UTC)[reply]
    For better understanding, I found one example: this one from 2017, which I requested such closure... well, against initiator's wishes. But the closure was somewhat criticized: Sept 2018. Tried to find other discussions containing such criticisms, but just found 2017 post-RfC discussion and past user talk discussion for better understanding, hopefully. George Ho (talk) 03:04, 28 February 2025 (UTC)[reply]
    We only request two or three closers when:
    • the result is not obvious to everyone and
    • the result is going to make some (i.e., a lot of) people very unhappy.
    The idea with having multiple closers is that the larger number will silence some complaints (sure, you didn't get what you wanted, but multiple admins said you lost, so complaining's probably a waste of time) and spread out some of the others (each unhappy person yells at a different closer, instead of everyone yelling at a single person).
    If you are not expecting drama, you don't need multiple closers. In fact, if the answer is completely obvious, and even the people who are "losing" agree that the consensus is against them, then you don't need any uninvolved closers. WhatamIdoing (talk) 06:07, 28 February 2025 (UTC)[reply]
    we're at 11 supports, meaning my throwaway joke about waiting to close until there were 10 has been fulfilled. though i still disagree with how that's written, that's really the one worry i had about closing the discussion consarn (prison phone) (crime record) 10:52, 28 February 2025 (UTC)[reply]
  • I take issue with the fundamental position some people are taking, above, that BLAR is some sort of loophole around the AFD process. It's the AFD process that is unusual - our normal way of handling disputed additions is covered by WP:BRD, WP:ONUS and WP:BURDEN. That is to say that if someone creates a new article, and I immediately BLAR it, the default if there is no consensus ought to be that remains a redirect. They boldly added new material, I removed it, now they must demonstrate consensus for it before restoring it. AFD inverts this for complicated reasons that are hard to change; but the idea that even edits that don't require actual AFDs ought to be required to go through that simply to... cause that inversion is absurd. If anything, I would take the opposite tack and forbid BLAR disputes from being sent to AFD. It's a normal content dispute, and should be handled in the normal way - which includes, crucially, the presumption that if there's no consensus for a recently-created article, it must remain a redirect. It's the person who attempts to send it to AFD who is abusing process to force through new material without consensus in violation of WP:ONUS / WP:BURDEN, not the person who objected and redirected it. --Aquillion (talk) 12:25, 13 March 2025 (UTC)[reply]
    By your logic, as an admin, I should be able to unilaterally delete a new page per ONUS/BURDEN even if it meets none of the CSD criteria and then insist that the editor who created the article satisfy me that it should be undeleted. voorts (talk/contributions) 13:25, 13 March 2025 (UTC)[reply]
    Also, what evidence do you have that XFD favors keeping pages. It's been my experience that redirects are often retained at AfD on contested BLARs, but both of our experiences are anecdotal and this is a factual question. voorts (talk/contributions) 13:32, 13 March 2025 (UTC)[reply]
    admittedly, i think an editor who blars something should have the burden of explanation as well, and the policy could try to cram that in somewhere. granted, it's a burden they can fulfill in edit summaries, talk pages, or, and hear me out because this is something that has never ever been said before ever by anyone ever[citation needed], rfd, so it's not a hard criterion to fill if it's done in good faith. then again, if an edit war happens over it, i do think a page should be restored to its pre-war diff (which might even not be a redirect), but that's probably besides the point since other policies have that covered consarn (prison phone) (crime record) 13:39, 13 March 2025 (UTC)[reply]

RFC: Allow for bots (e.g. Citation bot) to remove redundant URLs known to not host a full freely-accessible version.

Should bots like Citation bot be allowed to remove redundant 'raw' PubMed URLs, and raw OCLC URLs when pmid/oclc identifiers are present. Headbomb {t · c · p · b} 09:25, 17 February 2025 (UTC)[reply]

Details

Following the last, extremely frustrating discussion about the behaviour of bots wrt to links, the consensus that 'emerged' from it was that Citation bot was to leave urls alone, unless it was replacing them with a free alternative (e.g. |url=https://paywall.com → |doi=10.1234/654321 + |doi-access=free or |url=https://paywall.com → |url=https://freetoread.com).

However, there are two corner case I would like to establish consensus for the removal of a link.

The reason is that those links will never contain free versions of articles, they will link to either the PubMed database, which only contain abstracts (free versions would be hosted at PubMed Central instead), or the OCLC database, which formerly held google book previews (then deemed useful), but no longer does.

This means that these urls make it look like a free version is accessible, when really none are, making readers click through links that lead them to nowhere useful. Note that this isn't a proposal to removal any URL covered by an identifier (e.g. |url=https://www.jstor.org/stable/123456 → |jstor=123456) that may or may not be free, only these two, known to never host free versions.

Headbomb {t · c · p · b} 09:25, 17 February 2025 (UTC)[reply]

Discussion

  • Number of articles with PubMed links: 7.6k
  • Number of articles with OCLC links: 32.6k
Nobody (talk) 09:39, 17 February 2025 (UTC)[reply]

!Vote

  • Support as proposer. These link are reader-hostile. They also discourage the addition of free links because it makes it look like there already are such links. Headbomb {t · c · p · b} 09:25, 17 February 2025 (UTC)[reply]
  • I have no particular assessment of PubMed, but I would oppose this for OCLC because a lot of citations to OCLC for articles on books aren't citing the work attached to the OCLC, but the bibliographic data in OCLC itself. Links to it when that is not the case should be removed, but the bot cannot tell those apart. PARAKANYAA (talk) 09:41, 17 February 2025 (UTC)[reply]
    Then that would be a {{cite web}} with an OCLC url, not a {{cite book}} with a url pointing to OCLC. The RFC concerns the latter, not the former. E.g., the bot would cleanup
    • Carlisle, Rodney P.; Golson, J. Geoffrey (2007). Manifest destiny and the expansion of America. Turning Points in History Series. Santa Barbara, Calif.: ABC-CLIO. p. 238. ISBN 978-1-85109-834-7. OCLC 659807062.
    to
    • Carlisle, Rodney P.; Golson, J. Geoffrey (2007). Manifest destiny and the expansion of America. Turning Points in History Series. Santa Barbara, Calif.: ABC-CLIO. p. 238. ISBN 978-1-85109-834-7. OCLC 659807062.
    Not
    to
    Headbomb {t · c · p · b} 10:46, 17 February 2025 (UTC)[reply]
    If it can distinguish between the two use cases then I have no opposition. PARAKANYAA (talk) 11:43, 17 February 2025 (UTC)[reply]
    What about the use of {{citation}} template in a similar fashion? Espresso Addict (talk) 23:12, 17 February 2025 (UTC)[reply]
    It's just as easy to detect a {{citation}} where |work=Worldcat (or equivalent) than a {{cite web}} with |work=Worldcat (or equivalent). Headbomb {t · c · p · b} 05:33, 18 February 2025 (UTC)[reply]
  • Assuming that Headbomb's description of the situation is accurate (it does fit with my knowledge of PubMed and OCLC, but my knowledge esp. of the latter is limited), I support this proposal. Toadspike [Talk] 13:31, 17 February 2025 (UTC)[reply]
  • Support per nom -- GreenC 19:35, 17 February 2025 (UTC)[reply]
  • Support per WP:SURPRISE. When we link to a title, readers expect to find the linked reference at the link. No information will be lost because the discussed cases always involve an id containing the same link. —David Eppstein (talk) 19:46, 17 February 2025 (UTC)[reply]
  • Support utterly reasonable. Regards, --Goldsztajn (talk) 03:33, 18 February 2025 (UTC)[reply]
  • Support makes sense and the link is still present at the end of the citation. Rjjiii (talk) 05:28, 18 February 2025 (UTC)[reply]
  • Support title-links give the false impression to readers. AManWithNoPlan (talk) 15:08, 18 February 2025 (UTC)[reply]
  • I think this Double-barreled question needs separate answers. If I'm looking at a citation for a book and have a choice between:
  • then I don't want the version whose link on the title takes me to https://search.worldcat.org/title/1079344976 But if I'm instead looking at a citation for a WP:PAYWALLED article, and I have a choice between:
  • then I'd actually prefer having a link on the title take me to the abstract on PubMed (or at least not object to it). Those of us who are familiar with the literature and our citation conventions know that this is a "duplicate" or "redundant" link, but ordinary people don't know what all those acronyms mean. They expect that clicking the link on the title will take them to some useful place, so it should do that. WhatamIdoing (talk) 21:10, 19 February 2025 (UTC)[reply]

URLs with utm_source=chatgpt.com codes

Hi, certain articles replicate sources recommended by ChatGPT, which may not always be entirely accurate. I think Introducing a new policy could effectively address this issue. Regards Riad Salih (talk) 19:52, 1 March 2025 (UTC)[reply]

Why do we need a new policy for this? If source A simply republishes or quotes source B, one we determine the reliability based on how reliable source B is. If a source is simply replicating ChatGPT then the replication is exactly as reliable as ChatGPT (which is of wildly inconsistent accuracy, ranging from completely correct in all regards to the exact opposite and everything in between). Replicating an unreliable AI chat bot is no different to replicating an unreliable human source. If what you are talking about is not using ChatGPT as a source but using a third party source suggested by ChatGPT, then ChatGPT is completely irrelevant to the reliability of the source: ChatGPT recommends both sources of the highest reliability and sources that are utter garbage (as well as sources that don't exist). All sources suggested by ChatGPT should be checked for reliability and relevance, but then all sources added to articles should be checked for reliability and relevance. Thryduulf (talk) 20:07, 1 March 2025 (UTC)[reply]
You have been quite busy doing your best to try and keep Wikipedia from having any kind of policy on generati AI, haven't you? If there's a thread on this, you're there defending generative AI. The reality is that many of us are now dealing with the ramifications of machine-generated text, which is almost always just outright garbage trained on who-knows-what, from editors and we clearly need policies on it. We didn't sign up to sort through someone's prompt-generated misinformation and it is a total waste of every editor's time here to even engage with machine-generated text. :bloodofox: (talk)
I'm not defending generative AI, I'm defending Wikipedia from short-sighted policies that are unnecessarily redundant to existing policies and/or will do more harm than good. If text is garbage it's garbage regardless of the source, if it isn't garbage then it isn't garbage regardless of the source. Thryduulf (talk) 21:59, 1 March 2025 (UTC)[reply]
Are there any specific instances of disruption through AI that aren't already covered by existing P&G? Thebiguglyalien (talk) 🛸 05:03, 2 March 2025 (UTC)[reply]
The simple answer: The ease of use of this new technology needs new policies to deter its use to disrupt the site and waste the time of human editors. The site is being flooded by machine-generated text which has only recently been a possibility for anyone to produce with ease and Wikipedia editors are now having to deal with it on a daily basis. No doubt we even have new users who don't even realize it's a problem. Making the issue and its ramifications crystal clear would help. :bloodofox: (talk) 23:19, 2 March 2025 (UTC)[reply]
Making the issue and its ramifications crystal clear would help yet in all the discussions nobody has yet managed to make it clear why existing policies and guidelines are unable to deal with the problems. Lots of people have tried and everybody has failed. Thryduulf (talk) 23:30, 2 March 2025 (UTC)[reply]
While I'm sure tech companies like OpenAI appreciate your constant and full-throated defense of all things generative AI on Wikipedia whenever the matter arises, those of us who have to clean up after it don't appreciate it. As anyone even vaguely familiar with the topic knows, machine-generated text takes seconds to produce and a tremendous amount of time to attempt to correct by we human editors. We have no meaningful policies on machine generated text at the moment and anyone watching this page knows it is in part due to your 24/7 attempts at defending the status quo of 'we shouldn't do anything about generative AI on the site' and obfuscating change in the matter. :bloodofox: (talk) 00:14, 3 March 2025 (UTC)[reply]
As I have explained to you and others in pretty much every discussion we shouldn't do anything about generative AI on the site' is not my position and I really would appreciate it if you would stop repeating the falsehood that it is. My position is that whether text is AI-generated or not is completely irrelevant to and a distraction from the actual problems. If the AI-generated text is a copyvio then the problem is that the text is a copyright violation not that it is AI-generated, and we have existing policies for how to deal with copyright violations that apply regardless of whether the text is AI-generated or human-generated. The exact same is true for every other actual problem anybody has listed. Thryduulf (talk) 02:11, 3 March 2025 (UTC)[reply]
I'm not buying it. Everything you've said on these threads has been nothing more than a complete and total defense of the use of machine-generated text on the site, a total defense of the matter with zero criticism and absolutely no concern about associated problems. The makers of these companies couldn't have been more full-throated about it than yourself. Let's not play pretend here. :bloodofox: (talk) 02:50, 3 March 2025 (UTC)[reply]
Either you are not reading what I'm saying, you're not listening to what I am saying, you are so blinding by your point of view that you are ignoring what I am saying, or you have some ulterior motive (although this last seems the least likely the evidence doesn't allow me to rule it out). Regardless of which it is there is clearly nothing I can say that will convince you that when I say "X" I actually do mean "X" and not "Y", ao engaging with you is clearly a waste of everybody's time. Thryduulf (talk) 03:03, 3 March 2025 (UTC)[reply]
As a debate, you win because anyone can post anything and its source is not relevant. However, that pollyanna approach assumes there is an infinite supply of good editors who are able and willing to spend hours investigating and correcting AI text that was generated and added in a minute. That may be correct at the moment, but the trend of recent months shows that the supply will outpace human editors very soon. A rational discussion of AI in Wikipedia needs to account for the fact that it will drive away good editors. Johnuniq (talk) 04:07, 3 March 2025 (UTC)[reply]
A rational discussion of AI on Wikipedia needs to confine itself to sober discussion of facts and not hyperbolic FUD. If you want to solve a problem, on Wikipedia or elsewhere, you need to identify the actual problem and implement solutions that address that rather than introducing more problems by focusing on irrelevances. AI-generated text can be both good and bad, bad text can be bother AI-generated or human-generated. The problem is that bad text is bad, not that AI-generated text is AI-generated. What we need is solutions for dealing with bad text regardless of the source. Thryduulf (talk) 04:20, 3 March 2025 (UTC)[reply]
And now we have this editor referring to anyone who objects to cleaning up masses of AI slop on Wikipedia as 'buying into manipulative anti-AI propaganda'. See Fear, uncertainty, and doubt. For those of you haven't encountered it yet, today you're likely to encounter it in pro-AI and "effective accelerationism" circles where true believers dismiss those who for example 'stand in the way of' "the Singularity" and/or on Tech company blogs and posts like this one from Microsoft encouraging mass embrace of generative AI. :bloodofox: (talk) 04:52, 3 March 2025 (UTC)[reply]
Denialism occurs when trillions of dollars are bet on a technology with adverse consequences. Similar with global warming denial, the most frequently used logical fallacy is the reduction fallacy (which is the argument that because climate has changed naturally in the past, current climate change must also be entirely natural). The same argument presented here (because current policy works for human editors, it also works for bot produced text). AI text is not equivalent to human generated text, it is different enough to create problems. This is very obvious, but then, not everyone has tackled an AI written article. Yet. -- GreenC 06:55, 3 March 2025 (UTC)[reply]
If text is garbage it's garbage regardless of the source That is not true. Equating problems with AI text as equivalent to human generated text is seriously misguided. -- GreenC 23:28, 2 March 2025 (UTC)[reply]
I really need a citation on that. How is AI-generated text so categorically different to human generated text that existing policies can't deal with the issues? How does AI-generated text-soup differ from human-generated text soup that means we need a policy for AI-generated text-soup that is different to our policy for all text-soup? Thryduulf (talk) 23:32, 2 March 2025 (UTC)[reply]
Just off the top of my head, potential answers to this question that I have seen offered in previous discussions include:
  • the ease with which AI slop can be created versus the effort required to vet and assess it.
  • the tendency of AI text to be very good at mimicking the style of high-quality text (so the normal patterns that provide a cue to low-quality human contributions are harder to spot).
  • the difficulty in assigning responsibility and assessing intent with AI-text.
  • the actual current outcomes of AI use (which some have argued are poor).
  • the argument that Wikipedia's benefit to society lies in its human qualities, and that pasting ChatGPT content into the Wiki doesn't provide a benefit to readers who could have just queried ChatGPT directly if that is what they wanted.
  • The concern that because Wikipedia is used as a major source of training data for LLMs, the inclusion of LLM-generated content in Wikipedia creates a potentially-pathological loop situation.
I understand that these aren't convincing reasons for you, and I respect your position (I'm somewhat in the middle ground on this issue myself), but let's not pretend that the people opposed to AI use haven't voiced coherent concerns. -- LWG talk 23:46, 2 March 2025 (UTC)[reply]
Everything listed by LWG is correct. Until you encounter one of these animals, and spent days trying to untangle, you probably won't understand. It's not at all like working with human created text. -- GreenC 04:47, 3 March 2025 (UTC)[reply]
The gist is that it falls in a different place with regard to good faith. AI hallucinations often aren't like human errors and aren't the kind of thing that humans would make up in good faith.
For instance, someone might make a typo and write that the dotcom bust in March 2020 put Pets.com out of business, rather than March 2000. But there's not really a plausible way that a well-meaning human would write a detailed paragraph analyzing how the COVID-19 pandemic, which happened in March 2020, resulted in Pets.com going out of business, unless that person was deliberately creating a hoax. But a well-meaning human might use ChatGPT and have that output be generated and be none the wiser. Or with regard to ChatGPT-generated URLs, LLMs often just make up an article title or URL that doesn't exist, which is not something a human is going to do in good faith. All this affects how the edit should be treated -- someone creating a hoax is vandalizing the encyclopedia and knows it, someone producing a comparable AI hallucination is likely just misguided.
I still think an edit filter is better than a policy, to just stop this stuff at the root, though. Gnomingstuff (talk) 20:01, 4 March 2025 (UTC)[reply]
I don't understand how any of that is any indication of the faith that the person prompting the LLM is acting in? Someone using an LLM to create a hoax is acting in bad faith by creating a hoax, not by using an LLM. Someone posting LLM content that they believe improves an article is acting in good faith, even if the content is riddled with errors. Someone posting LLM content with the goal of introducing misinformation is acting in bad faith, even if the content doesn't contain errors. Thryduulf (talk) 20:14, 4 March 2025 (UTC)[reply]
Right, exactly, that's my point. If someone posts a made-up article title and URL there are basically only two ways that can happen:
1) They're deliberately inserting a fake citation
2) They're using a LLM that hallucinated a fake citation
Both of these result in the same fake citation getting added to an article, but editor #1 is obviously not acting in good faith, while editor #2 likely is. Moreover, editor #1 knew what they were doing, while editor #2 probably didn't. So while the fake citation should be still removed either way, editor #2 probably shouldn't face the same consequences that editor #1 would. This is technically covered under WP:VANDALISM already but I don't think it's a bad idea to add a specific note about LLM-generated misinformation there. (or, better yet, just filter them out) Gnomingstuff (talk) 03:45, 5 March 2025 (UTC)[reply]
Yes, absolutely. Wikipedia is now plagued with machine-generated text that the few human editors here have to contend with. Recently I have had to deal with two of such instances full of misinformation and other nonsense. Without action this problem is only going to spread and get worse. We need policies on this yesterday: we're well on our way to becoming overwhelmed by AI slop that takes two seconds to produce and much longer to correct in every nook and cranny of the site. :bloodofox: (talk) 20:17, 1 March 2025 (UTC)[reply]
User:Bloodofox: Yup. It's a huge waste of time, just dealing with one short AI generated article has taken days of research to untangle, only to conclude the entire thing should be redirected and summarized into a single paragraph. AI makes much out of nothing .. then gets it wrong anyway! -- GreenC 23:17, 2 March 2025 (UTC)[reply]
Any sources may not be entirely accurate. While people should definitely not rely on ChatGPTs description of the source, it may be a worthwhile tool for finding sources with reliable and usable content... much as Wikipedia itself is not a reliable source, but one of its great uses is finding the sources it uses on a given topic, which themselves may be reliable. So if the policy change you're suggesting is that you can't use sources suggested by ChatGPT, I don't see it... but if it's some sort of policy that you cannot use a source until you actually verify what the source says, that's at the very least a good guideline no matter where you find the source. -- Nat Gertler (talk) 20:23, 1 March 2025 (UTC)[reply]
Are these fake sources? Sources that are real but don’t support the content? Or what?
Blueboar (talk) 20:28, 1 March 2025 (UTC)[reply]
I did check just two of these, and in one of them I found real problems. In this paragraph claiming controversy about a living subject, there were two sources -- one which was a tweet from the subject (which did not thus show "controversy", although it was certainly a statement that could have generated such), and one which covered a controversy without mentioning the subject. Plus, it had the biggest Wikipedia sin of all: curly quotes. So that definitely looks like ChatGPT generating things that are not up to our standards, but also something that could have been caught if a good faith editor generating such material had checked the sources and understood BLP sourcing requirements. -- Nat Gertler (talk) 01:47, 2 March 2025 (UTC)[reply]
Editors have the responsibility of using citations to sources that they read to craft the text they wrote. They also are responsible to evaluate the reliability of sources and their suitability for the content being added. What additional guidance are you proposing? isaacl (talk) 22:47, 1 March 2025 (UTC)[reply]
There is a proposed edit filter to track these additions. Of course, the filter is not going to capture all uses of llms, just the ones where the llm helpfully appends a tag to the url and where the editor does not delete those tags. Last time I checked some they were riddled with problems, but you can revert them under current policies. CMD (talk) 03:18, 2 March 2025 (UTC)[reply]
Sounds like a good way to catch an editor's LLM use early before they rack up thousands of edits adding AI text. That's the sort of thing we should be focusing on. Thebiguglyalien (talk) 🛸 05:05, 2 March 2025 (UTC)[reply]
To make sure I understand this properly: this thread seems to be about links added in refs where the link's UTM source parameter is ChatGPT. Apparently ChatGPT adds that now when it references a URL in output.
I think an edit filter in articlespace is the best solution here, it's a great, unambiguous smoking gun for AI-generated text. Gnomingstuff (talk) 08:15, 2 March 2025 (UTC)[reply]
To test how unambiguous, there is a trial filter at Special:AbuseFilter/1346. CMD (talk) 13:02, 2 March 2025 (UTC)[reply]
I don't see a need for a new policy here when the problem is just one of countless possible ways to violate current policies with inappropriate sourcing. But there's little doubt that one of the things chatgpt is worst at is identifying sources (it would be bad for business to too easily connect specific sources with its output). Since the only way we'd be able to identify these sources to enforce this hypothetical policy is if they carried through the referral in the url, this is a case for an edit filter, not a new policy. I've talked to many people who mistakenly think that because chatgpt is decent at summarizing sources you feed it, it must be helpful with a literature review -- they're not fiends trying to ruin Wikipedia but people trying to improve an article using a popular new tool. This is a case for an edit filter, not a new policy. If someone adds a source with that chatgpt referral (and presumably other tools have something similar), we should explain to them that chatgpt stinks at connecting information with sources and flag the edit for others to look at. — Rhododendrites talk \\ 15:12, 2 March 2025 (UTC)[reply]
With the caveat that a LinkedIn post is not a reliable source and I don't trust this guy at all, apparently other tools do. Gnomingstuff (talk) 19:21, 2 March 2025 (UTC)[reply]
[Tangent] What I really want right now is a list of links to prior discussions about AI rules. I'm imagining a transcludable list, so every time someone posts yet another idea for yet another rule, we can ask them to read the previous discussions and give them a link to WP:Nobody reads the directions. WhatamIdoing (talk) 21:17, 2 March 2025 (UTC)[reply]
A partial list of AI-related discussions is at Wikipedia:Artificial intelligence#Discussion timeline. WhatamIdoing (talk) 17:41, 4 March 2025 (UTC)[reply]
Thanks. I was wondering the same thing, a central place to track the discussions. Now, we need AI to summarize each discussion for salient points. It would have to be in userspace, but its nature. Then a meta-analysis. This is IMO a good application of AI, which is essentially statistics based summation. -- GreenC 18:38, 4 March 2025 (UTC)[reply]
Wikimedia Global Search shows a total of 2716 articles with this URL parameter. Riad Salih (talk) 22:40, 2 March 2025 (UTC)[reply]
Editors need to verify the sources themselves, as they are ultimately responsible for the edits they make. But as long as they have done so there's no issue with using sources that an LLM suggests. Editors just adding text and sources created by LLMs without checking are already covered by guidance on disruptive editing. -- LCU ActivelyDisinterested «@» °∆t° 22:04, 7 March 2025 (UTC)[reply]
It's also worth noting that the presence of the url parameter is not an indication that the sources have or have not been checked. Even someone who knows about the existence of the parameter (which is likely to be a minority of people using LLMs in this manner) is unlikely to specifically remove it - if the source is OK they're most likely to just leave it as is, if it isn't they'll remove the whole thing. Thryduulf (talk) 22:45, 7 March 2025 (UTC)[reply]
In cases where the source is good we probably should be removing the utm_source parameter since otherwise we are causing any clickthroughs of Wiki references to appear on site analytics as ChatGPT referrals. -- LWG talk 02:22, 11 March 2025 (UTC)[reply]
I wasn't saying we shouldn't remove them if they are added, just that them being added is not an indication that the source is good or bad or that the URL has or has not been checked. Thryduulf (talk) 03:55, 11 March 2025 (UTC)[reply]

Where is this Wiki policy?

I remember reading a resonating policy page/section/essay whose thesis was don't exhaust people by pretending like your argument has gone unaddressed and repeating it over and over, and it had a picture of a head with hands over its ears. I can't seem to find it on w:Wikipedia:Etiquette or w:Wikipedia:Vandalism#Types_of_vandalism Lumbering in thought (talk) 16:20, 2 March 2025 (UTC)[reply]

WP:IDIDNTHEARTHAT maybe? Anomie⚔ 16:28, 2 March 2025 (UTC)[reply]
That's the one. Lumbering in thought (talk) 17:03, 2 March 2025 (UTC)[reply]
Perhaps you're thinking of Wikipedia:Drop the stick and back slowly away from the horse carcass. -- Nat Gertler (talk) 16:32, 2 March 2025 (UTC)[reply]
I may have read that essay, but I for sure read in the See Also there, Wikipedia:It's_not_the_end_of_the_world, Wikipedia:Let_it_go and Wikipedia:Wikipedia_is_not_about_winning (almost perfectly relevant) for what it's worth. Also sorry you replied before viewing my minor edit. Lumbering in thought (talk) 17:11, 2 March 2025 (UTC)[reply]
There's also WP:SATISFY which is part of WP:BLUDGEON. -- LCU ActivelyDisinterested «@» °∆t° 22:09, 7 March 2025 (UTC)[reply]

Rate-limiting new PRODs and AfDs?

Hi, I was recommended to post this at the village pump by a a comment here.

There has been a recent issue where dozens of PRODs and AfDs (about 80 of them last month) of pre-Internet-era track and field Olympians were all created in a short timespan. For comparison, the usual rate that these get created is one or two per week. The rate is of particular importance here because unlike most processes on Wikipedia, there is a one-week deadline for most PRODs and AfDs, so when many are created all at once it can be difficult to properly address them in time.

While it's true that some of these articles were created by User:Lugnuts without SIGCOV references, it's also true that significant coverage exists for most of them -- to quote User:WhatamIdoing at the above linked thread, At some level, we all know that there is local coverage on every modern Olympic athlete, because (a) local newspapers always run the 'local kid does well internationally' kinds of stories, because articles that combine national pride, local people, and good news sell well, and (b) every time someone has actually done the work of getting access to paper copies, they've found these sources.

A similar situation happened about four months ago, and the solution was just to procedurally revert all of the PRODs: User_talk:Seefooddiet/Archive_1#109 proposed deletions in a couple of hours?

Because finding pre-Internet newspaper sources for non-English speaking countries can be labor intensive, is there a policy solution to the above problem? --Habst (talk) 20:45, 2 March 2025 (UTC)[reply]

I don't think this is something we can solve with more rules.
Making 109 PRODs in one hour is just silly, and there's no amount of regulation that will stop people from doing silly things. I do understand this kind of rate is frustrating, but I think creating and enforcing rules about the rate of nominations will create unforseen problems. You can't stop people from being silly, but you can trout them after the fact. Cremastra (talk) 21:56, 2 March 2025 (UTC)[reply]
You can also WP:TBAN them after the fact. WhatamIdoing (talk) 22:30, 2 March 2025 (UTC)[reply]
109 PRODs in one hour sounds like a WP:MEATBOT issue. There is no way you can evaluate that many articles in that amount of time, so the first step would be to deprod with the summary that no WP:BEFORE was done and the article needs a full evaluation. Thryduulf (talk) 23:36, 2 March 2025 (UTC)[reply]
Note it's possible, if unlikely, that the tagger spent significant time researching the 109 articles individually before tagging them all at once. A single rapid tagging session does not by itself indicate WP:MEATBOT. Anomie⚔ 13:23, 3 March 2025 (UTC)[reply]
For small groups of closely related articles that is possible, but it's not at all plausible that you'd research that many before nominating them - you'd tag them as you go. Especially if you are not doing a group nomination. Thryduulf (talk) 14:34, 3 March 2025 (UTC)[reply]
This is mostly something that can be dealt with informally through current P&G (disruptive editing applies to all sorts of things). For larger deletion projects, it would be preferable to either bundle them or start a community discussion, depending on the nature of the articles. With that said, note that per WP:NSPORTS2022 Proposal 5 there's already consensus to delete any sports bios that do not currently have significant coverage in the article, overriding WP:NEXIST and WP:BEFORE. These deletions aren't indefinite, they're just until someone gets around to finding significant coverage. I'd also ask about whether local coverage is "significant" as opposed to routine; if all athletes have local coverage regardless of notability, it's unlikely to be significant. Thebiguglyalien (talk) 🛸 00:23, 3 March 2025 (UTC)[reply]
I have a relevant discussion open at WT:NOT about the definition of 'routine'. We're just getting started, so things may change, but from early comments, it appears that 'routine' is frequently understood to have no particular relationship to 'significant coverage'. SIGCOV is how many (encyclopedically useful) words/facts were written. 'Routine' is that if every ____ automatically gets (e.g.,) one article printed about it the next morning, then that is the routine. ("____" is a relevant large category, like "film" or "sports game" or "election", not a small category like "films starring Joe Film" or "FIFA World Cup finals").
With these two models, it is possible for routine coverage to provide SIGCOV. And if you agree or disagree with that, then I invite you to join that discussion and tell us so. WhatamIdoing (talk) 00:39, 3 March 2025 (UTC)[reply]
This sort of thing in general is a matter of good old common sense, no ammount of policy will help here. If you need one, WP:BULLINACHINASHOP would be it. Headbomb {t · c · p · b} 20:37, 3 March 2025 (UTC)[reply]
  • Absolutely not, not unless a similar rate limit is applied to article creation. At the moment an editor can mass-create a ton of articles very rapidly; to avoid a WP:FAIT situation, it is obviously necessary for another editor to be able to challenge those articles equally-rapidly. Regarding the evaluation of articles, above - often when people do this, it's in response to discovering such a mass-creation. In that case all the articles can reasonably contain the same crucial flaw that means they shouldn't have been created; I continue to assert that WP:BEFORE is advisory and optional (otherwise it would invert WP:BURDEN, which obviously places the burden to search for sources on the people who add or wish to retain material - you can't add something and then insist other people do that search before deleting it.) But even for people who try to insist that it is mandatory, it only requires "reasonable" searches, and when dealing with mass-created articles it is reasonable to simply evaluate the method they were created by and therefore examine them all at once before mass-prodding or mass-AFDing them. Obviously such mass actions are meant to be taken cautiously but we can't forbid them here, since they're sometimes clearly necessary. --Aquillion (talk) 12:36, 13 March 2025 (UTC)[reply]

The current WikiProject infrastructure was set up around 2006 with the Wikipedia:WikiProject Council and its Wikipedia:WikiProject Council/Guide. This system defines a WikiProject as "a group of people" and "a social construct" as opposed to a resource for the community. Per Wikipedia:WikiProject Council/Proposals: A WikiProject is a group of editors who want to work together. A WikiProject is not a subject area, a group of pages, a banner on talk pages, or any of the infrastructure used to support the group. I don't believe this lines up with how they're currently used or how the community sees them.

Wikipedia:WikiProject Council/Guide has guideline status but is relatively obscure and reflects how Wikipedia worked in its early days. Note that it also has additional guideline-style subpages at Guide/WikiProject, Guide/Task forces, and Guide/Merging WikiProjects, as well as a Proposals subpage. Given how much Wikipedia has changed in the 15–20 years since this system was established, and the growing opposition to insular groups on Wikipedia since then, I'm asking the community whether everything regarding the WikiProject Council and its guidelines still has sitewide consensus. Thebiguglyalien (talk) 🛸 04:14, 5 March 2025 (UTC)[reply]

TBUA, it's customary to discuss changes to a guideline at the talk page for that guideline. You already started a discussion there. Why did you create this WP:TALKFORK? WhatamIdoing (talk) 04:21, 5 March 2025 (UTC)[reply]
That's not a guideline talk page, that's a WikiProject talk page, and the fact that you want to constrain it there instead of get community feedback kind of proves my point. Especially since you've been the editor enforcing the current system more than anyone else. Thebiguglyalien (talk) 🛸 04:25, 5 March 2025 (UTC)[reply]
It's both, because Wikipedia talk:WikiProject Council/Guide redirects there. There are thousands of centralized talk pages on wiki, and this is one of them. WhatamIdoing (talk) 05:55, 5 March 2025 (UTC)[reply]
On the subject of WikiProject resources, I have raised a couple of times, including as a response to a request by the WMF for collaboration ideas, that the WMF explore the separation of the tools that rely on WikiProjects from the rigid WikiProject system. It would be great if others do the same, if they also feel that the use of WikiProjects has diverged from their original design. CMD (talk) 04:35, 5 March 2025 (UTC)[reply]
How else would we define these projects? Moxy🍁 04:46, 5 March 2025 (UTC)[reply]
My hope is not to redefine WikiProjects, but to have ways to use tools such as WP:Article alerts without requiring they be linked to a dead noticeboard. CMD (talk) 04:49, 5 March 2025 (UTC)[reply]
@Chipmunkdavis, I've not spent much time with the Wikipedia:Article alerts system, but I don't believe it actually requires a WikiProject. You can set up an alert page several different ways. I believe it would be possible, for example, to set up an alert based on Category:Featured articles or {{infobox book}} (giving you notifications about all actions affecting FAs or all actions affecting articles containing that infobox, respectively). It's possible that its |maincategory= would even let you get alerts to articles within a chosen content category like Category:Italian artists. WhatamIdoing (talk) 06:04, 5 March 2025 (UTC)[reply]
Yes there are a few options, but there is a limit to the flexibility. CMD (talk) 06:59, 5 March 2025 (UTC)[reply]
I do think the community views a WikiProject as a group of editors collaborating on a shared area of interest, without any special powers beyond those of any group of collaborating Wikipedia editors. I think the statements at Wikipedia:WikiProject Council/Guide § What is a WikiProject? continue to be an appropriate description of the roles currently filled by active WikiProjects. isaacl (talk) 05:52, 5 March 2025 (UTC)[reply]

I'm mostly active in one project (organised labour) and drop in and out of a number of others, but I'm really not clear what is the problem being called to attention here? If it is about the tools projects use, no problem, wish we could develop more, but I think generalising in toto about projects rather than pointing to specific projects with problems seems to be throwing the proverbial baby out with the bathwater. Regards, --Goldsztajn (talk) 10:37, 5 March 2025 (UTC)[reply]

I'm not opposed to evolving the WikiProject system but the statement, the current [X] infrastructure was set up around 2006 could apply to pretty much any process X. It's not in itself a reason to overhaul things – when a guideline remains unchanged for many years, we usually take that as a sign of more consensus, not less. – Joe (talk) 11:40, 5 March 2025 (UTC)[reply]
That guidance lines up pretty well with how I see the role of Wikiprojects. In what way do you believe that it does not line up with how they're currently used or how the community sees them? Phil Bridger (talk) 13:45, 5 March 2025 (UTC)[reply]

MOS/Images § Video content

Inviting people to join the discussion at WP:VPI § Adding video content to articles re: the possible inadequacy of existing policy on videos, which seems limited to MOS/Images § Video content. FactOrOpinion (talk) 21:03, 5 March 2025 (UTC)[reply]

Recent deaths.

Recent deaths often omits celebrities who have recently reported died even those who have a Wikipedia page. How recently is recent? 2A0C:4F41:1C13:6800:10A1:649C:E601:63CD (talk) 16:51, 6 March 2025 (UTC)[reply]

  • Recent deaths are nominated at WP:ITNC where they are reviewed for quality purposes, and if they don't reach sufficient quality in 7 days, the nomination fails. Most celebrities (particularly actors and musicans) do not have quality articles due to unsourced filmography or discography tables, nor get improved, so many of these are not posted. — Masem (t) 17:12, 6 March 2025 (UTC)[reply]
  • It also sometimes happens that people are not nominated, although this is uncommon with people likely to be described as a celebrity. Unsourced or partially sourced filmographies and discographies is by the most common reason but the whole article needs to be fully cited and free of orange maintenance tags and other significant issues. By far the best thing to do if there is someone you really think should be featured is to make sure their article is of good quality - and you don't need to wait until they die to start doing this.— Preceding unsigned comment added by Thryduulf (talk • contribs) 17:53, 6 March 2025 (UTC)[reply]
  • Remember that this is an encyclopedia, not a news site. The idea of this section is to show what encyclopedic content we have about the person who has died, not to report that fact. Phil Bridger (talk) 18:22, 6 March 2025 (UTC)[reply]
Moved to Wikipedia:External_links/Noticeboard#Template:Finance_links Polygnotus (talk) 06:35, 7 March 2025 (UTC)[reply]

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

Template:Finance links is used for large-scale violations of WP:EXLINK, specifically WP:ELMIN and WP:ELNO#13. This is an encyclopedia, we shouldn't end each article about a company with a list of links for finance bros. Can we delete the template and make the guideline clearer that this is not desirable? It has been used 1778 times. Polygnotus (talk) 02:26, 7 March 2025 (UTC)[reply]

Stock tickers are relevant information for a business to help readers to look them up further. Masem (t) 03:31, 7 March 2025 (UTC)[reply]
Yeah, but this is an encyclopedia and we are not in the business of helping readers look them up further. We are not Google and we are not DMOZ or Curlie. Polygnotus (talk) 03:39, 7 March 2025 (UTC)[reply]

This example is from Ferrari#External links:

  • Business data for Ferrari:

Articles should not normally have a such a spray of external links. It might be worth asking for opinions at WP:ELN. Johnuniq (talk) 05:55, 7 March 2025 (UTC)[reply]

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

Testing the waters: Overturning USPLACE

Yes, I know this is at perennial proposals, which is why I'm not jumping straight ahead to an RFC, but WP:USPLACE, the guideline that determines the titles of settlements in the United States, is fundamentally at loggerheads with the five criteria:

  • Recognizability: Large cities that are not usually associated with their state may astonish readers who see the page name connected to the state (for instance, when I hear Louisville, I don't think of it being in Kentucky). Yes, this is a double-edged sword, as people with no knowledge of the city might not know of it, but this can easily be solved with textual disambiguation. For instance, 2022 Ürümqi fire says in its lead sentence: On 24 November 2022, a fire broke out... in Ürümqi, Xinjiang, China, because the average reader will not recognize Ürümqi as being in Xinjiang or China, yet no disambiguation is present in the Ürümqi article. We could easily use this in the lead sentences of articles concerning these cities. Also, the short descriptions and previews of the articles with USPLACE disambiguation, which include the state, are redundant to the disambiguation in the title.
  • Naturalness: Readers are likely to search Louisville instead of Louisville, Kentucky just because of typing efficiency, and in articles, the short form is usually linked to (example: in Louisville Muhammad Ali International Airport). This satisfies both subcriteria in the Naturalness section.
  • Precision: In cases where there is a primary redirect, such redirect is unambiguous if a hatnote is added, as is present on Boston, Cleveland, and most of the other 26 undisambiguated city articles. If the title was ambiguous in any way, there would be no primary redirect.
  • Concision: Raleigh, North Carolina is almost three times longer than just plain old Raleigh, which redirects there already, so moving the much longer name to the shorter name breaks nothing and makes Wikipedia more efficient.
  • Consistency: Another double-edged sword. The argument for consistency is clear: not a single other country uses USPLACE. Yes, consistency has been used by supporters of USPLACE to argue that it goes against consistency to have some articles using commas while others don't. However, we don't worry about that in any other country: we have Valence, Drôme but Biarritz not Biarritz, Pyrénées-Atlantiques. There's no reason we need to treat the US different from literally every other country.

The argument is that appending the state is part of American English. That is not even remotely true. No source describes American English as such (see American English, which does not mention the comma convention at all) and other articles that use American English, such as Agua Prieta, whose article uses American English and with the town just across the border, even so, the article is not titled Agua Prieta, Sonora, which would be the title if the comma convention were part of American English. Yes, the AP Stylebook recommends the comma convention. But if we followed the AP stylebook, then we'd be ending quotes with ." instead of "., our article on the Salem witch trials would have to be moved to Salem Witch Trials, and our article on Gulf of Mexico would have to be moved to Gulf of Mexico/Gulf of America. Simply put, USPLACE violates our guidelines on article titles.

Furthermore, many editors oppose USPLACE, as can be shown by the three RMs opened in the last month, all of which unfortunately failed, on removing the state name from Brownsville, Lubbock, and Redmond. Even some of the oppose !votes in those RMs and others expressed dissatisfaction with USPLACE, with one editor calling it peculiar and another saying they were personally opposed to it. Consensus can change, especially when consensus is determined to be in conflict with policy. Thank you for considering my request.

—🐔 Chicdat  Bawk to me! 19:11, 7 March 2025 (UTC)[reply]

I can't see what the arguement is. We gave naming conventions for most of the world. In the case of Brownsville there us clearly two places on wikipedia with that name, so we need to distinquish them and the US has a lot of places with the same name. If we didn't have these conventions, based upon some of the arguments raised, Boston, Lincolnshire should be just plain Boston as it is the original - which is just silly. Davidstewartharvey (talk) 19:48, 7 March 2025 (UTC)[reply]
Yes, but that's true of lots of topics. Having the larger area name is something we do for disambiguation, and like anything that we disambiguate, there can be a primary name. We even do that geographically; we have an article on Paris and don't feel the need to specify it's the one in France and not Paris, Texas. -- Nat Gertler (talk) 19:57, 7 March 2025 (UTC)[reply]
But we should not have "Primary pages", as how can we determine what is primary? Boston, Lincolnshire or Boston, Massachusetts, or the 16 places in the US or the 34 other places around the world? Paris should be Paris, France. Even Britannica has it as Paris (national capital, France) so we are following normal conventions. Davidstewartharvey (talk) 20:17, 7 March 2025 (UTC)[reply]
Interesting viewpoint, however, it is not the consensus of Wikipedians, who believe that it is much more convenient to have a primary topic, with such a high consensus that it became one of our policies and guidelines. Feel free to open an RM at Paris asking to have it moved to Paris, France, however, in accordance with the primary topic guideline, it will likely fail. 🐔 Chicdat  Bawk to me! 20:22, 7 March 2025 (UTC)[reply]
Concensus? In Bios it isn't. Take John Smith, there is no primary article. What is the primary article is conjecture, which leads to edit wars. Clearly making something clear and simple is easy, and falls in line with what Encyclopedias have done for years. Davidstewartharvey (talk) 20:28, 7 March 2025 (UTC)[reply]
Not everything has a primary topic. John Smith is such a vague, common name, that of course there isn't one. But Boston, Mass., not Boston, Lincolnshire, is clearly the primary topic and thus does not need a disambiguator. voorts (talk/contributions) 22:30, 7 March 2025 (UTC)[reply]
So how is Boston MA the primary? The tea party may have taken place their, but that is a page on its own? Boston, Lincolnshire has a history of over 1000 years, while Boston MA is named after the UK town by settlers from their? I would say neither are primary, as they are amongst how over 40 world wide. Davidstewartharvey (talk) 02:05, 8 March 2025 (UTC)[reply]
We do it all the time in bios, when there's a clear "primary" topic -- i.e., the one that most of the people entering the name are looking for. Consider, say, Robin Williams, which takes you right to the comedian, even though Robin Williams (disambiguation) shows you eleven other Robins Williams. Over 13,000 page views a day for the comedian's page, and less than a quarter of one percent of those end up on the disambiguation page looking for the other Robin Williams they were looking for. See WP:DETERMINEPRIMARY for how we judge this. -- Nat Gertler (talk) 05:58, 8 March 2025 (UTC)[reply]
I'm not going to go into why Boston is the primary topic, but you can read WP:DETERMINEPRIMARY and then do the analyses between the former and the latter. In any event, Boston isn't a great example since we have an exception for major US cities that don't require disambiguation. voorts (talk/contributions) 02:26, 8 March 2025 (UTC)[reply]

You might want to first look at all the archived discussions and proposals listed near the top of Wikipedia talk:Naming conventions (geographic names). I count almost 30 dating back to May 2004 discussion, with the last one in February 2023. Even getting the AP Stylebook exception for the 28 or so for the larger cities seemed to be a hassle. I think it had gotten to the point in that last discussion, with over 20 years and 30 discussions with this disputed issue, that the titles are "stable" now and it would be more of a disruption for a massive change rather than keep retaining this existing style. Zzyzx11 (talk) 19:52, 7 March 2025 (UTC)[reply]

(edit conflict) Admin recall was soundly rejected for two decades before passing in 2024. Consensus can change, and it does. To Davidstewartharvey, the proposal is only for articles such as Louisville, Kentucky, to which Louisville redirects. If this proposal were to pass, Louisville, Kentucky would be moved to Louisville. And once again, no evidence that this is the style in American English. 🐔 Chicdat  Bawk to me! 20:04, 7 March 2025 (UTC)[reply]
Well thats just plain wrong! Louisville should redirect to Louisville (disambiguation) as there is more than Louisville in the US - 8 in the US alone plus 1 in Belize! Davidstewartharvey (talk) 20:23, 7 March 2025 (UTC)[reply]
Oh and I forgot to say, what do American reality programs for food and property do when they go anywhere? They normally flash the name up in the convention i.e. Boston, MA, which is just an abbreviation of what USPLACE is doing so it is used in American English Davidstewartharvey (talk) 21:14, 7 March 2025 (UTC)[reply]
It's not plain wrong. That is not how we deal with ambiguous names. If something is the primary topic (that is, it is either the most likely reference of that topic that someone is looking for or "itt has substantially greater enduring notability and educational value than any other topic associated with that term"), then the article is placed at that page, and a hatnote to a disambiguation page is provided. voorts (talk/contributions) 22:36, 7 March 2025 (UTC)[reply]
That would make the disambiguation page malplaced. If you think this primary redirect is incorrect, you can request that Louisville (disambiguation) be moved to Louisville. jlwoodwa (talk) 19:33, 10 March 2025 (UTC)[reply]
If Americans want to be excpetional then let's let them do it somewhere relatively harmless, like this. Phil Bridger (talk) 20:41, 7 March 2025 (UTC)[reply]
Chicdat, WP:ADMINRECALL finally passed in 2024 partly because it was initially identified as part of the larger urgent need to reform RFA. I did not see that sense of urgency in that last 2023 USPLACE discussion -- everybody basically repeats all the same arguments as in the previous discussions, and it ends with no consensus. I do not think you bring anything significantly new to the table that has not already been discussed repeatedly. Zzyzx11 (talk) 20:53, 7 March 2025 (UTC)[reply]
Fully concur with User:Zzyzx11's assessment. Also keep in mind that for many American attorneys and other legal professionals, the first Louisville they think of when they hear Louisville is Louisville, Colorado, because that is where the National Institute for Trial Advocacy is currently based. Most people who have heard of Louisville, Kentucky think of it only because they are fast food fans, and of course, all true fast food fans around the world love Yum! Brands. --Coolcaesar (talk) 05:13, 8 March 2025 (UTC)[reply]
Which is my point about Primary that I raised, you dont instantly think Louisville, Kentucky but one of the others! Davidstewartharvey (talk) 06:17, 8 March 2025 (UTC)[reply]
I had no idea NITA was based in Louisville or Colorado. We also don't base a primary topic or decision to disambiguate on whether a small population of people associate something with a place. voorts (talk/contributions) 17:37, 8 March 2025 (UTC)[reply]
I would definitely be in favor of allowing more specific exceptions to USPLACE, for additional large or particularly famous cities, and for unambiguously named state capitols. BD2412 T 03:43, 11 March 2025 (UTC)[reply]

Reminder that someone should post an announcement at WP:USCITY too, because this topic affect far more editors than just those who watch the WP:USPLACE article. • Sbmeirow • Talk • 00:44, 11 March 2025 (UTC)[reply]

Notified: Wikipedia talk:Naming conventions (geographic names). jlwoodwa (talk) 02:13, 11 March 2025 (UTC)[reply]
  • Thank you for your sound argumentation, Chicdat. I agree with your points, but as I am not familiar with the history of USPLACE I don't know how much of a trainwreck yet another RfC would be. Toadspike [Talk] 10:58, 12 March 2025 (UTC)[reply]

Taiwan MOS

In WP:NC-CN, We can clearly see when to use "China," "PRC," and "Mainland China." However, there are only a few sentences regarding "Taiwan" and "ROC." Due to the Political status of Taiwan is much more sensitive—for example, calling Taiwan a "country" may be controversial, while saying that "Taiwan belongs to the ROC" and that "the ROC is a country commonly known as Taiwan" is broadly acceptable—I believe it is necessary to establish a MOS for Taiwan and ROC, similar to that for China.

I think WP:NC-TW is a good solution, but it didn't work due to lack of consensus or other reasons. ?8 (talk) 16:30, 11 March 2025 (UTC)[reply]

Would you mind articulating the specific points you had in mind that require additional guidance? The one example offered is not terribly helpful, given that (as you have been told repeatedly) we refer to Taiwan as a country because that is what our sources do, regardless of what one feels to be controversial about it. There's nothing based in policy (which region-specific guidelines still have to obey) that allows one to circumvent that reality. Remsense ‥ 论 16:42, 11 March 2025 (UTC)[reply]
No, I just think that PRC has a detailed MOS and ROC should have one too. ?8 (talk) 03:21, 12 March 2025 (UTC)[reply]
We do not write guidelines simply because there are no guidelines – that's instruction creep. We write guidelines to record consensus if an issue arises and is discussed repeatedly. If you insist on pursuing this further, I would appreciate an example that does not contradict itself and illustrates an actual gap in the MOS. Toadspike [Talk] 12:52, 12 March 2025 (UTC)[reply]

Happy 22nd birthday (roughly), notability!

Further information: User:Uncle G/On notability § A tiny bit of history

It has been 22 years and 9 days since MartinHarper made an edit that quite a lot of people have missed since. I wrote Special:Diff/1278668922 on the 22nd anniversary, entirely coincidentally since someone was talking about the history and I thought that I should write it up. I didn't even spot the date when I was doing it.

(I'm not aware that this came up on the mailing list prior to that, although memory is hazy and I'd have to pore over the archives to refresh it. However, there is context in the form of m:What to do with entries related to September 11 casualties, which was a contemporary issue. c.f. Special:Diff/715056 on the policy talk page the day before.)

Uncle G (talk) 16:27, 12 March 2025 (UTC)[reply]

Please see discussion of IPBE

Please see the latest talk page entry of WP:IPBE. I added in that users from a censored country such as China could apply for it as an explicit mention on the page itself, but an editor objected. Please feel free to provide your views. Félix An (talk) 16:40, 12 March 2025 (UTC)[reply]

Technical

Category:Europe stubs

Hi can somebody use a tool to find how many stubs we have in total for Europe? ♦ Dr. Blofeld 15:40, 2 March 2025 (UTC)[reply]

A quick Petscan query shows over 760,000 articles. – DreamRimmer (talk) 18:28, 2 March 2025 (UTC)[reply]
Yikes!! Thanks! ♦ Dr. Blofeld 19:21, 6 March 2025 (UTC)[reply]

There's a template about talk page behavior & I cannot remember what it is called...

I can remember what it does... Anyway, isn't there a template that we can put on a celebrity's or politician's article talk page in reply to when someone comes along and wants to get in touch or maybe they ask the politician what can they do about Social Security (as if the article is a way to ask the celebrity or politician a question, etc.) Thanks - Shearonink (talk) 22:54, 5 March 2025 (UTC)[reply]

{{Astray}}? * Pppery * it has begun... 23:10, 5 March 2025 (UTC)[reply]
I think the closest thing for article talk pages is {{not a forum}}. Astray is for user talk pages. Izno (talk) 23:24, 5 March 2025 (UTC)[reply]
Astray would almost work...I'm surprised there isn't something written up, that could be used on the article talk to reply since this poster is an anon on a politician's page. Oh well, thanks anyway. I just thought I couldn't find it but yay it doesn't exist... - Shearonink (talk) 01:44, 6 March 2025 (UTC)[reply]
Somewhere there's a template, intended to be WP:SUBSTed, that reads (or used to read) something along these lines: 
I suspect, based on your question, that you found one of our over {{subst:#expr:(floor ({{subst:formatnum:{{subst:NUMBEROFARTICLES}}|R}} / 100000)) / 10}} million articles and thought we were affiliated in some way with that subject. Please note that you are at [[Wikipedia:About|Wikipedia]], the free online encyclopedia that [[Wikipedia:Introduction|anyone can edit]], and this page is for [[WP:TPG|discussion on how to improve]] the [[{{subst:PAGENAME}}]] article.
Maybe not exactly that, but maybe somebody knows how to do a proper search, using that as a clue. It was in use sometime around 2010. --Redrose64 🌹 (talk) 17:54, 6 March 2025 (UTC)[reply]
That would be {{Astray}}, which I pointed out above. * Pppery * it has begun... 18:16, 6 March 2025 (UTC)[reply]
I realise that, but the one that I've seen is about as long as my example above. Significantly, it lacked the second half (from Thus, we have no special knowledge onward). --Redrose64 🌹 (talk) 18:25, 6 March 2025 (UTC)[reply]
You mean this and this, Redrose64? Nobody (talk) 13:10, 7 March 2025 (UTC)[reply]

Display of contributions and "Current" label

When displaying contributions, a bold "Current" tag is added to the end of the edit when it is the latest edit to that article, talk page, etc. Is there a method or gadget to move it to a point where it is in a uniform column? I do a lot of wp:RCP and editor will often repeat their edits without correcting the problem. I will view the "Current" tag in my list of contributions to see if the article has been changed. Trying to determine if articles have been edited or not is rather cumbersome with just the list as the "current" tag is not in a uniform vertical column. I could add it to my watch list with a short expiration. I usually do a text search on my contributions page for "current" which highlights it. Highlighting makes it easier, but I'm looking for a better method. Example of listing in my contributions:

  • 19:08, 6 March 2025 (diff hist) (−6) Iran men's national basketball team (Undid revision 1279103344 by 217.218.49.102 (talk) unexplained change of header) (current) (rollback: 1 edit) (Tag: Undo)

What I would like to see:

  • 19:08, 6 March 2025 (diff hist) (C) (−6) Iran men's national basketball team (Undid revision 1279103344 by 217.218.49.102 (talk) unexplained change of header) (rollback: 1 edit) (Tag: Undo) --OR--
  • (C) 19:08, 6 March 2025 (diff hist) (−6) Iran men's national basketball team (Undid revision 1279103344 by 217.218.49.102 (talk) unexplained change of header) (rollback: 1 edit) (Tag: Undo)

Thank you, Adakiko (talk) 19:32, 6 March 2025 (UTC)[reply]

@Adakiko: "Search for contributions" on a contributions page has the option "Only show edits that are latest revisions". User:Markhurd/hidetopcontrib can do the opposite. Does that work for your purpose? PrimeHunter (talk) 20:35, 6 March 2025 (UTC)[reply]
@Adakiko: Here are two CSS rules: 
/* For current rev in contribs, add "(C)" before the size change */
li.mw-contributions-current span.mw-changeslist-links+span.mw-changeslist-separator:after {
  content: "(C)";
  font-weight: bold;
}
/* For current rev in contribs, suppress the "(current)" marker */
li.mw-contributions-current span.mw-uctop {
  display: none;
}
The second rule is optional. They go in Special:MyPage/common.css, since it works in all skins. But personally I use a rule that I wrote some months ago: 
/* highlight current edit in contribs */
li.mw-contributions-current {
  background-color: #eeffcc;
}
I created it at somebody's request, don't recall who for. --Redrose64 🌹 (talk) 21:07, 6 March 2025 (UTC)[reply]
@Redrose64: Thank you. added it to my CSS and it works great! Now all I have to do is to look for the "C" on the left. I go into shock each time I look at my contributions page and don't see "current". Cheers Adakiko (talk) 19:10, 8 March 2025 (UTC)[reply]
@Adakiko: As I mentioned, the second rule is optional - you can have both "(C)" and "(current)" displayed, by just using the first five lines, down to (and including) the first closing brace }. --Redrose64 🌹 (talk) 20:03, 8 March 2025 (UTC)[reply]
@Redrose64: I prefer the lack of "Current". I need to retrain myself. Can I train an old dog a new trick? Thanks again! 20:05, 8 March 2025 (UTC)[reply]

Parsoid error

I've been trying to edit my sandbox page in the visual editor, but when I click 'submit' it returns 'parsoid error'. Please could someone tell me what to do with this. I looked it up and none of the questions posted about this address my issue but instead go into a lot of detail about other kinds of error which are very technical. I can't paste an image here but the error essentially says: "Something went wrong [!] Parsoid error" and gives the options to 'dismiss' or 'try again'.

This error is occurring across multiple devices when I try to edit my sandbox. When I try to switch to the source editor it returns simply 'Parsoid error' and this time just gives me the option of 'OK'.

I don't know whether this is linked, but I recently had another (very minor) technical concern which I researched, and was told to create a common.css page with my username, in which I added the following: .mw-parser-output span.cs1-maint {display: inline;} /* display Citation Style 1 maintenance messages */. I don't know whether it had anything to do with this and I doubt it does, since I did this yesterday and was editing throughout the day yesterday with no issues even after pasting that in, but it might be useful context. Krimzonmania7078 (talk) 21:51, 6 March 2025 (UTC)[reply]

If it helps, I'll explain what I'm trying to do in my edit session. I'm working on a new article and decided to copy and paste another article into my sandbox to use as a 'template' of sorts (which ended up being a pointless exercise because I've basically written this article from scratch anyway). I think the issue might stem from that decision somehow. The reason why I'd like to get this fixed is that now I've been editing the article in my sandbox for a while and basically have no way to save my progress Krimzonmania7078 (talk) 23:21, 6 March 2025 (UTC)[reply]
I've actually found a workaround which is good enough (copy-pasted the article into another session of the sandbox with the first sentence missing) - that seems to have fixed it. Probably something right at the top of the article I was trying to use as a 'template' which I mindlessly copied was causing it. Krimzonmania7078 (talk) 23:39, 6 March 2025 (UTC)[reply]
Just report it on phab:. Your wikipedia account will work there. Include the name of the article you where copying in your bug report. The developers can look up specifics about your edit attempt, users can not do that. Snævar (talk) 13:10, 7 March 2025 (UTC)[reply]

CAPTCHA Security check

adding a internal link on Double Dutch (jump rope) requires a CAPTCHA Security check

there are pages where adding external links does not require a CAPTCHA Security check

suprising....

69.181.17.113 (talk) 11:53, 7 March 2025 (UTC)[reply]

Double Dutch (jump rope) hasn't been edited since 18 February. Your IP address has never edited it. Please always post a diff if you report a perceived issue with an edit. PrimeHunter (talk) 22:40, 7 March 2025 (UTC)[reply]
@PrimeHunter: Well, if you do a null edit on the page they linked as an IP you get a captcha, so I'm guessing it's some issue like Wikipedia:Village pump (technical)/Archive 212#unwarranted captcha (though it doesn't appear there is a news: link in that page, even transcluded). I purged the page and it still happens so I don't think it's from a change in a template causing a new link to be added... though maybe it's still the fault of a template? What else could it be? – 2804:F1...90:4783 (::/32) (talk) 16:25, 9 March 2025 (UTC)[reply]
I triggered a filter log by removing the short description(Special:AbuseLog/40204494), seems the url http://worldjumprope.org/# (with the # at the end) is confounding some algorithm, it thinks the url without the # was removed and that one with the # was added... I tried removing just the #, and the problem did seem to stop, though I have now went and removed it completely since that's not how external links are supposed to be used.
Edit: Not sure what exactly is causing this bug, tried to reproduce it in the sandbox, didn't work.
– 2804:F1...90:4783 (::/32) (talk) 20:59, 9 March 2025 (UTC) *edited: 21:29, 9 March 2025 (UTC)[reply]

Modifying system message on Petscan's interwiki page

When you type :petscan: in the search bar, you are taken to Special:GoToInterwiki/petscan:. The link on that page is https://petscan.wmflabs.org/?psid= which upon clicking takes us to an error page from where it is not possible to navigate back to petscan's main page. Is it possible to modify the system message so that there is a direct link to petscan's main page: https://petscan.wmcloud.org/? —CX Zoom[he/him] (let's talk • {C•X}) 14:23, 7 March 2025 (UTC)[reply]

That is probably due to the interwiki prefix on meta:Interwiki_map. That interwiki map is used on WMF wikis, not just english wikipedia.
Changing the system message from the tool itself would be done with a bugreport on the tool itself - https://github.com/magnusmanske/petscan_rs/issues Snævar (talk) 15:29, 7 March 2025 (UTC)[reply]
Yeah, and the interwiki map format doesn't support doing something different with an empty prefix. It possibly should, but that's another Phabricator ticket (which in my experience would languish forever). * Pppery * it has begun... 16:13, 7 March 2025 (UTC)[reply]
meta:Interwiki map assumes there is a page name after the colon. petscan:$1 goes to https://petscan.wmflabs.org/?psid=$1. If $1 is empty then you get the bad https://petscan.wmflabs.org/?psid=. Special:GoToInterwiki/petscan: uses MediaWiki:Gotointerwiki-external. It's possible to change it. I made a test at testwiki:MediaWiki:Gotointerwiki-external. It discovers if petscan: or acronym: were used with nothing after the colon and selects a different page, https://petscan.wmflabs.org or https://www.acronymfinder.com. It works (see testwiki:Special:GoToInterwiki/petscan:) but it may confuse users if interwiki prefixes don't behave the same way at Wikimedia wikis so I'm not sure we should do it. It's also confusing if entering petscan: in the search box doesn't lead to the same page as a wikilink petscan: which goes directly to the interwiki map target without using Special:GoToInterwiki. This also means "petscan:" and the displayed url at testwiki:Special:GoToInterwiki/petscan: have different targets. My test also has code for mail: but it's not treated as an external wiki so Special:GoToInterwiki isn't used for that. At phab:T309558 I suggested a redirect for mail: to https://lists.wikimedia.org/postorius/lists/. I also made a post saying "A more advanced solution would be adding a way for the interwiki map to specify where a link with an empty $1 should go". This would give a nice consistent solution across Wikimedia wikis with the search box and wikilinks behaving the same way. PrimeHunter (talk) 16:18, 7 March 2025 (UTC)[reply]
I think your solution solves the problem at hand, but I agree with the concerns you have with its implementation. Maybe the text could read something like: "Continue to https://petscan.wmflabs.org/?psid= or go to Petscan's homepage". It will keep the default destination intact, while also adding an additional link to the homepage for convenience. —CX Zoom[he/him] (let's talk • {C•X}) 16:43, 7 March 2025 (UTC)[reply]
Actually, I'm proposing that an additional line of text be added at Special:GoToInterwiki/petscan: with a direct link to Petscan's main page (if feasible with system messages). —CX Zoom[he/him] (let's talk • {C•X}) 16:21, 7 March 2025 (UTC)[reply]
Of course, changes to GoToInterwiki would only fix pages that go there, not direct links like petscan:. * Pppery * it has begun... 16:32, 7 March 2025 (UTC)[reply]

Privacy of sockpuppets and sockmasters

I have seen this in past but did not tell.

Check users are not allowed to disclose IP address of socks and sockmasters unless they do it themselves or long time offender or intentional IP socking.

But when I check administrator block log of check users, then check users often do this. First they block the large number of sockpuppets then after that sometimes they also block the IP range without mentioning the name of sockmaster in the IP block.

But those with experience can know that if the IP range is blocked immediately after blocking the sock accounts, then it belongs to the sockmaster.

I saw this when Mike V, Bbb23 used to block socks. 2409:40E1:100C:D174:78FA:B94D:2E28:A22A (talk) 07:33, 8 March 2025 (UTC)[reply]

See the policy about this which explicitly excepts that. — xaosflux Talk 10:35, 8 March 2025 (UTC)[reply]
Locally, the relevant passage in WP:CheckUser is WP:CUIPDISCLOSE. Izno (talk) 05:18, 12 March 2025 (UTC)[reply]

Page loading time

Help:Creating a bot: Revision history - Wikipedia Revision history 13:23, 8 March 2025 Anomie talk contribs 31,536 bytes +118 The rendered HTML is exactly the same after your edits, all you did was make the wikitext uglier. Please don't do this sort of thing again, and consider asking at Wikipedia:Village pump (technical) whether your ideas will actually work


How does reducing the bytes of the document not increase processing speed? In a sample from this: Simon E Spero Analysis of HTTP Performance problems www.w3.org @ "HTTP Illustrated" "This page is 1668 bytes long" indicates bytes is the determination - @"Very nice, but what does it all mean": "Another important metric is the bandwidth of the connection. This is a measure of how many bits per second our connection can carry." this would indicate that reducing the bits decreases bandwidth load. Understanding latency developer.mozilla.org: "the HTML includes requests for multiple CSS, scripts, and media files. The greater the number and size of these requests, the greater the impact of high latency". In my imagining (this is to say I don't know exactly how the server scans the data for retrieval): if a server scans a page with gaps the motion is from the 1st byte to the last byte in sequence: like a sensor which receives the imprint at each position- although the whitespace has no textual element the scan would need to pass through the byte of the space to reach the last datum in the stored document. Onemillionthtree (talk) 17:12, 8 March 2025 (UTC) ⇐ this is from my Talk page not here[reply]

Onemillionthtree, you've just edited the wikitext. The html will remain exactly the same unless you make an edit that is not cosmetic. — Qwerfjkltalk 17:49, 8 March 2025 (UTC)[reply]
The bytes are reduced so the retrieval is easier? Each time someone requests the page the complete bytes of the page is retrieved. If less bytes less to retrieve. Onemillionthtree (talk) 18:10, 8 March 2025 (UTC)[reply]
The page is parsed (converted from wikitext to HTML) once when you save the edit, then the HTML is cached and stored for every other person who visits it. Following that the page is reparsed once every 30 days to check for any updates.
Parsing the page automatically removes extra whitespace, new lines, etc, there is absolutely no point in removing them by hand. 86.23.109.101 (talk) 18:17, 8 March 2025 (UTC)[reply]
Converting the parsed version into the editorial page version: the retrieval isn't different but the conversion rate is different - the cached version is the same in both but the product of reconverting from the cached have different bytes value; so there is a time difference in the conversion. Onemillionthtree (talk) 18:25, 8 March 2025 (UTC)[reply]
Although the store amounts are the same - the bytes sent to the requestor each time is more with whitespace; that's obvious Onemillionthtree (talk) 18:29, 8 March 2025 (UTC)[reply]
What you seem to be stating is that when the request is made the server delivers a page - in both versions the bytes value is the same - but if an editor requests the editorial screen the server delivers coding screen with whitespace extra bytes. So if the whitespace makes no difference then it would be helpful for editors to maximize whitespace on the coding version? Onemillionthtree (talk) 18:46, 8 March 2025 (UTC)[reply]
There is a technical issue (is removing wikitext whitespace useful?) and a social issue (does removing wikitext whitespace irritate people?). We could debate the former but the answer to the latter is yes. There have been numerous cases where editor A adds whitespace because it looks good, and editor B removes it because it doesn't. That is not sustainable and the community has decided that existing stuff should be left alone unless there is a good reason to change it. Saving inconsequential amounts of time or storage is not a good reason. Please stick to the established procedure of not changing existing style (whether it be spelling, date formats, reference templates, or whitespace). Johnuniq (talk) 01:49, 9 March 2025 (UTC)[reply]
@Onemillionthtree: If you remove blank lines above a section heading (as you did here), then the very next time that somebody edits the section preceding that heading, the MediaWiki software will automatically restore that blank line. Secondly, some editors with less-than-perfect eyesight have previously stated that some of these gaps - particularly blank lines - have been shown to aid the editing experience, and so their removal can create an accessibility issue. Third, removing 118 bytes from the wikitext of a page that previously had 31,536 bytes is a reduction of about 0.37% - a miniscule saving. Fourth, WP:DWAP. --Redrose64 🌹 (talk) 08:25, 9 March 2025 (UTC)[reply]

Removing copyrighted text

This probably isn't the right place to ask this, but I User:141.154.49.21 has been cutting-and-pasting huge pieces of text into articles. I ran two articles through "Earwig's Copyvio Detector" and it was a complete cut-and-paste.

I'm not sure how to "rev del" the additions. A bit of help would be great. Thank you! Magnolia677 (talk) 11:28, 9 March 2025 (UTC)[reply]

You can always contact an admin at Category:Wikipedia administrators willing to handle RevisionDelete requests. I have started revdeling those edits, including one you hadn't caught, yet. I've also dropped a warning on the IP's talk page. - Donald Albury 13:38, 9 March 2025 (UTC)[reply]
Thank you! Magnolia677 (talk) 14:06, 9 March 2025 (UTC)[reply]
I've revdeled copyvios in 6 articles. I don't see any other actionable copyvios. Donald Albury 14:09, 9 March 2025 (UTC)[reply]
@Magnolia677, FTF the right place to ask for revision deletion is WP:ANI. Izno (talk) 05:21, 12 March 2025 (UTC)[reply]
@Izno: Er, it isn't. See WP:REVDELREQUEST - Donald Albury was correct. --Redrose64 🌹 (talk) 18:14, 12 March 2025 (UTC)[reply]
Uh yes I apparently did not process what I was responding to fully. Izno (talk) 18:30, 12 March 2025 (UTC)[reply]

Image not displaying in table header in mobile view

I am working a user-generated report on meta.

I want a sortable column header to display a single icon. The icon doesn't display at all on mobile view on my phone. It is possibly a screen width issue.

Re-creation:

Example 1 - seems to display icon in column six, is really small though.
Title Talk page (# edits) Status Focus area Order created
Example 2 - no heading visible for column six
Title Talk page (# edits) Status Focus area Order created
Blah Talk:Blah Number one 1 42

I am specifying image width in pixels ([File:Symbol support vote.svg|15px]), I am not sure of a better way.

Any workaround solutions would be appreciated. Thanks. Commander Keane (talk) 22:42, 9 March 2025 (UTC)[reply]

The responsiveness CSS for the mobile version makes the icon shrink to a minimum size that can be very small. You can add the noresize class to the header cell to prevent that. hgzh 09:23, 10 March 2025 (UTC)[reply]
Thanks hgzh. I wrapped the image in a div with class noresize...
Example 3 - noresize class applied
Title Talk page (# edits) Status Focus area Order created
Blah Talk:Blah Number one 1 42
I assume that is the way to do it. It seems to work.--Commander Keane (talk) 11:34, 10 March 2025 (UTC)[reply]
Adding it directly to the cell should have worked as well: ! class="noresize" | [[File:Symbol support vote.svg|15px]]. hgzh 07:41, 11 March 2025 (UTC)[reply]

Redirect to section not working

I'm currently fixing broken redirects and i noticed this redirect[1]. I tried to correct it with this link, which would be the obvious solution, but it goes one heading down to Structure and properties. Has anybody any ideas why this is happening and how i can fix it? Thanks in advance for any help. Synonimany (talk) 22:52, 9 March 2025 (UTC)[reply]

It works for me. It goes to the correct section using Chrome browser. – Ammarpad (talk) 17:02, 10 March 2025 (UTC)[reply]

Is it just me or are section links suddenly working differently? I think that it used to be that when linking to a section mid-page, the whole section heading was visible at the top of the browser page window. Now it seems that the title portion of the section heading is scrolled off the top so that only the horizontal rule portion of the heading shows.

Try this link: Technical research ship#Environmental research ship (AGER).

windows 10, chrome (a new version is available but I haven't yet got round to allowing it to update so that suggests that it isn't me ...)

—Trappist the monk (talk) 00:15, 10 March 2025 (UTC)[reply]

Works fine for me logged out on Brave and Safari for Mac OS, and logged in (Vector 2022 with a lot of customization) in Firefox for Mac OS. Depending on the browser, I see "Belmont class (Victory ship type)" at the top of the window, or one to three lines above that. – Jonesey95 (talk) 01:59, 10 March 2025 (UTC)[reply]
I guess I should have said that I use the old vector skin. With an incognito window (Vector 2022 without any customization), the above link puts the line with USS Belmont • 1964–1970 at the top of the window. That, to me, also seems like a mispositioning – since I don't use Vector 2022, I don't know what is 'normal' for that skin.
—Trappist the monk (talk) 02:57, 10 March 2025 (UTC)[reply]
I can confirm that this happens not just on Trappist the monk's computer. Polygnotus (talk) 05:24, 10 March 2025 (UTC)[reply]
Not happening for me in Firefox 136 or Chromium 133 on Linux with Monobook, Vector, or Vector 2022. Monobook and Vector put the section heading at the top. Vector 2022 puts the header a few lines lower; when logged in there's a floating header that it seems to be making room for. It would probably help if people specify their browser, OS, and skin. Anomie⚔ 11:49, 10 March 2025 (UTC)[reply]
This doesn't happen for me, but #Redirect to section not working above may be the same problem too. Matma Rex talk 13:37, 10 March 2025 (UTC)[reply]
For me that looks like the same issue. The top of the visible page is below the linked heading.
—Trappist the monk (talk) 13:43, 10 March 2025 (UTC)[reply]
The anomaly is not confined to section links. Here is a link to reference number 178 at an older version of Erasmus: ref 178 (permalink). For me, sometimes I see the page load and breifly display at the top of the page. It then repositions to the highlighted reference but then repositions again so that reference 180 is at the top of the page. It doesn't always flash the top of the page but always (so far) flashes the highlighted reference before repositioning to reference 180.
—Trappist the monk (talk) 15:35, 10 March 2025 (UTC)[reply]
I can reproduce this, but only when using Vector 2022. For all other skins, the expected target (be it section heading or entry in a ref list) is at the top of the window as expected. --Redrose64 🌹 (talk) 20:58, 11 March 2025 (UTC)[reply]

Email watchlist

I haven't received a watchlist email in two days. Is anyone else experiencing this, or is it a local problem? C F A 23:38, 9 March 2025 (UTC)[reply]

Frankentemplate in visual editor at Lace tell

Tracked in Phabricator
Task T388356

In the Flemish tells subsection of the Content section of Lace tell, VisualEditor interprets the ordinary article text as being some parameter in a conglomerate of templates including Lang and Verse translation. Why? ꧁Zanahary꧂ 23:40, 9 March 2025 (UTC)[reply]

Usually this means some template somewhere is producing invalid markup. But I have no idea what the culprit is here - this sounds like a bug that should be reported on Phabricator to me. * Pppery * it has begun... 23:46, 9 March 2025 (UTC)[reply]
There is a link in the editor to "Editing multi-part template content" on the MediaWiki site's "Help:VisualEditor/User guide" page. I don't see any further links that explain how such content is detected or defined. – Jonesey95 (talk) 01:57, 10 March 2025 (UTC)[reply]
I added a blank line before {{Verse translation}} to help VisualEditor separate it from the preceding paragraph.[2] That works for me. PrimeHunter (talk) 18:27, 10 March 2025 (UTC)[reply]

Search text box on Timeless doesn't format correctly

the formatting (search icon in the text)

So on timeless the search bar doesn't format correctly, when on the search bar specifically:

Vector works correctly however, and the search bar is correct when typing in top, only on while on a search page does the bug occurs. Des Vallee (talk) 07:18, 10 March 2025 (UTC)[reply]

I was 95% this has a task but it seems not to. Izno (talk) 05:26, 12 March 2025 (UTC)[reply]

Hide Patrolled for Special:Newfiles not working

Tracked in Phabricator
Task T388428

Special:Newfiles has a checkbox option to hide patrolled files. Previously, I've used this as filter so I look only at unpatrolled files. Now when I use it, the list of files generated is empty. I have checked and there are definitely unpatrolled files, and really it would be a shock if all the files really were patrolled. -- Whpq (talk) 14:44, 10 March 2025 (UTC)[reply]

If IP and similar templates saying I am not logged in?

Tracked in Phabricator
Task T388525

Whenever the {{If IP}}, {{If autoconfirmed}}, or similar templates are used, they say I'm not registered or autoconfirmed when I am a part of said user groups. This was a problem that happened more recently as it used to work before.

I don't believe this is because I edit on a blocked school IP address? I've tried it at home and it still says such, so I'm not sure why it could be doing this. Thanks in advance for any assistance. / RemoveRedSky [talk] [gb] 15:17, 10 March 2025 (UTC)[reply]

@RemoveRedSky: It works for me. I see "You are currently logged in." at top of {{If IP}}, and "You are autoconfirmed." at {{If autoconfirmed}}. Please quote the full strings you see when you are logged in. Have you enabled "Always enable safe mode" at Special:Preferences#mw-prefsection-rendering? That breaks the feature. Try to bypass your cache. Use Ctrl+F5 in Windows browsers, not F5 alone. What is your browser? What is your skin at Special:Preferences#mw-prefsection-rendering? Are you by any chance referring to what a screen reader reads out to you and not what you visibly see? Do you have any ad blocker or other browser feature which may block CSS? PrimeHunter (talk) 18:11, 10 March 2025 (UTC)[reply]
Hello PrimeHunter.
  1. "Always enable safe mode" - I have not tried it. After trying, that could be one possible solution.
  2. "Bypassing cache" - Doesn't do anything.
  3. "Browser" - I'm sure I have the problem both on Opera GX and Google Chrome.
  4. "Skin" - I am using Vector 2022.
  5. "Screen reader" - No.
  6. "Ad blocker" - I will have to test this whenever possible since I'm unsure if my school uses hidden ad blockers or other features. This might be the case.
Thank you. / RemoveRedSky [talk] [gb] 18:55, 10 March 2025 (UTC)[reply]
Note, these are all evaluated client-side by scripts, ensure you are not blocking any script processing from our domains. — xaosflux Talk 18:22, 10 March 2025 (UTC)[reply]
I was not aware of this, and I'll check to see if things such as ad blockers are doing this whenever I have the proper time. / RemoveRedSky [talk] [gb] 18:56, 10 March 2025 (UTC)[reply]
@RemoveRedSky: User:RemoveRedSky/common.css has a comment start /* without a matching end */. Either remove /* if you want the script, or add */ to the end if you don't (or remove the whole line). If that doesn't solve it then please quote the full strings you see at top of {{If IP}} and {{If autoconfirmed}} when you are logged in and not in safemode. The feature works by sending both versions to your browser together with CSS rules to first hide both versions and then unhide one of them. PrimeHunter (talk) 20:58, 10 March 2025 (UTC)[reply]
Nevermind, that solved the issue ;-;' I'm not that experienced with CSS code, thanks for your help / RemoveRedSky [talk] [gb] 02:10, 11 March 2025 (UTC)[reply]
I have reported it at phab:T388525. PrimeHunter (talk) 12:49, 11 March 2025 (UTC)[reply]

Edit summary notice: "changing height or weight"

In Special:Diff/1092464781/1095126194 it says: changing height and/or weight, Mobile edit. This is useful, IP vandals frequently change height numbers. But in this edit Special:Diff/1264321134/1279765644 there is no warning. So mostly these days I see vandals of this class messing with the {{convert}} template, perhaps because there is no edit summary that shines light on them. Not sure who detects and issues these edit summary notices. -- GreenC 15:38, 10 March 2025 (UTC)[reply]

That is Special:AbuseFilter/391. It only targets parameters in infoboxes. * Pppery * it has begun... 15:39, 10 March 2025 (UTC)[reply]
Great thanks, looks like I could make a Wikipedia:Edit filter/Requested for {{convert}} -- GreenC 15:48, 10 March 2025 (UTC)[reply]

Tech News: 2025-11

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

  • Editors who use password managers at multiple wikis may notice changes in the future. The way that our wikis provide information to password managers about reusing passwords across domains has recently been updated, so some password managers might now offer you login credentials that you saved for a different Wikimedia site. Some password managers already did this, and are now doing it for more Wikimedia domains. This is part of the SUL3 project which aims to improve how our unified login works, and to keep it compatible with ongoing changes to the web-browsers we use. [3][4]
  • The Wikipedia Apps Team is inviting interested users to help improve Wikipedia’s offline and limited internet use. After discussions in Afrika Baraza and the last ESEAP call, key challenges like search, editing, and offline access are being explored, with upcoming focus groups to dive deeper into these topics. All languages are welcome, and interpretation will be available. Want to share your thoughts? Join the discussion or email aramadan@wikimedia.org!
  • All wikis will be read-only for a few minutes on March 19. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks.
  • Recurrent item View all 27 community-submitted tasks that were resolved last week.

Updates for technical contributors

  • Recurrent item Detailed code updates later this week: MediaWiki

In depth

  • The latest quarterly Growth newsletter is available. It includes: the launch of the Community Updates module, the most recent changes in Community Configuration, and the upcoming test of in-article suggestions for first-time editors.
  • An old API that was previously used in the Android Wikipedia app is being removed at the end of March. There are no current software uses, but users of the app with a version that is older than 6 months by the time of removal (2025-03-31), will no longer have access to the Suggested Edits feature, until they update their app. You can read more details about this change.

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

MediaWiki message delivery 23:06, 10 March 2025 (UTC)[reply]

Redirect that should have been created in "Wikipedia:" namespace was created in mainspace

Continuation of phab:T388423 (reported by @Sebbog13) which was closed by @Sohom Datta and redirected here. Basically, the "search in" advanced search function doesn't append the namespace in the redlink it displays, instead creating a mainspace redlink.

A bugfix might involve adding the namespace in which the search is made to the redlink. However we should bear in mind that it is possible to search in several namespaces at the same time, and isn't obvious how we should generalize this fix to the case of multiple namespaces with none of them being mainspace.

Also alerting @AKlapper (WMF) (who followed the Phab task) and @Jlwoodwa (who was involved in fixing the original redirect). Chaotic Enby (talk · contribs) 01:31, 11 March 2025 (UTC)[reply]

From a discussion on Discord: the problem could be (mostly) solved locally by having {{no article text}} (called by MediaWiki:Noarticletext) generate a link like Special:Search/Wikipedia:THISDOESNTEXIST, rather than the current link, https://en.wikipedia.org/w/index.php?search=THISDOESNTEXIST&title=Special%3ASearch&fulltext=1&ns4=1. But I'm not sure why it does the latter in the first place, so by Chesterton's fence I'm hesitant to suggest making that change immediately. jlwoodwa (talk) 02:03, 11 March 2025 (UTC)[reply]
@Chaotic Enby: I think you are understanding it wrongly again. The issue wasn't me searching in a namespace, and it's possible to search in multiple at the same time, which means fixing it would be difficult. The problem is that I went to Wikipedia:UBXGALLERY and clicked the "Search for "UBXGALLERY" in existing pages within the Wikipedia namespace." which redirected me to searching for UBXGALLERY (in mainspace, instead of "Wikipedia:" space) and searching for pages within the Wikipedia namespace. When I clicked to create a redirect from the search page, the redirect was from mainspace UBXGALLERY to "Wikipedia:" space Wikipedia:Userboxes/Galleries, which is wrong. Thankfully User:jlwoodwa moved the page to the correct namespace. Sorry for the yapping. - Sebbog13 (talk) 15:10, 11 March 2025 (UTC)[reply]

Mw-Reverted tag on newest revision

Tracked in Phabricator
Task T387838

Is it just me, but the newest revision of Nagueshi has the reverted tag on it? Myrealnamm (💬Let's talk · 📜My work) 14:08, 11 March 2025 (UTC)[reply]

No, it has the tag, weird. - Sebbog13 (talk) 15:11, 11 March 2025 (UTC)[reply]
This is already reported at phab:T387838. – Ammarpad (talk) 16:48, 11 March 2025 (UTC)[reply]

Something broke map overlays in Infoboxes

Some recent change (last few days) broke map overlays in Infoboxes. In 2020 I wrote an article that uses an overlay on a map in an Infobox to outline an area. As of a few days ago, the outline is rendered but is shifted to N of where it should be on the Infobox map. The same outline's position is correct on other maps in the article that aren't in an infobox. There have been no changes to the map data since 2020.

The particular article is Walls of Lisbon; compare the infobox outline of the walls with the third map (Cerca Fernandina). The infobox overlay is shifted N of its proper position.

I should also add that this happened once before. I did not report it, and after six months or so it got fixed. Now it is broken again, but this time I'm being more proactive in seeking a remedy. Osoraku (talk) 18:55, 11 March 2025 (UTC)[reply]

As of right now, [[iarchive:newlettersofdavi0000hume|New Letters of David Hume]] displays like a wikilink: New Letters of David Hume. Can we format these links so that they appear the same as: New Letters of David Hume? There is not much oversight on IA for uploads. Rjjiii (talk) 21:48, 11 March 2025 (UTC)[reply]

@Rjjiii: [[iarchive:...]] uses the IArchive entry at meta:Interwiki map. Wikilink syntax [[...]] does not produce an external links icon. If we wanted to, we could make a template so {{iarchive|newlettersofdavi0000hume|New Letters of David Hume}} produces external link syntax like [https://archive.org/details/newlettersofdavi0000hume New Letters of David Hume]. A bot could change all current [[iarchive:...]] to use the template. PrimeHunter (talk) 23:37, 11 March 2025 (UTC)[reply]
Hmm, a template and bot is probably overkill. A bot could just replace Interwiki links with regular links. But now that I'm looking at the list, it's not clear why we should format many of these sites as wikilinks. A lot of them are wikis about very unrelated things like Pokémon, Linux distributions, and Final Fantasy. I might raise the issue over there, and see what the response is, Rjjiii (talk) 02:04, 12 March 2025 (UTC)[reply]
I'm pretty much the sole maintainer of meta:Interwiki map, so I might as well reply here. No, you won't get me to remove the iarchive: interwiki prefix. Both because I don't find "some projects want this with an icon" convincing as a reason to remove, and also there are more than 10,000 uses across hundreds of projects (slow link) affected by this and wrangling a bot to fix all of them exceeds my willingness to care even if everyone agreed it should be done. I don't think anything I can do there has any control over whether an icon is displayed, although maybe some local CSS hack could. * Pppery * it has begun... 02:08, 12 March 2025 (UTC)[reply]
That would indeed be theoretically possible:
.mw-parser-output a.extiw[href^="//archive.org"] {
    background-image: url(/w/skins/Vector/resources/skins.vector.styles/images/link-external-small-ltr-progressive.svg?fb64d);
    background-position: center right;
    background-repeat: no-repeat;
    background-size: 0.857em;
    padding-right: 1em;
}
However it's indeed very hacky - it unnecessarily duplicates code, and will break if theme internals change. So probably not a good idea to use on enwp.  novov talk edits 10:56, 12 March 2025 (UTC)[reply]
I can accept it if the answer is just that the cat is already out of the bag. I thought this was something new because I have only seen it in a few recent edits, but it looks like it was added over 10 years ago. To be clear though, the concern isn't about icons in general or aesthetics. If Wikipedia consistently formats wikilinks one way and external links another way, it's inherently confusing to randomly format something like "Windows XP". Rjjiii (talk) 02:43, 13 March 2025 (UTC)[reply]
There is an old 2009 request at phab:T20562: "Indicate in output whether an interwiki link is marked local". PrimeHunter (talk) 10:50, 13 March 2025 (UTC)[reply]

ParserFunction errors

I'm just terrible at tracking down the cause of ParserFunction errors. Can anyone fix whatever's causing the problem in Template:Data world#Derived data? Whatever it is, its causing similar errors in the same place in other template pages of the form "Template:Data [country]". The error message says that it's an error in Template:Nts; but that template hasn't been edited in nearly five years, and these errors have popped up only recently. Deor (talk) 00:53, 12 March 2025 (UTC)[reply]

Use "Related changes" for stuff like this. I reverted a recent edit at Template:Order of magnitude with a grumpy edit summary. Johnuniq (talk) 08:54, 12 March 2025 (UTC)[reply]
As a template editor with almost 20 years' experience, I don't appreciate the grumpy revert summary. The issue here (as Snævar explained) wasn't with my edit to {{Order of magnitude}}, but with other templates attempting to pass it non-numeric input, which may be buried deeply in template call stacks (see User talk:Pppery#Template:Order of magnitude). {{Order of magnitude}} has over 200 thousand transclusions, as its documentation states, and these breakages cannot be reasonably tested for (if you disagree, feel free to add example testcases to the testcases page - for the record, my change passed all current testcases without issue). 「ディノ奴千？！」☎ Dinoguy1000 17:58, 12 March 2025 (UTC)[reply]
Agreed with Dinoguy1000 here. * Pppery * it has begun... 19:30, 12 March 2025 (UTC)[reply]
  1. land area is text, not a variable
  2. Template:Data world returns three curly brackets on each side, which can not be used for calculation
  3. You are doing an calculation with the total area and land area numbers, so you need mw:Help:Extension:ParserFunctions##expr. It does not calculate without you asking it to.
So once that data world no longer gives curly brackets, you end up with this: {{ppm|{{sigfig|{{#expr:({{{total area}}}/{{data world|pst2|{{{land area}}}}})}}|3}}}}. Snævar (talk) 09:07, 12 March 2025 (UTC)[reply]
I have installed User:Anomie/previewtemplatelastmod. After installation, the technique is to go to the problem page, click the "Edit" tab for the whole page, and scroll down to the part after the edit box, publish/preview/etc. buttons, below which there is a line reading "Pages transcluded onto the current version of this page" - if this is preceded by a right-pointing triangle, click that to expand the list. The topmost entry (or entries) should be the most likely candidate for the problem. --Redrose64 🌹 (talk) 19:25, 12 March 2025 (UTC)[reply]

Technical error

Tracked in Phabricator
Task T388646

I get this when I try to edit a section.

[a4f116d8-d17e-4d45-abf2-d1a337557eff] 2025-03-12 11:19:03: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError" HandsomeFella (talk) 11:21, 12 March 2025 (UTC)[reply]

There are some ongoing issues, people are investigating. Follow T388646 for updates. Matma Rex talk 11:32, 12 March 2025 (UTC)[reply]

Forming a request at Wikipedia:RefToolbar

Hello everyone, after a bunch of back-and-forth about what the proper venue is for making an addition to the RefToolbar, I think I finally know the correct procedure. I'm to make a formal {{Edit interface-protected}} request there (after testing my proposed changes). I have the edit request ready to go. The specific page I need modified is MediaWiki:RefToolbarConfig.js and my request will look something like this:


The purpose of this request is adding the url-status field to to cite-news, cite-book, and cite-journal, matching what is already present at cite-web.

Instructions:

Add a comma to the end of current lines 93, 124, and 163, and add a new row beneath each reading: {"field": "url-status", "tooltip":"cite-urlstatus-tooltip"}

Same instructions, line by line:

Line 93: change {"field": "quote"} to {"field": "quote"},

New added line beneath: {"field": "url-status", "tooltip":"cite-urlstatus-tooltip"}

Current line 124: change {"field": "quote"} to {"field": "quote"},

New added line beneath: {"field": "url-status", "tooltip":"cite-urlstatus-tooltip"}

Current line 163: change {"field": "postscript", "tooltip":"cite-postscript-tooltip"} to {"field": "postscript", "tooltip":"cite-postscript-tooltip"},

New added line beneath: {"field": "url-status", "tooltip":"cite-urlstatus-tooltip"}


I'm nearly certain this will fix the issue. I however don't know the first thing about testing these changes in my sandbox. Could someone help point me in the right direction? I don't want to make the request and have it rejected for being untested. Thank you. TheSavageNorwegian 16:37, 12 March 2025 (UTC)[reply]

Internal error on Preview

Tracked in Phabricator
Task T388646

Trying to preview my edit at Lemon dove, I get "[e0a059cb-fd01-4dd0-a254-f278b1d56ebf] 2025-03-13 11:54:10: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"" Happened repeatedly. Has now cleared, but thought I should mention it here, I don't recall ever having anything like it in years of editing. DuncanHill (talk) 11:57, 13 March 2025 (UTC)[reply]

There are ongoing server issues, not related to your action, and seemingly the same thing as this yesterday. See T388646. Matma Rex talk 13:05, 13 March 2025 (UTC)[reply]

Proposals

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

RFC: Officeholder infoboxes

Should we delete order numberings from infoboxes of office holders?
See previous related discussions:

GoodDay (talk) 18:58, 9 February 2025 (UTC)[reply]

Survey (Officeholder infoboxes)

  • Yes - We have the numberings in the pros & that's enough. GoodDay (talk) 18:58, 9 February 2025 (UTC)[reply]
  • Mostly yes, as the numberings in most offices are done by WP editors counting and adding that information, and rarely is a numbering system used by reliable sources. But where the numbering is frequently used by reliable sources (such as in reference to the US presidency), it does not make sense to hide that. So numbering should only be used when it is clear that it is a common mention within the reliable sources. --Masem (t) 19:04, 9 February 2025 (UTC)[reply]
    We should indeed not hide the numbers from the US presidents. We should present them when we are writing about the presidents themselves, such as in the lead sentences; but the infobox and the succession box parameters present the office. See the messy "45th & 4th president of the United States" heading with different data underneath at the Donald Trump page. In any case, leaving the numbers in the US infoboxes guarantees that they will creep back into all the other infoboxes, because monkey see, monkey do. Surtsicna (talk) 20:16, 9 February 2025 (UTC)[reply]
  • Sometimes, only delete them if there is no (consistent) numbering used by reliable sources. I don't think we need to have a majority of reliable sources using the numbering (after all, no source is complete and information isn't excluded just because it isn't present in most sources). However, we still want sources to use a numbering, and that numbering to be consistent, to avoid OR. Chaotic Enby (talk · contribs) 19:44, 9 February 2025 (UTC)[reply]
    Sometimes for reasons laid out by Chaotic Enby ꧁Zanahary꧂ 20:08, 12 February 2025 (UTC)[reply]
  • Yes, because the way they are presented in the infobox does not make sense. The numbers are not part of the office. The number 46, for example, refers to Joe Biden specifically, not to the office he held. Name him 46th in the lead sentence, but not in the infobox or in the succession box, because in those templates we are talking about the office, not Biden personally. And of course, these numbers inevitably creep into topics where they are not used at all. Surtsicna (talk) 20:09, 9 February 2025 (UTC)[reply]
  • Yes, but they should be elsewhere, the current spot makes no sense. Maybe a specific Number field? I don't have any good ideas, but agree they don't belong where they are currently. --JackFromWisconsin (talk | contribs) 23:03, 10 February 2025 (UTC)[reply]
  • No, though it certainly isn't mandatory to use them. Officeholding is often sequential. Sometimes, the ordinal is part of the title itself, as in certain titles of nobility. Sometimes, that fact is also verifiable (per ChaoticEnby's argument) and sometimes it isn't. Sometimes it's irrelevant, as in the overlapping terms of US Senators. If, for a given office, order is relevant and verifiable, there is no better place to put in than in the infobox, since it provides readers with a clear navigational feature, along with preceded by and succeeded by. Of course editors on the given topic can make the decision as to whether it's relevant, meaningful, and verifiable, but taking it out of the template removes valuable information in all case.
The concerns raised by Surtsicna and JackFromWisconsin—"George W. Bush was not preceded by Bill Clinton in the role of '43rd President of the United States'"—refer to a visual interpretation that had never occurred to me before I read it. I would suggest that most people read the linked text different and understand that the ordinal isn't part of the title.--Carwil (talk) 00:34, 11 February 2025 (UTC)[reply]
If the ordinals are not part of the office, we should not present them as if they were. Surtsicna (talk) 00:46, 11 February 2025 (UTC)[reply]

Discussion (Officeholder infoboxes)

I realize that their may be resistance to 'deletion', concerning American, Australian, Canadian & New Zealand officeholders. But, perhaps we can eliminate the numberings from most (if not all) officeholders' infoboxes. GoodDay (talk) 18:58, 9 February 2025 (UTC)[reply]

Should other groups be able to use 2FA by default?

Should other groups be able to use 2FA by default? ~/Bunnypranav:<ping> 16:13, 11 February 2025 (UTC)[reply]

Background

In Wikipedia:Village pump (proposals)/Archive 216#Allowing page movers to enable two-factor authentication, many people advocated for other advanced and even that all used should be able to use 2FA by default. This RfC clearly asks which groups should get 2fa. This is asking for them to have the permission/ability to turn 2FA on, i.e. have the oathauth-enable right, not require these group holders to use 2fA. This will allow these users to enable 2FA themselves and not have to ask stewards at meta. Feel free to choose one or more options:

~/Bunnypranav:<ping> 16:14, 11 February 2025 (UTC)[reply]

Survey (2FA for more groups)

  • Support option 2, since that adds a basic barrier of I know what I'm doing. As said by me in the previous discussion, the responsibility and accountability of protecting your account lie on you and not WMF. Yes, they can assist in recovery, but the burden should not lie on them.~/Bunnypranav:<ping> 16:13, 11 February 2025 (UTC)[reply]
  • Oppose 1 and 2 - what this really would do is allow people to enroll in 2FA without asserting that they know what they're doing, which seems bad. Weak oppose 6, since rollback doesn't really grant you the ability to do anything you couldn't already, so it shouldn't be a distinguisher here. Weak support the others, I guess. * Pppery * it has begun... 16:45, 11 February 2025 (UTC)[reply]
  • Support 2 and weak support 1. We don't need to put a barrier to make sure people know what they're doing if they choose to set up 2FA. If they activate it, we can presume that they have an idea of how it works, and any consequence for their mistakes only affects them. Only weak support for 1 as the presumption of "they have an idea of what they're doing" is a bit lower for very new editors who might not be as familiar with the interface, but we can still presume that a new user finding the 2FA setting didn't do it fully by accident. Chaotic Enby (talk · contribs) 16:54, 11 February 2025 (UTC)[reply]
  • I was the person who made the original page mover 2FA proposal. I think that out of these groups, only file movers have a significant need for 2FA access, since that right allows for the ability to make rapid changes that could affect tens of thousands of pages (similar to template editors). However, I'm not opposed to allowing all autoconfirmed users to enable 2FA, as long as they must turn on a preference where they accept the risks of using it. This is similar to how the IP Information tool works. JJPMaster (she/they) 17:02, 11 February 2025 (UTC)[reply]
    I would also be fine with encoding in PHP the current process with a preference checkbox, since that's all the stewards ask for as it stands. * Pppery * it has begun... 17:08, 11 February 2025 (UTC)[reply]
  • Oppose all until Special:Manage Two-factor authentication (MediaWiki:Oathauth-ui-general-help) is rewritten in non-technical language that clearly explains the benefits and risks of enabling 2FA and links to the detailed help at WP:2FA. Once that has been rewritten then I'll consider which if any of the above groups should have access by default. Thryduulf (talk) 17:49, 11 February 2025 (UTC)[reply]
    I written up a draft at User:Bunnypranav/Oathauth-ui-general-help, and also posted an edit request at MediaWiki talk:Oathauth-ui-general-help. I am open to anyone editing my sandbox to create a more detailed and descriptive message. ~/Bunnypranav:<ping> 12:34, 12 February 2025 (UTC)[reply]
    Thryduulf, gentle reminder if you would be willing to reconsider your decision, now that the message has been updated. Thanks! ~/Bunnypranav:<ping> 12:22, 27 February 2025 (UTC)[reply]
    Oppose all. Despite the improved message, I'm convinced by the arguments below that the whole system is still not robust enough for casual adoption. It's true that going to meta to make a request is a small, arguably tedious hurdle, but it forces turning on 2FA to be a considered, conscious action which serves to reduce the number of people who will get locked out of their account accidentally. Thryduulf (talk) 14:29, 27 February 2025 (UTC)[reply]
  • Oppose all. There is already insufficient support for those who currently must or may have the WMF 2FA. The software is not yet properly supported, the planned-for upgrades are not yet complete, the documentation for the software is incomplete and not intuitive, and the only people who can turn off 2FA in case of loss of device are the very very small number of people with shell access. None of the roles listed above have the ability to adversely affect any project any more than an average user, unlike those few roles that today are required to have 2FA. Risker (talk) 19:01, 11 February 2025 (UTC)[reply]
    This might sound a bit blunt, but why should WMF care so much about recovering account who lost 2FA. If a user with no email given loses their password, its their own fault, WMF need not take any responsibility it tediously recovering it. Then can try and help, but they are not liable. Also, as SD has said below, the most newbie and non-techie friendly version a 2FA app, at least on android, is Google Authenticator, which drastically minimizes risk of losing by automatically syncing to a google account. Other platforms also offer such easy to use solutions. ~/Bunnypranav:<ping> 12:20, 12 February 2025 (UTC)[reply]
    Because people mess this up all the time, then start using up volunteer and staff time complaining about it. — xaosflux Talk 15:41, 12 February 2025 (UTC)[reply]
    How many people will even take the time and effort to enable 2FA? One has to install an authenticator app (probably with cloud backup enabled by default), scan the code, and enter a verification code from the app before even turning it on. This is not something like I clicked a button and now I'm locked out account level easy to mess up; those people who manage to enable this, and lose access to it should be less than people without an email who lost the password and now did a clean start. We can advise these limited people to do the same as well (fresh start, with a CU verify if they need advanced perms early). ~/Bunnypranav:<ping> 07:29, 13 February 2025 (UTC)[reply]
    Trust me, a shockingly high number of people screw up 2FA. There are 2 solutions to this problem. Either a) we don't care. We put a big warning, and if you mess it up you are permanently locked out. Or b) we decide its acceptable to use a lower level of validation for unprivleged accounts. Something like we send an email and wait 7 days and unlock the account if nobody responds. This defeats some of the point of 2FA, as an attacker can now attack this weaker process, but perhaps is a reasonable compromise. It all comes down to what you want to protect against with 2FA. There is a certain sense that in practise the real thing 2FA protects against is people reusing passwords (credential surfing), because in essence its a fancy password that wikipedia chooses for you. Bawolff (talk) 12:51, 13 February 2025 (UTC)[reply]
    "The software is not yet properly supported, the planned-for upgrades are not yet complete" – as far as I know, and based on ACN's comment at the last discussion, 2FA is not being actively worked on. If we are waiting for upgrades, we will likely be waiting years.
    "None of the roles listed above have the ability to adversely affect any project any more than an average user" – Autopatrolled and NPP can bypass article review processes and are highly coveted by promotional scam rings like Orangemoody, which you should be very familiar with. In my opinion, these groups are, right behind governments, the largest and most organized threat to Wikipedians. Toadspike [Talk] 07:48, 18 February 2025 (UTC)[reply]
  • Oppose all per Risker above. If someone really really wants to test 2FA they can already opt-in after being warned about risks. — xaosflux Talk 19:09, 11 February 2025 (UTC)[reply]
  • Oppose I am an admin and I don't use 2FA. The reason for that is that the implementation is (as Risker says above in far more polite language that me) a pile of crap, and I don't think the devs want an ever-increasing list of people who have managed to lock themselves out. Black Kite (talk) 19:13, 11 February 2025 (UTC)[reply]
  • Support 3–6 Like I mention in the reply below to Risker, a lot of the opposition to 2FA arises out of ignorance of how 2FA works. People seem to assume that the "multitude of commercial and free 2FA software" are incompatible with Wikimedia sites when in fact, they aren't. You can very well use Google Authenticator, Authy, Ente Auth and other 2FA apps with WMF sites – all three of these apps support syncing of your tokens in the cloud, ensuring that even if you lose your device, you can still view tokens using another device. – SD0001 (talk) 12:15, 12 February 2025 (UTC)[reply]
    The real problem is the collision of two situations: (a) many end users are ignorant of how 2FA works technically, and have no idea how to properly manage their recovery codes or backup and restore anything; (b) unlike many other places you may set up 2FA, we don't have good other ways to authenticate someone to aid in helping them recover from their errors in (a), nor a support system to with cycles to do it if they could. — xaosflux Talk 23:29, 12 February 2025 (UTC)[reply]
  • Support all, but from what I understand of the conversation above is that it's not well-implemented. MFA/2FA is great for account security, which is why nearly every service does it. Google can enable it for every user, why shouldn't we? SWinxy (talk) 16:53, 13 February 2025 (UTC)[reply]
    Google can enable it for every user, why shouldn't we? The biggest difference between Google's 2FA and Wikimedia's 2FA is that Google has approaching infinitely better support for those that are locked out of their account due to 2FA than we do, both in terms of number of options and in terms of support bandwidth. Google has multiple options available to establish identity, and literal teams of customer support people who can implement and help. Wikimedia sometimes has an email address, very occasionally has personal knowledge and very little else in terms of options, and rather than dedicated customer support people only a circa single digit number of developers who can implement and help. The difference is comparable to that between a multi-lane highway and a barely used footpath through the woods - both will get you from A to B but that's about where the similarities end. Thryduulf (talk) 18:39, 13 February 2025 (UTC)[reply]
    Google also still gets criticism for permenantly locking people out of their accounts with no recourse. Bawolff (talk) 19:05, 13 February 2025 (UTC)[reply]
  • Option 2 and probably everything else. Serial (speculates here) 19:10, 13 February 2025 (UTC)[reply]
  • Support 3, 4, and 5 based on ACN's comment and ToBeFree's comment, especially "there will be page movers who wouldn't request a global permission for 2FA yet would enable it in their preferences if it was a simple option", at the pagemover discussion. Autopatrolled and NPP are the most coveted userrights to scam rings and other malicious groups targeting Wikipedians. It is ridiculous that a user wishing to use 2FA has to bother a Steward to do so. 2FA is not going to get any better anytime soon, so we may as well encourage folks to start using it now and lower the barriers to doing so.
I am neutral on 1, 2, and 6. I don't think rollbackers need extra security, and while I agree in principle that most users should have access to 2FA I strongly disagree that extended confirmed = "I know what I'm doing". On the other hand, checking a box in your Preferences to activate 2FA does mean you should know what you're doing, and (assuming the explanatory pages are well-written) it's mostly your fault if you screw up. Toadspike [Talk] 07:37, 18 February 2025 (UTC)[reply]
  • Support 2 as optional choice for EC - i see args for technical limitations and user incompetence to be strange. It should not be hard to extend a preexisting system to other users, including those seeking additional protection. Honestly, if its buried as a preference for an account, most folks won't use it. User:Bluethricecreamman (Talk·Contribs) 04:46, 19 February 2025 (UTC)[reply]
  • If you really want 2FA you can just go to Meta and get the requisite user right freely - provided you've understood the risks involved. It would be better and easier to direct users interested in 2FA to go there, IMHO, and make that venue more visible. No need to separately enable 2FA access for a large number of users here - that's redundant, at the least. JavaHurricane 23:24, 20 February 2025 (UTC)[reply]
    The main concern raised is why should people bother to go to meta and request stewards? 2FA/MFA should be allowed by default. ~/Bunnypranav:<ping> 06:44, 21 February 2025 (UTC)[reply]
    Because we actually want people to understand the problems with the current 2FA system that Risker brings up before they get it for themselves. And if it really is a big deal to have to actually click on a link, read through a documentation page and write two lines in a request: well, what do I know. I for my part see this as a solution in search of a problem, and one that may result in users not being aware of the issues by default. And your blunt reply to Risker above is poorly thought: people can lose access to their authenticator app and security codes without any fault of their own, such as purely accidental loss of device, or a change in device, etc. It definitely is the WMF's job to care about if 2FA users can get locked out of their accounts and what should be done in such circumstances. For what it's worth, I had got 2FA for myself but had to turn it off when changing devices because for whatever reason Google Authenticator wouldn't load my Wikimedia 2FA on the new device. JavaHurricane 19:30, 21 February 2025 (UTC)[reply]
    If a person is signing up for a service [MFA], I guess they should be aware of the risks involved and what they're getting into? WMF should not have the job of taking care of users who just like to turn on stuff for the sake of testing it, and then lose their account. If I have to give a comparison, this is like saying you should request someone to be able to add a password to your account, because some people do not know how to save it and lose access to their account (lost password, no email set). If we can entrust saving a password to every user, why can't the same be extended to MFA? After all, it's another password. ~/Bunnypranav:<ping> 07:18, 22 February 2025 (UTC)[reply]
    The flaw in this analogy is that there is no way to "not have a password" or some other authorization credential and still have user accounts be a thing—there must necessarily be some credential for the computer at the other end to request, for you to prove that you are actually User:Example and not, J. Q. Random, or, another computer executing a program to guess passwords and crack into people's accounts. (And of course, as-is, people can edit without any account, subject to some restrictions.)
    This in fact—no accounts—is precisely how Wikipedia was when it first began back in the primeval eons of 2001 on Usemodwiki! There are no user accounts on Usemodwiki; the site is simply world‐writable by all and sundry. "Administrative tasks" such as deleting and blocking were protected behind "the admin password": the way you originally became an admin was, you asked Jimbo on the mailing list and if he approved he emailed you the password. (Have a look at nostalgia:Wiki Administrators.)
    This is the origin of what functions were originally bundled into the "administrator" package. When what became Mediawiki was first written, it essentially just copied the functions of UseMod and that distinction between "regular user" and administrator, only now with actual individual user accounts with password authentication, hooked into the Mediawiki SQL database backend. --Slowking Man (talk) 05:33, 23 February 2025 (UTC)[reply]
    @Slowking Man The analogy seems wrong, but it is actually being done, IRC. Unless you specifically set a password, your nickname is free for anyone to use (Ofcourse I'm not ranting about IRC, it is an example). Same can be extended for my argument about widely available MFA in Wikimedia, like we have a password granted by default to users, why can't we give them the opportunity to get a second password (MFA)? ~/Bunnypranav:<ping> 06:02, 23 February 2025 (UTC)[reply]
    There is a bit of a distinction: In IRC, two clients can't both have the same nick at once. The distinction arises because IRC is a stateful protocol, while HTTP (Web) is stateless. In IRC, servers keep track of which client currently has nick X; in HTTP servers have no concept of "users" or "usernames" or "user X is currently connected to me" (a connection state), anything like that. All that, where it exists, is implemented "on top" of HTTP in the application layer via mechanisms like Web cookies. (Similarly IRC nick "ownership" and authentication are implemented "on top" of IRC—which is a very rudimentary protocol—by adding "network services" like NickServ, which are just "bot" programs that sit on the network as users with superuser powers and (in the case of nicks) kick people off a nick unless they authenticate with the password.)
    The IRC case is actually quite similar to how "anonymous" users work in Mediawiki: because of TCP being stateful and connection-oriented, and IP using globally-unique "public" addresses, two clients can't both have the same IP address at once (analogy: IRC nicks). There can't be a situation where one-half of an edit from 1.2.3.4 is from one person, and the second half of the edit is from a different person on another continent. However IP addresses can be reassigned, so from one edit to the next, 1.2.3.4 can be different people.
    Also, from reading others' comments, my understanding is that 2FA de facto already is available to anyone who wants it? You just have to jump through the hoop of going to Meta and asking for it. --Slowking Man (talk) 17:02, 23 February 2025 (UTC)[reply]
    Also, from reading others' comments, my understanding is that 2FA de facto already is available to anyone who wants it? You just have to jump through the hoop of going to Meta and asking for it.
    Yes, anyone who wants it and isn't in a 2FA group here just needs to:
    1. Know they need to ask at Meta
    2. Ask at Meta
    3. Convince whoever it is at Meta that does the processing of requests that they understand the risks.
    My understanding is that all that is required for 3 is:
    1. Making the request in the right place
    2. Stating that you have read the documentation and/or understand the risks
    3. Not doing/saying something that makes it obvious you don't understand the risks
    Thryduulf (talk) 18:17, 23 February 2025 (UTC)[reply]
    Apologies if I did not get it clear, IRC was just an example with no intentions to get into the nitty-gritties of the tech behind it. Since 2FA is just frame a rationale to stewards that you know what it is and what can be the risks, I proposed that everyone*(EC if option 2, autoconfirmed if option 1) have it by default, with an additional change to the 2FA interface message (MediaWiki:Oathauth-ui-general-help) to clearly indicate the risks. I believe that it should help give the opportunity to help more people to secure their accounts. ~/Bunnypranav:<ping> 12:47, 24 February 2025 (UTC)[reply]
    In re If we can entrust saving a password to every user, why can't the same be extended to MFA?
    We entrust saving a password to every user, and people do lose their accounts this way. However, the difference is that the password works the way people expect, and the 2FA software is ...maybe not quite so likely to meet people's expectations. WhatamIdoing (talk) 19:27, 26 February 2025 (UTC)[reply]
  • Support > 3 provided it is optional, tbh the current defacto granting standard for oauth-testers on meta seems to be "has a pulse and/or has eyes". We are merely going to save folks a trip down to meta with this change. Sohom (talk) 04:50, 21 February 2025 (UTC)[reply]
  • Support 3, 4, 5 and 6 per Toadspike and TBF. Users in these groups are trusted by the community to wield advanced permissions that can do damage in the wrong hands so any argument about incompetence does not convince me, especially after MediaWiki:Oathauth-ui-general-help was updated to mention the risks. If such users want to secure their accounts with 2FA, they shouldn't need to ask anyone for it. Nickps (talk) 16:18, 4 March 2025 (UTC) 6 added on 18:52, 4 March 2025 (UTC)[reply]
    On second thought, supporting 6 as well. While not as dangerous as the others, I think that a user trusted with rollback can be trusted with 2FA as well. Nickps (talk) 18:52, 4 March 2025 (UTC)[reply]
    I don't think 2FA is a trust-based permission. Whether or not someone can use it is determined more by a baseline understanding of the technical risks of using it rather than trust. JJPMaster (she/they) 13:32, 11 March 2025 (UTC)[reply]
    That's not what I'm saying. My point is that editors are expected to be competent. This is even more true for editors holding advanced permissions. Therefore, we shouldn't insult their intelligence by having them tell the stewards that they understand the risks before they gain access. We should just assume they do. Nickps (talk) 13:56, 11 March 2025 (UTC)[reply]
    We expect editors to be competent at editing the encyclopaedia, we do not require them to be competent with poorly supported technologies with risks that are significantly greater than (and significantly different to) anything else you can casually turn on in your settings. Ensuring someone is actively aware of the risks of permanently losing access to their account is not an insult to their intelligence but a proportionate precaution. Thryduulf (talk) 14:28, 11 March 2025 (UTC)[reply]
    anything else you can casually turn on in your settings There's nothing casual about enabling 2FA even if you don't have to ask the stewards for permission. It's an process with multiple steps involving at least 2 different UIs, (WP and the 2FA app). Multiple warnings are given before and during this process. If the user ignores them and gets locked out of their account because of it, it's on them to convince T&S to let them back in. Otherwise, that's a CIR global lock right there. Nickps (talk) 15:49, 11 March 2025 (UTC)[reply]
  • Oppose all, you can already get 2FA tester by just asking the stewards for it, and they'll just ask if you actually read the policy (ie: don't blame us if you screw up 2FA because you didn't read it). I don't think we should really need to make it easier, especially when the only support for being locked out is essentially to convince Trust and Safety/sysadmins that you're the legitimate owner of the account. EggRoll97 (talk) 16:34, 4 March 2025 (UTC)[reply]
  • Oppose all, as the benefits basically consist of a couple fewer requests on SRP and are far outweighed by the massive backlog for T&S/sysadmins that would result. I am not convinced that occasional non-admin compromised accounts pose a major security risk. ⟲ Three Sixty! (talk, edits) 16:07, 11 March 2025 (UTC)[reply]

Discussion (2FA for more groups)

  • "with a registered email" isn't even an available option in this software. If someone wants this, I hope they are ready to write a patch to build it... — xaosflux Talk 19:11, 11 February 2025 (UTC)[reply]
  • Just noting that a lot of people already have non-WMF 2FA in one form or another. For me, it's that I need it to open my password keeper, which I need to do because I have no idea what my passwords for WMF wikis are. So I've already done a 2FA before I even log into my account. There is a multitude of commercial and free 2FA software, much of which is better supported than the WMF variant; if people are really concerned about the security of their account, they should consider that. Or not do things like use public computers or wifi in Starbucks, or choosing easy passwords; account security is ultimately the responsibility of the user. Note that I'm not kicking the WMF on this point; I know that improving this software and ensuring proper "ownership" and ongoing maintenance is very much on their radar, but there's still a lot of work to be done. We do need to keep in mind that the underlying software was created for WMF staff (at the time a much smaller and cohesive group), and it was maintained by volunteers for most of its existence. Risker (talk) 22:50, 11 February 2025 (UTC)[reply]
    There is a multitude of commercial and free 2FA software, much of which is better supported than the WMF variant Please avoid spreading FUD about 2FA. There is no WMF "variant" – Wikimedia uses the same, standard TOTP protocol like most other websites. I have been using 2FA for Wikimedia and other accounts for 5 years and have never faced any issue, nor seen any difference in Wikimedia's implementation as compared to others. – SD0001 (talk) 12:15, 12 February 2025 (UTC)[reply]
    My point is that many people are already using 2FA just to get to their WMF account. Having to then use the WMF 2FA on top of that adds zero security. The WMF requires the use of its own software (what I call the WMF variant) for certain permission types. It is in fact distinct from others, only a very limited number of WMF people are authorized to reset it. This is all well and good for English Wikipedia, but we are the exception. We speak the same language as the primary contacts to get things fixed. Most of the rest of the world doesn't. There is zero security or other benefit for those groups to use 2FA on their WMF account. The project doesn't benefit. The more people who use this particular extension, the more WMF resources are needed to support users who mess up. Given the non-existent security benefit for the websites, that is not good use of our resources. (And yes, I would call the one that I need for my password keeper a variant, just as I would the one I need for Google, and the one I need for two other apps I use. They may use the same principles, but they are all linked to specific functions and are only useful on that one site or group of sites.) Risker (talk) 19:01, 12 February 2025 (UTC)[reply]
    We don't use the term 2FA for anything other than mw:Extension:OATHAuth – doing that would be very confusing. The WMF requires the use of its own software (what I call the WMF variant) for certain permission types. It is in fact distinct from others,... Which permission types? Which software? I don't think what you are referring to has anything to do with this proposal. – SD0001 (talk) 07:23, 13 February 2025 (UTC)[reply]
    You can use any compatible client-side software for this, server-side you obviously have to use that extension. WMF only requires 2FA enrollment for these groups: meta:Category:Global user groups that require two-factor authentication. — xaosflux Talk 09:54, 13 February 2025 (UTC)[reply]
    This is a bit of a pet peeve of mind, but i think we should stop telling people not to use the wifi in starbucks. While that was good advice in 2010, its not really accurate anymore (hsts preload makes pulling off a MITM attack against Wikipedia very difficult even if you are on path). As far as what you're describing with a password manager - that is very good security practise, but would traditionally not be considered a form of 2FA (arguably though the security benefits are mostly the same). Bawolff (talk) 12:34, 13 February 2025 (UTC)[reply]
    Pure technical note: things like password managers are nice, but they don't add any "extra" security to your WMF account—besides encouraging you to use a better password. The password is the only thing that proves your identity as the account owner to WMF's computers, and anyone with it "is you" as far as the computers know and has total control over the account. This is "one-factor authentication": the password is the only thing, factor, needed to authenticate. Calling a password manager "non-WMF 2FA", while I understand where that's coming from, can mislead those not fluent with the concepts. The point of 2FA is that authenticating to the system on the other end, requires you to provide both of those two factors. Just the password by itself isn't sufficient. Hence if a malicious actor guesses or obtains the password, they still can't do anything with it without also obtaining access to that second factor. Analogy: something locked with two locks, keyed to different keys, so that both keys are required to unlock. --Slowking Man (talk) 21:57, 18 February 2025 (UTC)[reply]
  • IMO Option 1 (and maybe Option 2) should, if they gain consensus here, also require global consensus. It wouldn't make much sense for 2FA access to be automatically granted to anyone who makes a few en.wikipedia edits but restricted to advanced permission holders on every other WMF wiki. ⟲ Three Sixty! (talk, edits) 15:58, 13 February 2025 (UTC)[reply]
    Basically, yup. I tried to pass an RFC on meta-wiki to enable for all there, so that you would at least have to make a trip over to a non-content project and read a centralized, translated warning - but it failed to gain consensus. The lack of support is a real problem, but once someone makes it over to metawiki 2FA access is pretty much shall-issue - we mostly only check that a requester says that they read the warning. — xaosflux Talk 16:11, 13 February 2025 (UTC)[reply]
  • A notice for this discussion has been added to Help talk:Two-factor authentication. Nickps (talk) 01:07, 7 March 2025 (UTC)[reply]

Allow file movers to upload files locally that share a name with a file on Commons

TLDR: Grant the File movers group the reupload-shared permission.

Rationale: Currently, only admins have the reupload-shared permission, which allows a user to upload a file here that has the same name as a file on Commons. As a Commons admin, I occasionally delete files there (for being non-free) which are in use here. To move the file here, I have to 1) upload it here under a temporary name, 2) delete the file on Commons, 3) move the file to the correct name here, and then 4) request speedy deletion of the redirect I've left behind. (I prefer not to delete the file on Commons until after I complete the local upload, both because it makes the process of filling out the local upload form easier, and because it means I don't have to undelete the file if the local upload goes wrong). This wastes both my time as the uploader and an admin's time deleting the redirect. When I was discussing file migration options in the admin channel of the Wikimedia Community Discord yesterday, a local admin suggested this idea. reupload-shared and movefile seem to me to require a similar level of trust, and expertise in the same namespace.

  • Support as proposer. The Squirrel Conspiracy (talk) 02:57, 19 February 2025 (UTC)[reply]
  • Support * Pppery * it has begun... 05:50, 19 February 2025 (UTC)[reply]
  • Support ~ 🦝 Shushugah (he/him • talk) 06:24, 19 February 2025 (UTC)[reply]
  • Support, seems to require the same levels of trust/competence. CMD (talk) 07:48, 19 February 2025 (UTC)[reply]
  • Support Sensible idea. -- King of ♥ ♦ ♣ ♠ 08:51, 19 February 2025 (UTC)[reply]
  • Support per nom. Also, would that allow file movers to undo any move made by a file mover, or is another permission needed for that? Chaotic Enby (talk · contribs) 11:04, 19 February 2025 (UTC)[reply]
  • This is a reasonable-sounding usecase, but I can't support it. There are a lot of file movers - this would increase the number of users who can change the main page by almost half - and while I trust most of the usernames there that I recognize, and while I'm sure there's other Commons admins among them who, like Squirrel Conspiracy, I don't recognize, there are several who used to be able to edit the main page but lost that privilege for cause. This risk isn't worth the inconvenience it would mitigate. —Cryptic 11:30, 19 February 2025 (UTC)[reply]
    Maybe this would be technically more difficult to implement, but would there be a way to make it so that cascade-protection prevents reupload-shared? Chaotic Enby (talk · contribs) 11:40, 19 February 2025 (UTC)[reply]
    Or protection of the underlying image at Commons. But both of those are well outside the one-line config change proposed here. —Cryptic 11:47, 19 February 2025 (UTC)[reply]
    That sounds like a bug that should be reported on Phabricator. * Pppery * it has begun... 17:20, 19 February 2025 (UTC)[reply]
  • I kinda worry that this will result in a lot of questionable decisions to put local files over a Commons file. Not all edits to Commons files are bad, in fact, I suspect it's more the other way around. Jo-Jo Eumerus (talk) 14:36, 19 February 2025 (UTC)[reply]
  • Support while noting that I'm the person who suggested this idea. I'm not worried about the main page here, as the images on Commons could already be uploaded-over. I seriously doubt any of our file-movers, even those desyopped for-cause, would use this for vandalism, and if so that could be quickly resolved. As for questionable overwriting decisions, I'd hope and expect that our file-movers would have a good understanding of when files should be local. If this goes poorly, it can be reversed, but it's better than requiring sysop for this task. Elli (talk | contribs) 17:41, 19 February 2025 (UTC)[reply]
  • Support per Elli. charlotte 👸♥ 19:15, 19 February 2025 (UTC)[reply]
  • Support as if file-movers abuse this, they should lose that ability. Graeme Bartlett (talk) 21:47, 19 February 2025 (UTC)[reply]
  • Support, but with conditions. I can't say for sure that the use case the OP has pointed out is the only use case for this permission by file movers, but it should be trivial to add reasonable restrictions to when non-admin filemovers can use this permission, such as "when a file is being deleted from Commons but meets the criteria to be uploaded locally either under enwp policy or non-free use criteria". I would not support non-local-admin filemovers being able to use this permission, for example, to upload local versions of high traffic files, since they by definition can't immediately protect those files and I believe (please point out if I'm wrong) that once it's uploaded, anyone could replace it with a new version pending it being protected which may take some time. -bɜ:ʳkənhɪmez | me | talk to me! 21:51, 19 February 2025 (UTC)[reply]
  • oppose the hassle presented in the proposal is understandable, but it's a relatively rare need AFAIK, especially when contrasted with the huge potential for mistakes and confusion. It looks like this is going to pass, so I hope someone has a regular report ready to ensure we never have a local file with the same name as an extant (not deleted) commons file. — Rhododendrites talk \\ 23:35, 19 February 2025 (UTC)[reply]
  • The Squirrel Conspiracy, how many file movers are also Commons admins and do this kind of work regularly? Could we maybe just make you (and anyone else) an admin here instead? WhatamIdoing (talk) 03:14, 20 February 2025 (UTC)[reply]
    Note that Squirrel Conspiracy (narrowly) failed in the last AELECT. charlotte 👸♥ 05:31, 20 February 2025 (UTC)[reply]
    Oh, that's too bad. I was thinking that having a clear purpose would be a positive thing at RFA. WhatamIdoing (talk) 06:21, 20 February 2025 (UTC)[reply]
    If people here think I have a realistic chance of success going through the conventional route, I'm happy to talk to potential nominators, but I assumed that my lack of recent local activity would be a dealbreaker. The Squirrel Conspiracy (talk) 16:17, 20 February 2025 (UTC)[reply]
    We've made people be admins under similar circumstances in the past, but I don't know how long it's been since the last time. I don't hang out at RFA. WhatamIdoing (talk) 18:01, 20 February 2025 (UTC)[reply]
  • Oppose this is an edge case, and an edge case about another project. We shouldn't be creating shadows-commons files here. This would also override upload-protected files on commons here, by allowing non-admins to just upload local copies. — xaosflux Talk 10:32, 20 February 2025 (UTC)[reply]
  • Support, but there needs to be a bot or other system that flags local files that share names with Commons files so that errors don't slip through the cracks. ꧁Zanahary꧂ 22:27, 20 February 2025 (UTC)[reply]
  • Support. The people saying that this is a rare occurrence are being somewhat optimistic. I track down a lot of copyvios on Commons and unfortunately it's semi-regular for an image to have gone undetected long enough that it gets used in an article by someone well meaning. I didn't know the process to remove them from here was so tedious. Gnomingstuff (talk) 23:39, 21 February 2025 (UTC)[reply]
    Gnomingstuff, it's because there's a EnWiki --> Commons importer, but not a Commons --> EnWiki importer. Ideally we'd have a version of the tool that moved files back out of Commons, but I suspect the volume is low enough or the problem obscure enough that that's why no one has developed such a tool. The Squirrel Conspiracy (talk) 01:09, 22 February 2025 (UTC)[reply]
  • Support for now -- Main page vandalism will be immediately noticed and the person responsible will lose permissions. Vandalism of other pages using this is less of a serious concern. I think this change may have to be reverted if vandalism does turn out to be a problem, but as file movers are approved, I think that Wikipedia should try to give people the level of trust they need to fix the things they want to fix. Mrfoogles (talk) 16:51, 25 February 2025 (UTC)[reply]
  • Support - if there turn out to be more downsides that we expect, we can undo later. The potential amount of damage seems limited enough that I'm not worried about try-it-and-find-out-what-happens. --SarekOfVulcan (talk) 17:26, 25 February 2025 (UTC)[reply]
  • Support. Commons and enwiki have very different policies on copyright, especially with regard to PD in source country. I don't understand why people are saying this is an edge case. Toadspike [Talk] 12:35, 2 March 2025 (UTC)[reply]
    I think it's because it's only a small fraction of files where the difference in copyright matters. I also suspect that in many cases, uploading the file to a different name is a perfectly valid option. Jo-Jo Eumerus (talk) 09:03, 3 March 2025 (UTC)[reply]
  • Oppose While I can understand the frustration, the example given perhaps requires some more targeted technical solution. Permitting all file-movers to re-use filenames already in use on Commons will, in my view, result in:
  • The widespread duplication of files on this project simply because it is convenient to do so, undermining the fundamental principle that media should be hosted on Commons wherever possible. Unless there are compelling technical or legal reasons, we should not be creating shadow versions of Commons files;
  • Errors and confusion, where different files are inadvertently uploaded or moved to a filename already in use on Commons and linked from this project.
It is unrealistic to expect file-movers collectively to have the experience or vigilance to avoid such issues. MichaelMaggs (talk) 10:06, 3 March 2025 (UTC)[reply]
There are only 389 file movers, so I think it is unlikely that any mass duplication will be "widespread". JJPMaster (she/they) 19:14, 3 March 2025 (UTC)[reply]

Time for a new Nutshell Icon?

No consensus has emerged in favour of this proposal, and since opposition to it is unanimous, it walnut be likely to emerge in future. Fortuna, Imperatrix Mundi 17:41, 5 March 2025 (UTC)[reply]

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

Hi, I believe it is time to consider updating the icon used for nutshell to a more contemporary design. The current icon have been in use since 2006, and after 18 years, I am of the opinion that it merit a refresh. Regards Riad Salih (talk) 17:44, 25 February 2025 (UTC)[reply]

It isn't used on very many en.wikipedia pages, but is globally used on quite a few pages, so it seems like your suggestion should take place at the file page on Commons. Schazjmd (talk) 17:53, 25 February 2025 (UTC)[reply]
The other option would be to replace its uses here with a new file (rather than changing the current file), in which case making the suggestion here does make more sense. Chaotic Enby (talk · contribs) 18:14, 25 February 2025 (UTC)[reply]
It's mainly used to summarize all policies, guidelines, and essays so the number isn't too large but not too small either. When changing an icon here, we don't usually open a discussion on Wikimedia Commons since it's used in a template here. Riad Salih (talk) 22:47, 25 February 2025 (UTC)[reply]
What is wrong with the current icon, other than it being old? If you are unable to articulate any specific problems the current design is causing or specific benefits a different design would bring then this just feels like change for the sake of change (c.f. WP:BROKE). Thryduulf (talk) 18:15, 25 February 2025 (UTC)[reply]
The design of Wikipedia evolves over time. If we consistently apply WP:BROKE to all proposed changes, Wikipedia would end up looking like it did in 2001. We simply need a way to insert text, media, and references; nothing more.
I think we are not obligated to retain icons indefinitely, also the design does not align with the OOUI icons developed by Wikimedia. Riad Salih (talk) 22:58, 25 February 2025 (UTC)[reply]
Wikipedia doesn't look like it did in 2001 because we've made changes that have fixed identified problems or otherwise made identifiable improvements. We are indeed not obligated to retain icons indefinitely, but equally we are not required to change icons just because they haven't been changed in a long time. The OOUI icons are user interface icons, which the nutshell icon is not, so that's irrelevant. The actually comparable icons are for things that identify types of content, e.g. featured articles, redirects, disambiguation pages, etc, at least most of which have remained unchanged for decades. So you haven't actually answered the question I asked. Thryduulf (talk) 00:08, 26 February 2025 (UTC)[reply]
I completely agree with you, but I mentioned OOUI icons to explain that continuous improvements are made to icons and appearances here. Regarding the examples you mentioned, if nobody has raised these points for discussion, it doesn't mean they should be used as valid arguments. These finer details often catch the eye of designers or those with a similar background. Personally, I don't see a strong reason to stick with an outdated designed icon. Riad Salih (talk) 00:24, 26 February 2025 (UTC)[reply]
As someone advocating for a change (any change) the onus is on you to explain why the change would be beneficial. You thinking the current icon is "outdated" is the only reason you've even attempted to give, but that's completely irrelevant because we don't do change for the sake of change. We are an encyclopaedia not a graphic design studio, it doesn't matter if we're using "outdated" design language unless changing that design language will bring some benefit for readers and/or editors. Thryduulf (talk) 06:14, 26 February 2025 (UTC)[reply]
We don't have to align with the OOUI icons. Just becuase the trend is to more and more minimalism until we lose all aesthetic grace whatsoever and all logos are coloured circles doesn't mean we have to follow it. Cremastra (talk) 22:20, 3 March 2025 (UTC)[reply]
This definitely isn't significant enough to warrant a post at the Pump. And it'll be more likely to go somewhere if there is a specific proposal for a new icon on the table. Sdkb talk 19:23, 25 February 2025 (UTC)[reply]
The conversation has already started on the template's talk page. I shared it here to gather a variety of opinions. Riad Salih (talk) 00:18, 26 February 2025 (UTC)[reply]
@Riad Salih, for next time, see WP:TALKCENT. We like to centralize discussions in a single place. You can place {{Please see}} notices elsewhere to draw attention to them, but starting the same discussion in multiple places tends to fragment it and create confusion. Sdkb talk 15:59, 26 February 2025 (UTC)[reply]
@Sdkb sure, thanks. Riad Salih (talk) 16:00, 26 February 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to not refer to the children of Donald Trump as simply "Trump" on their articles

Originally posted on Talk:Donald Trump, but I was advised to post it here instead.

Before I start, yes, I am aware that what I am proposing violates Wikipedia's manual of style, however I believe that in this case, an exception is justified.

While I was scanning the article of Tiffany Trump, I encountered the following sentence: "In 2015, Trump worked as an intern for Vogue magazine and, in 2016, modelled for an Andrew Warren fashion show during New York Fashion Week". For a brief moment, I was pretty confused by this, until I realized that "Trump" in this context was referring to Tiffany, and not Donald Trump. I realised that the article on multiple occasions referred to Tiffany as "Trump", as would be typical on any other article per WP:SURNAME. However, this leads to other bizarre statements such as "In summer 2018, while on vacation in Greece with the actress Lindsay Lohan, Trump met Michael Boulos, a Lebanese-American business executive. The pair began a relationship and were married on November 12, 2022, at Mar-a-Lago in Palm Beach, Florida. In October 2024, it was announced that they were expecting their first child together."

While this convention works perfectly fine on most articles, I believe it is problematic on articles pertaining to the children of Donald Trump, as at this point the name "Trump" has become so heavily associated with the president himself that most people will instinctively think of D.J.T. whenever they see simply "Trump" written without a first name, which could lead to confusion, as well as Wikipedia passages potentially being taken out of context (as I have done here). For this reason, I believe it would be best if Wikipedia articles did not refer to Trump's children, or indeed anyone carrying the Trump surname, as simply "Trump", with the exception of D.J.T. himself. While I appreciate that Wikipedia's manual of style is robust, and has been painstakingly developed over the span of many years, all guidelines have exceptions, and I believe that this should be one of them.

As for how it should be handled, I think the best way would be to simply use their first names instead (and append Jr. in the case of Donald Trump Jr.), however I am not explicitly proposing that this is the way it should be handled. My proposal here is simply to stop referring to them as "Trump" alone, and for another convention to be agreed upon. Alex the weeb (talk) 13:44, 1 March 2025 (UTC)[reply]

I disagree that Donald Trump is such an exception as to warrant dropping our guidelines. Surely you didn't think that he had worked for Vogue or married someone called Michael? If I am reading about snooker and see the name "Trump" I think of Judd, not Donald. There is life beyond contemorary American politics. Phil Bridger (talk) 14:13, 1 March 2025 (UTC)[reply]
  • Given that any article on Trump’s children will likely mention their father, and that in the context of articles relating to that family confusion can arise as to which member of the family is being referred to as “Trump”… I agree that we should specify more clearly. This obviously isn’t needed in an article on the snooker player. Blueboar (talk) 14:50, 1 March 2025 (UTC)[reply]
  • After writing several articles about United States first ladies, including Melania Trump, I've found that it's simply not practical to have a clear understandable article using a surname in these cases. If every part of the article goes back and forth mentioning different people with the surname Trump, then it should refer to them by their first names for readability purposes. I recently promoted Edith Roosevelt to featured article with her and her immediate family members referred to by first name, and I believe the article benefits from it. Thebiguglyalien (talk) 🛸 16:48, 1 March 2025 (UTC)[reply]
    I'm not sure we need a policy on this. Perhaps it should be settled on an article by article basis in normal editing discussion. Wehwalt (talk) 16:50, 1 March 2025 (UTC)[reply]
    Note this usage is covered by Wikipedia:Manual of Style/Biography § People with the same surname. isaacl (talk) 16:53, 1 March 2025 (UTC)[reply]
    I see this problem when only one member of the family is famous (or infamous) and the others are only known because of their relative. It's even more awkward in the childhood section where most the people the subject interacts with have the same surname. The max is when a Briton becomes so famous that he's ennobled and from then on everybody calls him by his titular town or other namesake and this is also used in describing childhood activities. General Sir Arthur Wellesley is an example. I would prefer a bit more looseness in such matters, making him "Arthur" as a child, "Wellesley" as a soldier, and "Wellington" in politics. Jim.henderson (talk) 17:13, 1 March 2025 (UTC)[reply]
    The scenario of the commonly used name changing is covered by Wikipedia:Manual of Style/Biography § Subsequent use, which I believe the article follows (I appreciate it doesn't match your personal preference). isaacl (talk) 17:27, 1 March 2025 (UTC)[reply]
    Thing is… as is stated at the top of the guideline page… “occasional exceptions may exist”. The question is: should this be one of those occasional exceptions? Blueboar (talk) 18:20, 1 March 2025 (UTC)[reply]
    I think Wikipedia's guidance (and how the article mostly handles it) seems reasonable: use Wellesley until the event where he gained his title, then use Wellington. I don't see a reason to treat his childhood differently than the childhoods of other people. isaacl (talk) 18:32, 1 March 2025 (UTC)[reply]
  • Of course if an article refers to several people with the same surname we should disambiguate somehow, and first name is an obvious thing to use. My main problems with the OP are with the phrase "or indeed anyone carrying the Trump surname" and the implication that Donald Trump is unique in this regard. Phil Bridger (talk) 18:22, 1 March 2025 (UTC)[reply]
    Trump and Wellington are only two examples of what could be made a more general guideline. I am often confused by unmarried women who only did anything notable after taking her new husband's name, and her biography backdates the name to her girlhood or premarital collaborations. Better to follow the usage of whatever time is being handled in each section, with a notice of each change both in the intro and at the time at happened. Or by a British Ambassador or whatever, who became Baron whatever, and continued doing important things. Jim.henderson (talk) 18:44, 3 March 2025 (UTC)[reply]
My knee-jerk reaction is that there's no reason to treat the Trump-children different in this regard than say John Shakespeare and Tom Shakespeare. Gråbergs Gråa Sång (talk) 19:46, 3 March 2025 (UTC)[reply]
  • This does not have the makings of any kind of "rule", it happens all the time in sections describing families that you write differentiation into the text but let writers be free how they want do so. In general, it remains, if the last mention is Sam Trump than Trump is going to refer to Sam. Also, this is nothing new, even in the United States: Adams, Astor, Rockefeller, Roosevelt, Bush, etc, etc, Alanscottwalker (talk) 20:12, 3 March 2025 (UTC)[reply]
  • I don't really see why this is a thing. Surely this is true for any famous person, and people who share their surname. Should we also not refer to Judd Trump as Trump? Lee Vilenski (talk • contribs) 20:34, 3 March 2025 (UTC)[reply]
  • This shouldn't need a special rule. Everything should be written in a way that is quick to understand and hard to misinterpret. That's just common sense, and outweighs even the manual of style. Where a reader is likely to be confused (to think of Donald when we meant Judd), allow editors the discretion to use whatever name best minimises the risk of misreading. Same goes for other famous names. Elemimele (talk) 15:33, 4 March 2025 (UTC)[reply]
  • I recently had this problem with Gittings family, there are three John Sterett Gittings - the third is a "Jr." because his father had the same name, but the second took his name from the grandfather so is not "Jr." The only way to disambiguate the first and second is (birth-death). I'm all for first name though, particularly in "early life" sections when referring to the mother and fathers life. Convention for primary topic is last name throughout, any ancillary family can use first name, or some other method. -- GreenC 17:47, 4 March 2025 (UTC)[reply]
    You might find a phrase like "the elder Gittings" to be useful on occasion, and for childhood, there's sometimes a family nickname that can be presented (e.g., the man who is called "Junior" his whole life, so you might write about "his grandfather, who was called Junior..."). WhatamIdoing (talk) 04:04, 5 March 2025 (UTC)[reply]
    In the convention I am familiar with, the three John Sterett Gittingses would be JSG, JSG II , and JSG III. Junior would only be used for a son named after a father who was not named for any ancestor. --User:Khajidha (talk) (contributions) 09:16, 8 March 2025 (UTC)[reply]
  • I think this can only be handled on a by-article basis, and it is up to the editors of each article to deal with any possible ambiguities. If there is a paragraph which mentions each of Donald, Donald junior, and Tiffany, the way to handle it is just like that—first names only. In this sort of situation, I think existing guidelines hold good, and it really doesn't matter who Donald Trump is when it comes to preventing ambiguity. The readers come first. Spartathenian (talk) 10:32, 13 March 2025 (UTC)[reply]

Forums?

I think people can talk on a discussion forum whilst contributing to make a free and open-source encyclopedia... We should have two boards, one is related to Wikipedia, and the other one is any topic alike. We may have to change What Wikipedia Is Not, but I find this as a great idea. A editor from mars (talk) 08:08, 4 March 2025 (UTC)[reply]

Changing WP:NOT to allow forums doesn't really have a chance of succeeding, but there are discussions forums around, such as the Wikipedia subreddit, WP:IRC, and WP:Discord, which you may be interested in. CMD (talk) 09:02, 4 March 2025 (UTC)[reply]
And, if you like that sort of thing, Wikipediocracy etc. Gråbergs Gråa Sång (talk) 06:31, 5 March 2025 (UTC)[reply]
The internet has plenty of any-topic forums, reddit, Quora, Twitter, etc. Gråbergs Gråa Sång (talk) 09:17, 4 March 2025 (UTC)[reply]
I know. A editor from mars (talk) 09:18, 4 March 2025 (UTC)[reply]
Why not just use the relevant talk pages, either for articles or for broader topics? If you're looking for general Wikipedia chat, that exists in the usual places like reddit, facebook, etc. If you think we should have some kind of place that's a general "open for any kind of suggestion or proposal" talk page, well, this is it right here. If you're thinking of a more purely social space, hmmm...--Jimbo Wales (talk) 15:04, 7 March 2025 (UTC)[reply]
To your first sentence: because article talk pages fall under WP:NOTFORUM, which is to say that they are intended for discussions that are focused on improving the associated article, not for general discussions on the article's topic. This is a helpful principle to short-circuit a ton of drive-by whinging about a topic that the hypothetical OP doesn't like or agree with, but doesn't care to actually interface with the article about, or attempts to contact the article's subject, or any number of other topics that already clutter up talk pages. Writ Keeper ⚇♔ 15:15, 7 March 2025 (UTC)[reply]

Please see

Please Wikipedia talk:Talk page guidelines#AI for translation and grammar checking. Please comment over there. WhatamIdoing (talk) 03:57, 5 March 2025 (UTC)[reply]

School Block

When schools are blocked indefinitely after kids going ahead and vandalizing multiple times cause its fun or cool, the IP often almost always gets blocked, with account creation blocked. Obviously kids who do want to edit Wikipedia will create an account and kids who vandalize because its just cool generally don't go through the hassle of that. This is why I propose that when Administrators block school IP addresses, they allow people to still create accounts. Of course if vandalism goes on even after a block is imposed through creating accounts, then an administrator can step in and block account creation access. I predict that this argument will spring up, so I will answer it: "Why not just create the account at home and login with it at school?". Well its simple, people might have accounts but they might not want to associate it with the school for safety and technical reasons. Heres an example: If a person is LGBTQ+ and they live in an extremely religious neighborhood which is hostile to the idea of LGBTQ+ and on Wikipedia they have edited heavily on LGBTQ+ topics or they may even identify as LGBTQ+ on their userpage, if they log in to Wikipedia and are caught they can face severe consequences by the community and their parents. Another example is accidentally leaving it logged in while at school, at home this would be fine as your likely using a personal computer, at school however someone can just walk in, see that your logged in to Wikipedia and start to vandalize. This is why having 2 separate accounts, one for school and one for personal reasons can avoid the examples above. DotesConks (talk) 05:23, 12 March 2025 (UTC)[reply]

In that case, I would suggest them to go through Wikipedia:Request an account, which explicitly points to school blocks as one of its relevant use cases. Chaotic Enby (talk · contribs) 09:43, 12 March 2025 (UTC)[reply]
Do you know which schools are blocked indefinitely? Both Wikipedia:Blocking policy#IP address blocks and Wikipedia:Blocking IP addresses#Block lengths indicate that IPs shouldn't be blocked indefinitely. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 03:21, 13 March 2025 (UTC)[reply]

Good Night

We could put a table of acknowledgments of edits also comparing with the page, would that be good? Exxxtrasmall (talk) 05:41, 12 March 2025 (UTC)[reply]

Isn't that what the page history is for? Chaotic Enby (talk · contribs) 09:42, 12 March 2025 (UTC)[reply]
I can't. I prefer to compare non-editor articles with this parameter and not users. Exxxtrasmall (talk) 13:02, 12 March 2025 (UTC)[reply]
Sorry, Exxxtrasmall, but I can't make sense of either your original post or the reply above. Could you elaborate a bit, or say what you want to say in your native language and let the reader translate? Phil Bridger (talk) 13:40, 12 March 2025 (UTC)[reply]
Prefiro a segunda opção como falante nativo de português. Exxxtrasmall (talk) 18:45, 12 March 2025 (UTC)[reply]
I don't know much Portuguese (only a few words I have learnt from friends, mostly Brazilian), but I think that translates to "I prefer the second option as a native Portuguese speaker". Phil Bridger (talk) 19:10, 12 March 2025 (UTC)[reply]
Podia criar uma tabela atualizada por um bot ranqueando as 5000 páginas do domínio principal com mais "thanks log" (agradecimentos em português). Exxxtrasmall (talk) 19:16, 12 March 2025 (UTC)[reply]
You're saying that you'd find it useful to have a way to see a compact list of distinct contributors to an article instead of combing through every one of the thousands of contributions from a few contributors in order to get their names? If you want to get a list of who's contributed to an article instead of a list of every contribution, that's not currently easy to do AFAIK.
Now I'm trying to think of what that might be used for. If I understand your message correctly, your use case is to thank everyone who contributed to an article? (Sorry, I don't speak Portuguese either; just attempting to understand based on French and Latin cognates.) -- Avocado (talk) 22:31, 12 March 2025 (UTC)[reply]
When viewing an article click history, then page statistics, which brings you to something like this that lists contributors. ScottishFinnishRadish (talk) 22:35, 12 March 2025 (UTC)[reply]
TIL -- thank you! -- Avocado (talk) 22:35, 12 March 2025 (UTC)[reply]

Conversion of all-numeric date formats

Hi, all. First, I hope I've come to the right place. This proposal concerns WP:CITESTYLE and WP:DATEVAR, which I understand to be guidelines rather than actual policies. Please point me in the right direction if I've gone astray.

A very useful maintenance aid I've adopted is the 'MOSNUM dates' script written by User:Ohconfucius. Using this has made me aware of inconsistent date formats across a wide range of articles. WP:CITESTYLE rightly says citations within any given article should follow a consistent style. It goes on to deprecate all-numeric date formats with the exception of YYYY-MM-DD. As CITESTYLE says, an all-numeric date can be ambiguous as to which number is the month and which is the day.

I agree with YYYY-MM-DD up to a point, in that it does remove ambiguity for the editor. But, it does not remove it for the reader.

Even if 9 January 2024 (dmy format) appears in United States—or if January 9, 2024 (mdy format) appears in England—a reader of any nationality knows it means the ninth day of January. But, 2024-01-09 remains ambiguous, even if the reader is aware of CITESTYLE and believes YYYY-MM-DD is the only format we use for all-numeric dates. Bear in mind that very few readers will be aware of that and, probably, only a minority of editors too. Also, the reader has no certainty that a numeric value has been input correctly, because the editor might have got their numbers mixed and inadvertently written 2024-01-09 instead of 2024-09-01.

If the name of the month is written, whether as 9 January or January 9, the ambiguity is gone. Then, it's only a question of whether the topic is, for the most part, British or American.

Having said all of that, I do realise there must be some editors who find it easier to type a single numeric format than to choose and write one of dmy or mdy. I am not saying they should cease doing that, because it may create difficulties for them.

Proposal. When an article is reviewed, and to avoid ambiguity, dates should be converted to one of the dmy or mdy formats only, subject to the variety of English in which the article is written. All-numeric dates should be amended, but use of the YYYY-MM-DD format is not prohibited as a means of date input.

To achieve this, we would amend the second paragraph of CITESTYLE to confirm that YYYY-MM-DD remains an acceptable informat, but that it is subject to conversion when the article is reviewed, so that the outformat becomes either dmy or mdy. Furthermore, to ensure a smooth process, we would amend WP:DATEVAR so that it endorses reformatting of all-numeric dates to one of the dmy or mdy formats. Spartathenian (talk) 14:16, 12 March 2025 (UTC)[reply]

  • Oppose as WP:CREEP. I do sometimes change YYY-MM-DD to dmy or mdy depending on the established style of the article, but I just do not see the necessity of mandating the change. - Donald Albury 14:47, 12 March 2025 (UTC)[reply]
  • Oppose except if automatic conversion can be done by a bot. Many tools such as WP:ProveIt automatically generate YYYY-MM-DD dates, and it would be an added burden for new page reviewers to have to change them each time, especially given the already increasing backlog of articles to review. Noting that "converting dates to a consistent format" is not even, currently, a requirement for marking an article as reviewed. (edit 12:48, 13 March 2025 (UTC): striking the bot idea per Jc3s5h) Chaotic Enby (talk · contribs) 15:15, 12 March 2025 (UTC)[reply]
    I agree it would be ideal if a bot could do the job. Thanks. Spartathenian (talk) 15:48, 12 March 2025 (UTC)[reply]
    Striking this as a bot would be indiscriminate, and I now accept that some types of article do require the YYYY-MM-DD format. Spartathenian (talk) 12:43, 13 March 2025 (UTC)[reply]
  • Oppose. YYYY-MM-DD AKA ISO 8601 is not ambiguous ("The standard provides a well-defined, unambiguous method of representing calendar dates and times in worldwide communications"), and indeed is the only correct format in some contexts. Date formats should be consistent in the prose (except where date formats are the subject of discussion, direct quotes, etc) and consistency of citation date formatting is a nice to have, but YYYY-MM-DD needs to remain one of the allowed formats. Thryduulf (talk) 16:23, 12 March 2025 (UTC)[reply]
    The Wikipedia article "ISO 8601", like all other Wikipedia articles, is not a reliable source. It would be rare indeed that ISO 8601 would be the only correct format in a Wikipedia article, if it's visible to the reader. Jc3s5h (talk) 12:18, 13 March 2025 (UTC)[reply]
  • Comment. These are fair points, but I get the impression you think I'm advocating compulsory conversion. I'm suggesting "should", not "must", so conversion is at the reviewer's discretion. If that is the de facto case already, I think we need to tighten the guidelines to make clear that the reviewer does have that discretion, as when using the 'MOSNUM dates' script. Thanks for taking part, all. Spartathenian (talk) 09:33, 13 March 2025 (UTC)[reply]
  • Oppose, YYYY-MM-DD is not only an ISO standard, it is commonly used in some countries, albeit likely due to word order in a non-English language. It is not really ambiguous, when is YYYY-DD-MM used? It may be unfamiliar to some readers, but I don't agree unfamiliarity necessitates depreciation. CMD (talk) 10:25, 13 March 2025 (UTC)[reply]
  • Does anyone anywhere use YYYY-DD-MM? Otherwise I can't really see a reasonable possibility for confusion with YYYY-MM-DD. – Joe (talk) 11:52, 13 March 2025 (UTC)[reply]
    Hi, Joe, it's more a case of what readers know about formats. Someone might see 2024-03-12 and it may not be obvious to them that it means March last year, so they wonder if the event or action was in December. My concern is removing possible ambiguity, but I'm happy to accept YYYY-MM-DD where it is necessary as a standard format, as seems to be the case in some types of article. Perhaps we should be focusing on articles where it is not a necessary format? Thanks for your reply which is a good point. Spartathenian (talk) 12:06, 13 March 2025 (UTC)[reply]
  • Strongly oppose conversion with a bot. I also use the script written by Ohconfucius, and it has fewer errors than any date-related bot or template I've seen, but it still requires manual supervision to spot errors it makes. Jc3s5h (talk) 12:22, 13 March 2025 (UTC)[reply]
    Hi, Jc3s5h. I agree, now, that we can't have a bot doing it, and I've struck my earlier comment. Due diligence is still necessary when using any kind of utility. Spartathenian (talk) 12:48, 13 March 2025 (UTC)[reply]

Idea lab

What do we want on the front page?

A recent RfC was closed with the suggestion that in six months an RfC be held on whether or not to abolish In The News. We could, of course, just abolish ITN without replacing it. However, I wonder if rather than asking "abolish ITN? yes/no" as the survey we might find consensus with "On the front page do we want a section for: In the news or X?" in a way that we wouldn't if we just discuss about abolishing ITN. Looking at some other projects things that I see on their front pages in roughly the place of ITN on ours are a featured image and information about how to participate. But I'm guessing there might be other ideas? And is this concept even a good one rather than the binary abolish/not? Best, Barkeep49 (talk) 22:51, 3 February 2025 (UTC)[reply]

I honestly think that we should revisit the two proposed amendments which were derailed by the added "abolish ITN" option. The close did find consensus against the nominated forms of the proposals though, so I'm not sure if re-asking these questions would be disruptive.
On replacing ITN, we could replace just the blurbs and the title with "Current events"—the newest blurb for each category, with 2 blurbs in a category if needed. (In practice, this will probably mean armed conflicts will have 2 blurbs most of the time and occasionally another category will have 2 blurbs.) Other possible replacements include a short introduction like simplewiki, a blurbed version of Wikipedia:Top 25 Report, {{tip of the day}}, a WikiProject spotlight, and perhaps the WP:Signpost headlines. Looking at all these, perhaps Current events is the only way we can preserve the innocent Current events portal and Recent deaths... Aaron Liu (talk) 23:20, 3 February 2025 (UTC)[reply]
Or we could, I dunno, list recent deaths whenever "deaths in <year>" pops up under Top25. Aaron Liu (talk) 23:28, 3 February 2025 (UTC)[reply]
These suggests strike me as ways of "fixing" ITN (in quotes because I think some argue it doesn't need fixing?) rather than saying what is a different way we could use that mainpage space (which was my hope in this section). I found it interesting and not what I'd have initially thought that the closers felt abolishing was more likely to get consensus than some other form of fixing ITN as the two proposals that were on the table both had consensus against. I'm not sure what the value would be in revisiting either of those so soon. Best, Barkeep49 (talk) 16:17, 4 February 2025 (UTC)[reply]
I did talk about ways to replace the space in my second paragraph and beyond. What do you think of those?

I'm not sure what the value would be in revisiting either of those so soon.

There was a lack of discussion and engagement regarding the fixing proposals after option 3 was introduced. I have had quite a few counterarguments that weren't addressed by newer !votes repeating the previous arguments. Maybe we could just split the RfC into separate, isolated sections. We could also change the proposals to be alternate qualification routes inserted. Aaron Liu (talk) 17:31, 4 February 2025 (UTC)[reply]
Anything featured on the main page needs to be representative of the quality of work that WP can produce, so a blind inclusion from something like Current Events is very much unlikely to always feature quality articles. — Masem (t) 05:04, 5 February 2025 (UTC)[reply]
Makes sense. I guess that also eliminates the "Top 25 Report" option. Aaron Liu (talk) 12:38, 5 February 2025 (UTC)[reply]
I don't agree that everything on the Main Page needs to be "representative of the quality of work that WP can produce", where what we "can" do means "the best we can do". I think we should emphasize timely and relevant articles even when they are underdeveloped. WhatamIdoing (talk) 22:48, 6 February 2025 (UTC)[reply]
In the case of articles about current events, the quality seen on ITN postings often approximates the best that can be achieved. GA, let alone FA, requires a stable article and that is simply not possible when the thing we are writing about is not stable. Obviously not every ITN post is of the same quality, but then the existence of FAR shows that not every FA is of the same quality. Thryduulf (talk) 22:54, 6 February 2025 (UTC)[reply]
Yeah, apart from TFA I really don't get the impression that any of the Main Page sections actually are showcasing particularly "high-quality" articles, but rather represent what the average reader would expect to see with any topic that has received above-average editorial attention. Merely meeting the core requirements of V, NPOV, and OR isn't "the best we have to offer", it's just the minimum we feel comfortable advertising so publicly. JoelleJay (talk) 23:19, 20 February 2025 (UTC)[reply]
ITN was set up in reaction to how well an article about 9/11 came together when that happened, and not just a breaking news article but at least writing towards an encyclopedic style. We've done similar with more recent examples such as 2024 South Korean martial law crisis or back when Jan 6 was happening. Importantly all within a few hours of the onset of these events it was immediately clear they would be topics that meet NEVENT and had long term significance, so their posting to ITN was in part that they showed clear quality including notability concerns.
What's been happening far more recently is that editors are writing articles on minor news stories without clear long-term significance (such as traffic accidents that happen to have a larger loss of life), and then trying to nominate those as ITN. The problem is that in the bigger picture of NOTNEWS and NEVENT, most of those are not suitable encyclopedic topics, and because they lack the encyclopedic weight, the articles read more like news coverage than encyclopedic coverage. Thus the quality issues are compounded by both notability (for purposes of an encyclopedic) and writing style (more proseline than narrative). There is a need to address the NOTNEWS issue as a whole as it has longterm problems across the entire encyclopedia, but for ITN, we need to be more wary of that stuff. But if there is a good change the news event will have longevity, and we know similar events in the past have generally proven to be good encyclopedic articles, as the case for most commercial airplane accidents and major hurricans/typhoons, then the quality check should be to be assured that the article is moving towards what is eventually expected, but definitely does not need to be super high quality.
Its far easier when we are dealing with ITN stories that involve an update to an existing article, which is where most of the recurring ITN topics (at ITNR) make sense, since quality should have already been worked on before the known recurring event occurs. Similarly, when we do blurbs for recent deaths, quality of the bio page should be very high to even consider a topic for a blurb (we get complained at alot of times for not promoting "famous" people's death to blurbs, but often this is a quality factor related to their bio page like filmographies). — Masem (t) 13:37, 21 February 2025 (UTC)[reply]
I've always liked the {{tip of the day}} concept, in order to get more of our readers to make the jump to editing. Otherwise, something as simple as moving WP:POTD up could be a "band-aid" solution, but I would certainly prefer trying something new rather than just shuffling our sections around. Chaotic Enby (talk · contribs) 17:00, 4 February 2025 (UTC)[reply]
POTD needs more space than ITN has. Aaron Liu (talk) 17:27, 4 February 2025 (UTC)[reply]
  • The main page juggles a lot of tasks, but they can be boiled down to editor retention, reader engagement, and editor recruitment. Most of the main page has long been about showing off our best or most interesting work (reader engagement), and giving a sort of reward to encourage editors (editor retention). Hitting the front page requires dedication, and also a little bit of luck, which really helps with gamification of our work--and that's a good thing! Knowing that I could get something I did on the front page was and remains a major motivation to contribute. I think DYK and FA are currently perfect. If we could come up with a new stream of quality content to hit the front page, that'd be awesome, but perhaps a bit pie in the sky. If we had to replace ITN with DYK, I wouldn't lose much sleep. If we replaced it with OTD, I would want to see the OTD process reformed to encourage higher quality entries. However, that brings up the last, perhaps less frequently considered point of the front page: editor recruitment. I'd be interested to see some data on how much new editor traffic is created from articles that hit the front page. CaptainEek Edits Ho Cap'n!⚓ 17:17, 4 February 2025 (UTC)[reply]
I'll add the suggestions I've raised previously:
  • The best option in my opinion would be an "Intro to Wikipedia" box: a brief explanation of what anyone can edit means, some links to help with the basics of editing, and maybe a tip of the day as suggested by Chaotic Enby above. This might also subsume what currently exists as "Other areas of Wikipedia" toward the bottom of the main page. Editor recruitment is paramount, and something like this could help.
  • We could feature more content with "Today's Good Articles". This would function similarly to TFA, but instead of a full paragraph it would be a bulleted list of ~6 GAs and their short descriptions. We have over 40,000 GAs, so just those alone give us enough material for 20 years, let alone everything promoted in that time.
  • We could add a portal hub with icons that link to the main portals. I'm a little more hesitant about this one given the track record for portals, but I have a hunch that they'd be more useful if we gave them front-and-center attention. The current events portal has a subtle link to it on ITN, and it gets a ridiculous number of page views. There's been talk of Wikipedia's identity in the AI age, and a renewed focus on browsing could be part of that.
  • We could have a display for recently updated articles. This is cheating a little since it's kind of an ITN reform, but a brief list of high quality previously-existing articles that have received substantial updates based on new sources would be more useful than a list of news articles.
Even if there's no consensus to replace ITN, I strongly believe Wikipedia would benefit if we added one or more of these somewhere on the main page. Thebiguglyalien (talk) 17:35, 4 February 2025 (UTC)[reply]
The display for recently updated articles is what DYK is supposed to be, right? CapitalSasha ~ talk 17:46, 4 February 2025 (UTC)[reply]
That's more for new content, such as newly created pages or stubs that got expanded. I'm picturing already-written articles that get large additions based on new developments. It's at the bottom of my list for a reason though, these are in the order of how viable or useful I think they are. Thebiguglyalien (talk) 17:50, 4 February 2025 (UTC)[reply]
I'm partial to the Today's Good Articles box, since I think GAs don't get enough love. Although of course a GA promotion is a DYK qualifying event, so there is some overlap. With the downfall of featured portals, I don't think portals are exactly what we want to be showing off. CaptainEek Edits Ho Cap'n!⚓ 18:03, 4 February 2025 (UTC)[reply]
I'd support replacing ITN with either DYK or Today's Good Articles. SilverTiger12 (talk) 18:08, 4 February 2025 (UTC)[reply]
Another idea would be a “Can you help improve these articles?” Section… each week we nominate a few underdeveloped articles and highlight them for improvement by the community. Not a replacement for draftspace or New Article patrol … for articles after that. Blueboar (talk) 18:40, 4 February 2025 (UTC)[reply]
Asking unacquainted readership to make substantial improvements is a bad idea. Aaron Liu (talk) 19:44, 4 February 2025 (UTC)[reply]
The goal would be to highlight articles for the benefit of experienced editors who are acquainted with the topics, but may not know that a particular article (within their field of expertise) needs work. Blueboar (talk) 02:17, 5 February 2025 (UTC)[reply]
This sounds like WikiProject article improvement drives. Thryduulf (talk) 02:50, 5 February 2025 (UTC)[reply]
Unfortunately, most of our wikiprojects are moribund. Most no longer do article improvement drives. So why not shift that concept to the main page? Blueboar (talk) 12:01, 5 February 2025 (UTC)[reply]
This section header asks "what do we want on the front page", but "we" do not include casual readers or non-editors. Would they really want us to replace ITN with a boring "Please help out with these articles" type of box? Besides, when new people sign up to edit Wikipedia, I believe there's a feature already recommending them articles that need improvement, see Newcomer tasks. Some1 (talk) 12:13, 5 February 2025 (UTC)[reply]
I agree that we should be taking the desires of non-editing readers into account. WhatamIdoing (talk) 22:48, 6 February 2025 (UTC)[reply]
The main page does not filter out non-experienced editors. Aaron Liu (talk) 12:39, 5 February 2025 (UTC)[reply]
It could; we can selectively hide any content from logged-out editors. WhatamIdoing (talk) 22:49, 6 February 2025 (UTC)[reply]
Then what should we display for logged-out editors? Aaron Liu (talk) 02:29, 7 February 2025 (UTC)[reply]
I assume that the logged-out editors would like to see Wikipedia:In the news, but if we don't want to have that, then we could leave it blank. WhatamIdoing (talk) 03:46, 9 February 2025 (UTC)[reply]
As we discussed last year, Wikipedia:Articles for improvement used to have a section on the main page, but it was removed after its trial was considered unsuccessful, as there were few new editors making edits to the highlighted articles. I suggest working with that WikiProject on the feasibility and potential cost/benefit ratio of having a corresponding section on the main page. It could also be something to consider for user home pages, which has a specific intent of suggesting tasks for new users. isaacl (talk) 04:48, 5 February 2025 (UTC)[reply]
Could we do GAs but on a certain topic, using WikiProjects? So for instance if you get 3 GA articles (or another number) tagged for WP:Literature, it gets added to the queue for the main page much like with DYK. If the article has multiple tags, nominator of the GA chooses which WikiProject they want it to be part of. A big benefit of this is that it could revive interest in WikiProjects and give people a common mission that isn’t just vaguely improving Wikipedia’s coverage. Perhaps the display would have the topic at the top, which would link to the WikiProject, and then the three or so articles below maybe with excerpts. Basically something that fostered collaboration, improved collegiality etc. Kowal2701 (talk) 19:51, 4 February 2025 (UTC)[reply]
There are good topics. That's an intriguing concept for me. Between good topics and featured topics there are just under 700 potential topics. That's close to two years of topics to rotate through and if we put it on the front page I can't help but think we'd get more of these made. Best, Barkeep49 (talk) 22:18, 4 February 2025 (UTC)[reply]
I also like that idea! A neat way to emphasize good articles without it being either DYK or "today's good article". Chaotic Enby (talk · contribs) 22:29, 4 February 2025 (UTC)[reply]
We might have 365 days x 20 years of GAs listed at the moment, but if we don't resolve the fundamental disagreement about whether the Main Page can offer links to imperfect content, then we're just replacing "Get rid of ITN because it has so many WP:ERRORS" with "Get rid of GA because it has so many WP:ERRORS".
One of the things that seems to surprise folks is that GA is literally one person's opinion. There's a list of criteria, and one single, solitary editor unilaterally decides whether the article meets with the listed criteria. The most important criteria are largely subjective (e.g., "well written") and therefore something editors can and do disagree about. Most reviewers aren't especially knowledgeable about the subject matter, and therefore they will not notice some errors or omissions. In other words, while GAs are generally decent articles, a critical eye can and will find many things to complain about.
IMO people either need to decide that imperfect content is permissible on the Main Page (and thus quit complaining about how other people have sullied the perfection and ruined our reputation), or that imperfect content is not permissible (and thus get rid of everything except featured content). WhatamIdoing (talk) 05:27, 5 February 2025 (UTC)[reply]
I'm not sure where the WP:ERRORS thing is coming from, because that's not at all why there's such widespread dissatisfaction with ITN. You're also saying that a system that promotes GAs to the main page wouldn't work despite DYK doing exactly that for years. Thebiguglyalien (talk) 05:57, 5 February 2025 (UTC)[reply]
One of the persistent complaints about ITN is that the articles aren't Wikipedia's finest quality. This complaint is also leveled against DYK entries, sometimes including GAs. WhatamIdoing (talk) 06:21, 5 February 2025 (UTC)[reply]
Not sure where GAs come in in all of this. If anything, GA quality is the least controversial thing about DYK, with complaints usually centering around misleading blurbs or recently created articles of mediocre quality.
Our threshold for ITN/DYKNEW quality is way lower than GA, and it doesn't really follow that GAs would have the same quality issues. Lumping GAs alongside ITN/DYK issues as "imperfect content on the Main Page" is oversimplifying the situation. Chaotic Enby (talk · contribs) 10:24, 5 February 2025 (UTC)[reply]
WAID is correct in saying that with GAs, "one single, solitary editor unilaterally decides whether the article meets with the listed criteria" (see Talk:I-No/GA1 for example). The quality of GAs are subjective, the same way the quality of ITN/DYK, etc. articles are. Some1 (talk) 12:21, 5 February 2025 (UTC)[reply]
One of the persistent complaints about ITN is that the articles aren't Wikipedia's finest quality: I don't think many are expecting finest. Are there example threads? ITN is already an editing drive of sorts to meet WP:ITNQUALITY. —Bagumba (talk) 08:39, 7 February 2025 (UTC)[reply]
A few people[5][6] who supported the "abolishment" of ITN at the RfC argued that the main page should only feature "high quality" content. Some1 (talk) 12:41, 7 February 2025 (UTC)[reply]
Much less. Phil Bridger (talk) 20:47, 4 February 2025 (UTC)[reply]
  • However, I wonder if rather than asking "abolish ITN? yes/no" as the survey we might find consensus with "On the front page do we want a section for: In the news or X?" Why ITN vs [X]? What if editors want to keep ITN and replace another section on the main page such as DYK with something else? Any future RfCs regarding the potential removal of ITN from the MP should initially and explicitly ask whether editors want ITN removed or not (a "binary abolish/not?" sort of question).
    We could also go the more general, less ITN-focused route and ask the question you just asked in the heading: "What do we want on the front page?" and in that RfC, provide multiple options, such as ITN, DYK, OTD, TFA, [and any new ideas that people have]; then have the community choose their favorites or rank the choices. Some1 (talk) 00:44, 5 February 2025 (UTC)[reply]
  • I like both the "learn to edit" and "good topics", but given the appalling deficit of editor recruitment on the main page, the former is my decided preference. Cremastra (talk) 00:39, 5 February 2025 (UTC)[reply]
  • If we are going to remove it we shouldn’t replace it with anything, there isn’t anything else that won’t have just as many problems as ITN. PARAKANYAA (talk) 04:01, 5 February 2025 (UTC)[reply]
    A static box as an introduction to editing? Aaron Liu (talk) 12:50, 5 February 2025 (UTC)[reply]
    I am very opposed to that idea. It's just not main page type content. No matter what we put on the main page it should be showing stuff, not begging/pleading for more editors. PARAKANYAA (talk) 18:17, 5 February 2025 (UTC)[reply]
    Why not a simple explanation of the pillars? I could say it features some of our best projectspace work. Aaron Liu (talk) 18:26, 5 February 2025 (UTC)[reply]
    How exactly then are we supposed to continue to attract new editors? Cremastra (talk) 20:46, 5 February 2025 (UTC)[reply]
    In my opinion, part of this exercise should be reconsidering what "main page type content" actually means. Thebiguglyalien (talk) 21:14, 5 February 2025 (UTC)[reply]
  • I looked at page views being driven by the Main Page, using the list of recent deaths from mid-December (the latest data in Wikinav). https://wikinav.toolforge.org/?language=en&title=John_Fraser_Hart is a typical example. Most of the page views for that article came from the link on the Main Page. This makes me wonder whether the question about "What do we want on the front page?" should be interpreted as "What 'categories' or 'departments' do we want?" (e.g., a box dedicated to WP:GAs) vs "What purposes do we believe the Main Page should serve?" (e.g., helping readers find the articles they want to read). I think that ultimately, no amount of rearranging the deck chairs is going to solve the fundamental problem, which is that we need the community to decide whether the Main Page is only for WP:PERFECT content, or whether the Main Page is for WP:IMPERFECT content, too. WhatamIdoing (talk) 05:15, 5 February 2025 (UTC)[reply]
    One of the more common positives of Wikipedia that RSs bring up is the speed and neutrality with which it covers even contentious current events topics. I would say that ITN does reflect the best of Wikipedia in a sense, even if the exact process needs revamping. -- Patar knight - chat/contributions 06:36, 5 February 2025 (UTC)[reply]
    I agree, and apparently our readers agree, too. Current events are one of the places where we shine – some of "the best", just not always "the most polished". WhatamIdoing (talk) 22:51, 6 February 2025 (UTC)[reply]
    It's not "Perfect", it's "quality enough". Very few people !voted option 3 due to perceived quality issues. Aaron Liu (talk) 02:30, 7 February 2025 (UTC)[reply]
  • This is not meant as an idea to replace ITN, but the top box on the main page is extremely sparse compared to any other Wikimedia project page. The top box should serve better as a welcome box to WP for any incoming link so should feature a search bar, links to the key pages about how to contribute to WP, and other similar links. The closest info for that is buried near the bottom of the current main page. --Masem (t) 05:18, 5 February 2025 (UTC)[reply]
    The search bar is at the top of the page. I do think it would be helpful to add at least a more explicit sign-up link or something. We already advertise that anyone can edit, which is sort of an WP:EASTEREGG link to an introduction page, and the number of editors. -- Patar knight - chat/contributions 06:41, 5 February 2025 (UTC)[reply]
  • You know what I'd love? Some widget that features articles on topics from around the globe. Maybe a map with a promoted article for each country, with irregular turnover (so that Burundi isn't expected to have the same frequency of front page-worthy articles as France does). The promotion could be handled by each country's wikiproject ꧁Zanahary꧂ 22:49, 11 February 2025 (UTC)[reply]
    Would love to see something done with WikiProjects. Even if ITN is kept, just get the featured list segment to budge up and introduce a new one Kowal2701 (talk) 23:05, 11 February 2025 (UTC)[reply]
    They're such a great idea—obviously, people will be more motivated to contribute to Wikipedia if they feel they have a community of other active editors passionate about the same topics as them. But they're totally out of reach for inexperienced editors, and the space for that valuable and enticing discussion is tucked in the talk pages of projectspace pages. ꧁Zanahary꧂ 23:24, 11 February 2025 (UTC)[reply]
    Also, I second calls for some feature showing articles that are trending or the top viewed for a certain period. It's one of the unique features of Wikipedia that we can stay up to date on new things. ITN does a more flawed and complicated job at this than a trending module would. ꧁Zanahary꧂ 01:51, 6 March 2025 (UTC)[reply]
    I share Masem's concern that we should make sure the main page features work of some quality. Aaron Liu (talk) 03:08, 6 March 2025 (UTC)[reply]
    The ITN process often responds to new stories by motivating a rapid effort to improve relevant articles as quickly as possible. I believe the same would happen for the top-viewed articles. ꧁Zanahary꧂ 03:14, 6 March 2025 (UTC)[reply]
    But on ITN, the articles have to be improved to a certain quality before they are on the main page. Quite a bit of the most viewed articles would fail ITN for quality. Without an actual nomination process or "risk" of the article not being featured, there's way less motivation to improve the articles. Aaron Liu (talk) 14:12, 6 March 2025 (UTC)[reply]
    Maybe then, there can be a buffer wherein articles are not featured until they meet a quality greenlight. I think it would move fairly quickly, since highly-viewed articles often have a lot of eyes on them to begin with. ꧁Zanahary꧂ 14:37, 6 March 2025 (UTC)[reply]
First of all we need a foody-section,
plants Taraxacum, dishes Lentil soup, environment Kitchen; Ecoregions in Poland, Gordon Ramsay, useful animal for hobby garden Mandarin duck, drinks Sake, Cherry-Banana-Juice, cocktails White Russian (cocktail), edible or non-edible grasshopper? which cocktail glass? Spatula lot's of history there; probably enough content on "potato" alone to get a whole month full - also I admit I am hungry while writing this
second, Random Article just generally bigger and better;
I remember some nights just smashing on the random button article, it was great fun and I wasn't depressed
On English Wikipedia, the amount of informative articles; e.g. some historical figure, concepts, buildings etc. i would get was fairly low compared to German random articles, (I just tried that again and I hit warhammer 40k and Monsters Inside me, these are tier A hits for me) but I thought someone could make a filter: I want to read a random article, but it has to be say about 16th century polish history or only articles with keywords plants+south america, or music related but not mexico, full random but in English or French
third, Moving Text
I see that the main page is meant to be lean and clean and non-distracting, but this is the 21st century, at least we need a (lean and clean) 90s moving text banner, better-yet an RSS feed that I can sync to my Divoom (hey look which article is missing) even better: you make your own little informative reading screen I can put on my wall.
fourth, The News
i don't see whats wrong about the news at all (other than it is likely a lot of work) and agree it is best to feature high quality articles over sloppy or hastily established singular-event articles, especially regarding Wikipedias high standard on sources and citations
lastly, Spotlight List
Where are the lists at? Qdajet22 (talk) 01:41, 6 March 2025 (UTC)[reply]
Why a food section? In my opinion, we first of all need a leech section: a FA article, a GA or two, and then so other other... common ... species –— the big orders, Rhynchobdellida and Arhynchobdellida, and then a "featured family of the month". Cremastra (talk) 02:04, 6 March 2025 (UTC)[reply]
An Android app screenshot from 2023
  • The Featured Picture would be a natural replacement for the ITN top right slot on the desktop view. Having a prominent picture at top right is our standard look and the featured picture is a logical complement to the featured article.
Otherwise, to see other existing possibilities then try using one of the Official apps. The Android app provides the following sections:
  1. Featured article
  2. Top read (daily most-viewed articles)
  3. Places (nearby articles based on the current location)
  4. Picture of the Day (from Commons)
  5. Because you read (suggestions based on a recently read article from your history)
  6. In the news
  7. On this day
  8. Randomizer (a random article with some filtering for quality)
  9. Suggested edits (suggestions to add content to Wikipedia)
And what's nice is that you can turn these sections on or off in your settings to customize the feed.
Andrew🐉(talk) 09:56, 6 February 2025 (UTC)[reply]
I love the top read module in this screenshot. We should implement that! ꧁Zanahary꧂ 01:52, 6 March 2025 (UTC)[reply]

Front‽ Hah! Neither Google nor Bing, nor anyone pointing to Wikipedia for some reason, have taken me anywhere near it in decades. And none of the people who print Wikipedia into books and YouTube videos ever include it.

Whatever you do to it, though, it's probably best not to replace it with things from Project:Community portal, which is there for the potential editors in project space as opposed to the potential readers in article space. Whereever one may go when it comes to the content quality rules, the "main page" being article content as opposed to project content still remains as a distinction.

Unless you want to take the drastic step, which some wikis (e.g. German, Spanish, and Polish Wikipedias — de:Project:Hauptseite, es:Project:Portada, pl:Project:Strona główna) do take, which is to set the MediaWiki:Mainpage as somewhere outwith article space (vide de:MediaWiki:Mainpage). But then MediaWiki still has a distinct page (set at MediaWiki:Portal-url) for the "community" rather than for the readership.

Uncle G (talk) 07:28, 8 February 2025 (UTC)[reply]

  • There's quite a bit of users who commented in the ITN RfC that they found the box useful, so they must have checked the main page somewhat frequently.
    Main Page is in the article namespace solely because of inertia (from having too many links to it and stuff) and not because it's article content. And the Community portal only links to community forums, which is not what the "introduction to editing" suggestion entails. Aaron Liu (talk) 14:23, 8 February 2025 (UTC)[reply]
    • Hence why I said "drastic". However, it is article content. If it weren't, we wouldn't be having all of these discussions about how it should be the best example of our article content, or whether it should satisfy our Wikipedia is not a newspaper article content policy, or whether (if it is exempt from policy, a huge double-standard given everything else on the main page) it should be more like a real newspaper rather than an obituaries column. (Only 2 death notices, as I type this.)

      The best response to that question is to ask where, in amongst the DYK snippets from articles, the featured articles, the featured pictures, the snippets from the almanac pages, and the featured lists, does the questioner see the non-article content that leads xem to think that it isn't chock full of article content. It's a good question to ask why it's in article space, given that clearly it doesn't have to be and almost none of the ways in which Wikipedia gets re-used ever use it. It's not a good question to argue from the premise that it isn't article content, though. I wonder how many people really have, or whether that's been phrased as a straw man.

      Uncle G (talk) 13:19, 10 February 2025 (UTC)[reply]

  • Yes, the main page is checked quite frequently. It was the most viewed page in January actually - and had over 4.9 million views yesterday alone… ✈ mike_gigs talkcontribs 21:45, 8 February 2025 (UTC)[reply]
    • That's almost certainly bogus, since the $wgMainPageIsDomainRoot setting is turned on for Wikipedia and the sidebar hyperlink is not nofollow for starters. Notice how things are very different for the Wikimedia App, where one has to deliberately choose to go to the main page. Also notice that TopViews excludes the main page alongside excluding other things in the sidebar.

      Are people really still making the "the main page is what people primarily see of Wikipedia" argument? Not since the search engines started putting individual Wikipedia pages in sidebars on their search results, it isn't. I cannot remember who first shot that argument down by pointing that simple reality out, but it was almost a decade ago, shortly after Bing started doing it if memory serves. The most viewed page in January 2025 was really, and unsurprisingly, Donald Trump.

      Uncle G (talk) 13:19, 10 February 2025 (UTC)[reply]

      • Does it matter? Our job is to write and present encyclopedic content, not to rack up clicks. Wikipedia is not about page views. Thebiguglyalien (talk) 15:45, 10 February 2025 (UTC)[reply]
        • Obviously yes it does to all of the other people still making the long-since fallacious "the main page is what people primarily see of Wikipedia" argument, and clearly mike_gigs thinks that it matters. You are trying to have it both ways, now.

          I think that everyone should recognize that this argument from supposed popularity is fallacious, and has been for a decade. It's a lot of fuss about a page that actually not nearly as many people read as the bogus statistics, that the TopViews tool has been excluding for all this time, imply; and it's long since time to more strongly shoot down the "But it's our public face and our most-viewed page!" fallacy.

          Our public face for January 2025 was the Donald Trump article, which was also part of our public face for 2024 per Project:Statistics#Page views.

          I really would like to remember who made this argument all of those years ago, so I could give proper credit. Xe was right. I think that most of the people who concern themselves with the Main Page would find that if they ever stopped being involved in those processes, as simple readers like all of our other readers nowadays they would almost never go to it in the first place. Then perhaps discussions about what belongs on it would be less fraught and more relaxed.

          Mind you, the flip side is that discussions about the Donald Trump article would be even more fraught. ☺

          Uncle G (talk) 09:51, 14 February 2025 (UTC)[reply]

          I'm just pointing out that you are incorrect by saying nobody sees the Main Page, just because you haven't been anywhere near it in decades. And you calling the statistics bogus doesn't change them at all. We won't ever know how many people who land on the Main Page actually look at it, but saying that none of them look at it so we shouldn't even bother with this conversation is absurd.
          And simple readers like all of our other readers nowadays? Really...? ✈ mike_gigs talkcontribs 14:26, 14 February 2025 (UTC)[reply]
          The clickstream data for January shows that, even counting only the top ten most common destinations there were over 2.5 million (2,508,183) instances of people clicking on links on the main page (not including the search) and collectively links on the main page were clicked over 34 million times in that one month (I don't think that includes the search). 31.5% of the views of Deaths in 2025 came from people clicking the link on the main page. This clearly demonstrates that your (Uncle G's) assertion that nobody views or interacts with the main page is the one that is fallacious. Thryduulf (talk) 17:44, 14 February 2025 (UTC)[reply]
        not to rack up clicks. Wikipedia is not about page views I mean, we have GalliumBot notifying "nominators when their [DYK] hooks meet a certain viewcount threshold." Some1 (talk) 23:30, 18 February 2025 (UTC)[reply]
      • I'm not sure how being the domain root makes the statistic bogus. Aaron Liu (talk) 15:49, 10 February 2025 (UTC)[reply]
        • Then you need to think about it a bit more. The writers of TopViews did, back in 2015. The people who wrote about unintentional views at Project:Popular pages did, too, as did the people who came up with meta:Research:Page view and the Phabricator bugs tweaking all that for the PageViews and TopViews tools. Uncle G (talk) 09:51, 14 February 2025 (UTC)[reply]
          I don't see anything written to explain why, though. I'm guessing the argument is that readers usually use the main page to search for things. But even in that case, readers do see what is on the main page, especially the graphical content on the top. Not to mention the countless social media posts about main page content. If you know something else about the main page, could you elaborate? Aaron Liu (talk) 14:37, 14 February 2025 (UTC)[reply]
          I think the idea is that most people aren't going to the Main Page for its own sake. There are presumably some who want to know what the TFA is, but for the most part, people go to the MP so that they can get somewhere else, and not for the purpose of reading the MP itself.
          Thinking of my own behavior, I end up at the MP several times a day, usually because I want to search for an article whose title I don't know. An empty page with a Special:Search box would be equally effective for me. (If I know the title, I'll just hand-edit the URL to go straight there.) Maybe once a month, I might drop by to glance at the TFA or ITN (not counting when I check the MP due to a discussion on wiki). A couple of times a year, I might glance at DYK. But mostly, if I end up at the MP, it's for a purpose other than reading the MP. If readers are like me (hint: That is not usually a valid assumption), then the "page views" for the MP are not representative, and the MP should be treated like a transit hub instead of a destination. Sure, sometimes a student will go to Grand Central Station to look at its artwork or its architecture. But most of the time, people are going through there to get to their real destination. WhatamIdoing (talk) 22:46, 19 February 2025 (UTC)[reply]
  • I naturally go to the main page several times a day either because I'm opening the site from a shortcut in a browser or because I click on the globe icon to get to a standard start point in the site. Having gone to the main page, I will naturally tend to browse it.
The number of people who browse the main page on a given day seems to be about 100K. I say that because that seems to be about the peak readership for articles when that's mainly driven from the main page. Featured articles get the most attention with about 50K views while ITN articles get about 20K readers from the main page and DYKs get about 10K.
These numbers aren't huge but they are better than nothing. If you've written or improved an article then it's nice to get some attention and comment. A problem with just writing an article that's reasonably complete and competent is that you usually get little feedback. The main page thus provides a good showcase for such work and so helps motivates editors. This is not a problem.
ITN is not such a good driver of editing because articles such as Donald Trump have been written already and are often battlegrounds or needs lots of fixing up. The focus at ITN then seems to be on gatekeeping rather than editing and this is why it's not as productive as the other main page sections.
Andrew🐉(talk) 21:04, 20 February 2025 (UTC)[reply]

Would a filter to identify changes from "transgender" to man, boy, girl, female, woman be appropriate

I'm seeing editors make such changes, presumably related to the Trump's making official there are only two choices, male or female. Doug Weller talk 12:19, 9 February 2025 (UTC)[reply]

Might not be a bad idea. A lot of that may start to happen in relatively unventilated corners (i.e., little-watched BLPs), and a filter could, in the first place, be helpful to figure out whether it is going to be a problem. --Elmidae (talk · contribs) 12:40, 9 February 2025 (UTC)[reply]
Maybe, provide some diffs as examples so we can evaluate from a technical perspective. — xaosflux Talk 12:58, 9 February 2025 (UTC)[reply]
I only have one right now.[7] Doug Weller talk 13:44, 9 February 2025 (UTC)[reply]
Notifying WP:EFR of this. Also agree with the proposal, presuming it's only logging rather than completely disallowing. The amount of false positives might be pretty high, so it's best that humans take a second look at them. Chaotic Enby (talk · contribs) 14:46, 9 February 2025 (UTC)[reply]
I would hope that most filters, apart from ones that deal with an urgent problem, start life by only logging, so we can get a better idea of how prevalent the problem is, how many false positives are thrown up etc. Phil Bridger (talk) 15:13, 9 February 2025 (UTC)[reply]
Oh definitely, and I'd also be interested in seeing the editors. Doug Weller talk 15:15, 9 February 2025 (UTC)[reply]
Is there an actual problem that needs fixing, or just the chance that there may be a problem some day? So far, it seems just the standard levels of vandalism. Cambalachero (talk) 15:20, 9 February 2025 (UTC)[reply]
I think it's a real problem - part of the problem that certain Wikipedia editors feel emboldened towards particular kinds of disruption by the current power shift in the US. Here's an example, with a specific reference to "the government" having ruled that trans women are men. Bishonen | tålk 15:35, 9 February 2025 (UTC).[reply]
So? Did that user edit articles in a way that this proposed filter would catch? All I see in that link is a user explaining his view over the way the article is written. And citing big proponents of a given idea (such as the government of the US) is a way to show the weight of that idea. Cambalachero (talk) 01:43, 10 February 2025 (UTC)[reply]
Sorry, I should have given the actual diff rather than assume it would be easy to find from the conversation I linked. Here it is. Bishonen | tålk 02:23, 10 February 2025 (UTC).[reply]
That doesn't add much. Remember, the proposal here is about a specific type of vandalism (changing pronouns from biographies), and an edit filter that would detect those; not about the presence of editors with certain ideas. But before implementing a solution for a problem (which requires time, resources, and editor's work) we need to know that the problem actually exists (because if it ain't broke, don't fix it). For example, 10 or 15 examples of such vandalism reverted on the last week. Cambalachero (talk) 13:20, 10 February 2025 (UTC)[reply]
Here's a two-edit diff from a brand new account today, undoing an announcement of trans status and updating of pronouns that had happened just yesterday in the face of the subject's public announcement of trans status. No visible alarms were triggered other than reference removal. Not the precise text change originally noted by OP, but pronoun reversal and in general an example of what we're facing. -- Nat Gertler (talk) 20:53, 10 February 2025 (UTC)[reply]
I think Special:AbuseFilter/1200 tries to catch some versions of this, but limited only to BLP articles. 86.23.109.101 (talk) 20:26, 9 February 2025 (UTC)[reply]
  • What I would filter for is something along the lines of... changes from one gendered word to another (pronoun or gender-identifier), especially on articles categorized as trans-related in some way, and particularly on biography articles for trans individuals. Some false positives are inevitable and there's no way to catch everything, but it could probably get the number flagged for review down to a reasonable number and could catch a lot of the blatant "someone sweeps in and changes pronouns throughout the article" stuff. --Aquillion (talk) 20:35, 9 February 2025 (UTC)[reply]
    Even "someone sweeps in and changes pronouns throughout the article" is occasionally going to be correct, such as when some notable person first publicly comes out as transgender, so human review will always be needed. However flagging them so that humans know there is a need for review seems like a very sensible idea. Thryduulf (talk) 23:56, 9 February 2025 (UTC)[reply]
    Special:AbuseFilter/1200 covers most of what you mention (it flags people changing a bunch of pronouns on a trans person's page), but if people want more filters like that, diffs are useful - generally it is hard to create a useful filter without a few diffs which help to figure out patterns that can be filtered for. Galobtter (talk) 01:49, 10 February 2025 (UTC)[reply]
Hmm. Just reverted one last night (sorry not sorry for the RV edit summary). Did this pop up on the filter? I can't check, I assume. --Elmidae (talk · contribs) 11:06, 10 February 2025 (UTC)[reply]
@Elmidae I don't see it here.[8].. Doug Weller talk 13:33, 10 February 2025 (UTC)[reply]
@Galobtter That filter looks good but of course doesn't have "transgender" in it. And It looks as though it didn't pick on up last night. Doug Weller talk 13:34, 10 February 2025 (UTC)[reply]
The general idea of a filter sounds good. Even better if it can capture articles with trans or transgender in as well. Lewisguile (talk) 18:31, 10 February 2025 (UTC)[reply]
I saw the request for diffs so I had a look at edits I had reverted in the recent past. I thought I had more diffs to hand than I do. In many cases I see these bad edits after somebody else has already reverted them. Even so, I've found a few and I think we can extrapolate a few patterns from them. Let's try to break them up into categories and suggest some possible rules.
Flag on addition of phrases "Trans identified men" and "Trans identified women". These are never legitimate except when discussing the dog-whistle phrases themselves.
  • Suggestion 2:
Flag on changing "trans/transgender woman/women" to a phrase containing "man/men/male/males"
Flag on changing "trans/transgender man/men" to a phrase containing "woman/women/female/females"
  • Suggestion 3:
Flag on addition of common slurs, particularly when used to replace "trans" or "transgender". Whitelist articles that specifically discuss the slurs as they will need to contain them.
Flag on replacing "cisgender" or "cis" with "biological", "actual" or "real"
(Not sure how much a filter can help with this type.)
  • The Ferengis:
    • I didn't find any examples of this in my recent reverts but we should probably flag for changing any gendered term to "males" or "females". I'm not sure if my suggestion 2 covers this sufficiently.
And finally, here is a good example of a troll trying to leverage Trump's pronouncements as an excuse to censor Wikipedia. I don't think that can be dealt with by a filter. Maybe a FAQ would help or maybe it would just invite more of the same.
--DanielRigal (talk) 19:20, 10 February 2025 (UTC)[reply]
Not sure if this would count as recent enough, but this is another example, non blp but another example, this edit stayed around for a month so it would have been useful to have been flagged. It used the phrase "trans-identified males" so we might have to do quite a few variations to be able to flag this kind of language appropriately. LunaHasArrived (talk) 09:12, 17 February 2025 (UTC)[reply]
Don't have a lot of comments on the technical side but did want to drop in and say this is important work that needs to be done. Mrfoogles (talk) 17:07, 2 March 2025 (UTC)[reply]

Only 1 of those diffs is from the last week. So far, it seems like a minor problem that can be perfectly dealt with with the current anti-vandalism tools. Cambalachero (talk) 19:57, 10 February 2025 (UTC)[reply]

@Cambalachero you really seem to object to this. But you aren’t being asked to do any work here, why try to stop it from being created? Doug Weller talk 20:08, 10 February 2025 (UTC)[reply]
I don't think it's relevant, but if you need to know, I don't like edit filters. They make the watchlist increasingly busy. I understand why they are there, but I would prefer them to be added only when really necessary, when there's an actual ongoing problem to fix, not "just because", because each new filter adds some extra technical gibberish next to many watchlist entries. As said, don't fix it if it ain't broke. Cambalachero (talk) 01:06, 11 February 2025 (UTC)[reply]
@Cambalachero Tagging and logging are separate things. Tags are what you see adjacent to a watchlist entry (e.g. "possible unreferenced addition to BLP"), the log is a list of edits that have matched the given filter that you have to actively look at to be aware of. For example the edit to South Korea at 05:28, 11 February 2025 is listed in the log for filter 833 but this is unknowable if you look at the edit history or see the edit in your watchlist. Thryduulf (talk) 05:41, 11 February 2025 (UTC)[reply]
Seems fine, then. Cambalachero (talk) 18:07, 11 February 2025 (UTC)[reply]

I don't see any problem with a logging only filter to attempt to catch changes in pronouns or the addition/removal of "transgender". I do, however, want to point out that a filter that looks for "trans" or "trans-" or "trans " potentially cause many false positives from science articles, where trans (and cis) can be used to describe cis–trans isomerism of a molecule. In the chemical names, this would be (properly) written as trans-(name of molecule) or cis-(name of molecule). But after it's first referred to, it is common to simply refer to "the trans isomer" or similar, rather than repeating the whole name. I suspect there may be a way to account for this in the filter design to reduce the false positives. -bɜ:ʳkənhɪmez | me | talk to me! 20:06, 10 February 2025 (UTC)[reply]

Yeah. That's definitely a risk. If the filter can handle it, it might make sense to do something like:
  • On any article, if they mess with "transgender", "trans woman" or "trans man" then apply the filter. The risk of false positives is small.
  • Only apply the filter on "trans" if the article has categories indicating that it is about transgender people or topics or if "trans" is linked to an article about a transgender topic.
I think that would be enough to avoid stomping on any chemistry articles, unless there are any transgender chemists who specialise in isomerism, in which case I guess that's one to whitelist.
I agree that logging only is the best way to go, except maybe for the outright slurs. --DanielRigal (talk) 20:38, 10 February 2025 (UTC)[reply]
This proposal seems to have died, is that correct? Doug Weller talk 17:06, 2 March 2025 (UTC)[reply]

Is this idea limited to just English Wikipedia? If so, then a gadget perhaps. Of course, a user would have to go to user preferences to enable that. For logged-out users, that's a huge challenge, and an edit filter would be too limiting. If the issue goes beyond English Wikpedia, then why not take this to Meta-wiki RFC? George Ho (talk) 18:41, 17 February 2025 (UTC); edited, 20:05, 17 February 2025 (UTC)[reply]

Really not sure why a gadget would be more useful than an edit filter, as those already have the functionality we're looking for. And yes, this is for the English Wikipedia. Chaotic Enby (talk · contribs) 19:22, 17 February 2025 (UTC)[reply]
Personally, I'm not a fan of edit filtering except in Commons and to combat spamming and questionable sources. As I fear, any more of edit filtering would lead to more outrage and attempts to bypass the filter. IMO, a gadget would appease those who would make preferences as they see fit without having to edit (over and over probably). George Ho (talk) 19:35, 17 February 2025 (UTC); struck, 20:05, 17 February 2025 (UTC)[reply]
As I fear, any more of edit filtering would lead to more outrage and attempts to bypass the filter. To clarify, we're talking about a filter for logging, not for disallowing the edits. We already have more than a thousand edit filters for various purposes, and many of them just log the edit in the edit filter log (the edit isn't even tagged in the history page, and shows up as normal). Chaotic Enby (talk · contribs) 19:54, 17 February 2025 (UTC)[reply]
As I realized, even as a longtime Wikipedian, I'd been unfamiliar with logging-only filtering (or "log the edit" setting/option as WP:Edit filter guideline calls it) until now. George Ho (talk) 20:05, 17 February 2025 (UTC)[reply]
Someone seeking to make such edits would not activate a gadget that logged the edit (or that tried to block it), so I don't think it would help. isaacl (talk) 19:55, 17 February 2025 (UTC)[reply]
Rescinding my gadget suggestion then. George Ho (talk) 20:05, 17 February 2025 (UTC)[reply]

Dealing with sportspeople stubs

I've been thinking about the thousands of sportspeople stubs on Wikipedia this evening, and I think it would be a good idea for the community to come up with an idea to address them.

While I'm not familiar with the lore, I'm aware that at one point there was a user who made thousands of these stubs for Olympic sportspeople, and I assume based on the volume that others must have participated in this as well. The end result of this is a steady stream of these articles in AfD, which I think is counterproductive.

AfD takes time, and with 70 odd articles being added to it every day, anything that reduces the total amount of time editors need to spend discussing AfDs, and the amount of time administrators spend closing AfDs, would be a net positive to the project. I feel as though either all of these sportspeople stubs should remain, per WP:NOTPAPER, or we should find a way to carefully nuke the whole lot per WP:NOTEVERYTHING. Getting rid of them one by one creates a very choppy browsing experience, for the one person who does want to know who won a specific race in Spain in 1932. I looked around and I didn't see this having been discussed in-depth prior to this, but if I missed a previous discussion please let me know. Kylemahar902 (talk) 00:29, 20 February 2025 (UTC)[reply]

I am really glad that Kylemahar902 has made this point - I've been going through and nominating a lot of articles for deletion and there's still so many more to do. I can't do too many at once as we need time to properly look for sources. I'm not entirely sure what we can do but I think we need to at least talk about it. RossEvans19 (talk) 02:13, 20 February 2025 (UTC)[reply]
Do you like sending articles to deletion? Is it satisfying somehow? WhatamIdoing (talk) 03:16, 20 February 2025 (UTC)[reply]
Oh, are we doing that thing again where we're trying to prove those people who say that there's no such thing as a stupid question wrong? How fun! But if that's not what this is, I have a few questions of my own. Is your reading comprehension level above that of the average third grader? Are there any other pointless and insulting questions you'd like to add at this time? Dr. Duh 🩺 (talk) 07:23, 20 February 2025 (UTC)[reply]
Is this aimed at me? I don't really know what I did wrong? RossEvans19 (talk) 13:06, 20 February 2025 (UTC)[reply]
You didn't do anything wrong. I don't mean to assume, but I believe Dr. Duh was replying to the user above them. There's nothing wrong with sending articles to AfD, that's why it exists. I don't want to start any arguments about the merits of deletion, though, that's not really what this is about. Kylemahar902 (talk) 13:13, 20 February 2025 (UTC)[reply]
To ask my question in a more verbose, and therefore possibly less misunderstandable way:
Approximately 99% of Wikipedia editors don't spend their days looking around for articles they can send to AFD. This is, therefore, an unusual behavior. People who do this probably enjoy the work at some level, because if they didn't, they're WP:VOLUNTEERS and would presumably stop doing it.
So: What's the appeal for you, @RossEvans19? You've nominated 25 articles in the last week. Do you like this work, or do you feel like it's some sort of obligation? Do you feel a sense of accomplishment when you find a subject that should be deleted? Is it satisfying to think you have protected Wikipedia from having two outdated sentences about an athlete such as Taku Morinaga? Do you feel like you're protecting the subjects themselves? In short, why do you do this? WhatamIdoing (talk) 18:12, 20 February 2025 (UTC)[reply]
I don't think this type of questioning directed at an individual editor is the best way to discuss potential improvements to either the editor's workflow or that of the overall process. For process improvements, I think it would be more effective if you would state the reason for your inquiries up front (for example, I'm trying to understand editor motivations to nominate articles for deletion so we can adjust the process to keep the incoming rate to a manageable level), and solicit opinions from all editors. isaacl (talk) 18:25, 20 February 2025 (UTC)[reply]
If anyone else has nominated an unusually large number of athlete articles for deletion recently, I'd be happy hear from them, too. The >99% of us who contribute only in other ways, or who share Phil's sentiment below, aren't really going to be able to answer the question usefully. WhatamIdoing (talk) 18:43, 20 February 2025 (UTC)[reply]
I realize you don't participate in AfD really at all, and especially not on sportspeople, but 25 articles in a week is not "unusually large". And clearing the encyclopedia of non-encyclopedic topics seems like a pretty straightforward motivation. JoelleJay (talk) 19:05, 25 February 2025 (UTC)[reply]
I've only made 14 edits at AFD so far this month, which I'm sure is less than a day's work for you and the others who spend a lot of time in that area. Of course, I usually only comment if I think the nomination is wrong or otherwise problematic in some way, or if there's no sign of a consensus forming, so I review far more than I post in, and my comments (example, example, example) usually take a lot longer than to write than someone saying "Delete because I've WP:NEVERHEARDOFIT and I couldn't find any obviously reliable sources within 30 seconds".
Spot-checking Wikipedia:WikiProject Deletion sorting/Sportspeople over the last month, it appears that this list usually has 50 to 90 AFDs listed each week. That means that 25 is a lot – up to 50% of the week's noms. Perhaps of greater relevancy if you're nominated 25 Japanese athletes and can't read enough Japanese to do a valid BEFORE search in Japanese sources, Wikipedia:WikiProject Deletion sorting/Japan normally has about 10 AFDs listed. Adding 25 triples the workload for our limited number of Japanese speakers. WhatamIdoing (talk) 20:51, 25 February 2025 (UTC)[reply]
I have checked for sources, but I will cut it back, as I have been nominating a lot of articles. RossEvans19 (talk) 21:13, 25 February 2025 (UTC)[reply]
It's perplexing that this sentiment is always expressed in terms of increasing workload for volunteers, but never any consideration about the fact that these articles exist whatsoever also increases the workload. People can ignore the AfDs the same way they can ignore the stubs. Also, let me ask, why are you so opposed to getting rid of bad content on Wikipedia? I get you got paid to buy into the "all content added is good content" canard the WMF has always loved peddling, but the fact you regularly show up to complain about anyone taking issue with people dumping poor-quality content onwiki is as inscrutable to me as you thinking someone who methodically nominates stuff for AfD has a screw in their head loose. Der Wohltemperierte Fuchs talk 21:14, 25 February 2025 (UTC)[reply]
@David Fuchs ignoring the bad faith assumptions in your comment, I share similar (but not identical) perspectives to WAID about deletion and notability. The issue is not with deleting articles about subjects we shouldn't have, it's with deleting articles about subjects we should have. Every article about a notable subject that gets deleted harms the encyclopaedia in two ways - firstly it means that people looking for neutral encyclopaedic information about that subject are less likely to find it, and secondly it discourages contributors from adding content. It's much easier to delete an article that someone else has written than it is to write a new article, especially if you're new here and the subject you want to write about is one somebody might want to promote (whether you are promoting it is barely relevant). Thryduulf (talk) 21:42, 25 February 2025 (UTC)[reply]
It's much easier to delete an article that someone else has written than it is to write a new articleThat is objectively untrue. It takes one person under two minutes to create a new article, which in these sportsperson cases often involved a boilerplate intro and a single citation to a stats database. It takes 7+ days and at least two editors to delete an article, with noms expected to be able to rebut any existing refs in it, many of which weren't even added by the creator. JoelleJay (talk) 23:24, 25 February 2025 (UTC)[reply]
It takes 7+ days and at least two editors to delete an article, with noms expected to be able to rebut any existing refs in it – in reality, that's not usually the case. Almost every active sportsperson AFD right now is something like Played 16 times professionally in 2014, hasn't played professionally since, fails GNG; Fails WP:SPORTSCRIT and WP:NOLY. Eliminated in 1st round of heats.; Non-notable athlete., etc. – Then the vast majority get a few drive-bys like Does not meet guidelines for athlete a per nom. / per nom, Insufficient coverage by independent, reliable secondary sources to pass WP:GNG. and then get deleted, with little actual evidence of decent BEFORE searches being performed. Its actually very easy to get these deleted. I recall one user who not long ago mass nomm'ed about 60 figure skaters for deletion in 30 minutes with no BEFORE – some of which even did have decent sources, and almost all of them were soft-deleted, except for the tiny handful that got some users actually recognizing the notability of the nominated subjects. BeanieFan11 (talk) 23:40, 25 February 2025 (UTC)[reply]
7+ days and 2+ people (nom and closer) is required for every non-speediable AfD... That is still more total effort than was put into creating many of these articles. However I do think that noms based only on failing a sport-specific criterion should be challenged and procedurally addressed for not supplying a valid deletion rationale (if the nom doesn't amend their statement to show BEFORE was done). JoelleJay (talk) 00:40, 26 February 2025 (UTC)[reply]
"It's much easier to delete an article that someone else has written than it is to write a new article"—that's simply not the case, otherwise we wouldn't have these perennial questions and we wouldn't see Wikipedia's article count grow unrestrainedly. I suppose you can argue this is true at a single article level, but the entire problem with mass creation has always been that there's no way of deleting even bad articles with the rapidity they can be created. If that weren't the case then there would have never been any need for the LUGSTUBS remedy. Der Wohltemperierte Fuchs talk 21:52, 25 February 2025 (UTC)[reply]
@David Fuchs, I remind you that Wikipedia:Editing policy – our policy, not the WMF's – says "Wikipedia summarizes accepted knowledge. As a rule, the more accepted knowledge it contains, the better."
I just spent an hour looking at Wikipedia:Articles for deletion/Naoki Hara. I picked it because the OP here nominated it for deletion. I found multiple news sources. Apparently neither the nom nor the other respondent there found any.
I assume the difference is that I deliberately looked for sources in Japanese, and they didn't. As you will see on the AFD page, I conclude – from the sources I found, with my limited abilities, which mostly involve knowing that the List of newspapers in Japan exists and being able to copy and paste the BLP's Japanese name into a search box – that this BLP is possibly notable in GNG terms, and that we're probably better off having the article than not having it. Someone who could actually read Japanese, or who checked more than four Japanese-language newspapers, might think the case is even strong.
When I look at nominations like this, I think that it's much easier to send an article to AFD than to provide an accurate response to the nomination. What do you think?
I'm not saying that anyone is acting in bad faith. Sometimes a nom seems like a good idea, because you personally don't have the necessary information or access to the necessary sources to do a reliable WP:BEFORE search, or because it's actually really complicated. (Wikipedia:Articles for deletion/Fudge cake is an example of that: good sources are hard to find under piles of recipes, and when you do find them, some give exactly opposite definitions to distinguish Fudge cake from Chocolate cake.) But I do feel like some articles, especially those that aren't about English-language subjects, are much easier to take to AFD than to create or to defend. WhatamIdoing (talk) 22:45, 25 February 2025 (UTC)[reply]
As I note in my comment at that AfD, the coverage you found is routine transactional announcements, passing mentions in game recaps, and stats profiles. Noms/!voters generally do not even mention, let alone link, such sources because they are expected for every single athlete and do not count towards notability. JoelleJay (talk) 23:15, 25 February 2025 (UTC)[reply]
The GNG, unlike NCORP, does not discount "routine" sources. Attention from the world at large is still attention from the world at large, even if it is predictable attention. WhatamIdoing (talk) 23:30, 25 February 2025 (UTC)[reply]
NOT discounts routine coverage, and this is implemented at NSPORT. routine news coverage of announcements, events, sports, or celebrities, while sometimes useful, is not by itself a sufficient basis for inclusion of the subject of that coverage. Routine coverage of transaction announcements is exactly what we dismiss for sportspeople. JoelleJay (talk) 23:36, 25 February 2025 (UTC)[reply]
And WP:ROUTINE names "sports scores", but not "more than Wikipedia:One hundred words, including a description of the athlete's educational background".
Perhaps the community needs to have a discussion about what's really "routine", so that we can have a shared understanding. Is it about brevity ("sports scores")? The lack of continued coverage ("wedding announcements" – though not necessarily the weddings themselves)? The mere predictability of it (the Super Bowl happens every year)? WhatamIdoing (talk) 23:54, 25 February 2025 (UTC)[reply]
WP:NOT, which I cited, specifically states "routine coverage of announcements". "The community" clearly rejects these barely-refactored press releases, otherwise it would not have reached the global consensus that it did. If you are not familiar with NSPORT and typical sports coverage, perhaps you should do what I did before ever participating in an NSPORT AfD and read 200+ old 10kb+ discussions in the sportsperson delsort archives first. JoelleJay (talk) 00:05, 26 February 2025 (UTC)[reply]
Is the content in a "routine coverage of announcements" more like "Alice has announced that Bob is being transferred" or more like the non-announcement statement that "Bob attended This School"?
An the original version (2007) of that sentence said "Routine and insubstantial news coverage, such as announcements, sports, gossip, and tabloid journalism, are not sufficient basis for an article"; it was later "Routine news coverage and matters lacking encyclopedic substance". The discussions on the talk page is at Wikipedia talk:What Wikipedia is not/Archive 15#Tabloid news and was focused on Tabloid journalism, defined in that discussion as "the gossipy crap magazines". I doubt that a couple hundred words describing a BLP's background and achievements, even if that news article was written in the context of a "routine" news event, was what they intended for that sentence to cover. WhatamIdoing (talk) 00:34, 26 February 2025 (UTC)[reply]
I also participate virtually exclusively in controversial AfDs... Brief, unsupported arguments are just as common among keep !votes, which more often take the form of presuming SIGCOV exists somewhere even when, e.g., someone has shown only passing mentions exist in the archives of 27 sports news sites across four different languages.
Sportsperson AfDs often come in waves; sometimes regulars come across a walled garden of articles that were all solely justified in their creation by a deprecated criterion and are similar enough in time period and level of play that they have similar SIGCOV predictions as well. The number of articles at AfD has lately been consistently much lower than what I've seen the past. JoelleJay (talk) 22:53, 25 February 2025 (UTC)[reply]
I just want to say before I explain my reasons why, that it seems like I've done something wrong - I'm just a bit confused why your asking me about this. The truth is, I do like it, and it is an obligation. Articles about footballers who played once 10 years ago need to be deleted, they aren't notable. I think I might be misunderstanding you and your genuinely just curious xD RossEvans19 (talk) 01:58, 25 February 2025 (UTC)[reply]
What do you like about it? For example, some people enjoy making Wikipedia conform to the rules.
To whom do you feel obligated?
By the way, this sentence: Articles about footballers who played once 10 years ago need to be deleted, they aren't notable is completely wrong. It doesn't matter when they played, because notability is not temporary. They don't "need" to be deleted, and the usual thing for someone who played on a team is to not delete but instead redirect it to the team's page. And nothing you've said actually proves that they're not notable. Someone "who played once 10 years ago" could have gotten an enormous amount of attention; someone who played 10 times one year ago might have gotten none.
Finding sources in a language you don't speak is a very challenging task. WhatamIdoing (talk) 05:05, 25 February 2025 (UTC)[reply]
I'm not doing anything wrong. These players aren't notable. And the fact you've replied to this, which means you would have seen my other post and ignored it, means you are intentionally misgendering me. RossEvans19 (talk) 13:12, 25 February 2025 (UTC)[reply]
How can you be certain that these players aren't notable? Did you check for Japanese-language news sources, or only English ones?
How did you decide that a non-notable athlete who played for a team should be deleted completely instead of redirected to a list? We have many sports-related lists, such as the List of players who appeared in only one game in the NFL (1920–1929) and List of Minnesota Vikings players. What made you think these should these athletes should not be redirected to a suitable list?
(No, it only means that I got distracted before correcting it.) WhatamIdoing (talk) 17:35, 25 February 2025 (UTC)[reply]
There is unfortunately not a list of Japanese players who have played 1-25 games in Japan, but there is lists for designated special players, which I have been adding redirects to today :) - One more thing, you added one they, but it still says "and he's managed to nominate 25 in the space of one week"
Look, I think we've gotten off on the wrong foot. Would it be okay if we could end this discussion with no hard feelings? RossEvans19 (talk) 18:00, 25 February 2025 (UTC)[reply]
Most of the discussions on this issue have taken place on the NSPORT and WP:N talk pages. See also WP:LUGSTUBS for an example of other approaches to cleaning up sportsperson stubs. JoelleJay (talk) 02:26, 20 February 2025 (UTC)[reply]
Unless they're wrong in some way I don't think their existence is a pressing concern. Maybe not ideal, but is it a serious issue? PARAKANYAA (talk) 03:27, 20 February 2025 (UTC)[reply]
Some editors are annoyed by the existence of short articles. Their thinking seems to be that if it's worth having, it's worth having hundreds of words immediately. (A quarter of our existing articles have less than 150 words.)
Others disagree with the long-standing rule that Notability is based on the existence of suitable sources, not on the state of sourcing in an article. They are less interested in whether the subjects are notable and more interested in whether the subject's notability has been proven, preferably in the form of a dozen citations to lengthy articles that are free to read online. (A quarter of our existing articles contain only one or two ref tags; half have four or fewer.)
And some of this is a real shift in standards. Two decades ago, writing "Nobody knows what his full name is, but John played professionally for the Blue Team in Smallville on 32 Octember 1898[1]", then that was considered a net positive contribution. Now it's considered, at most, to be worth a list entry. WhatamIdoing (talk) 05:38, 20 February 2025 (UTC)[reply]
There have been many discussions about this. Further WP:MASSCREATE is against consensus, but there has never been consensus to do anything to existing stubs outside of the normal editing process. There is a wide variety of differences in scope and content in stubs, and you can be bold with any edits. CMD (talk) 05:23, 20 February 2025 (UTC)[reply]
I just read the above comments. Thanks to @JoelleJay for the link to prior discussions, and I hope I'm not opening a can of worms here. I actually have no strong opinion either way, but my point is we should be aiming for consistency. If consensus is that these stubs are worth keeping, and that mass deletion is too risky, then I'd like to see a way to stop having them flood AfD. Yes, there's plenty of more pressing issues facing the encyclopedia, but apparently this keeps coming up and there hasn't yet been a solution. If the issue was serious enough to warrant all the past drama, then surely it's serious enough to solve now, right? Kylemahar902 (talk) 11:31, 20 February 2025 (UTC)[reply]
The only way to stop them flooding AfD is to either sanction individual editors for being disruptive or improve the articles to their standards before they get there. Consensus of the past discussions has never been in favour of mass deletion, and rightly so, and trying to get around that by flooding AfD is disruptive. Thryduulf (talk) 12:13, 20 February 2025 (UTC)[reply]
I agree with you that if consensus isn't in favour of mass deletion, then sending them to AfD en masse could be considered disruptive. Just thinking out loud here—I wonder if it would be an idea to have AfDs for these sportspeople stubs automatically close as keep, unless an additional flag is added. I wouldn't want to go so far as to sanction people who send them to AfD, or stop the ability to AfD them altogether, but maybe a method of making people think twice about whether or not it's worth the hassle of AfDing these articles would be enough to stop the flow. An alternative could be to only allow prods of sportspeople stubs, to cut out the wasted time of the discusson and review, but administrators would still have to go through and clear out all the prods in that case. Would love to hear some more ideas if anyone wants to help me brainstorm here. Kylemahar902 (talk) 13:31, 20 February 2025 (UTC)[reply]
That suggestion would go against the recent strong global consensus that all sportsperson articles must cite a source of IRS SIGCOV in their article, in addition to the subject meeting GNG. The problem isn't "too many articles at AfD", it's that too many articles were created in the first place. JoelleJay (talk) 19:28, 20 February 2025 (UTC)[reply]
Whether or not the articles should have been created is, at this point, irrelevant. They were created and they do exist. There is a consensus that the articles must cite significant coverage, a consensus that the articles should not be deleted without review but no consensus about how to resolve the tension that creates. "Too many articles at AfD" is still a problem, even if it isn't the first problem in the pipeline, because it means articles are not getting the review that consensus says they need before deletion. The best way, in my view, to resolve the issue is to make a full BEFORE search mandatory for stubs of sportspeople created more than circa a year ago, and require that a summary of this search be included with any nomination. That would slow down the rate of AfDs to a level that is manageable by reducing the number that are being sent there unnecessarily.
Before anyone howls in protest about how this requires more effort from nominators than was put into their creation, firstly that is not necessarily actually true, and secondly you've already succeeded in massively increasing the amount of effort required to create an article, and in massively increasing the effort required from those reviewing articles at AfD, so slightly to moderately increasing the effort required to delete an article is simply partially correcting this imbalance. If you require more effort from others you cannot complain if others require a comparable increase in effort from you. Thryduulf (talk) 22:08, 20 February 2025 (UTC)[reply]
OTOH, Ross says that he's they're taking the time to properly look for sources, and he's they've managed to nominate 25 in the space of one week. If we really do have a volume problem at AFD, I'd suggest first trying to recruit a couple of people with excellent search skills to respond to the nominations. Only if alternatives fail would I consider something drastic, like a per-editor cap on the number of nominated articles per week/month. WhatamIdoing (talk) 22:21, 20 February 2025 (UTC)[reply]
We had that with WP:ARS - a "group of people" who have excellent search skills, deep knowledge of the NOTE rules, good writing skills. Successfully expanded and saved thousands of articles. However the community banned most of the editors because they thought it was a canvassing board (the deleters successfully portrayed them as such), we no longer have any "group of people" to save articles from deletion, and likely never will again. It's wishful thinking. AfD is dominated by a deletion-mindset, by its nature. It's the old got a hammer / looks like a nail problem. Deleters should be held to higher standards, they weild a powerful tool, they should be accountable for an obvious lack of WP:BEFORE, in most cases that is the problem. -- GreenC 18:02, 25 February 2025 (UTC)[reply]
[people nominating articles for deletion] should be accountable for an obvious lack of WP:BEFORE absolutely. Despite main howls of protests over the years I'm still not convinced there is any reason why a BEFORE search that includes looking in the place sources are most likely to exist should not be a mandatory aspect of a deletion nomination on the grounds of notability. A google search in English is absolutely fine when the topic under discussion is 21st century American popular culture, it is absolutely not sufficient when the topic is 19th century railway stations in rural India or 1970s footballers in Japan. Thryduulf (talk) 18:10, 25 February 2025 (UTC)[reply]
Just want to say very quickly, my pronouns are they/them, which it says at my talk page! :) RossEvans19 (talk) 01:59, 25 February 2025 (UTC)[reply]
Thank you for letting me know. WhatamIdoing (talk) 17:36, 25 February 2025 (UTC)[reply]
I would support pushing nominators to summarize their BEFORE approach. However BEFORE absolutely does not require exhaustively checking news archives. JoelleJay (talk) 19:18, 25 February 2025 (UTC)[reply]
I'd like to know your opinion: Say we have someone who has passing mentions in modern times as the "greatest athlete in the history of Niger" (but the mentions are not considered as sigcov), and they competed in the 1960s. Nigerien archives go back only about five years (everything before that has gone dead or was never put on the internet in the first place). What do you think an appropriate-level BEFORE search would encompass? BeanieFan11 (talk) 19:29, 25 February 2025 (UTC)[reply]
If we do not have notability-demonstrating sources to build an article, we should not have that standalone article. Brief mentions of greatness do not satisfy any notability criteria, and without at least one SIGCOV source even their sport-specific achievements cannot be presumed to have garnered SIGCOV. That's what the global consensus decided. This is especially true for BLPs, where we need particular care WRT NPOV. The same Nigerien sources you presume might have SIGCOV of someone's sporting career might also have coverage of significant controversies involving them, discussion of which would be required for a biography to be neutral. A stub simply relaying their stats and repeating the "greatest athlete" claim would thus be inappropriate as a biography, which is supposed to encompass a person's life. Passing mentions should not be the basis of an article no matter what they say, as by definition they do not explore the subject deeply enough that we can presume they reflect the overall treatment of the subject in IRS. JoelleJay (talk) 21:58, 25 February 2025 (UTC)[reply]
Even only one IRS SIGCOV is still weak to demonstrate the article's notability. Articles about people generally require multiple of them. ⋆｡˚꒰ঌ Clara A. Djalim ໒꒱˚｡⋆ 11:16, 6 March 2025 (UTC)[reply]
I didn't ask your thoughts on whether it is appropriate to have a stub without sigcov on the greatest Nigerien athlete ever. I asked: what do you think would be an appropriate level of BEFORE searching if one was considering nominating the greatest Nigerien athlete ever for deletion? BeanieFan11 (talk) 22:14, 25 February 2025 (UTC)[reply]
The more generic way to ask this question would be: If you personally have knowledge (e.g., from reading sources that namecheck the subject as the greatest Nigerian athlete ever) that leads you to believe that sources probably exist, but those sources are not FUTON-compliant ("full text on the net" or "free text on the net"), should you:
  • assume the subject isn't notable after all, and send it to AFD, or
  • assume that the problem is in your ability to access the sources, instead of their non-existence?
WhatamIdoing (talk) 22:49, 25 February 2025 (UTC)[reply]
Sorry I didn't see this earlier. I think a search in the local language, as outlined in BEFORE, should be enough for a topic where the only claim to notability is a couple passing mentions of being the "greatest Nigerien athlete ever". What little we can objectively say about them can be covered in other articles, there is no reason for a standalone. JoelleJay (talk) 17:55, 6 March 2025 (UTC)[reply]
I think a search in the local language, as outlined in BEFORE, should be enough – Do you mean a 45-second Google search in the language or actually looking at newspapers from that country, where coverage is most likely to be? Also, while not on Niger, an issue I have with many of these active AFDs on Olympians is no search at all is being performed in the local language. Do you think all the Olympian AFDs going on right now are appropriate given that no search in the language is being performed? BeanieFan11 (talk) 18:10, 6 March 2025 (UTC)[reply]
I think @LibStar would be well advised to outline the products of their BEFORE in their noms, especially what searches they've done in local languages. But equally you should recognize that the community came to a global consensus that sportsperson articles must cite a source of IRS SIGCOV, and this applies even to topics where coverage would be difficult to access. No carve-out was accepted at the RfC. JoelleJay (talk) 19:28, 6 March 2025 (UTC)[reply]
Too late now, but honestly, I don't think SPORTCRIT ever would have been passed if the proposal was made clear to require all historic athletes to have sigcov with deletion allowed en masse with no BEFORE search otherwise. I don't remember that ever really being discussed there (that one could mass nominate articles on old athletes without BEFORE). Cbl62 originally called its passage A complete travesty ... one that was never, ever supported by consensus. BeanieFan11 (talk) 19:44, 6 March 2025 (UTC)[reply]
From memory (and I've not got time right now to verify this) but I believe that when it was passed it was explicitly stated that mass deletion was explicitly not supported by consensus and should not happen. Thryduulf (talk) 22:33, 6 March 2025 (UTC)[reply]
And one more thought. If consensus is that we don't want to mass delete, but we don't want to limit them going to AfD, or otherwise take action on the issue, then in that case we could publish a guideline explaining that position. I can't help but feel as though this will continue to come up as long as we ignore it. Kylemahar902 (talk) 13:47, 20 February 2025 (UTC)[reply]
What is the precise issue that is coming up? Articles being created, and articles going to AfD, are normal parts of the editing process. That is not something being ignored, it is expected. If 70 AfDs a day is too much, what is the target, and how would envisioned action on sportsstubs affect it? CMD (talk) 13:57, 20 February 2025 (UTC)[reply]
You make a great point. I do regret my wording of "as long as we ignore it", what I meant was "as long as the issue remains unaddressed." I do feel that whatever action is going to be applied to sports stubs, it should be applied consistently. As it stands right now, the action being applied is just letting them get ever-so-slowly thinned out through AfD, which really doesn't make a whole lot of sense. It's clear that this is something that editors care about, given the large amount of discussion on the topic and the actions taken against those who perpetuated the creation of these stubs. Maybe I'm making mountains out of molehills here, and feel free to tell me if you think so, but surely it wouldn't be a bad idea to try to clarify the community's position on sports stubs. Kylemahar902 (talk) 14:42, 20 February 2025 (UTC)[reply]
I don't know that aggregate sum of AfD results, but the article base getting ever-so-slowly thinned out is what I would expect AfD to do. If say out of every 10 articles created one should be deleted for various reasons, that's a small thinning out that still sees the overall number of articles rise, and I suspect it's a very high estimate for the percentage of articles that are deleted. CMD (talk) 09:51, 23 February 2025 (UTC)[reply]
Kyle, what you seem to be asking for is something like WP:LUGSTUBS2. It turns out that the community is deeply divided on this issue, and the status quo reflects the lack of a unitary position either to delete sports stubs in bulk or to protect them from deletion. 1.5 years later, I don't see any indication that there's been a strong shift in community feeling to either side of the debate; an attempt to "clarify the community's position" would almost certainly repeat LUGSTUBS2, i.e., expend enormous amounts of time and emotional energy without coming to a really definitive answer. "The lore" is not just some weird handle to allow grognards to flex on you; it's an important record of what the community will and won't accept. I think unfamiliarity with these past transactions has led you to massively underestimate the cost to the community of establishing "consistency" on a point where there is no consensus, but rather a sharp division of opinion. I know you mean well and I can see why the inconsistency would bother you, but this is not something that can be fixed up with a casual discussion and promulgation of a new guideline. Choess (talk) 18:06, 20 February 2025 (UTC)[reply]
Thank you Choess, I appreciate the thoughtful response. I was hesitant to post about this, but I'm glad I did, because this discussion has certainly given me a different outlook on AfD in general. Perhaps the best solution really is no solution. I would get behind @BeanieFan11's idea for a WikiCup, though. Kylemahar902 (talk) 18:44, 20 February 2025 (UTC)[reply]
Just don't deal with sportspeople stubs. Why make more work for yourself and others? Phil Bridger (talk) 18:40, 20 February 2025 (UTC)[reply]
No offense, but not only are you opening up a can of worms, but you are opening up a can of worms that has had something like 1 million words and counting expended on it, and is responsible for some very ugly rhetoric directed at people (sometimes long after they've left the project). I'm going to give you the benefit of the doubt and believe you that you independently came up with this idea, but most of this discussion -- this reply included -- is the same people fighting the same battles now that they've been gifted another battlefield. Gnomingstuff (talk) 07:51, 23 February 2025 (UTC)[reply]

I do a lot of NPP's. Regarding sportspeople, I sure wish we had a workable notability standard. We went from one extreme ("did it for a living for one day") to "full GNG" (which approximately 0% of new sportspeople articles meet). I try to interpret what the "middle of the road" community standard is which is sort of a "1/2 GNG" with at least a a bit of content outside of stats/factoids. A FAR bigger problem are multi-criteria topic "stats only" articles (like "The 2013 season of the XYZ team" or "the XYZ tournament of the XYZ sport at the XYZ location") with zero even 1/4 GNG sources and maybe one or two of the stats turned into a sentence. There are a lot of these being created by completionists. ("I'm going to create an article from databases for each year for each team"). These are piled up in the backlog, probably because NPP'ers (like me) avoid having one of those miserable "trips to AFD" days. Sincerely, North8000 (talk) 20:09, 25 February 2025 (UTC)[reply]

Applying my previous post to the specific topic at hand, given that we have extreme deletionists out there, and extreme inclusionists out there (who forget that we are an enclyclopedia covering material in articles) the question is unsolvable until there is a realistic wp:notablity standard (or de facto practice) for these. Without that:

  • The inclusionists can take 3 minutes to make an "article" out of what should be a list item and the demand a 2 hour "before" search including finding and GNG-evaluating non-english articles (or proving a negative that they don't exist) as a condition to get rid of a non-article that they took 3 minutes to make
  • The more extreme exclusionists out there (and they exist) applying a literal reading of selected rules can say that 99% of sportspeople articles don't meet (a rigorous interpretation of) GNG, and the community doesn't want to turn them loose and start a purge of the 99%. But the only tool they have for keeping them at bay is the ham-handed one of making ALL deletions difficult.

Solving this needs a workable notability standard for these. My idea would be that there be at least one source that is an edge case regarding being a GNG source included in the article. Finding and including such a source should be considered the main useful task of creating or keeping such an article. Making an "article" out of a database entry with only database sources isn't useful work, it's littering, and somebody who just calls for an unusually thorough "wp:before" makes it a huge job to remove each one piece of litter. Conversely, we should consider a norm for sportspeople articles that if there is an at least "close-to-GNG" source in there and a couple sentence of prose that isn't just turning a database factoid into a sentence, that the norm is to not bring it to AFD and to keep any that meet that criteria. Sincerely, North8000 (talk) 22:25, 25 February 2025 (UTC)[reply]

I don't demand a "two-hour BEFORE" or any of the other extreme exaggerations that opponents of asking deletion nominators to expend any effort claim, I simply want two things:
  • A BEFORE search that includes looking for sources in the most likely place for such sources to exist.
  • Deletion nominators to summarise their BEFORE searches in their nomination. Not only will this demonstrate whether they actually have done an adequate BEFORE search, but also it helps other commenters avoid duplicating effort (if you spent an hour searching e.g. Google books then say that, so that someone else can spend their available hour searching somewhere different). 23:55, 25 February 2025 (UTC)
Thryduulf (talk) 23:55, 25 February 2025 (UTC)[reply]
North, do you remember the discussion about six months ago at Wikipedia:Village pump (policy)/Archive 194#"Failure to thrive"? Campaign desk was an example AFD there. A couple of us found multiple reliable sources for it. Guess what? They're still not in the article. A highly experienced, well-respected (including by me) admin "cared" enough about it being unsourced to try to get it deleted on the grounds that it was uncited, but apparently didn't care enough to copy and paste the sources into the article. This doesn't require a "two-hour BEFORE"; this requires two tabs and three minutes. WhatamIdoing (talk) 00:16, 26 February 2025 (UTC)[reply]
My idea would be that there be at least one source that is an edge case regarding being a GNG source included in the article....Have you not read NSPORT? Has no one here read NSPORT? JoelleJay (talk) 00:33, 26 February 2025 (UTC)[reply]
Why don't you be more specific instead of just referring to an entire guidline and implying that nobody read it or missed something relevant to this discussion?

Okay, look, I can't take this anymore. I shouldn't have brought it up. I'm going to opt out of messages from this discussion. I'm not trying to upset, or offend, or hurt, I'm just trying to remove poor articles. I don't want to be involved in the discussion anymore. I appreciate everyone's time and effort. RossEvans19 (talk) 02:15, 26 February 2025 (UTC)[reply]

To clarify: NSPORT literally already says that a fully-GNG-contributing source must be cited in all sportsperson articles, regardless of whether an athlete meets a sport-specific SIGCOV-presuming criterion. We don't need to propose having "GNG edge case" sources when the guideline is already extremely clear from an extremely well-attended global consensus. That so many athlete articles do not cite an IRS SIGCOV source is a problem, as articulated by a supermajority of the policy-aware community, and if editors cannot identify sources to bring these articles into compliance then AfD is absolutely acceptable. JoelleJay (talk) 05:55, 28 February 2025 (UTC)[reply]

I bolded the part that made it a two hour before to satisfy some of the demands. To further explain, it is what it would take to analyze the sources in a non-English search to see if they are GNG grade. And doing enough of that to prove a negative when they don't exist. North8000 (talk) 03:35, 26 February 2025 (UTC)[reply]

  • Speaking of WP:BEFORE searches, stuff like Wikipedia:Articles for deletion/Ismael Mahmoud Ghassab is why it should really be enforced more. A subject which it is exceedingly clear no adequate BEFORE search was done – the subject is Arabic from the pre-internet era, the nominator says they "can't read Arabic" but then immediately shifts the question of BEFORE to others and declares that anyone asking about it is just "playing games"... BeanieFan11 (talk) 22:43, 27 February 2025 (UTC)[reply]
    If you know that your search was ineffective (e.g., because you searched English-language sources for a person who would have been covered only by non-English sources), you probably shouldn't send it to AFD at all. Apply a little collegial humility, you might say.
    We have talked before about the misaligned incentives. If a subject is notable but the article is unsourced or weakly sourced, we actually don't want an AFD to happen at all. AFD means anyone interested in the subject needs stop working on their goals and reply before the seven-day WP:DEADLINE. But if your own goal is to force somebody else to prove that this subject is notable right now, then AFD is a very effective method of getting what you want. And, hey, if that means that other, more important articles are getting neglected or other, more important problems aren't being addressed, then that's not your fault. The universe should be providing the community with an unlimited amount of time and energy to meet your demands, or those other editors just shouldn't care whether we delete these unimportant articles about people from non-English-speaking countries. I mean, really: who actually cares if we delete this apparently accurate information? WhatamIdoing (talk) 23:40, 27 February 2025 (UTC)[reply]
I agree with WhatamIdoing. There are times people are active, but they're not editing sometimes. Regarding articles, this is why I've been having a difficult time cleaning up pre-internet articles, but the only problem is I don't have experience with referencing archived newspapers. ⋆｡˚꒰ঌ Clara A. Djalim ໒꒱˚｡⋆ 11:16, 6 March 2025 (UTC)[reply]
If you're having trouble finding archived newspapers, and the subject is reasonably expected to be covered in English-speaking newspapers (e.g., a non-famous US Olympic athlete from the 1980s), then try Wikipedia:The Wikipedia Library. Remember that you have to search some partners individually, so you can't just rely on the big search box at the top.
If you're having trouble figuring out how to WP:CITE old newspapers, then remember that URLs are not required. You can just write this:
  • Journalist, Jo (29 February 1964). "Local Player Goes to the Olympics". The Local Daily News.
If I've found it in TWL, then I like to put <!-- [[WP:TWL]] --> in the |via= parameter. It's invisible to readers but gives a hint to future editors. WhatamIdoing (talk) 17:28, 6 March 2025 (UTC)[reply]
Thanks for reminding me, but I'm afraid I don't have access to those newspapers. Normally, I'm cleaning up sportspeople from outside English-speaking countries. Someone else might know it. ⋆｡˚꒰ঌ Clara A. Djalim ໒꒱˚｡⋆ 14:46, 7 March 2025 (UTC)[reply]
When you need help finding sources, especially non-English sources, then I sometimes leave a note at a relevant WikiProject (e.g., Wikipedia:WikiProject Egypt) to ask for help. Wikipedia:WikiProject Unreferenced articles might be willing to help if the articles are actually unref'd. WhatamIdoing (talk) 17:57, 7 March 2025 (UTC)[reply]

I wonder if Wikipedia:List of Wikipedians by article count plays a role in motivating editors to mass-create sportspeople stubs. Lugnuts apparently cared about that sort of stuff, judging by their userpage. Some1 (talk) 05:23, 5 March 2025 (UTC)[reply]

@Some1: That is exactly the reason why we ultimately decided to scramble the top 100 on that list. BD2412 T 19:58, 6 March 2025 (UTC)[reply]

Proposal: mass merges

Why is it not obvious that the solution here is to merge and redirect these stubs into lists of these sportspeople organized by sport and nationality, breaking them out into individual articles when sufficient content and sourcing exist to support individual notability? BD2412 T 20:13, 6 March 2025 (UTC)[reply]

We absolutely do not need to break them out by decade, for athletes in specific sports, particularly from smaller countries. The suggestion that such lists will fail NLIST is not reality. Of course athletes in a given sport in a given country will be discussed as a group. BD2412 T 23:10, 6 March 2025 (UTC)[reply]
@BD2412, maybe you should look at Wikipedia:Articles for deletion/List of current MPBL North Division team rosters, Wikipedia:Articles for deletion/2022 Pacific Women's Four Nations Tournament squads, Wikipedia:Articles for deletion/2022 WAFF Women's Futsal Championship squads, and some similar pages. We can have thousands of lists in Category:Sportspeople by club or team, but this argument is actually made and accepted on occasion, and usually for less popular sports, women's teams, and teams that are from developing countries. WhatamIdoing (talk) 23:21, 6 March 2025 (UTC)[reply]
Individual teams, maybe, but sportspeople for an entire sport in an entire country? BD2412 T 23:22, 6 March 2025 (UTC)[reply]
Well, there's plenty of countries that have had only one Olympian in a particular sport in the history, for example. BeanieFan11 (talk) 23:27, 6 March 2025 (UTC)[reply]
Some AFD folks are very much in the Show me the money mindset; common sense does not always prevail. What's a matter of "Of course" to you and me is a matter of "Links or it didn't happen" to others. WhatamIdoing (talk) 00:48, 7 March 2025 (UTC)[reply]

Add an AI-Talk tab to each page

LLMs are now useful in their ability to generate encyclopedic-like material. Quite rightly Wikipedia heavily limits bot/AI editing. It is not possible to make use of LLMs within those bounds, and the bounds should not be loosened to accommodate LLMs. So how can the power of LLMs be harnessed for the benefit of Wikipedia without undermining well-established and successful processes for developing content?

I believe it would be useful to add a 3rd tab to each page where AI generated content either from human activity or bots could be posted, but clearly distinguished from other discussion.

On the (existing) Talk page, an appropriate response to lack of engagement to one's proposal is be WP:BOLD.

However, on the AI-Talk page the default response must be to resist editing. This would allow human contributors to check proposed AI based edits for value and encourage or enact them following normal Wikipedia guidance. However, if no human editors engaged with the AI proposal then no harm would be done because no edit would be made without such engagement.

The approach I propose allows the wikiepdia editing community to organically determine how much effort to put into making use of AI-generated content, and in doing so may make clear what kind of AI involvement is helpful. DecFinney (talk) 15:38, 21 February 2025 (UTC)[reply]

Wikipedia will not, and will never implement AI slop content. We are one of the few places left on the internet that haven't embraced this corporatized, overhyped technology and most people firmly intend to keep it that way Mgjertson (talk) 16:08, 21 February 2025 (UTC)[reply]
@DecFinney: No. AI has a known problem with blatantly making things up and is incapable of actually assessing sources. You're proposing to include a section which by default is going to be filled with junk to the point people will just blatantly ignore it to avoid wasting their limited time. (On a related note, I recently had to help assess a fully-AI-written draft; aside from the usual tells the reference list included cites to two books that did not exist.) —Jéské Couriano v^_^v threads critiques 16:24, 21 February 2025 (UTC)[reply]
Wikipedia is the opposite of AI. It’s like oil and water; they just don’t mix. Pablothepenguin (talk) 19:57, 21 February 2025 (UTC)[reply]
A few years ago we had an article suggestions system, but for human rather than AI suggestions. One of the reasons why it failed, and was predicted to fail from the outset, is that we are primarily a community of people who want to write and correct an encyclopaedia, with an emphasis on the first part of that. Hence we have to have measures such as quid pro quo at DYK, and a bunch of watchlisting and other systems to encourage our volunteers to play nice with others who add cited info to their work. We find it easier to recruit volunteers who want to write than volunteers who want to check other people content. Before we take on a scheme to create loads of content suggestions for our volunteers to check and integrate into articles, we need to find a way to recruit a different sort of volunteer, someone whose favourite task is checking and referencing other people's work. Otherwise we have a scheme to make Wikipedia less attractive to our existing volunteers by trying to distract them from the sort of thing they have volunteered to do and instead direct them into something they find less engaging. Worse, like any attempt to organise Wikpedians and direct them towards a particular activity, we undermine one of the main areas of satisfaction that editors have, the autonomy that comes from choosing which tasks they want to undertake. That isn't to say we can't have AI tools that make Wikipedia a better place, but we need to find ways that work with the community rather than against it. That said, I'm currently testing some typo finding AI routines, and I think there is some potential there. ϢereSpielChequers 22:13, 21 February 2025 (UTC)[reply]
Thanks for such a thought-through reply. Ultimately, I don't think having an AI-Talk page would require that anyone change how they currently interact with editing Wikipedia (nobody has to use the existing Talk page). Therefore, I don't think the feature would act against the community except indirectly through the potential for wasted effort/resources. The Ai-Talk page would be there for those that were interested.
Nevertheless, you make some good arguments that this kind of feature is not one likely to be well-used by existing users.
You also make me think about how such an approach could lead to an overly homogeneous style to Wikipedia articles. I'm not sure everyone would consider this a bad thing, but I do think that could be an unfortunate consequence of using AI-generated content. DecFinney (talk) 14:38, 22 February 2025 (UTC)[reply]
Maybe an AI talkpage would be treated differently than the normal talkpage. But we have a lot of editors, and many of those who write content are the people who are hardest to engage with proposed changes to the features. I'm thinking of the proverbial person who spends an hour or to a month checking some articles they watch. I suspect a lot of those editors would feel they had to respond to the AI talk as well, otherwise eventually someone would change the article with an edit summary of "per AI talk" and they'd feel they lost the opportunity to point out that the paywalled sites they have access to take a very different line than the fringe sites that are free to access. ϢereSpielChequers 18:24, 22 February 2025 (UTC)[reply]
Strong point, well made. Thanks. DecFinney (talk) 09:46, 24 February 2025 (UTC)[reply]
Absolutely not. It is a terrible idea to let the junk generators (and possible WP:BLP violation generator) loose on a page that, let's be real, is not going to be closely watched. We do not need a graveyard of shit attached to every article. Gnomingstuff (talk) 23:45, 21 February 2025 (UTC)[reply]
@Jéské Couriano @Gnomingstuff - The proposed AI-Talk page is a self-contained space for proposed content that has involved AI-generation. The default is that no edit to the article can be made unless human contributors permit it (i.e. they would not be "loose on a page". Therefore, I don't understand what you are afraid of. If you are correct and AI-generated content is never good enough, then it would not be used. If I'm correct in thinking that at times AI-generated content may be useful in improving a page, then it would be used in such cases, while poor AI-generated content would be left to archive on the AI-Talk page.
My impression from your responses is that either: 1) You're worried Wikipedia's human editors are not capable of effectively using AI-generated content from an AI-Talk page, or 2) You're scared that in some cases AI-generated content may actually prove good enough to improve Wikipedia articles and therefore be used.
Just to note, that various safeguards could be put in place that would deal with most of the tangible concerns you raise, e.g. no AI-Talk page for featured articles, no AI-Talk page on WP:BLP, possibly only allow registers users or users with advanced experience to view and use the AI-Talk page. DecFinney (talk) 14:54, 22 February 2025 (UTC)[reply]
I don't really understand what the proposal is trying to do. Is the idea to have an AI evaluate all ~7million articles? If so, how frequently? If anyone wants AI feedback on a particular article, they can input the current version of an article into their AI engine of choice. This is possible without any of the work needed to add a whole new area to en.wiki. CMD (talk) 15:11, 22 February 2025 (UTC)[reply]
I imagine, that in the same way that people make bots that make direct edits to pages, their might be useful tasks that bots could do but which are too subjective and risky to allow direct edits. Instead they could post to AI-Talk, to allow a check of what they are doing. What tasks AI bots were allowed to contribute could still be constrained but there would be more opportunity to explore their potential without doing direct harm to a page. In summary, I don't have a prescribed view of what would be undertaken, it would be dependent on what bot develops would look to address and the constraints on that agreed by the Wikipedia community. DecFinney (talk) 09:49, 24 February 2025 (UTC)[reply]
I understand what and where this page is proposed to be. Your impression is wrong. My response is:
3) I am concerned -- with good reason -- that AI-generated content produces false statements, and that when they are applied to real, living people, those false statements are likely to be WP:BLP violations. There is no way for a human editor to "effectively" use false statements, and there is no point at which they are "good enough." The problem is that they exist in the Wikipedia database at all.
As such, the BLP policy is that we need to be proactive, not reactive, in not inserting BLP violations anywhere, and should remove them anywhere they come up -- including on talk pages and project pages, which are still pages. So, one way to be proactive about that is to not do something that risks them accumulating on largely unmonitored (but still visible and searchable) pages.
Even non-BLP falsehoods are not things that we want to commit to the database. I don't think you realize the extent to which this stuff accumulates on even prominent articles, or talk pages with enough activity to get really long. We do not need an accelerant, there are already 20+ years of this shit to clean up. Gnomingstuff (talk) 17:19, 22 February 2025 (UTC)[reply]
@DecFinney: Do the words Seigenthaler incident mean anything to you? —Jéské Couriano v^_^v threads critiques 17:21, 22 February 2025 (UTC)[reply]
@Jéské Couriano @Gnomingstuff - Thanks both for the follow-up. I am a physical scientist, I don't engage much with BLP side of Wikipedia but I appreciate it's a major component and I see your concerns. I don't see why there couldn't be a ban on AI referring to BLP, and no AI-Talk page on BLP pages. In which case, LLM's would still be able to benefit the non-BLP parts of Wikipedia.
@Jéské Couriano - Regarding falsehoods, I consider LLMs to have moved on a bit in the last year. They certainly do hallucinate and state things falsely at times (I don't deny that). But they are much more accurate now, to the extent that I think they possibly don't make more mistakes than humans on small bits of certain kind of text (I don't claim they could usefully write a whole article unaided, as things stand). That said, I think you are potentially acknowledging the fallibility of humans as well as AI in your "20+ years of this shit" statement. In which case I respect you point regarding not wanting "an accelerant" -- I would probably agree. DecFinney (talk) 09:57, 24 February 2025 (UTC)[reply]
@DecFinney: In order:
Does this help? —Jéské Couriano v^_^v threads critiques 19:05, 24 February 2025 (UTC)[reply]
Even if/when AI gets better, there are already loads of places where readers can get an AI summary of the subject (for example, the top of a Google search - and I'm quite sure Google will continue to improve their use of the technology). The world needs an alternative place, a place which gives a human-written perspective. It may or may not be better, but it's different, so it complements the AI stuff. My strong feeling is that Wikipedia should avoid AI like the plague, to preserve its useful difference! In fact the best reason I can think of to provide an AI tab is so that there is somewhere where people who really, really want to use AI can stick their stuff, a place that the rest of us can steadfastly ignore. In effect, the extra tab would be a sacrificial trap-location. Elemimele (talk) 18:04, 25 February 2025 (UTC)[reply]
I respect this point of view, and may even agree with it. However, I wonder if the wider global population in such a future is likely to continue visiting Wikipedia to any significant extent. And if not, then would editors still feel motivated to maintain such an alternative place?
I know you are probably jesting, but I do see the AI tab for human proposed edits that have a amajor AI comoponent, as well as bot generated proposed edits. So my suggesting is consistent with your proposed use of the AI tab :D DecFinney (talk) 10:08, 26 February 2025 (UTC)[reply]
It was a very early development of LLMs that they can be forced not to discuss certain topics. Since a list of topics off-bounds could be produced, I still do not see BLP has meaning LLMs could not be used on non-BLP topics. I understand your arguments but I think either you don't understand that, or disagree that, LLMs can be constrained. Either way, I respect your disagreement but I feel like we are now going round in circles on this particular point. I am happy to agree to disagree on it.
I see your experience and impression of AI-generated content. It is familiar. Nevertheless, I have experience that LLM-generated content is at times effective, though it still requires human engagement with it.
I agree with your point around "source assessment" being key, and agree that AI is not good at this. I do, however, think AI has been steadily improving on this skill over the last year. Though it is still not good enough. DecFinney (talk) 10:16, 26 February 2025 (UTC)[reply]
@DecFinney:
  • Even if you constrained the LLMs, contentious topics are broadly construed, and as such include discussions and sections on pages otherwise unrelated to the contentious topic. (To use a recent example, Sambhaji falls under WP:CT/IPA, WP:RFPP/E does not, and a request for Sambhaji on RFPP/E falls under WP:CT/IPA.) You would likely have to hand-code in every single article that is under a contentious topic - which I'd estimate to be at or around 1 million (and I'm low-balling that) - which becomes more and more untenable due to tech debt over time, either due to new articles being created or CTOP designations lapsing (YSK, HE) or being revoked (SCI, EC). And this would still result in the AI potentially sticking its foot into its mouth in discussions on unrelated pages.
  • You can't improve AI's ability to assess something it is fundamentally incapable of interpreting (scanned media and offline sources). The (legitimate) sources in the draft mentioned were both scans of print media hosted on the Internet Archive.
—Jéské Couriano v^_^v threads critiques 06:49, 27 February 2025 (UTC)[reply]
Thanks @Jéské Couriano I respect your view, and your concerns are well-founded. I think our experiences and impression of LLM potential is different so I'm afraid I do not agree that it is definitely impossible to address your concerns. I do not intend to take this idea further at this point, so I will not continue to try to persuade you otherwise. Thank you for engaging in the discussion, I have found it interesting. DecFinney (talk) 08:24, 27 February 2025 (UTC)[reply]
Red X symbolN Oppose. I don't want to see AI taking over Wikipedia. The Master of Hedgehogs (talk) (contributions) (Sign my guestbook!) 16:10, 27 February 2025 (UTC)[reply]
Ah well, this is a great idea. I'm sure they won't violate WP:BLP! Worgisbor (Talking's fun!) 20:40, 7 March 2025 (UTC)[reply]

Policy for anonymous edits

Given the recent ANI, Le Point, Sambaji situations (See the most recent The Signpost coverage and also List of people imprisoned for editing Wikipedia), where editors have faced persecution for edits they made, I believe a creation of a process for making anonymous edit is needed. I drafted a rough prototype at User:Ca/Anonymous edits. Any ideas for improving the process are welcome. In particular, I am still working out what should happen if an anoymized edit was reverted by a good-faith user. Ca talk to me! 12:15, 28 February 2025 (UTC)[reply]

One thing that immediately springs to mind is that what is described here are not really anonymous edits, but edits where the identity of the author is confidential and only known to an admin. This makes me extremely worried about the wisdom of a volunteer admin taking on such a responsibility when the stakes are so high, the security of their own identity, and their ability to self-assess whether they live in 'safe circumstances' (notably, most people in Western democracies that have not interacted with the justice system do not feel threatened by it... until they do). Not to mention the potential blowback from a Wikipedia policy/process implicitly or explicitly vouching for any of these things.
I think this is a noble goal but very risky as currently conceived. Investigating means of facilitating supervised, cryptographically-secure edits seem more feasible to me. – Joe (talk) 12:31, 28 February 2025 (UTC)[reply]
A pseudonymous right to disappear might be better - a method of allowing a permanent namechange, logged possibly with Arbitration rather than an admin, which is agnostic for the reason as to why the person wants the namechange. Old account is shut down and locked. New account is opened with no technical information indicating that the new account is the old one. It would have to adhere to new account restrictions like ECR but it would allow a person afraid that their identity was compromised in a way that might threaten their safety to disappear without having to stop editing altogether. this would require changes to WP:CLEANSTART and there would have to be a method to prevent this from being exploited for socking. Simonm223 (talk) 14:36, 28 February 2025 (UTC)[reply]
There are limitations to the effectiveness of such a scheme. Basically, anyone can apply the duck test, and non-Wikipedian actors are not constrained by any of our policies in rooting out the possible identity of an editor. We can make it as hard as possible for governments or other agencies to discover the real life identities of editors, but an agency with sufficient resources and will can probably eventually discover the real life identity of any active editor. That said, we should do everything we can to hinder efforts to discover real-life identities of WP editors. Donald Albury 16:18, 28 February 2025 (UTC)[reply]
I agree that there is a big risk in a single admin handling such responsibilities. Perhaps a softer version of the proposal can be implemented, where the roles of an oversighter is expanded to allow the deletion of usernames on edits upon request under reasonable concern of future harassment. Ca talk to me! 09:20, 3 March 2025 (UTC)[reply]
It's an interesting idea with many possible comments. My primary thought is that this doesn't require an administrator. I also agree this should be labelled as 'proxied', there are several other possibilities, rather than 'anonymous'. That's because anyone making the potential edit is far from anonymous and carry for themselves many potential risks. -- zzuuzz (talk) 16:49, 28 February 2025 (UTC)[reply]

Seems a good a place as any to put this. Here's a process I've been thinking about, which has some overlap with this proposal.

  • First, an account -- let's call it AnonymizerBot -- is set up with an IP block exemption to allow it to connect via proxy.
  • A user wishing to be anonymous sends a message to the bot via Signal or similarly secure platform.
  • [one-time step to verify the user is who they say they are]. Someone with better cryptographic knowledge than me would need to come up with a step to hash the user's Signal contact for future reference.
  • AnonymizerBot checks to ensure the user is in good standing (no active sanctions, edit count above a certain threshold, account age over a certain threshold, and not on a manually updated list of users who cannot use this service). It also checks to see if the user has edited the page in the last X months (I do not think there would be community support for someone making some edits with their account and some edits anonymously).
  • Assuming the user is in good standing and has made no recent edits, the request is added to an anonymized queue for review by some user group akin to pending changes reviewers (perhaps it's even an extension of pending changes, but with different criteria for reviewers). These reviews are organized in two categories, based on a variety of factors (e.g. the size of the edit, an ORES (or similar) evaluation, the experience level of the user [perhaps whether they're on a bot's whitelist], etc. We would also need to determine how/whether to log reviews and how to select reviewers (not just trust, but security reasons):
    • Changes that require a single approval, at which point AnonymizerBot will make the edit. (How to take an input from anonymous editors that can be parsed into an actual change is another technical challenge). This is similar to pending changes.
    • Changes that require some higher threshold to be accepted, such as an OK by multiple reviewers or some consensus process among reviewers.

The key difference between this and the process above is that no identifiable editor is actually making the log, so the WMF has no information to be subpoenaed other than the proxy address the bot connects from. The bot in turn should have no logs apart from an encrypted list of users who can use it. There are several challenges in here, granted, but it's another idea... — Rhododendrites talk \\ 20:08, 28 February 2025 (UTC)[reply]

How would the bot have no logs? Would we need every edit it makes to be suppressed? Or do you just mean there wouldn't be a log of who uses it? JJPMaster (she/they) 19:02, 3 March 2025 (UTC)[reply]
The latter. Talking about the bot's logs, not Wikipedia's logs of edits. — Rhododendrites talk \\ 20:45, 4 March 2025 (UTC)[reply]

Thoughts about browsing and navigation

I'm posting this in the idea lab because it's more open-ended, but I've been giving some thought to how Wikipedia functions from a casual reader's perspective. Editors have been worrying about LLMs as they invade Wikipedia's space as a search tool where people Google something and then pull up the associated Wikipedia page. But many readers are simply interested in browsing Wikipedia and going down rabbit holes, and that's somewhere we could excel if we were to do more for these readers. Our navigational tools aren't the greatest. Right now we have:

  • The main page, which could be improved but works okay for giving people a few articles each day.
  • Categories, which are not intuitive to a lot of people.
  • Outlines, which would need quality checks, and are well-hidden so that most people don't know about them.
  • Portals, which were popular historically but are increasingly hidden.
  • Sidebars and navboxes, which work well but aren't accessible on mobile.

Categories and navigation templates are more technical in nature, while outlines and portals are obscure because editors (as opposed to readers) dislike them. I'm interested in hearing what others think about this sort of thing. Thebiguglyalien (talk) 🛸 00:46, 3 March 2025 (UTC)[reply]

Statistically, most readers click on a maximum of one link per session. Usually, that link is in the article's lead. (The most popular link is the official link for a company/organization/film/etc., but the second most popular link is something in the lead of the article.)
I suspect that people who are really doing the "rabbit hole" aren't looking for organized lists. They are playing their own personal version of Wikipedia:Getting to Philosophy: they read, click an interesting link, read some more, click another interesting link, and so forth. WhatamIdoing (talk) 06:32, 3 March 2025 (UTC)[reply]
This isn't meant to appeal to all readers. It's meant to appeal to the readers who would be interested in this. And of course Wikipedia isn't used for browsing when we don't provide highly visible options to do so. That's why I'm hoping someone will come along with constructive input. Thebiguglyalien (talk) 🛸 23:46, 3 March 2025 (UTC)[reply]
What sort of navigation are you thinking of? I would wager that outlines and portals are not much better than the main page of a topic, where you would expect the links to be similar, just embedded in more context. This likely applies to navboxes too, although at least those are roughly constrained to a single screen. For category navigation, that's a longstanding challenge but we have H:DEEPCAT, which helps to some extent. Missing from your list is Special:Random. CMD (talk) 02:30, 4 March 2025 (UTC)[reply]
I wonder if we could set up a Special:Random toy, suitable for April Fool's Day, that takes people to a related article. Same article topic, maybe? A simple search for similar articles? WhatamIdoing (talk) 21:11, 4 March 2025 (UTC)[reply]
Special:RandomInCategory is a thing, and e.g. Special:RandomInCategory/Stuffed toys can be used to choose a specific category in advance. Whether it is possible to pick a category from among those the current article being read is in I don't know. Thryduulf (talk) 21:32, 4 March 2025 (UTC)[reply]

A feature suggestion

Moved from Wikipedia:Teahouse § A feature suggestion

It would be interesting to have a "suggested edit" feature, whereby users —any users, experienced or new ones— could draft and suggest individual edits they're not too sure about and that they thus maybe don't want to immediately go live. Currently this staging can be done on the Talk page, but a "suggested edit" feature would provide another, possibly more direct mechanism. Once the suggestion is made, any other users could accept the edit – or just let it linger. Obviously, the longer any suggested edit lingers, the more likely the attempt to accept it would generate an edit conflict, at which point the suggestion would need to be manually worked in. This would be somewhat similar to —but also different from— the Wikipedia:Pending changes feature. "Suggested edits" could be submitted for any article, even by users who do have the right to just full-on edit the page. Perhaps the submitter of the suggested edit could even set a threshold i.e. this suggestion needs to be voted for by at least n other editors to go live. This feature would basically be an instrument of self-restraint and confidence and consensus-building, which could avoid some potential for controversy and friction and eventually overbearing "policing" altogether. It would set apart edits that really clearly should go in, and go in right away, from those it's quite reasonable to disagree on. Because once those are conflated, that can tempt overbearing policemen to treat constructive contributions very non-constructively. So I don't know, maybe a technical fix like this could avoid any such friction, and reduce opportunities for would-be self-appointed policemen to reach for the foot-guns. —ReadOnlyAccount (talk) 18:45, 4 March 2025 (UTC)[reply]

I remember reading about a similar proposal not long ago, and that could definitely be interesting to explore. Something inbetween pending changes and edit requests, making Wikipedia more Git-like, is a tempting idea, although I'd have to find the previous discussion as I remember some important points were brought up there. Chaotic Enby (talk · contribs) 20:38, 4 March 2025 (UTC)[reply]
Here's the link to the previous discussion, if you're interested. Chaotic Enby (talk · contribs) 21:28, 4 March 2025 (UTC)[reply]
For a period of time, an article feedback tool was deployed to selected articles on English Wikipedia that solicited suggestions. The community reached a consensus not to pursue a full deployment. The request for comments discussion in question used a now out-of-vogue format of commenters expressing a viewpoint and like-minded individuals signing up to support the view (without any opposes being collected), so without re-reading the whole thing, my recollection is that a significant factor was that the signal to noise ratio was extremely low (the report from the developer team stated that 12% of comments were useful). This made it both a poor investment of volunteer time, and a disincentive for volunteers to spend time examining the feedback, which resulted in backlogged queues. Anyone considering developing a new feature along these lines should look for a way to mitigate the problems encountered in the past. isaacl (talk) 04:31, 5 March 2025 (UTC)[reply]
You fail to make the case that the added benefit is worth the added costs—both short-term (developer time) and long-term (increased complexity, resulting in increased learning curve for newcomers). As you have noted, anyone can simply start a new thread to "suggest" an edit. ―Mandruss ☎ IMO. 11:51, 5 March 2025 (UTC)[reply]

Adding video content to articles

Someone started a discussion at WP:RSN about whether a video was an RS. It turned out that the intended use was not as a source, but to embed the video in an article. Since I had no experience with the question of adding video content, I went looking for information. MOS:IMAGES § Video content is relevant, but doesn't give a great deal of guidance: "Videos should be used as a supplement to article material, to concisely illustrate the subject in a way that a still image or text cannot do. Videos should not replace article text, and articles should remain coherent and comprehensive when video playback is not available" strikes me as the most relevant part. The WP:VIDEO infopage also has a bit of relevant discussion; the Examples of videos we can use section has several didactic/summary videos.

Some editors at the RSN felt that since the video wasn't being used as a source, the RSN wasn't the right venue to discuss the video's use, and that it should instead go to WP:NPOVN to assess whether the video is DUE in the article. I don't know whether the involved editors will take it there, but regardless of what's decided with that specific video and article, this all made me think that the video policy needs some work. In particular, it seems to me that a didactic video is like presenting content in wikivoice, but without any other source supporting it. Are we supposed to assess the video as an RS (e.g., do the creators/publisher have a reputation for fact-checking and accuracy)? Are we supposed to check that everything said/shown in the video is supported by existing text in the article that's sourced to other RSs? How long can a video be before it exceeds being a "concise" illustration? If it's intended to serve as a summary video, is that really a question of whether it's DUE? Etc. I figured I'd bring this here for discussion. @Rhododendrites, @Bastique, pinging you since you seemed interested in a more general discussion of video use (apologies if I misunderstood). FactOrOpinion (talk) 21:52, 4 March 2025 (UTC)[reply]

If I've posted this to the wrong Village Pump, please let me know the correct place to raise it. I'm not experienced at starting topics here. FactOrOpinion (talk) 21:56, 4 March 2025 (UTC)[reply]

  • With respect to summary style videos, am in support of the use of MDWiki:WPM:VideoWiki style videos, which are supportable by reliable sources and collaboratively editable. For Example. Doc James (talk · contribs · email) 00:44, 5 March 2025 (UTC)[reply]
  • I support the inclusion of summary and didactic style videos, as those supplement the article, made them more accessible and improve the overall experience of the readers. Many articles are long, and having summary videos will improve the learning experience in the core of the word encyclopedia. There are many examples of videos that could add to the articles, even documentary ones. This kind of videos are being used in other language Wikipedias, and adopted widely, but English Wikipedia is now lagging behind. And this goes against the current learning strategies people have (let's remember that Encyclopedias are for learning), where video and podcasts are consumed way more than written text. There's a huge gap between those who want to complement their readings with a summary video or extra learning material (it may be a didactic video about a subtopic, or a whole documentary) and what we are currently offering. Wikipedia should be the primary place to learn, and people is currrently going to YouTube or, even worse, TikTok, where standards for accuracy are worryingly low. Adding videos doesn't harm Wikipedia, it makes it stronger and more useful. Theklan (talk) 10:35, 5 March 2025 (UTC)[reply]
    Doc James, I have to admit that my response to the TB video was mildly negative. I didn't feel like I got anything useful from it being a video rather than just audio (and it sounded to me like an AI-generated voice). A video should "illustrate the subject in a way that a still image or text [or audio] cannot do." Did I miss something in the visuals?
    Theklan, none of that really addresses my questions, which are not about whether videos should be included in Wikipedia, but about what it is that we're supposed to assess in determining whether a given video is appropriate to insert into a given article. For example, do we need to assess that all of the content in the video is supported by existing RSs in the article, or by a combination of those and RSs that aren't in the article? (See, e.g., the Example that Doc James linked to, which identifies RSs for the video's content.) If it's intended as a summary video, are we supposed to identify the key ideas in the article and then check that the video addresses all of them? We have policies for the use of videos as sources, but we have very little policy that addresses the use of videos as article content. It seems to me that existing policy is insufficient. FactOrOpinion (talk) 15:50, 5 March 2025 (UTC)[reply]
    Yes, I understand that. But we are in a loophole here, because we also have policies against adding videos or images which repeat the content of the article. So, if the video has the same content the article has, but with visuals to make it more appealing, the argument against it would be that the content is already in the text. And, if the video adds content, like a documentary video, or the example that triggered this conversation, then it is not accepted because it doesn't reflect the text. As far as I see it, there are two different issues stopping us to innovate and add some interesting content (and maybe new contributors) to our project. Theklan (talk) 20:21, 5 March 2025 (UTC)[reply]
  • The essay Wikipedia:Wikipedia is not YouTube sums up my thoughts on this topic. Some1 (talk) 12:28, 5 March 2025 (UTC)[reply]
    That essay has two problems. The first one is in the nutshell section, when it says "Encyclopedia" means "not YouTube". The second one is letting all the knowledge in the world to YouTube, instead of claiming that we should be the center for those who want to learn something. It happened something similar in the late 1980s and early 1990s when printed encyclopedia editors claimed that "Encyclopedia" meant "not online". We can see where they are. Theklan (talk) 20:22, 5 March 2025 (UTC)[reply]
    While hosting an encyclopedia on YouTube could be a possibility, it doesn't mesh well with the model of Wikipedia, as videos are not really user-editable. Not sure about your historical analogy, given how major print encyclopedias like Encyclopedia Britannica did go online. Chaotic Enby (talk · contribs) 20:31, 5 March 2025 (UTC)[reply]
    I'm not suggesting to host an encyclopedia on YouTube, but to have more videos in Wikipedia. There are plenty of learning materials nowadays on YouTube, that are encyclopedic/educative. If Wikipedia is seen as a place where videos can help the text, there will be more people doing those videos, so we will have a better understanding of what is possible. Technically, videos are user-editable, in the same way that audios or images are user editable: it just takes more time. And we have Wikipedia:WikiProject Videowiki, which a software allowing the collaborative scripting and edition of videos.
    About the analogy, it comes from the book All the Knowledge in the World. And you are right, after a decade claiming that printed books were superior to online text, they ended up closing their printing media and adapting to the online world. I see that we are in the same point: we think that text is superior to other media, and that other media is going faster and deeper than we thought. We can adapt and see how we include rich media, or we can be a one-generation-wonder. Theklan (talk) 22:21, 5 March 2025 (UTC)[reply]
    Maybe you could request that the WMF create a new video-focused project called "Wikivideos" (en.wikivideos.org) or something similar. Some1 (talk) 23:33, 5 March 2025 (UTC)[reply]
    Eventually, that may happen, but we don't need it now, as we already have Commons. We can even make dedicated video portals at Wikipedia using the videos in Commons. Take a look to eu:Atari:Hezkuntza/Ikusgela for an idea on how a didactic video project can be organized at Wikipedia. Theklan (talk) 07:01, 6 March 2025 (UTC)[reply]
  • I can't see a problem with videos created through consensus and normal contribution-tracking editing, following all content policies, and that respect copyright, being included as a summary of a topic. Tools to make such could be a barrier. In terms of video as content, the block here is more accessibility, since those reliant on screen readers will not see it, so the video must stay within bounds of what is already presented in text. Masem (t) 16:00, 5 March 2025 (UTC)[reply]
    Masem, your idea about videos requiring the same kind of sourcing and allowing editing makes sense to me, though I wonder how we'd be able to track the effects of edits, as I don't know what the equivalent of a diff would be. My impression is that the video that Doc James linked to is consistent with your intent. I'm not sure how to address the accessibility issue, and I'll see whether there's a WikiProject that could provide guidance about that; one approach might be to add subtitles explaining the visuals, just as subtitles for the deaf include important sound effects, not just dialogue.
    Theklan, I think that adding examples of key uses could be a good addition to the existing policy. I don't know if one intent is to use visuals to make content more appealing; that's possible, but it involves judgements about what visuals are appealing (for example, I like good animation, but I find some animation visually boring, and I don't know that my assessments of "good" and "boring" would be widely shared). Personally, I'm more interested in visual content that accomplishes something more effectively than can be accomplished with words, still images, or audio. If a video adds content, then perhaps we should have an expectation that the editor adding the video will also add written content to the article. FactOrOpinion (talk) 20:54, 5 March 2025 (UTC)[reply]
  • Thank you for starting this discussion @FactOrOpinion! One of my responsibilities at WMF is to track where and how people like to get information online globally outside of Wikipedia, and for the past ~4 years I've been keeping a close eye on the growing global popularity of video platforms (i.e., TikTok, Instagram, and YouTube) as not just entertainment platforms but sources of learning and information. Here are some insights we have gathered via large-scale global surveys on this topic over the past couple of years that might be relevant for this conversation:
  • Gen Z-aged people (18-24 years old) around the world increasingly see video apps like TikTok and YouTube as places to get overviews of a wide variety of topics (both encyclopedic and non-encyclopedic) and find them more relevant and useful than visiting Wikipedia. (Source: Brand Health Tracker)
  • Despite this, we still have many Gen-Z-aged people coming to read Wikipedia today! In fact, most of our readers globally fall into this age group. The Gen Z people who do visit Wikipedia are quite different from those who don't in some key ways (e.g., they skew more male than the general population, and they report far less social media usage than the general population of 18-24-year-olds), but even they are currently also turning to video apps like TikTok and YouTube for information at greater rates than older Wikipedia visitors. (Source: Meta:Research:Knowledge Gaps Index/Measurement/Readers Survey 2023)
(We don't survey people younger than 18, so we don't have data on even younger people and their preferences in this regard, but I strongly suspect all of the above holds true for Gen Alpha, as well.)
I do think this may be indicating a growing preference for video as a learning format among younger people. However, it's not so straightforward to draw conclusions from this data about what kinds of videos might help people learn on Wikipedia. (We don't know, for example, to what degree the reason video apps are so relevant and useful for younger audiences is that they serve both encyclopedic and non-encyclopedic content – e.g., DIY, lifestyle tips, humor, etc. – that doesn't belong in Wikipedia.) And none of this data can answer the question of how/if videos could or should be used on Wikipedia in a way that respects the editable, collaborative, reliability-focused nature of the project – which is why I'm happy to see this discussion starting to flush out some of these deeper questions! Maryana Pinchuk (WMF) (talk) 21:08, 5 March 2025 (UTC)[reply]
@MPinchuk (WMF), it seems to me that if videos should be editable, one challenge is developing some means of identifying how a video has changed, without having to rewatch the entire video each time it's edited or having to assume that someone's edit summary is accurate and complete. With text, we have diffs that enable us to see all of the changes, and that helps in reverting vandalism or simply assessing whether a given edit improved the article. But I'm not sure how that would work with video content. Is this something that WMF is thinking about / working on / plans to work on? FactOrOpinion (talk) 00:06, 6 March 2025 (UTC)[reply]
@FactOrOpinion that's definitely a challenge (both making videos collaboratively editable and having some way to track changes made by multiple users) and is not something we're working on. But I imagine the level of complexity in reviewing would vary greatly depending on how long the video is and how often/by how many people it was being updated. With a short video and only the occasional edit, it probably wouldn't be much more work to get a sense of what the changes were than, say, reviewing that the sources added in a new text revision of Wikipedia accurately summarize from (and paraphrase without copyvio-ing) the source But I'm guessing a video over a few minutes long and/or with multiple people editing would get exponentially more tricky to manage. Maryana Pinchuk (WMF) (talk) 01:42, 6 March 2025 (UTC)[reply]
VideoWiki already handles diffs between videos, as the changes are done via text. However, that is one of the video types we could be adding. If you open WMF's TikTok account, you will find videos that summarize topics "Did you know" style, and could be a good addition to both articles or even the Wikipedia main page. In this videos you should follow AGF as we follow for other media. Imagine that I download Beethoven's 9th symphony file, I add randomly at 3:56 another sound, and I reupload the audio to Commons. That would be clear vandalism, but the file would still be available at Wikipedia until noticed. The same applies to other media. Theklan (talk) 07:05, 6 March 2025 (UTC)[reply]
I don't understand "the changes are done via text." Could you link to an example? I don't understand what "you should follow AGF as we follow for other media" refers to. We absolutely don't assume that potential sources are created in good faith, whatever media they're in. FactOrOpinion (talk) 13:32, 6 March 2025 (UTC)[reply]
At VideoWiki you can follow each change to the script: https://mdwiki.org/w/index.php?title=Video:Acne_keloidalis_nuchae&action=history or https://eu.wikipedia.org/w/index.php?title=Wikipedia:VideoWiki/Planeta_teluriko&action=history. Every change in the script can be coded (if clicked) into a new version of the video, so you can see what changed just watching the script (or the file in Commons, whatever you prefer). I agree with you that potential sources are not created in good faith, but currently taking any file we have at any article, inserting something that shouldn't be there, and reuploading the file is perfectly possible. We assume that people is not randomly inserting nasty images at Steamboat Willie video, funny sounds at Symphony No. 9 (Beethoven) or adding a vectorial layer behind another vectorial layer in a WWII map. And, if they do that, eventually we will revert and block the trolling. Theklan (talk) 14:24, 6 March 2025 (UTC)[reply]
Much of the above discussion is the reason why we don't have more video. The thing is, that fundamentally a good video is engaging, coherent and it tells a story. That makes it much more suited to being edited by one ore multiple people ONCE. This is also why many of the most successful science channels on YouTube are heavily focused around a single person Veritasium, Tom Scott, SmarterEveryday, physics girl, numberphile, just as it was in TV land with David Attenborough and Brian Cox. Being a good presenter and story teller matters. Creating a good coherent story with a TON of very expensive preparation, matters.
We on the other hand focus on bland facts, sourcing, completeness and changing our material all the time. Those are two styles that simply do not match very well (not impossible, just incredibly hard). It is like comparing a textbook at school with a video of the teacher explaining a single chapter in that book. Or thinking we could collective wikiwrite poetry at the level of the Illiad or The Complete Tales and Poems of Edgar Allan Poe. We can't, the work would lack the personality that makes those things as good as they are.
If people are really interested in creating a wiki version for educational video content, you'd be much better off indexing, sorting and verifying youtube content and making that presentable and navigable for an audience, then it is to write your own video for wikipedia in my opinion. —TheDJ (talk • contribs) 20:48, 6 March 2025 (UTC)[reply]
I think you are giving a good example of one of the problems we are facing within the media revolution. If we had, let's say, Veritasium videos with a Creative Commons license, or BBC would republish David Attenborough's documentaries with one of those licenses... what would we do? The current policies point towards not including those videos in articles, even as supplementary materials. Theklan (talk) 09:05, 7 March 2025 (UTC)[reply]
Those videos could be uploaded to the Commons then added to the hypothetical video-focused "Wikivideos" project. Some1 (talk) 10:16, 7 March 2025 (UTC)[reply]
I think that the good videos tend to be copyrighted for example Ken Burn's history videos or even The Great Courses videos by actual professors and experts. Ramos1990 (talk) 02:04, 10 March 2025 (UTC)[reply]
And the good photographs, and the good music. But here we are, promoting free content. Theklan (talk) 08:49, 10 March 2025 (UTC)[reply]

Hello all, as a member of the Wiki Loves Broadcast project, I think that videos can generally contribute to a good article (which is obviously not the controversial topic here). We have already gained some experience with this in the German Wikipedia and so far we have only included videos that come from a reliable source (public broadcasters from German-speaking countries) and also do not contradict the article and summarise the content from the article (either a section or completely). We have deliberately not included videos that have nothing to do with the article or have touched on topics that are not covered in the article. In addition, there are of course general criteria such as no topicality, no annoying music, etc. As we are also planning to collaborate with English-language content in the future, or perhaps videos other than these short explanatory videos will come about as part of these collaborations, I am following this discussion here with great interest. More information about Wiki Loves Broadcast can be found on Meta (page still under construction). — Preceding unsigned comment added by New York-air (talk • contribs) 14:29, 11 March 2025 (UTC)[reply]

Forums?

I think the Village Pump wasn't the right place to post this, so here it is: I think people can talk on a discussion forum whilst contributing to make a free and open-source encyclopedia... We should have two boards, one is related to Wikipedia, and the other one is any topic alike. We may have to change What Wikipedia Is Not, but I find this as a great idea. A editor from mars (talk) 06:23, 5 March 2025 (UTC)[reply]

Please do not duplicate discussions, this has already been replied to at Wikipedia:Village pump (proposals)#Forums?. CMD (talk) 07:09, 5 March 2025 (UTC)[reply]


WP:Long-Term Abuse

From time to time, a nomination is made at MFD to delete a Long-term abuse file. The reason given for deleting the abuse file is usually to Deny recognition. Miscellany for Deletion is a highly visible forum, while the existence of a Long-term abuse file is seen only by an editor who is actively searching for LTA files. So there is a Streisand effect in nominating a long-term abuse file for deletion. However, perhaps the real problem is that there is no control over the creation of these files. As a result, anyone can create an LTA file, while deleting an LTA file requires the public procedure of nominating it for deletion. This seems to put a cart before a horse. My suggestion is that we restrict the creation of Long-term abuse files to Checkusers and SPI clerks, who are the editors who normally deal with chronic offenders and have the training and background to know when it is useful to write them up and when they should be ignored.

It is true that any editor would have the technical capability to create Long-term abuse files, but these could then be speedily deleted without the need to deny recognition by providing recognition. Robert McClenon (talk) 03:23, 7 March 2025 (UTC)[reply]

Ambiguity of Unreleased Film Guideline

The guideline on the notability of unreleased films is ambiguous. There is currently a somewhat contentious Deletion Review in progress which reflects the fact that reasonable editors are interpreting the same guideline differently because the guideline is unclear. An attempt to clarify the guideline in November 2021 and December 2021 was closed as No Consensus, so the guideline is still ambiguous, and has been ambiguous since it was written in 2008.

The guideline on future films reads:

Films that have not been confirmed by reliable sources to have commenced principal photography should not have their own articles, as budget issues, scripting issues and casting issues can interfere with a project well ahead of its intended filming date. The assumption should also not be made that because a film is likely to be a high-profile release it will be immune to setbacks—there is no "sure thing" production. Until the start of principal photography, information on the film might be included in articles about its subject material, if available. Sources must be used to confirm the start of principal photography after shooting has begun.

In the case of animated films, reliable sources must confirm that the film is clearly out of the pre-production process, meaning that the final animation frames are actively being drawn or rendered, and final recordings of voice-overs and music have commenced.

Additionally, films that have already begun shooting, but have not yet been publicly released (theatres or video), should generally not have their own articles unless the production itself is notable per the notability guidelines. Similarly, films produced in the past which were either not completed or not distributed should not have their own articles, unless their failure was notable per the guidelines.

Some editors read the third paragraph restrictively. Some other editors read primarily the first paragraph. We agree that there are three classes of films:

  • 1. Films that have not begun production (principal photography or animation).
  • 2. Films that have at least began production, but have not been released.
  • 3. Films that have been released.

There is agreement that films that have not yet begun production may not have their own articles. The plans for such films are often discussed in the article about the filmmaker. There is agreement that articles about films that have been released should describe reviews and other third-party coverage. The question is about films that are in production, and are reported by reliable sources to be in production. The question is whether the significant coverage of these films should be about the production itself, or whether the coverage can be about the film, and may refer to production.

There have been differing interpretations of this guideline for years. An attempt to change the wording of the guideline by RFC resulted in no consensus, so there are still differing interpretations. The issue has to do with films, usually high-budget films, that are in production or have completed production and have had considerable coverage, focused mainly on plans for the film, rather than on the production itself.

Should the guideline be changed either to clarify that such films are normally not considered notable, or to ease the guideline for articles on films that have not yet been released? Robert McClenon (talk) 03:25, 7 March 2025 (UTC)[reply]

My issue with writing about pre-production films is that it seems most of what's published are rehashes of press releases as the production attempts to create "buzz" about the project. Like the weekly announcements of cast that have been attached to the project or fluff interviews. Would it be more understandable to editors for the guideline to explicitly note that such sources do not demonstrate notability? – Reidgreg (talk) 14:54, 11 March 2025 (UTC)[reply]

Reference prompt for new/IP editors

I believe one issue the encyclopaedia faces is contributions from new or IP editors in which information is added but not sourced.

My suggestion in response to this is that new or IP editors face a prompt before their edits are published along the lines of:

If you have added information to this article, have you provided an appropriate reference?

...with 'Yes' and 'No' buttons, and one for other kinds of edits (or it could be a two-part questionnaire).

Answering no would provide the editor with further information about Wikipedia's referencing policy and direct them to provide a source – with information too about correct formatting.

This seems to me a simple enough imposition to counter such edits. Any thoughts on the proposal would be much appreciated.

Will Thorpe (talk) 03:42, 7 March 2025 (UTC)[reply]

I believe the technical capability for something similar already exists, able to prompt users for a certain number of times, although I can't find what it was called and what happened to testing/deployment. CMD (talk) 06:18, 7 March 2025 (UTC)[reply]
That's mw:Edit check. Looking at Wikipedia:Village pump (idea lab)/Archive 62#New users, lack of citation on significant expansion popup confirmation before publishing, it looks like all that remains is for someone to actually do an RfC on edit check. Aaron Liu (talk) 12:31, 7 March 2025 (UTC)[reply]

Download pages as HTML?

Why you can download pages as a PDF file but not as a single HTML file with no scripts or stylesheets? I think you should be able to. 90.154.73.20 (talk) 09:14, 7 March 2025 (UTC)[reply]

Wikipedia pages are delivered as HTML files as default and all web browsers should allow you to save them, most with the option of making them self-contained. For example, using Firefox, you can right click on the page and select "Save page as...", which will be default use the "Web page, complete" format. – Joe (talk) 09:46, 7 March 2025 (UTC)[reply]
And how do I save Wikipedia pages as a single HTML file without any stylesheets? It won't look good. 90.154.73.20 (talk) 09:59, 7 March 2025 (UTC)[reply]
Also without any JS. 90.154.73.20 (talk) 10:00, 7 March 2025 (UTC)[reply]
Update: apparently, there's something called "&action=render" when a page will look like this and can be saved as a single HTML file. However, this produces slightly malformed HTML (no doctype, for example). I wonder why nobody made this a Wikipedia skin... 90.154.73.20 (talk) 10:07, 7 March 2025 (UTC)[reply]
Saving in "complete" format will give you a single file that looks the same as it does live by inlining the CSS and JS, if that's what you mean. Otherwise, saving just the HTML file will give you an unstyled view similar to your link above (which delivers just a fragment of the page, intended to be embedded elsewhere). The Wikipedia server doesn't need to do anything special to support this. It's a fundamental feature of the HTTP protocol. If you want to see Wikipedia pages without styles or Javascript, your browser probably has a setting for that too. – Joe (talk) 10:20, 7 March 2025 (UTC)[reply]
saving just the HTML file will give you an unstyled view similar to your link above - this will look good only if you use the "&action=render" parameter in the URL, otherwise (at least with Vector-2022) it looks really ugly.
Saving in "complete" format will give you a single file that looks the same as it does live by inlining the CSS and JS - for me saving in complete format creates a folder with all images, CSS and JS. I'm using Firefox. 90.154.73.20 (talk) 10:23, 7 March 2025 (UTC)[reply]
Oh that's right, you need an extension for the single file: https://addons.mozilla.org/en-US/firefox/addon/single-file/ – Joe (talk) 10:27, 7 March 2025 (UTC)[reply]

Edit recommendations

For new users or those who've made only one edit, we should add a "Recommended Edits" bar on top, for example how X asks you for interests and then gives you relevant tweets, have Wikipedia ask you about your interests and suggest pages. Batorang (talk) 10:07, 8 March 2025 (UTC)[reply]

That’s what the newcomer homepage is. It should be there if you click on your username at the top of the screen. If it isn’t there, you can turn it on in preferences. Roasted (talk) 15:44, 8 March 2025 (UTC)[reply]
@Batorang see User:SuggestBot. 86.23.109.101 (talk) 20:08, 8 March 2025 (UTC)[reply]
Special:Homepage Aaron Liu (talk) 15:04, 9 March 2025 (UTC)[reply]

The edit button for admins on a fully protected page should indicate that it's fully protected.

Tracked in Phabricator
Task T388405

Same goes for TE-protected pages. For ECP I don't know if this makes sense (since there are so many of them), but there have been a couple of times I've edited a fully protected page and not even noticed it. Sure, there is the gold lock, and I am personally able to see a protection log entry at the top of the edit page on desktop, but I suspizzle it would be easy to edit (or create) some MediaWiki page for this. If there already exists such a page, then my proposal is to make it say Edit (protected) or something. jp×g🗯️ 00:03, 10 March 2025 (UTC)[reply]

Source editing
Visual editing (the yellow background is custom CSS for all VE editing areas)
When I try and edit a fully protected page in VE I get a popup highlighting that it's a protected page. When using the source editor, the editing area background is pink (both using monobook on desktop, see screenshots). Additionally (but harder to spot) the tab at the top of the page reads "change protection" rather than "protect". Thryduulf (talk) 02:10, 10 March 2025 (UTC)[reply]
As for changing the button label, as best I can tell that text isn't set by a MediaWiki page, rather what the button says is set by the interface language - if you append ?uselang=cy to the URI all the interface elements change to Welsh and "edit" becomes "golygu" (compare [9] and [10]) and so would need to be defined on translatewiki. However, from what I can tell MediaWiki has no concept of "edit protected" in this context so it would require a software change. I haven't the foggiest how much work that would be to implement, but it sounds like a potentially useful change so I'll open a phab ticket when I'm more awake if nobody beats me to it. Thryduulf (talk) 03:42, 10 March 2025 (UTC)[reply]
Now phab:T388405. Thryduulf (talk) 13:19, 10 March 2025 (UTC)[reply]

Wrapping floating decorative elements in a standardized CSS class

Notified: Wikipedia talk:User pages HouseBlaster (talk • he/they) 21:02, 10 March 2025 (UTC)[reply]

A quick intro about what I mea by "floating decorative elements": I am talking about the stuff you can see on display at User talk:HouseBlaster/sandbox, which follows you down the screen when you scroll. I am not talking about {{skip to top and bottom}} (which is very helpful for longer talk pages), or other functional stuff. I am talking about the stuff which we put there for fun and decoration.

I love that people find a way to enjoy Wikipedia. "It is fun" is the main reason why I edit Wikipedia, and I'd imagine it is for many others, too. WP:MALVOLIO is a really good essay. The idea is not to ban this way of expressing yourself. But some people (myself included) find the elements annoying and distracting. They make it harder to read the content on the talk page by covering part of the text. This hurts most on mobile, where your screen space is already quite limited.

What I propose is adding a section to Wikipedia:User pages stating that these floating elements should be wrapped in a CSS class, such as floating-decoration. This is easy for anyone to do: simply place <div class=floating-decoration> before the wikitext generating the floating element and </div> after it. The CSS class lets anyone who finds these floating decorations annoying opt-out by adding a line to their common.css page hiding these elements if they so choose. (An example CSS line is at User:HouseBlaster/sandbox.css.) The CSS class only affect the appearance of the elemnts for people who have explicitly modified their common.css.

The idea is to provide an opt-out, not to ban the practice altogether.

Thoughts? In particular, anyone have a better name for the CSS class? Best, HouseBlaster (talk • he/they) 07:24, 10 March 2025 (UTC)[reply]

Sure why not.
(An alternative class name could be "decor-float". Not sure if that's better.) Aaron Liu (talk) 13:33, 10 March 2025 (UTC)[reply]

I should probably propose some wording; this would be placed as a subsection in Wikipedia:User pages § What may I have in my user pages?

Floating decorative elements
Shortcut

Editors are permitted to have a reasonable number of decorative elements which follow the reader down the screen on their user page, their talk page, or both. Some editors find these elements distracting or otherwise annoying. If they are included, they should be wrapped in class=floating-decoration. This allows anyone to opt-out of seeing floating elements by adding the following line to their common.css: 

.floating-decoration {display:none;}
Functional elements (such as {{skip to top and bottom}}) are not required to be wrapped in class=floating-decoration.

HouseBlaster (talk • he/they) 21:02, 10 March 2025 (UTC); c/e at 23:24, 10 March 2025 (UTC); clarified scope at 22:44, 11 March 2025 (UTC)[reply]

Wikipedia's new AI sidekick.!

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.
Similar ideas have already been extensively discussed before, and here again is a clear consensus against. Closing this as we don't need more pile-on opposition. Cremastra (talk) 14:19, 11 March 2025 (UTC)[reply]

Hello there,

I've been visiting Wikipedia for quite a while and I like how much info is here! But sometimes, I find myself turning to a chatbot to get the main point of an article—like with Mind at Large. Skimming didn’t quite cut it, and I needed a quick, clear explanation.

What if Wikipedia had a small AI helper—maybe a little icon tucked in the corner (like Grok on X)—that stays out of the way unless you click it? You could ask something like, “What does ‘Mind at Large’ really mean?” and it’d give you a short, simple summary. Nothing fancy, just the crux of it. I think this could help a lot of users, especially on tricky or dense topics that aren’t super clear right away.

A feature like this could make Wikipedia even more welcoming and useful, drawing in more people (like how Grok boosted X). It’d be great for articles that are hard to grasp or need a little extra clarity.

What do you all think? Could this be a fun, helpful addition? Maverick 9828 (talk) 17:48, 10 March 2025 (UTC)[reply]

As has been stated multiple times whenever someone suggests something along these lines: no. signed, Rosguill talk 17:55, 10 March 2025 (UTC)[reply]
To agree completely with Rosguill: no. SportingFlyer T·C 18:20, 10 March 2025 (UTC)[reply]
Thanks... It's not like it's [AI is] all bad. This feature will save time and get more people to Wikipedia for finding a quick, witty or however prompted solution tailored to their need from the huge pile of information. Maverick 9828 (talk) 18:27, 10 March 2025 (UTC)[reply]
AI fucks things up quite often. Read the article yourself. If you want AI to think for you, you can seek those tools yourself. Headbomb {t · c · p · b} 18:36, 10 March 2025 (UTC)[reply]
then explain what's Mind at Large from wikipedia, without much digging.
Not easily possible cause this article itself is not clear enough. That's when this tool will be helpful. And you can seek it yourself to not to use it. Maverick 9828 (talk) 19:06, 10 March 2025 (UTC)[reply]
That's not a very good reason to add something to Wikipedia which we know to be expensive, bad for the environment, and also often factually incorrect. MrOllie (talk) 19:09, 10 March 2025 (UTC)[reply]
agreed with your first two reasons. Partially agreed to third. Thanks. Maverick 9828 (talk) 19:11, 10 March 2025 (UTC)[reply]
If you're curious, the Wikimedia Foundation did experiment with AI tools to help explain/summarize pages, you can read about them at meta:Future Audiences/Experiments: conversational/generative AI and on the project's report! Chaotic Enby (talk · contribs) 20:44, 10 March 2025 (UTC)[reply]
While AI has made a lot of progress, it's not there yet, and some of the results have me referring to it as Artificial Stupidity. Always verify any results you get from an AI engine. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:45, 10 March 2025 (UTC)[reply]
Can we not? For reasons already stated, this is a bad idea. Others have already said it better than I could, but I just wanted to add that for me personally, I would straight up stop editing wikipedia if this was implemented, not to try to make a 'statement' but because I know that I physically would not be able to comply with WP:NPOV if this was implemented. I'm sure this is the case for others as well. Froglegseternal (talk) 11:03, 11 March 2025 (UTC)[reply]
If you find the introduction to the article unclear, perhaps drop a note on the talkpage noting this. They're intended to do what you propose, provide a concise summary. CMD (talk) 11:53, 11 March 2025 (UTC)[reply]
alright. Thanks Maverick 9828 (talk) 12:06, 11 March 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Modification of Airport template

Hey all, been a while since I edited Wikipedia (a loooooong time), but I was just looking at the Airport template and noticed it doesn't currently have provisos for things like airport plates (technical diagrams of airports) or for the operating frequencies for things like ATC. Can this be changed? Can I change it? Moonbloom (talk) 20:47, 11 March 2025 (UTC)[reply]

Can you link the airport template you're discussing? Template:Airport is actually about adaptations of a 1968 novel.
I think whatever you're discussing could be changed, and you can change it per WP:BOLD, and if anyone dislikes it they will revert and you can discuss it further. satkara❈talk 21:35, 11 March 2025 (UTC)[reply]
Thanks. I will try to add this soon. Moonbloom (talk) 00:30, 12 March 2025 (UTC)[reply]
I was referring to the "{\{Infobox airport}\}" thing (as seen on Auckland Airport) Moonbloom (talk) 00:29, 12 March 2025 (UTC)[reply]
Thank you! That would be template:infobox airport. You can't edit it directly - only admins or people with Template editing permission (this is where to request that) can - but you can request an edit on the infobox's talk page. See WP:TPROT. satkara❈talk 00:54, 12 March 2025 (UTC)[reply]
Thank you so much! I've added a request for the template editors (I figured requesting that myself would be futile, since I don't come anywhere NEAR the requirements as listed under Wikipedia:TPEGRANT ). Thanks for the help @Satkara! -- Moonbloom (talk) 04:03, 12 March 2025 (UTC)[reply]

Lead sections of government leaders

I'd like to propose that the leads of current government leaders (ideally all government officials currently holding office) include their expected term length or next election date - within the first paragraph or the infobox.

I think this is a vital fact for political leaders that quickly contextualizes their influence and their country's system of government.

Using Narendra Modi as an example, whose page is considered "good", the infobox says and lead sentence say he assumed office in 2014. However, nowhere in the article mentions when his next election is expected to be or how long he will serve. The lead does not even mention his recent reelection in 2024 (it does say "In the 2024 general election, Modi's party lost its majority in the lower house of Parliament and formed a government leading the National Democratic Alliance coalition.").

Not every official title has explanatory articles, but India's does. Still, even Prime Minister of India doesn't quickly explain. The lead says there are elections every 5 years and, at the end, that Narendra Modi has been serving since 2014, so you could calculate it - but it's not as simple as "the next PM of India will be elected in 2029, after the general election".

If there is no expected end of term, that context can be explained ie "Trudeau was appointed Prime Minister after his party, the Liberal Party, won a majority in the Canadian House of Commons in the 2015 Federal Election. He maintains his role indefinitely, until he resigns or loses parliamentary support."

Some modifications to Modi's article could be:

  • Adding "Next election cycle: " or "Current term: 2022-2029" or something similar to the infobox.
  • "Narendra Damodardas Modi (born 17 September 1950) is an Indian politician who has served as the prime minister of India since 2014. He began a third 5-year term in 2024."
  • "Narendra Damodardas Modi (born 17 September 1950) is an Indian politician who has served as the prime minister of India since 2014. He began a new 5-year term in 2024 after being re-elected as head of party by members of the National Democratic Alliance."
  • Or for directly elected officials, "Claudia Sheinbaum Pardo (born 24 June 1962) is a Mexican politician, scientist, and academic elected to serve as the 66th president of Mexico from October 1, 2024 to October 1, 2030."

Apologies if I got any facts wrong (it's a symptom of the problem I'm trying to address) but hopefully this exemplifies the idea.

Push back appreciated! satkara❈talk 00:49, 12 March 2025 (UTC)[reply]

Modi is not head of state, that is the President of India. Modi is head of government. 331dot (talk) 00:57, 12 March 2025 (UTC)[reply]
Thanks - I'm using heads of state loosely here; ideally I think it should be all government officials including state govt officials. I'll change it to "government leaders". satkara❈talk 01:18, 12 March 2025 (UTC)[reply]
It's not always clear. For example in the UK, general elections are held no less frequently than every 5 years but when exactly the election is held is at the discretion of the prime minister - and as recent history shows there is no guarantee they will serve the full term so all we can say is that Keir Starmer's current term will end no later than 15 August 2029. There are no term limits, so it's quite possible that the next election will see no change in the head of government. UK government ministers stay in their role until they resign, they get sacked or the next election happens whichever happens first. Then there are all the government officials who are not elected (e.g. monarchs), are only nominally elected or just play fast and loose with their country's constitution and have elections only when it is expedient for them. Thryduulf (talk) 01:34, 12 March 2025 (UTC)[reply]

WMF

WMF annual planning: How can we help more contributors connect and collaborate?

Hi all - the Wikimedia Foundation is kicking off our annual planning work to prepare for next fiscal year (July 2025-June 2026). We've published a list of questions to help with big-picture thinking, and I thought I'd share one of them here that you all might find interesting: We want to improve the experience of collaboration on the wikis, so it’s easier for contributors to find one another and work on projects together, whether it’s through backlog drives, edit-a-thons, WikiProjects, or even two editors working together. How do you think we could help more contributors find each other, connect, and work together? KStineRowe (WMF) (talk) 20:27, 10 January 2025 (UTC)[reply]

@KStineRowe (WMF), by providing more funding for scholarships to Wikimania and other conferences, for one thing. Sdkb talk 22:57, 10 January 2025 (UTC)[reply]
Anyone is invited to collaborate and provide feedback on the page, Meta:Meta:Neuro-inclusive event strategies. I think working on this could go a long way. Hexatekin (talk) 19:33, 28 January 2025 (UTC)[reply]
I think opening up the article translation features to more people would be beneficial for collaboration between the various languages of wikipedia. I also think english wikipedia and simple english wikipedia should collaborate more, but I don't have any ideas for that specifically (other than maybe having a button to link users to a simple english version of a page if it exists) Mgjertson (talk) 16:06, 6 February 2025 (UTC)[reply]
I think WikiProjects could get more promotion with maybe a popup for new editors saying "talk with other editors active in this topic area here". ꧁Zanahary꧂ 22:51, 11 February 2025 (UTC)[reply]
To me it seems like WikiProjects are mostly handy to get assistance from other people interested in a topic area / get consensus for some widespread change, but they only really work if the talk pages aren't dead. So links might help, although every article in a WikiProject's talk page already links to the project, though. Mrfoogles (talk) 03:50, 25 February 2025 (UTC)[reply]
I concur with more support to WikiProjects. These projects are invaluable to content diversity and surely there should be an effort to link these projects with both direct funding from WMF as well as other Affiliates. The synergy is obvious. — Thuvack | talk 00:18, 5 March 2025 (UTC)[reply]

Kill switch to delete information on user IP and email addresses

WMF should have a kill switch to delete all information on the IP addresses and email addresses associated with all user accounts. If DOGE can just walk in and seize the US treasury, seize USAID, gain access to the federal payment system and potentially everyone's SSN's, etc., then there is no reason to think people couldn't just show up at the WMF some day and seize all of our user data. The WMF should have a protocol in place to rapidly delete user data should that occur. Photos of Japan (talk) 07:16, 4 February 2025 (UTC)[reply]

I think WMF would just say "No". DOGE is only able to do the stuff it does the federal government because it has the President, who can at least lie to people who work for him he has authority over this stuff. WMF would instead say something like "Do you have a warrant?" and suchlike. Mrfoogles (talk) 18:23, 20 February 2025 (UTC)[reply]
Why would they care about the WMF saying "No."? They just show up to federal agencies with armed officers and waltz on in, who is going to stop them? Some office worker in the WMF, "Do you have a warrant?", bunch of armed people just walk right past them. Photos of Japan (talk) 18:31, 20 February 2025 (UTC)[reply]
Do you have any evidence of DOGE going in to any organisation that is not government owned? I'm no fan of Elon Musk, but I don't think he has any control over Wikipedia (much as he'd like to). Phil Bridger (talk) 18:51, 20 February 2025 (UTC)[reply]
They are too busy to care about something like Wikipedia right now. They are also in the process of flushing out the Department of Justice and mass firing FBI agents to replace them with their own people. They just released an EO declaring Trump determines the authoritative legal interpretation of the law for all employees of the executive branch, and has complete supervision and control over the executive. If Trump has thousands of FBI agents that do whatever he says, then one year from now there's no reason to assume the WMF won't be subjected to some illegal raid. You prepare for problems before they happen, you don't wait for them to occur and then react to them. Photos of Japan (talk) 19:16, 20 February 2025 (UTC)[reply]
I think that currently both the main and backup sites are in the USA, along with the WMF and the endowment. Maybe now would be a good time to move some or all of that to countries with a greater seperation of powers between the executive and the judiciary. Or at least change the fundraising model to a more decentralised one where the money raised in each country where we have a national charity is under the control of that charity. ϢereSpielChequers 21:44, 21 February 2025 (UTC)[reply]
Yeah. Regardless of who's in charge, it's just a good idea to not keep everything in the same place. We should probably think about setting up a backup site in Europe Mgjertson (talk) 19:30, 11 March 2025 (UTC)[reply]
Principality of Sealand RoySmith (talk) 19:50, 11 March 2025 (UTC)[reply]
WP has "caching" data centers in Amsterdam and Marseille, as well as Singapore and Sao Paolo. What I don't know is how much would need to be done to move the "application" functions from the data centers in the US to one of those non-US facilities. I don't know how much protection that would provide, as the Foundation is a US registered corporation, and some European standards, such as the "right to disappear", clash with WP aims. Donald Albury 21:22, 11 March 2025 (UTC)[reply]
Hey, I wanted to add my two cents. This is not really related to any recent events, but is about privacy and data we collect. The Trust and Safety Product team is working on Temporary Accounts, something which really strengthens the logged-out editors' privacy. The feature is live on 12 wikis already, and we are expecting it to be ready for deployment everywhere (yeah, on all our wikis) later this year. You are welcome to subscribe to the newsletter to keep track of our work, and to comment on the draft plan for the team's work in the next fiscal year. SGrabarczuk (WMF) (talk) 00:46, 5 March 2025 (UTC)[reply]
SGrabarczuk (WMF), this discussion was raised due to a potential concern about the privacy of logged-in users, whose accounts are not temporary. I see the draft plan includes some items on reducing abuse for logged-in users, but don't see any notes about data or privacy relating to logged-in accounts. CMD (talk) 01:25, 5 March 2025 (UTC)[reply]

We want to buy you books - update

The next phase of discussion has started for the resource support pilot project, building from the opening questions' responses to now try and develop the details of what the pilot will look like. Please participate at: Wikipedia talk:WikiProject Resource Exchange/Resource Request#Working on specifics, and let me know if you have any questions :) RAdimer-WMF (talk) 00:12, 27 February 2025 (UTC)[reply]

Without context, this just sounds like the Wikimedia Foundation will buy you random books. What if they gave you a random slice of the World Book encyclopedia??? The Master of Hedgehogs (talk) (contributions) (Sign my guestbook!) 12:24, 28 February 2025 (UTC)[reply]
I think the idea is to buy books that are requested at places like WP:RX but are not easy to obtain. I think this idea was first proposed on a talk page somewhere during a discussion about non-ideal ways the WMF was spending their money and what they should be spending it on instead. I'm actually quite happy to see that the WMF took the idea seriously and is trying to meet volunteers in the middle by listening to their ideas and turning them into an actionable program. Full credit to WMF for trying this out. –Novem Linguae (talk) 23:11, 28 February 2025 (UTC)[reply]
That makes sense. The Master of Hedgehogs (talk) (contributions) (Sign my guestbook!) 11:18, 1 March 2025 (UTC)[reply]
Sounds amazing, so how that works? Can this come to Rwanda? Annick green (talk) 17:54, 7 March 2025 (UTC)[reply]
Hi Annick green! There's a subsection on geography that answers some of these questions – in short, it will depend on the resource being requested. RAdimer-WMF (talk) 18:38, 11 March 2025 (UTC)[reply]

Wikilinking to Asian News International vs. Wikimedia Foundation

Recently an editor removed wikilinks to Asian News International vs. Wikimedia Foundation from many articles. [11][12][13][14][15] What are our thoughts on if we should or should not wikilink to the article Asian News International vs. Wikimedia Foundation? I am inclined to keep these links and have said so before, but would appreciate hearing some other thoughts. cc Pppery. –Novem Linguae (talk) 04:17, 10 March 2025 (UTC)[reply]

@Novem Linguae All wikilinks to the article ANI v. WMF should be removed as the article isn't even an article. Its just a template saying "Asian News International is trying to censor Wikipedia for simply telling the truth". DotesConks (talk) 04:24, 10 March 2025 (UTC)[reply]
(edit conflict) My comment there:

I think it's better we try to heal into a self-consistent state involving that article not existing, rather than deliberately sending people to the memory hole. Reverts are cheap, so when it comes back it won't be hard to revert my edits. I likewise would prefer that the article on the individual case be a redirect to an appropriate section rather than a visible sore (assuming that's legally allowed). I totally get the other viewpoint, though. * Pppery * it has begun... 15:39, 21 October 2024 (UTC)

Rephrased, I don't think it's appropriate to have a link that looks like it's going to point to something, but instead points to nothing. The only information the link conveys is that the WMF has blocked access to the article. In all of those cases the article still says that later in the same paragraph, so the link is redundant. I was inspired to do this now (after having been previously reverted in October) because months later I think the case for doing this is stronger than it was back them when things were still in flux. * Pppery * it has begun... 04:27, 10 March 2025 (UTC)[reply]
(edit conflicted but applicable here too) If that is the consensus, is there a Template:ill type solution that could hide the wikilink if that is the case? Usually for pages with possibility redlinks mean there is not a need to redo all links if a page is created, however in this case there the wikilink removal is creating future work that would involve tracking down prior links as well as reverting. CMD (talk) 04:30, 10 March 2025 (UTC)[reply]
I'd prefer that we retain the links. The situation has already forced us to make extraordinary against-encyclopedic-interests changes, and modifying other articles as well would be an unforced deepening of the wound. Links, even when not clicked, reveal information to readers about e.g. which topics are notable enough to merit coverage. Removing them would send the false message that we don't consider the topic notable. This is also analogous to the situation with red links for notable topics, which we retain despite them not leading to information, so I don't find the "links need to lead to info" argument above persuasive. Lastly, reverts aren't the most expensive change, but they do take some work, especially once an article has evolved around them (e.g. by providing more context when a link is absent or by adjusting MOS:SOB workarounds). Keeping the links takes the longer-term view, in which the article will eventually go up again and we won't have to reintegrate it into the rest of the encyclopedia. Sdkb talk 07:02, 10 March 2025 (UTC)[reply]
I agree with the idea that links should be retained, unless there is any legal compulsion against it. —CX Zoom[he/him] (let's talk • {C•X}) 08:40, 10 March 2025 (UTC)[reply]
Sdkb makes sense to me. Gråbergs Gråa Sång (talk) 12:32, 10 March 2025 (UTC)[reply]
I came in here with no strong opinion, but I think Sdkb makes a good point that the links, even to a removed topic, are valuable information. Valereee (talk) 12:59, 10 March 2025 (UTC)[reply]
I see a rough consensus to restore the wikilinks. Any objections before I go making edits? –Novem Linguae (talk) 11:48, 11 March 2025 (UTC)[reply]
 Done –Novem Linguae (talk) 06:08, 13 March 2025 (UTC)[reply]

Status

While we're all here, can we get an update on the case itself? Is there a time estimate on when the page could be made available again? Are the editors out of legal risk? Is this case going to lead to risks of other articles going down and/or restricted availability in India? Tazerdadog (talk) 08:37, 13 March 2025 (UTC)[reply]

Wikimedia Foundation banner fundraising campaign in Malaysia on English Wikipedia only

Dear all,

I would like to take the opportunity to inform you all  about the upcoming annual Wikimedia Foundation banner fundraising campaign in Malaysia, on English Wikipedia.

The fundraising campaign will have two components.

  1. We will send emails to people who have previously donated from Malaysia. The emails are scheduled to be sent in March 2025.  
  2. We will run banners for non-logged in users in Malaysia on English Wikipedia itself. The banners will run from the 2nd to the 30th of June 2025.

Prior to this, we are planning to run some tests, so you might see banners for 3-5 hours a couple of times before the campaign starts. This activity will ensure that our technical infrastructure works.

Generally, before and during the campaign, you can contact us:

Thank you and regards, JBrungs (WMF) (talk) 12:07, 10 March 2025 (UTC)[reply]

Wikimedia Foundation banner fundraising campaign in South Africa

Dear all,

I would like to take the opportunity to inform you all  about the upcoming annual Wikimedia Foundation banner fundraising campaign in South Africa.

The fundraising campaign will have two components.

  1. We will send emails to people who have previously donated from South Africa. The emails are scheduled to be sent between the 23rd-27th of June 2025.  
  2. We will run banners for non-logged in users in South Africa on English Wikipedia itself. The banners will run from the 2nd - 30th of June 2025.

Prior to this, we are planning to run some tests, so you might see banners for 3-5 hours a couple of times before the campaign starts. This activity will ensure that our technical infrastructure works.

I will soon be sharing the updated community collaboration page, where we outline more details around the campaign, share some banner examples, and give you space to engage with the fundraising campaign.

We will also be hosting a community call, details will be on the collaboration page, to which you can bring your questions and suggestions.

Generally, before and during the campaign, you can contact us:

Thank you and regards, JBrungs (WMF) (talk) 12:41, 10 March 2025 (UTC)[reply]

Wikimedia Foundation Bulletin 2025 Issue 4

Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on 24 February. Please help translate.
Wikimania 2025 Theme
Wikimania 2025 programming proposals are now open.

Upcoming and current events and conversations
Let's Talk continues

  • Annual Planning: Help shape our early-stage thinking around our Product & Tech work and provide feedback before budgets and measurable targets are committed.
  • Global Trends 2025: As part of annual planning, we identify a list of global trends that will impact the Wikimedia movement, such as changes in how and where people search for and contribute information online, the rise of misinformation and disinformation in online spaces, and evolving regulation of online information providers.
  • Wikimania 2025: Apply now to speak at Wikimania 2025 whether to lead a workshop, host a panel, present a poster, or showcase a tool demonstration. Submit your session by March 31 anywhere on earth. If you're interested reviewing proposals for Wikimania 2025 and helping shape the program, you can fill out a short form to apply to be a program reviewer by 17 March.
  • WikiConference North America 2025: Scholarship applications are now open until April 4. This conference will take place in New York City from October 16–19, 2025, under the theme “Wiki’s World Fair".
  • Wikimedia Enterprise and Global Advocacy at SXSW 2025: Wikimedia Enterprise is coming together with Creative Commons on March 9 for a day of conversations and panel discussions at SXSW 2025 that tackles the challenges of AI and the preservation and ethical development of open data. Global Advocacy is participating on a panel on March 8, diving into conversations about the future of the internet.
  • WikiCauserie: The online bi-monthly meeting aimed at bringing together the French-speaking member communities of WikiFranca will be held next on March 21 at 18:00 UTC.


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


Annual Goals Progress on Knowledge Equity
See also a list of all movement events: on Meta-Wiki

  • Women’s History Month: Wikimedia Foundation is running a campaign to spotlight some of the Wikimedians working to close the gender gap on Wikimedia projects. The campaign, Knowledge is human. Knowledge is her., is aimed at reaching external audiences in Sub-Saharan Africa.
  • Wikimedia Research Showcase: "Gender Gaps" will be the featured theme for the next research showcase taking place on March 19 at 16:30 UTC.
  • Global Resource Distribution Committee (GRDC): The call for candidates is being extended until March 31.


Annual Goals Progress on Safety & Integrity
See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog


Annual Goals Progress on Effectiveness
See also: quarterly Metrics Reports


Board and Board committee updates
See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter


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 askcac(_AT_)wikimedia.org know if you have any feedback or suggestions for improvement!


MediaWiki message delivery 15:55, 10 March 2025 (UTC)[reply]


Miscellaneous

Adding "Paid subscription required" to New York Times citations

The New York Times website has a paywall that prevents you from reading all articles unless you subscribe. But for some reason, most if not all citations that cite the New York Times website don't have the "paid subscription required" tag, which should have been added.

(Note to administrators: Please relist this if it doesn't fit into the "miscellaneous" category) RaschenTechner (talk) 21:21, 3 March 2025 (UTC)[reply]

Meh… I can go to my local public library and search the NYT for free (both the hard copy paper and the on-line version). Blueboar (talk) 22:01, 3 March 2025 (UTC)[reply]
I only just now became aware that this the {{cite web}} template includes a parameter to mark a source as requiring registration. Anyway, that's a matter of the person creating a citation knowing about that parameter and thinking to set it. It doesn't have anything specific to do with the New York Times. Largoplazo (talk) 22:22, 3 March 2025 (UTC)[reply]
  • This is true of every subscription site. The |url-access=subscription is underutilized. There may be good reason. Pages may start out as paywall, then revert to free (or other way around). There might be some free access (5 per day etc). Possibly geography plays a role. Archive URLs often get around paywalls. Thus, access can change over time, and be relative to the viewer. IMO I see no reason to maintain these across millions of citations. Either you can get the page, or you can't, with whatever means is at your disposal. The warning doesn't change the verifiability, it's a courtesy, not a necessity. -- GreenC 00:31, 4 March 2025 (UTC)[reply]
    I think that it's 10 free articles per month at The New York Times (but that may be wrong or outdated). Like Blueboar, my local library provides both hard copies and online subscriptions for free. WhatamIdoing (talk) 03:19, 10 March 2025 (UTC)[reply]

Something needs to be done about the excessive use of Al Jazeera on Israel-Palestine articles

Proposer is not extended-confirmed so is ineligible to start this discussion. * Pppery * it has begun... 18:26, 6 March 2025 (UTC)[reply]

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

according to Wikipedia:Reliable sources/Perennial sources/1 Al Jazeera in English and Arabic is not considered a reliable source on topics related to the Arab-Israel Conflict. But despite this many articles on the topic cite it like they would the BBC or Reuters. To solve this, we should get rid of these citations and any text only supported by them in IvP articles. It'll have to be a group effort because it's simply too much for 1 person. Denninithan (talk) 06:48, 4 March 2025 (UTC)[reply]

Read RSP again, it says "biased", but that is not the same thing. Gråbergs Gråa Sång (talk) 16:34, 4 March 2025 (UTC)[reply]
I would have pretty serious neutrality concerns over excluding AJ from the Israel - Palestine topic area considering there's few other reliable news sources in English for an Arabic POV. Simonm223 (talk) 16:36, 4 March 2025 (UTC)[reply]
While an Arabic POV is important using good sources is more important. And if the only sources that can be found for a claim are all biased or banned for being propaganda then the reliability of that claim is questionable and it shouldn't be included. I feel like using Al Jazeera along with other more reputable sources is fine (and this is very common) but my main issue is with articles where the vast majority of citations are either AJ or one of many smaller Palestinian website who's reliabilities I question; in my experience most of these articles are flat out biased. Denninithan (talk) 18:24, 6 March 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

How to flag Arab-Israeli conflict related article

The article Alhambra Cinema (Israel) has a long history of people changing the country-designation of the pseudo-flag mounted on top of the building in the 1937 image. I think this article should be included under "Israeli–Palestinian conflict and all related issues" as listed in WP:List of controversial issues. I found the template {{Contentious topics/Arab-Israeli editnotice}}, but I'm not sure how to deploy it. (I'm not familiar with the geopolitical conflicts, I've just watchlisted this article about a building, and am annoyed with the back and forth edits.) Any help on how to reduce the long-term edit warring?   ▶ I am Grorp ◀ 16:55, 5 March 2025 (UTC)[reply]

No tips? Anyone?   ▶ I am Grorp ◀ 16:21, 9 March 2025 (UTC)[reply]
@Grorp, if you mean that you want to add the big warning on the talk page, then you post {{Arab-Israeli Arbitration Enforcement}} there. WhatamIdoing (talk) 03:22, 10 March 2025 (UTC)[reply]
@WhatamIdoing: Okay, I added that. However, the message states "You must be logged-in and extended-confirmed to edit or discuss this topic" but one can still edit the page as a non-logged-in IP editor (I tried it). There must be another step to limit editing on the article page.   ▶ I am Grorp ◀ 05:19, 10 March 2025 (UTC)[reply]
The default is to allow anyone to edit. Now the page is tagged it warns about the situation, and an admin can protect the page if trouble comes along. For the talk page, others may wish to make edit requests. Graeme Bartlett (talk) 09:25, 10 March 2025 (UTC)[reply]
But the flagging shows only when you edit the talk page, not the article itself, so the warning is inadequate for drive-by editors.   ▶ I am Grorp ◀ 16:22, 10 March 2025 (UTC)[reply]
We only protect the pages when it is actually necessary. It is not, strictly speaking, necessary to protect a page just because someone might edit it. WhatamIdoing (talk) 17:32, 10 March 2025 (UTC)[reply]

Universal Code of Conduct annual review: proposed changes are available for comment

I am writing to you to let you know that proposed changes to the Universal Code of Conduct (UCoC) Enforcement Guidelines and Universal Code of Conduct Coordinating Committee (U4C) Charter are open for review. You can provide feedback on suggested changes through the end of day on Tuesday, 18 March 2025. This is the second step in the annual review process, the final step will be community voting on the proposed changes. Read more information and find relevant links about the process on the UCoC annual review page on Meta.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) 18:51, 7 March 2025 (UTC)[reply]

Missing 9/11 backup data

While I was attempting to download a data dump an host a mirror to aid others, I came across this weird fact. On https://dumps.wikimedia.org/ under the missing backups page, it seems to insinuate that the only missing backup page is a 2007 version of the September 11th article. On the given URL there is a link that appears to list "backup dumps of wikis that no longer exist". Upon opening said link there only a single article listed . September 11 wiki dump from September 2007. Why is this? Eternallygr8fu1 (talk) 01:19, 9 March 2025 (UTC)[reply]

I think it would be better if we had a link to the ressource mentionned.

I think I'm unable to help you as I haven't the technical level necessary but it would be better with a link. Anatole-berthe (talk) 07:12, 9 March 2025 (UTC)[reply]
@Eternallygr8fu1 The sep11wiki isn't the September 11th article, it was a completely separate project. After 9/11 a wiki was created to act as a memorial and document everything about the events. This wiki was moved to a different domain before being deleted. See Meta:911wiki for a short information page. 86.23.109.101 (talk) 08:26, 9 March 2025 (UTC)[reply]
86.23.109.101, you just got in the way of a good conspiracy theory there! Phil Bridger (talk) 08:36, 9 March 2025 (UTC)[reply]

Do we need Recent changes" in the sidebar?

On special-purpose wiks with low volumes of traffic, recent changes is a great way to review what's been going on. But enwiki has such a high rate of edits that recent changes presents an essentially random sampling of pages. Is there really any value to having this in the sidebar? RoySmith (talk) 13:21, 10 March 2025 (UTC)[reply]

That is a good question but in my knowledge every Wikipedia linguistical version have an equivalent button.
I don't know if this can be deleted as I'm far to be a specialist. Anatole-berthe (talk) 13:25, 10 March 2025 (UTC)[reply]
I assume this is something that an WP:INTADMIN can change. Or of not that, then certainly a dev by editing the project config file. But before we go there, we should figure out if we really want it or not. RoySmith (talk) 13:38, 10 March 2025 (UTC)[reply]
@RoySmith It can be removed by editing MediaWiki:Sidebar. 86.23.109.101 (talk) 15:29, 10 March 2025 (UTC)[reply]
Putting #n-recentchanges { display: none } on your css page works if anyone wants to hide it. Nobody (talk) 15:34, 12 March 2025 (UTC)[reply]
I use Special:RecentChanges all the time. — xaosflux Talk 15:39, 10 March 2025 (UTC)[reply]
In Wikipedia:Requests for comment/2020 left sidebar update there was consensus to keep this. At the time I voted to keep, saying Not only does it serve a important purpose to editors, but it also serves as a live demonstration of Wikipedia's editing activity to those unfamiliar with the site; I still agree with this.  novov talk edits 01:02, 13 March 2025 (UTC)[reply]

-ve stuff

Is it wise to put -ve stuff on the Wikipedia home page. ? 220.240.117.89 (talk) 19:09, 10 March 2025 (UTC)[reply]

Probably not, but your question is so lacking in context that it's impossible to answer properly. Phil Bridger (talk) 20:02, 10 March 2025 (UTC)[reply]
Likely that they meant one of the ITN or DYK blurbs as those sometimes have negative (BLP) stuff (like the Arrest of Rodrigo Duterte). Nobody (talk) 15:24, 12 March 2025 (UTC)[reply]
Yes, if the -ve stuff have good sources. Lova Falk (talk) 10:48, 11 March 2025 (UTC)[reply]
What is "-ve stuff"? Schazjmd (talk) 13:38, 11 March 2025 (UTC)[reply]
I presume "-ve stuff" means "negative stuff". What had me stumped were the questions of what the "Wikipedia home page" is, and what negative stuff does it contain or someone want it to contain. Phil Bridger (talk) 13:53, 11 March 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(all)&oldid=1092610382"