Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.

Before creating a new section, note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for 10 days.

« Archives, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83

Replace the hyphen in html titles with an en dash

Currently, when visiting a Wikipedia page such as fox, the HTML <title> is Fox - Wikipedia. This is not to be confused with the article title, which is an <h1> heading in HTML. MOS:DASH says: do not use one or more hyphens in place of a dash, and I find this quite annoying that every page title breaks our manual of style, which is fairly standard in this matter.

The reason I brought this here rather than /PR is that I have no idea if or how this could be changed. (please mention me on reply) (in solidarity), JacobTheRox^{(talk|contributions)} 16:15, 17 August 2026 (UTC)

Yes, it can be changed. No, it's not difficult to change. Either we would need one of the Wikipedia:Interface administrators to do it, or we would need a config change request. Someone at Wikipedia:Village pump (technical) you which one. Jon (WMF) could probably tell us whether there is an important reason for using a hyphen-minus instead of a spaced en dash in that place. WhatamIdoing (talk) 19:01, 17 August 2026 (UTC)

My guess is that it maximizes compatibility with different character encodings as the hyphen-minus is the only short horizontal line character in ASCII. This also probably saves a tiny bit of disk space as ASCII characters only take up one byte in UTF-8, whereas all the other short horizontal lines take up two. SuperPianoMan9167 (talk) 19:26, 17 August 2026 (UTC)

Any admin can edit MediaWiki:Pagetitle, doesn't have to be an iadmin. A developer would only be needed if we think the default (for all MediaWiki sites everywhere) should be changed. Anomie⚔ 22:39, 17 August 2026 (UTC)

Looking at that page's talk, a discussion to replace the hyphen-minus took place five years ago at Wikipedia:Village pump (proposals)/Archive 176#Replace hyphen with en-dash in Wikipedia browser tab name – MediaWiki:Pagetitle, which closed as "no consensus". SuperPianoMan9167 (talk) 22:43, 17 August 2026 (UTC)

This is a pretty good illustration of why the guidelines in the Manual of Style usually only makes sense when applied to article content. Is there any good reason to replace the hyphen-minus other than visual preference? What benefits will come from making the short horizontal line slightly longer? Changing the separator to a non-ASCII character runs the risk of creating mojibake. SuperPianoMan9167 (talk) 19:34, 17 August 2026 (UTC)

Yes. One could misunderstand the hyphen but not the dash. There's a reason dashes exists; hyphens are not supposed to be used in this way and knowledgeable readers need to decide whether we picked the wrong character or it's part of the article's title. FaviFake (talk) 15:51, 14 September 2026 (UTC)

I am going to be honest, I didn't even know until right now that it was a hyphen not an en dash in the tab title. Looking at my tab list, I think they all use hyphens except for bluesky, which uses an em dash. For websites from microsoft outlook to google gmail and docs. Reddit uses a colon. I personally don't see the need, and agree that the MoS makes sense for article content alone, generally. 📎 JackFromWisconsin (talk | contribs) 17:30, 14 September 2026 (UTC)

Just because a good practice appears in the MOS doesn't necessarily mean it only applies to pages where the MOS applies. FaviFake (talk) 17:32, 14 September 2026 (UTC)

The MOS says to not use contractions. Editors routinely use them in discussions anyway. SuperPianoMan9167 (talk) 17:40, 14 September 2026 (UTC)

What does that have to do with anything? We're not talking about talk pages. FaviFake (talk) 08:45, 15 September 2026 (UTC)

That's exactly the point - manual of style recommendations are not relevant outside of the context they are written for. MoS recommendations for article text do not apply to the html header in the same way that they do not apply to talk pages. Thryduulf (talk) 09:51, 15 September 2026 (UTC)

Just because a good practice appears in the MOS doesn't necessarily mean it only applies to pages where the MOS applies. If the MOS said we need to use correct grammar, saying the MOS doesn't apply outside mainspace is not a valid reason for using incorrect grammar in the HTML headers. FaviFake (talk) 09:54, 15 September 2026 (UTC)

What the MOS says is completely irrelevant to what we should put in the HTML header, regardless of what the MOS says or why they MOS says it. The reasons for using a hyphen in the HTML header have nothing to do with grammar, and (from a quick scan) nobody supporting a hyphen has mentioned grammar at all because grammar is completely irrelevant. The reasons for using a hyphen are technical. Thryduulf (talk) 11:17, 15 September 2026 (UTC)

What the MOS says is completely irrelevant to what we should put in the HTML header, regardless of what the MOS says
Yes, that is what I said.

"If the MOS said we need to use correct grammar" was an example, of course this isn't a grammar issue... FaviFake (talk) 11:20, 15 September 2026 (UTC)

In a perfect world, I suppose, this would be an en-dash. As much as I'm a stickler for this usually, I don't think it really matters in this case. If this is going to create an ugly missing character for some users, it is not worth it. —Myceteae‍🍄‍🟫 (talk) 23:12, 17 August 2026 (UTC)

@JacobTheRox: Would this be done with a raw UTF-8 character or a HTML Escape code? A escape code would prevent mojibake. Velocifyer (talk) 17:06, 3 September 2026 (UTC)

You're right, I didn't think of that. I still see very little incentive to make this change besides personal preference. SuperPianoMan9167 (talk) 17:37, 3 September 2026 (UTC)

The argument that it’s following the MoS isn’t nothing! One would expect a style guide to apply to all text that’s visible to readers. Ham II (talk) 19:51, 3 September 2026 (UTC)

Most of the time the separator isn't actually visible to readers as it gets cut off by the limited horizontal space for the tab title. SuperPianoMan9167 (talk) 20:46, 3 September 2026 (UTC)

Also, how is a dash more correct here? The traditional separators for HTML titles are hyphens and pipes. SuperPianoMan9167 (talk) 20:48, 3 September 2026 (UTC)

It's "more correct" in the sense that if it were being laid out for printing on paper, then a good typesetter wouldn't use a Hyphen-minus there. WhatamIdoing (talk) 02:16, 4 September 2026 (UTC)

Don't fix what isn't broken. Katzrockso (talk) 12:18, 15 September 2026 (UTC)

+1 —Myceteae‍🍄‍🟫 (talk) 14:11, 15 September 2026 (UTC)

What about another character, like a pipe? Does that have the technical issues an en dash has? It would avoid going against the MoS. Ham II (talk) 08:26, 26 August 2026 (UTC)

The pipe character is in ASCII, so it would avoid any potential technical issues that an en dash might have. SuperPianoMan9167 (talk) 13:55, 26 August 2026 (UTC)

Let's not do this. I'm sure there's various bits of software out there that parse our titles to do various useful things. By changing the format, we'll break them. Why do we want to do that? I know it would piss me off if some data stream I'd been happily ingesting for years changed how something was formatted and broke my code.

What would the benefit be? I really can't think of any. RoySmith (talk) 19:58, 2 September 2026 (UTC)

Are you saying that software could parse <title> and strip " - Wikipedia" rather than <h1> which is how the title is stored? (in solidarity), JacobTheRox^{(talk|contributions)} 17:56, 3 September 2026 (UTC)

Having seen the very many different ways websites present titles and how these are interpreted in tools like the visual editor citation filler read them, doing something like that seems entirely plausible. Thryduulf (talk) 19:58, 3 September 2026 (UTC)

Reasons not to do this:

1. Replaces an ASCII character with a non-ASCII character, potentially reducing readability in certain environments.
2. Breaks compatibility with any systems that parse our content and expect it to be the way it is now.
3. Inconsistent with norms on other websites like Google.
4. I personally prefer hyphens because I'm a square like that.
5. HTML page titles are part of the interface, not part of the content.

Reasons to do this:

1. Complies with an MOS that wasn't written for this situation.
2. Looks better if for some reason someone pulls the HTML titles for a physical print edition (and we didn't break the script they used to pull them per point 2!).
3. Creates ambiguity for all 8 people on the planet who can notice the difference but can't figure out the intent.

IMO it's fine as it is. -- LWG ^{talk (VOPOV)} 17:49, 14 September 2026 (UTC)

I was skeptical to begin with and over the course of this discussion I have become persuaded that we should not change this. User:LWG gives a fairly good summary above. There's not a good reason for the change and several potential problems have been identified. —Myceteae‍🍄‍🟫 (talk) 14:15, 15 September 2026 (UTC)

My browser window shows the Wikipedia title PLUS some big dash (not sure if endash or emdash) and then the browser name. So a big dash is already in use and having an endash in the title would make it slightly more confusing to parse. Jason Quinn (talk) 08:44, 28 September 2026 (UTC)

Ping all participants in closed discussion

I asked about this at the Help desk a year ago and it didn't go anywhere: Wikipedia:Help desk/Archive 69#Ping all participants in a prior discussion.

Would it be possible to design a functionality that would allow you to identify and tag ('ping') all participants from an old, closed discussion? For live talk page and discussion posts, I can use the reply tool and type @ to generate a dropdown list of every user who has contributed to the current discussion. I would like to duplicate this functionality for closed posts. It would be great if this worked for archived posts as well as posts that are closed but still on the active talk page.

Potential use case: Say there was a closed RM last year and I want to notify all participants of a new discussion. Or an archived post on an article talk page or noticeboard that is related to a new discussion, possibly on a different page.

Currently my approach is to scan the old thread and pick out all the users. This gets the job done but is somewhat cumbersome and it is easy to miss people. —Myceteae‍🍄‍🟫 (talk) 18:43, 17 September 2026 (UTC)

I made a bot to count participants in an RfC. I think it could be tweaked to make a ping list.

Try pasting an RfC link on its talk page like this one. Runs every 5 minutes.

User talk:DwAlphaBot/RfcEditStats#c-Dw31415-20260729165100-Opus Dei Dw31415 (talk) 21:01, 17 September 2026 (UTC)

Nifty! I've posted two examples, one archived and one not archived to see if there is any difference. I could see a version of this for RMs being of interest, with or without the pinging functionality. —Myceteae‍🍄‍🟫 (talk) 21:58, 17 September 2026 (UTC)

I can’t remember if it only works on RfCs or any topic will work. Let me know if there’s any requests and/if you would use it enough for me to have it generate a pipe separated line Dw31415 (talk) 01:02, 18 September 2026 (UTC)

I tried it with an RM and it didn't work. Request: User talk:DwAlphaBot/RfcEditStats#Kate Shaw RM (testing to see if it works with RM). Results: User:DwAlphaBot/RfcEditStats#RfC stats: Kate Shaw - requested move 11 august 2026. I can't say I would use this all the time but it would certainly save time when I wanted to use it to generate a list of editors to ping, and I suspect it would catch on with others if they were aware of it. The desire for this functionality crosses my mind periodically and I either do it the hard way or decide it's not worth it. I suspect that if it were quick and easy, I would use it more often —Myceteae‍🍄‍🟫 (talk) 03:29, 18 September 2026 (UTC)

@Myceteae: Conveniently, I pushed an update of Move+ yesterday that creates a list of editors involved a discussion and allows them to be notified. To do this:

1. Click "Notify"
2. Expand "Autofill"
3. Paste the talk page and section link (for example, "Talk:NBT Bank Arena#Requested move 11 September 2026") in the "Relevant pages" field, removing existing values
4. Select the option "Discussion participants"
5. Click "Autofill"

The list of editors who participated in the discussion will then appear in the "Users to notify" field; for an RM, you can then just select "Notify" (maybe adding an explanation of why you are notifying them), and it will ping all of them. BilledMammal (talk) 02:30, 18 September 2026 (UTC)

Aha! I actually noticed this change to Move+ earlier but didn't really take stock of it as it wasn't relevant to the task I was performing at the time. Fantastic addition, @BilledMammal! —Myceteae‍🍄‍🟫 (talk) 02:36, 18 September 2026 (UTC)

Myceteae, my main reaction is that I don't want you to do this. If I want to follow a discussion, I've clicked the [subscribe] button. If you want me to see it, add an ordinary comment in the discussion. If it's really important, then un-archive it. WhatamIdoing (talk) 02:41, 21 September 2026 (UTC)

Duly noted. My intent is not to encourage or discourage the practice beyond the current largely editor-dependent judgment call as to when, where, and how to make notifications about or 'advertise' discussions. —Myceteae‍🍄‍🟫 (talk) 23:27, 22 September 2026 (UTC)

Hide bot's messages on Talk page

I think bot's create lot's on noise on User talk page. Maybe bot's messages should be hidden from public view by default. It should also be excluded from archiving.SideEffect ^{talk to your doctor} 10:40, 18 September 2026 (UTC)

Are you talking about notifications (like when a bot archives a topic)? I think you can mute a specific bot and maybe all bots in preferences. Dw31415 (talk) 13:47, 18 September 2026 (UTC)

No, I'm talking about the bot messages that you see on other people's talk pages. SideEffect ^{talk to your doctor} 14:00, 18 September 2026 (UTC)

I think very few people who only read Wikipedia and don't edit will read editors' talk pages, so it doesn't seem necessary to me. Lova Falk (talk) 14:05, 18 September 2026 (UTC)

It's to help editors and to cut down on the noise. SideEffect ^{talk to your doctor} 14:09, 18 September 2026 (UTC)

Ah, I thought you were concerned about "public view". However, hiding them for editors? AFAIK editors can unsubscribe from the bot messages. Lova Falk (talk) 14:13, 18 September 2026 (UTC)

Yes, but we can still see them on other people's talks. Maybe it's useful for the subscriber. But, they are useless for other's. So that's why I'm suggesting it's hidden for everyone else. Bots need a way to notify or communicate with its intended recipient. But they don't need to communicate with other editors. SideEffect ^{talk to your doctor} 14:23, 18 September 2026 (UTC)

Finally I understand. You don't want to see them! I wouldn't object to your idea. (Changing my position because of Schazjmd's argument. Lova Falk (talk) 14:46, 18 September 2026 (UTC)

Perhaps they could develop a settings option to hide it automatically (for you at other people's talk), or create a browser script to handle it. SideEffect ^{talk to your doctor} 14:38, 18 September 2026 (UTC)

I have a lot of Wikipedia:FRS messages on mine. One challenge is that I asked for them. Maybe we could change the archive bots to more aggressively archive Bot messages. Could you say more about the impact to you? Add topic will jump to the bottom so what’s the pain to you when another user’s page has a lot of topics? Dw31415 (talk) 14:16, 18 September 2026 (UTC)

I find it annoying to read bot messages when I go to other people's talk. Bot messages should be only visible to their subscribers. SideEffect ^{talk to your doctor} 14:25, 18 September 2026 (UTC)

Some bot messages are useful to other editors, such as warnings from ClueBot NG. Schazjmd (talk) 14:28, 18 September 2026 (UTC)

Hmm. Yeah. But most of them are useless, especially the ones that create a lot of noise or post in mass numbers. SideEffect ^{talk to your doctor} 14:32, 18 September 2026 (UTC)

Good point Schazjmd  Lova Falk (talk) 14:46, 18 September 2026 (UTC)

I find they can be informative when seen on other users' talk pages. They can provide insight into edit patterns and activity. —Myceteae‍🍄‍🟫 (talk) 14:49, 18 September 2026 (UTC)

This feature is optional; users who do not wish to see them can choose to hide them. SideEffect ^{talk to your doctor} 15:28, 18 September 2026 (UTC)

As an optional feature, wouldn't it be better to ask Wikipedia:User scripts/Requests for a Hide bot button especially for you? Because as a proposal for everybody, I don't think this idea is going to make it. Lova Falk (talk) 16:51, 18 September 2026 (UTC)

Great idea. It’s hard to see enhancements for reading other people’s talk pages as getting much priority. I might even be willing to work on it. Dw31415 (talk) 18:22, 18 September 2026 (UTC)

I have mine customized for that purpose. KiranBOT took up most of the space on my talk page at first due to all my Teahouse questions, so I've cleared out the automated notifications. Considering editors have substantial leeway over managing their own talk pages as well as the stated point that others do sometimes prefer being able to see such messages it would only be appropriate to implement as a personal option that people could choose to opt into or out of. ChompyTheGogoat [ Bleat | Munched ] 09:54, 27 September 2026 (UTC)

AI-assisted search

While AI is terrible for writing articles or as a source of information, I think it could be very useful for performing advanced searchs in Wikipedia (and other Wikimedia projects). Many information in Wikipedia about a particular topic is disperse across several articles (many of them unrelated), and I think AI could be useful to find all the information related about a particular advanced search. The key points of my idea are:

• Wikipedia is losing visits because of AI. While Wikipedia is not a business and its main goal is not to maximize the number of visits, many Wikipedians are worried about this. If Wikipedia makes use of AI, the people who go where there is AI because it's cool, would also come to Wikipedia (they wouldn't see Wikipedia as an old-fashioned site where AI is not present at all, but as a modern cool one). Another reason why more serious, conscious people can be making use of AI in place of Wikipedia is the ability to perform advanced queries and get links to reliable websites in a quicker way than they would with Wikipedia (or with a traditional search engine). If Wikipedia provides this ability, in combination with its human-reviewed, extense articles, it can be an absolute winner.
• Full respect to people who reject use of AI. Wikipedia is not anti-AI, but people who don't want to use AI at all must remain free to keep doing so. The current search box must continue working without any LLM AI.
• Any used software, including the LLM, must be freely licensed. All such software (LLM included) should be run at WMF's infrastructure.
• An AI button would be shown at the right of Wikipedia's search box. From there, the user would be able to perform advanced searches using natural language. The button should be present in all Wikipedia editions in languages supported by the LLM, and maybe also in other Wikimedia wikis.
• The AI must have restrictions in place so it can't be used for any purpose that is not the search of information in Wikipedia or other Wikimedia sites.
• The search results can include Wikipedia articles, Wikivoyage travel guides, books at Wikisource, images, videos or PDF books at Wikimedia Commons, etc. All of them in any language, with machine translation being used when convenient. The results could also be a specific section or subsection of any of these wiki pages. Unlike a "normal" search, the search results would not be a simple list of links, but a coherent text that presents them in a way that is easy to understand by the user.
• The AI should generate the shorter possible response in natural language. The important part of the response would be the search results: the generated text would be mostly for putting the different results together, and for providing context to the user, but the generated text should never be provided in a way that replaces reading the original wiki text. If the specific search makes it convenient, parts of such wiki text (including their external references) could be provided verbatim in the response, in a way that it's clear to the user that the shown text comes directly from the wiki.

Of course, this idea would cost time, money and resources to WMF, but maybe these costs could be far less than those of the failed Abstract Wikipedia, while achieving a similar goal (or so I believe; sincerely, I was never able to fully understand the exact goal of Abstract Wikipedia), and in a way that is accessible to the mass public (and, for a part of them, even "cool"). MGeog2022 (talk) 17:46, 18 September 2026 (UTC)

Besides being more expensive and probably worse, how would this be different from going to your chatbot of choice and typing in "I would like to know _____. Please use exclusively Wikimedia sources to research and write a summary answer, and provide links and quotes to relevant wiki articles as appropriate."? -- LWG ^{talk (VOPOV)} 18:58, 18 September 2026 (UTC)

Well, my proposal would give the user true Wikipedia results, and encourage the user to use Wikipedia. The user would be using pure Wikipedia, with no hallucinated garbage in the middle (the summary would be brief and leading to true Wikipedia articles; in some cases, it could include verbatim copies from them).

Please use exclusively Wikimedia sources to research and write a summary answer: the point here is: how many people (particularly non-Wikimedians) would do that? How much hallucinated trash are people believing and reusing because of not being conscious of these options in LLMs? When bad quality information/"knowledge" is on the increase, we could help to solve this problem. And, well, it would probably be expensive, but I suspect Abstract Wikipedia is more expensive and produces next to none useful results, while integrating AI could help to connect again with the mass public that is leaving Wikipedia for their "new toy". About being "probably worse", with all the conditions that I specified (brief summaries with the only purpose of querying Wikipedia, leading the user to actual wiki pages or parts of them), there is no need for the LLM to be the best one available. As a source of knowledge, every LLM is bad. LLMs are (relatively) good at doing things, they are not good at knowing non-trivial facts. MGeog2022 (talk) 19:15, 18 September 2026 (UTC)

"how would this be different from going to your chatbot of choice and typing in": by the way, this is not different from many commercial websites that include their own AI chatbot. People could use any general-purpose chatbot for that, but the site's owners consider that having their own chatbot is the way to retain visits to their site. While Wikipedia is non-commercial, and maximizing visits is not our main goal, a really massive loss of visits can eventually become a huge problem for the community (even while it will always keep a certain niche of users, but that would not be the same Wikipedia we all know). MGeog2022 (talk) 19:22, 18 September 2026 (UTC)

An important detail that I forgot: on its own initiative, WMF has plans to introduce AI for suggestions when editing, no matter how expensive it is or if a general purpose chatbot could do it better. In my opinion, this is just the case where AI should be avoided at all: for writing content (other than for minor adjustements, such as translations, where it is acceptable). If WMF is in favor of using AI in Wikipedia, I think the querying part is the one where it can do more good than harm. MGeog2022 (talk) 20:00, 18 September 2026 (UTC)

I suspect that WMF is fully aware of our strong antipathy towards AI. Blueboar (talk) 20:06, 18 September 2026 (UTC)

please read the thread you linked in its entirety, there have been some clarifications and changes to said plans which will become clear once you read it Gnomingstuff (talk) 06:46, 20 September 2026 (UTC)

A really long discussion there. What seems clear is that most of the community fully rejects any use of AI in Wikipedia. MGeog2022 (talk) 08:52, 20 September 2026 (UTC)

with no hallucinated garbage

Another fatal misunderstanding of AI. You cannot prevent hallucinations. They aren't a flaw limited to how specific systems are programmed - they're an inherent flaw with the technology itself. Don't you think they'd fix it if they could? Limiting the database to specific sources won't solve it. I've experienced outright hallucinations from a micro AI that was programmed for a single book. The only way to guarantee information is accurate is to verify it yourself, regardless of where the feature is hosted. Why should we waste WMF resources for something that would have no significant benefit over external tools? ChompyTheGogoat [ Bleat | Munched ] 20:40, 18 September 2026 (UTC)

Thanks for your responses. Yes, that's true. But, if the software behind this function asks the LLM to work in some specific ways, including writing only very brief summary texts with links, or verbatim copying some sections, the risks of hallucinations causing any damage is minimal (the brief text itself could contain instructions not to directly use it but to click on the provided links to articles or sections of articles).

Why should we waste WMF resources for something that would have no significant benefit over external tools? I think the benefits would be about reaching the wider public in the AI era, and I believe this is no minor issue: it's like having official Facebook and Twitter accounts 10-15 years ago; we could dislike social network sites, but Wikipedia created official accounts in both of them, and it helped to reach a wider public. I don't like Wikipedia being considered as something from the past by an important part of the population, no matter how silly their thought can be. This is a complex issue, but it shouldn't be considered in a Wikipedia vs AI way. In any case, it's a knowledge vs ignorance one, and by making Wikipedia acceptable to AI "fanatics" (distinct from simple AI users, but I fear those involuntary "fanatics", said with all respect to them, possibly outnumber the sum of AI users and AI non-users), knowledge can win over ignorance.

Another reason would be providing an easy to use way to query the vast Wikimedia datasets (a general purpose chatbot is not optimized for querying Wikimedia data only, and properly using it for that would be very difficult, and, while very useful, giving the enormous size of the dataset, really few people would take the needed work to do it).

WMF resources will be wasted anyway in the "AI-generated edit suggestions". MGeog2022 (talk) 21:05, 18 September 2026 (UTC)

And I'm fully against that proposal too. We're already seeing damage from the Revise Tone tasks. As a donor I have a vested interest in how funds are utilized - and WMF should be acutely aware of how their actions are perceived by donors, given the events regarding WWU.

General chatbots do not need to be "optimized" to search Wikimedia. I can tell it to look for something here and it does. If users made a conscious choice to come here and utilize a built in tool they can make the same choice to tell an external tool to search for results here. Simple as. If they're not explicitly looking for results here, they won't navigate here in the first place.

Wikipedia was built by humans, for humans, and people who value human knowledge come here for that purpose. The last thing we want to do is dissuade those users - especially those who are editors, or have the potential to be. Fanatics already have Grokipedia, so it's amusing that they still feel the need to come here and try to insert AI content. If it was so great everyone would flock over there instead. ChompyTheGogoat [ Bleat | Munched ] 21:21, 18 September 2026 (UTC)

Here, I was talking about "AI fanatics", not "X man"'s fanatics (many people, regardless of their ideology, have a blind faith in AI; they may consider any encyclopedia as unneeded in 2026, whether Wikipedia or Grokipedia). I agree with your comment 👍 MGeog2022 (talk) 21:31, 18 September 2026 (UTC)

oh. aight CHIMERA2212 (talk) 21:40, 18 September 2026 (UTC)

Get links to reliable websites in a quicker way than they would with Wikipedia

We're not a search engine. We only provide limited external links for additional context to article content. If people are wanting to navigate to external sites they shouldn't be utilizing Wikipedia for that purpose. ChompyTheGogoat [ Bleat | Munched ] 20:32, 18 September 2026 (UTC)

The WMF is not going to be able to outcompete commercial llm-companies fully dedicated to LLMs. If someone wants to overlay one of those over Wikipedia and craft a relevant prompt, that would be much simpler and sustainable way to achieve the goals above. CMD (talk) 07:13, 20 September 2026 (UTC)

The WMF is not going to be able to outcompete commercial llm-companies fully dedicated to LLMs. WMF should never try to do that, and this was never the purpose of this proposal (AI companies create LLMs: this proposal was about deploying and using an already existing, freely licensed LLM). MGeog2022 (talk) 09:30, 27 September 2026 (UTC)

[Use RAG -- gain trust] Some entity might indeed want to implement a natural language querying and summarisation/formatting of a response based on Wikipedia-specific data. It mightn't be necessary for WMF to host that facility, given (possible) additional resources above its usual search. This natural language interaction would be different from prompting a popular chatbot to "Please use exclusively Wikimedia sources to research and write a summary answer, and provide links and quotes to relevant wiki articles as appropriate". One couldn't guarantee a popular chatbot would accurately follow the prompt... however... popular chatbot (or other) could be explicitly configured to use Retrieval-Augmented Generation and low temperature based on the live Wiki data to increase reliability and leverage the naturally multilingual nature of AI embeddings. How WMF could contribute to a Wikipedia-with-AI done better I think is down to technical aspects of implementation. I believe it prudent for WMF to be proactive on how its scraped data is being used. It's not a competition between AI-easy-untrustable and Wiki-harder-high-value, it's about preserving the integrity of information and facilitation of wide access. Munnum (talk) 09:54, 26 September 2026 (UTC)

Good comment. If done, while it mightn't be necessary for WMF to host it (it would be highly convenient, though), user privacy must be fully guaranteed, and all the used software (LLM included) must be freely licensed. Wikipedia is about freely licensed content, and that's also the case with associated software such as MediaWiki. AI software can't be considered in a different way: one thing is the vast hardware resources that running it requires at this moment, so it may need to be run externally (but this should change in the future), and a very different one is to neglect its free licensing. Some years from now, good AI should be able to easily run in a normal computer or server. With AI computing, we are still like in the mainframe era of the 1960s. The AI equivalent of the 1980s and the Personal Computer will need to arrive at some moment. MGeog2022 (talk) 09:21, 27 September 2026 (UTC)

Should admins be running AI Noticeboard?

Currently the AI Noticeboard is run by Editors not the administrators I want to put it simply that my idea is that administrators should run AI noticeboard like they with other noticeboards there needs to be a an appropriate level oversight.

The structure should follow structure as other noticeboards where editors can file a report.

What do you think of this idea?

1keyhole (talk) 01:15, 21 September 2026 (UTC)

Wikipedia:Noticeboards#List has a long list of noticeboards. What percentage of those do you believe are actually "run by admins"? I'll help you out with one: to the extent that anyone can be said to actually "run" the Wikipedia:External links/Noticeboard, it's me, and I'm not an admin. WhatamIdoing (talk) 02:53, 21 September 2026 (UTC)

You need to become an admin. For sure. You have more common sense than 90% of Wiki users. So just become one. Yesterday, all my dreams... (talk) 05:13, 21 September 2026 (UTC)

I may not always agree with waid, but she has an annoyingly charming habit of changing my mind anyways (partially sometimes or fully most other times). im certain she would be an excellent admin if she wanted to User:Bluethricecreamman (Talk·Contribs) 05:36, 21 September 2026 (UTC)

There should be a barnstar specifically for editors who publicly say that they have changed their minds. It is something we need to encourage. WhatamIdoing (talk) 16:10, 21 September 2026 (UTC)

Well, I would not get that since even privately I can not recall having changed my mind on any wiki discussion. Our agreement rate is probably around 50% but I do respect your work. As for barnstars, I think they are nonsense, so one other item we do not agree on. Have a good day. Yesterday, all my dreams... (talk) 16:33, 21 September 2026 (UTC)

Context: WP:AINB#User:1keyhole Kowal2701 (talk, contribs) 03:12, 21 September 2026 (UTC)

Thanks for the link. It looks like a difficult situation. WhatamIdoing (talk) 16:11, 21 September 2026 (UTC)

FWIW, AINB is primarily a cleanup noticeboard with conduct issues tacked onto it. Admins do patrol it, and admin actions can be requested using {{@AINBA}}.

If anyone has any other criticisms or potential improvements for AINB (or AI cleanup in general), now would be a good time to voice them as we're currently looking at moving to new system (mostly translating the current system to have reports on subpages a la SPI) Kowal2701 (talk, contribs) 03:34, 21 September 2026 (UTC)

Admins are just editors with a few extra tools. being an admin is not supposed to be that important wrt building an encyclopedia anyways that ainb should be blocked to nonadmin users User:Bluethricecreamman (Talk·Contribs) 05:26, 21 September 2026 (UTC)

It's a content noticeboard and so should not be run by admins, as they have no special say in content matters. -- LCU ActivelyDisinterested «@» °∆t° 13:20, 21 September 2026 (UTC)

By the way, I think you should also become an admin. In my view you and Whatami are the top 2 best editors. Your agreement rate is well below 50% but you are both very good. So go for it. Yesterday, all my dreams... (talk) 16:29, 21 September 2026 (UTC)

Our agreement rate is much higher than is visible. I frequently decide not to post in discussions because AD's already said everything that needs to be said. WhatamIdoing (talk) 16:59, 21 September 2026 (UTC)

Something I also find myself. I remember asking you the same question about becoming an admin, I'll quote you as my answer to Yesterday "Thank you for the compliments. I won't run." -- LCU ActivelyDisinterested «@» °∆t° 19:00, 21 September 2026 (UTC)

We should stop this now before everyone gets complimented to near death. Yesterday, all my dreams... (talk) 19:45, 21 September 2026 (UTC)

FWIW, from my perspective, the thing needed to help AINB is not administrative support. It's just more bodies helping cleanup, which doesn't necessarily require admin tools. And frankly is a good way for someone to build the experience/credentials if they wanted to be one. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 20:42, 21 September 2026 (UTC)

I fully agree with you that there is no need to be an admin to be active on noticeboards. Regarding the AI board, that is 10 times as true. I acted on that board for a short while. It was utterly frustrating because in my view there was too much tolerance towards users who utilized AI. It was like, ok, you have done 3 bank robberies, now try not to kill any anyone during your next robbery. Now you know why that board is short of bodies.. Yesterday, all my dreams... (talk) 21:52, 21 September 2026 (UTC)

The context this person has left out, as Kowal has mentioned above, is that they have an active AI noticeboard thread about their AI use, which has resulted in a lot of their articles being LLMPRODed as they flounced: I am respectfully stepping away from this discussion and topic to take an extended break from editing. This suggests that their respectfully stepping away from their previously scheduled respectfully stepping away, in order to vaguepost here about how there needs to be a an appropriate level oversight, is an attempt to WP:FORUMSHOP/ask to speak to the AI cleanup board's manager. Gnomingstuff (talk)

To be fair, it's reasonable to ask the community to check whether a cleanup board is being properly run. I personally think this one is being properly run but the question isn't nuts.

The view from 30,000 feet is that admins are elected to deal with conduct problems and normal editors (in practice extended-confirmed editors) deal with content problems. AI cleanup straddles both, so you do need admins at that board to deal with the conduct stuff.—S Marshall T/C 11:34, 25 September 2026 (UTC)

It's reasonable to ask in good faith; the example here clearly is not, given the context. Gnomingstuff (talk) 23:11, 26 September 2026 (UTC)

It brings to mind blocked editors screaming for reviews because clearly their block is the result of a grand conspiracy among the admin cabal - all the way through losing talk page access and finally getting shut down for good by UTRS, therefore obviously confirming said mass conspiracy. ChompyTheGogoat [ Bleat | Munched ] 10:19, 27 September 2026 (UTC)

• No: (1) as others have said, the clean-up function of AI noticeboard is a content-editing matter in which admins have no special role; but (2) detection of AI is a specialist skill, likely to become harder. AI noticeboard will inevitably play a role in identifying people whose AI behaviour is inappropriate, and that's where admin activity becomes necessary. Separating the AI experts from the behaviour-enforcers means we aren't asking the police investigators to be the jury and judge. AI experts can identify problematic behaviour on this noticeboard, but admins get a chance to sanity-check the evidence before taking action. Elemimele (talk) 16:30, 29 September 2026 (UTC)

Marshall, it depends on what one considers "proper" of course. I no longer even glance at that board because I see it as an example of how a group of well meaning editors are reduced to participating in extremely inefficient editing by dealing with repeat offenders who refuse to clean up their own mess. The well meaning editors seem petrified, yes petrified, that the messy editors may leave Wikipedia. Are we kidding or what? So you have a repeat bank robber and you fear that he may leave town? What can I say except: waste of time. Yesterday, all my dreams... (talk) 08:20, 30 September 2026 (UTC)

Student research question: wikitext vs VisualEditor

Hi, I'm a university student doing a coursework case study on MediaWiki's move from the legacy wikitext parser to Parsoid. I'm not a Wikipedia editor myself, just researching for a report. If anyone has a moment, I'd love to hear your thoughts on a few questions:

1. Do you mainly edit using wikitext or VisualEditor, and why?

2. What's the hardest part of wikitext for newcomers, in your experience?

3. Has VisualEditor made onboarding easier, or created its own problems?

4. Any concerns about Wikimedia making Parsoid the default parser (e.g. templates or bots breaking)?

Thanks a lot for your time. Happy to keep this short if you can only answer one or two. BirungiHairat (talk) 12:46, 23 September 2026 (UTC)

1. Wikitext, because when I started this twenty years ago, that was the only way to work, and now I'm highly accustomed to it.
2. Citations.
3. Yes to both.
4. Haven't seen any unwelcome side effects.

Hope this helps.—S Marshall T/C 21:46, 24 September 2026 (UTC)

1. I use the visual editor, VisualEditor's wikitext mode, and the 2010 wikitext editor, depending on the task at hand. The visual editor is best for copyediting and tables. Any wikitext editor is better for switching from one template to another (e.g., from {{infobox person}} to {{infobox musician}} without having to re-add all the content). I mainly use the 2010 WTE when I'm concerned that the Preview in VisualEditor (which uses Parsoid) might not produce the same appearance as the legacy parser.
2. Templates, especially Wikipedia:Citation templates. However, wikitext is IMO not the biggest thing that newcomers struggle with; instead, many of them struggle with the contents (e.g., whether that thing they read on social media is true, or whether the things that they see in their filter bubble are representative of the main viewpoints on a subject).
3. Without the visual editor, the pattern would likely be: Step 1, struggle with wikitext; Step 2, struggle with content. With the visual editor, they can often skip straight to Step 2.
4. On a wiki as complex as this one, we should expect a few odd results. Someone will have a dodgy template or a bit of complex formatting, so the switch will expose the oddity. Therefore, right after we get Parsoid everywhere, we can expect someone to be terribly upset, and instead of fixing the underlying problem, they'll probably create a petition to get rid of Parsoid.

BTW, "VisualEditor" normally refers to the software package, and "the visual editor" is normally used to talk about the visual editing mode, because technically VisualEditor has both wikitext and visual options. Try changing the settings in Special:Preferences#mw-prefsection-editing-editor if you want to try them all out, or these links might work:

• https://en.wikipedia.org/wiki/Abstract_algebra?veaction=edit (the visual editor)
• https://en.wikipedia.org/wiki/Abstract_algebra?veaction=editsource (VE's 2017 WTE)
• https://en.wikipedia.org/wiki/Abstract_algebra?action=submit (2010 WTE)

Additionally, some long-time editors prefer the User:Cacycle/wikEd script, which has a different installation process. WhatamIdoing (talk) 13:54, 25 September 2026 (UTC)

Speaking this as a new-ish editor here (but knows about the "behind-the-scenes" stuff on Wikipedia):

1. I switch between both, close to 50/50, or maybe 40/60 (or vice versa). Depends on the task.
2. For mainspace articles that usually don't have any fancry HTML tags/CSS styling, citations. But the 2017 Wikitext editor can fix that (I think @S Marshall might be interested in knowing this)
3. Closer to making onboarding easier, but a small number of problems cropped up
4. Same as above (nothing is breaking due to the Parasoid switch so far)

Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 13:48, 25 September 2026 (UTC)

1. Wikitext for all my edits, because I feel I have more control over wikitext.
2. Learning format and finding it on the keyboard, for instance, when to use [[..]] and when to use {{..}}
3. I don't know, I never use it.
4. I hadn't heard about this until now, but as far as I can see, it wouldn't affect me much. How it would affect other editors, I don't know. Lova Falk (talk) 15:47, 25 September 2026 (UTC)

1. Wiki text. A lot of my edits have been to solve technical issues with article, these are much easier to solve using wikitext. Some are simply not fixable with the visual editor. I think once you get used to using wikitext the visual editor doesn't give many reasons to switch.
2. Citations and other templates. The text goes from plain text to what looks like gobbledygook.
3. Visual editors is certainly easier to get started on and so will make it easier for new editors to get started, but as I said there are still things it can't do and it doesn't have the precision of editing the source text.
4. It's the type of technical improvement that has to happen. There has been few issues with it's implementation, the only one I can think of isn't that certain templates using images fail to align correctly when previewing pages.

-- LCU ActivelyDisinterested «@» °∆t° 00:22, 26 September 2026 (UTC)

1. I use WikEd. I only use the Visual Editor on training courses.
2. Markup. Editors of an older generation were familiar with HTML, but now few see it. The whole concept of markup like [[..]] and {{..}} is unfamiliar.
3. I think that the Visual Editor makes it easier to get started, which is one reason why I use it on training courses; the other is that it is the editor most newcomers are familiar with. It used to struggle with many things, so as an older editor who attempts advanced tasks, I find that I cannot do everything with the Visual Editor. Its improvement has been fitful.
4. There was some issues with Parsoid and some things broke, although many issues have since been fixed.

Hawkeye7 (discuss) 10:53, 27 September 2026 (UTC)

1. VE when I need to move or edit large paragraphs or text, source when I need to carefully edit a few paragraphs
2. <ref></ref> tags and citations
3. Immensely and not really, at least in its current state. There are a few bugs, of course.
4. Only one: Wikipedia talk:Articles for deletion § Extra line break?

FaviFake (talk) 00:28, 28 September 2026 (UTC)

Context: I've had this account for more than a decade, but for most of that time I wasn't using it and only made minor edits to Wikipedia while logged out. This year, I got more seriously into editing, and have been doing so logged into my account, with account preferences set.

1. I use wikitext exclusively. I'm a programmer offwiki and am used to editing source code and interpreting diffs, and it makes me more confident that I know what I'm actually changing. Visual editors in general have too much magic.

2. Adding citations. Suðurhafsljósæta (talk) 08:16, 28 September 2026 (UTC)

ITN RfC Workshop

Following the close of RfC: ITN and sham elections, I have opened a workshop at Wikipedia:Village pump (idea lab)/ITN reform RFC workshop. BilledMammal (talk) 01:48, 25 September 2026 (UTC)

A sort of "practice" request for adminship feature

Hi! I would like to propose something new: a new process so that people who would like to make a request for adminship could see if they would get approved or not without making a formal proposal.

• It should be a separate page specifically for mock requests.
• On the page, it should simulate the real RfA process and NOT change it significantly.*
• If they win the vote, they could make a formal request.
• If they don't win, then they can improve themselves.
• It should be optional, but it doesn't have to.

*The only major change is to make it more lenient.

I am hoping to make a full proposition at the village pump or similar if this gains consensus. Thanks! Robloxguest3 (talk) 00:46, 27 September 2026 (UTC)

WP:ORCP is a venue where editors can see if they would get approved or not without making a formal proposal, without adding layers of RfA-style formality. —ClaudineChionh (she/her · talk · email) 00:59, 27 September 2026 (UTC)

Physical poster campaign

Attending WCNA this weekend has gotten me thinking about ways to recruit editors. I had a few discussions with people about how many of our go-to methods, like edit-a-thons, are ineffective at getting people to keep editing. Having just moved to a walkable city, I see poster campaigns fairly often, and I am curious as to whether anybody has considered some kind of equivalent aimed at recruiting people to edit Wikipedia. I am not quite sure what this would look like, but I'm envisioning QR-code posters with a graphic and a pitch to "improve Wikipedia's coverage of XYZ," with some basic analytic on the QR code to track how many scans it's receiving.

The whimsical, idealist side of me thinks that this could be a surprisingly effective means of recruitment, but the cynic in me says it would do absolutely nothing. Still, I may try to spin something like this up, even if it's just as a personal experiment. ThadeusOfNazereth(he/him)^{Talk to Me!} 02:52, 28 September 2026 (UTC)

Monmouthpedia? Not quite the same, but QR codes and logos. CMD (talk) 03:40, 28 September 2026 (UTC)

That is fascinating, thank you for sharing! You're right that it's not quite the same but it is helpful to know that this sort of real-world integration has been done before. ThadeusOfNazereth(he/him)^{Talk to Me!} 04:08, 28 September 2026 (UTC)

Update - I have mocked up a few posters and will be scattering them around Boston. This is by no means a scientific experiment (I think I could've set up a dashboard landing page to track account creations, etc), but I am interested in seeing how many people even scan the QR code. ThadeusOfNazereth(he/him)^{Talk to Me!} 14:24, 30 September 2026 (UTC)

Volunteer Outreach Team

We have the Volunteer Response Team, which responds to emails from non-Wikimedians. I am thinking of the reverse: A way for Wikipedians to send emails from an @wikipedia.org domain. I've sent countless emails to article subjects saying something to the effect of "we don't have an image of you; we would love it if you sent us one under a free license!" or "hey, the photo we have of you is really ugly; can you please send us a replacement?". I have received zero (0) replies. And I can't blame them! I, too, would ignore emails from the @gmail.com domain if they claimed to be an "admin" on a top-ten website.

I'm sure there are other use cases—for example, confirming that a WP:BLPREQUESTDELETE request is genuine. Of course, any uses would need to have explicit community consensus behind them.

It would make use of a shared email address (e.g. volunteer-outreach@wikipedia.org) to contact others, and WP:Volunteer Outreach Team noticeboard (or something like that) would exist to hear requests from all stripes of editors.

Anyone have thoughts? Could we build it on top of VRT? Other comments? Best, HouseBlaster (talk • edits • he/they) 15:24, 30 September 2026 (UTC)

I believe it's possible to build on top of VRTS (the New email ticket button under Tickets can send emails I believe). Tenshi! (Talk page) 15:32, 30 September 2026 (UTC)

Technically sending mail is already function, nothing much to change there. A new queue would need to be created, with an address like something suggested. We would need the approval of the admins for something like this, in addition to general consensus of course.

I personally like the idea a lot. I don't think many people would mind to send a nice photo over an email for their own article, it's just not much work to reply to an email, but immensely useful to us. I would love to volunteer in a queue like this. ~/Bunnypranav:<ping> 15:53, 30 September 2026 (UTC)

VRT works on external requests only, and does not active contact anybody, to not create the impression that the sender speaks for the Wikimedia Foundation or the community, and the scope of VRT currently is to answer requests only, not to create ones.

I think personal requests should be sent from personal addresses only. Krd 16:03, 30 September 2026 (UTC)

Krd is very right. While we have the functionality of sending emails on VRT, it is very odd, because it'd create an assumption that the sender is not speaking as an individual but as an agent from either the Foundation or the community at large. _signed, Aafi (guesthouse) 17:37, 30 September 2026 (UTC)

The point of this proposal is that, in some circumstances, editors should be able to speak on behalf of the community to request an image for an article. Best, HouseBlaster (talk • edits • he/they) 17:54, 30 September 2026 (UTC)

I wonder if a public message (e.g., on social media) would be more effective for photo requests. WhatamIdoing (talk) 19:04, 30 September 2026 (UTC)

Actually, we have a lot of situations when people approached the article subjects asking for a photo, and those happily sent a photo, but had no understanding of copyright and the nature of cc-by-sa licences. The photos were not properly released under a compatible license, and sometimes even were taken by a third party who had no idea about the photo being released, so unfortunately many of those ended up deleted. Ymblanter (talk) 09:14, 1 October 2026 (UTC)

That can be resolved by not just asking, but attaching a form for them to fill in. Of course people do not usually take photos of themselves, so the photographer will have to be involved. But of interest would be people who are the photographer. Please see my comment below about Danny Syon as photographer. Yesterday, all my dreams... (talk) 10:26, 1 October 2026 (UTC)

Not just that, but first explaining what the license actually means, and this is the hardest part. People are happy to send photo "to be used in Wikipedia" but they often become less enthusiastic when they learn that it can be used anywhere, by anyone, can be modified in any way and can be used commercially. Speaking as a Commons admin specializing in the image deletion. Ymblanter (talk) 11:27, 1 October 2026 (UTC)

There's an essay at WP:PICYOU encouraging article subjects to provide photos (ideally selfies) through social media, with an attempt at explaining the licensing. This is all much easier on the modern internet, where an article subject can easily and immediately share a photo to the web through a channel publicly verified as belonging to them, but it's still being used much less than it could be. Belbury (talk) 15:34, 1 October 2026 (UTC)

Ymblatner, yes that can sometimes, or often, be a problem. But not always. So is the X% that are OK with the license worth the effort? Is there a half a page simple explanation of the license issues? And of course people who are no longer alive, eg Claire Epstein would not object, and the photographer would need to consent. Also please see my comment below about the utterly depressing photo of John McCarthy (computer scientist). We need a better one, for sure. FYI many years ago I saw a photo on commons when someone's lips had been vertically reverted and they looked pretty bad. So the fears of those people are justified. The real issue then is that Wiki policies are too relaxed about images. But there is zero hope that they will change this century. Thanks for the info. Yesterday, all my dreams... (talk) 14:32, 2 October 2026 (UTC)

A general question: What about people who are no longer alive. Consider Claire Epstein. A picture of her working in the field would be interesting. There are a couple of them on the web. Tracing the photographer would be hard. How can we do this? Thanks — Preceding unsigned comment added by Yesterday, all my dreams... (talk • contribs) 19:24, 30 September 2026 (UTC)

A picture is worth... If our wiki-goal is to "inform people" we must consider the fact that in many cases we can not do so without pictures. I have to provide context. Consider the case of a rather unique character that I still find hard to understand, namely Shmarya Guttman. From age 67 to 81 or so this fellow spent about 14 years on the forsaken mountain top of Gamla, digging for archeological remnants. His wiki page page can never describe him unless you see pictures of him up there digging. His wiki page does not inform the reader about who he really was up on that mountain. Danny Syon, at one point head of archaelogy in Israel has many pictures oh him that he took. He has excellent photos of Gamla too. If you are wondering, what interested me was that Guttman lived beyond 80, despite the terrible conditions up there, burning sun, dust, no refrigerator, etc. for 14 years. And that was a lot longer life than Mark Hurd or Steve Jobs. But I digress there. Syon is alive but old. If a facility can be set up to contact Syon, I think he would provide the pictures. Yesterday, all my dreams... (talk) 10:58, 1 October 2026 (UTC)

Blaster, I think you have a very good idea. Please try to do it. Thanks Yesterday, all my dreams... (talk) 11:03, 1 October 2026 (UTC)

I think this is a great idea. I have tried (unsuccessfully) to ask for permission for photos of artwork from my personal gmail account, and maybe the outcome would be different if my request appeared more professional and official from us. Aude (talk) 11:37, 1 October 2026 (UTC)

Sorry if this is known info, but commons:Commons:WikiPortraits has some systems for this sort of need. I believe the sleight of hand there is sounding official without actually saying they are 'Wikipedia' as we might with a common email system. They issue credentials and their own sort of press pass as I understand it. I don't know if this comes with a different email domain, but it's worth asking them. CMD (talk) 11:41, 1 October 2026 (UTC)

CMD, interesting. I did not know that project existed. But from what I can see most of what they have is already there, e.g. George Clooney type people. I have been hoping for images of non-celebrities, or better images. E.g. the photos of John McCarthy (computer scientist) are all so utterly depressing and do not show the "real man" when he was active, agile and quick witted. They do him disservice. That photo is not of the real man. And I am pretty sure that unlike Clooney he never went to the Venice film festival. So getting to the photographers may be a better option. Yesterday, all my dreams... (talk) 14:47, 2 October 2026 (UTC)

This idea probably hinges on whether the WMF feels comfortable with the thought of random, anonymous volunteers sending emails from the official @wikipedia.org domain. Some1 (talk) 12:06, 1 October 2026 (UTC)

I think WMF will not feel comfortable with that if these are random emails. But when there is a will, there is a way. All emails need to have the same format and the anonymous volunteers can type nothing, except fill a form. The form needs to be reviewed by an admin, who presses the send button. It will take some software development but will better than the wasted projects like abstract wiki. Yesterday, all my dreams... (talk) 12:26, 1 October 2026 (UTC)

Technically the current VRT is also anonymous volunteers sending emails from the official @wikipedia.org domain, it is just that we currently only reply to incoming mails. By the way, random might be some oversimplification, since VRT has a vetting process and requires prior contributions in some/more wikis. ~/Bunnypranav:<ping> 13:39, 1 October 2026 (UTC)

In today's phishing world, I'm uncomfortable with sending out emails asking for people's personal information, including photos of themselves. I think public campaigns (or messages as suggested by WhatamIdoing) pointing to appropriate instructions on Commons or Wikipedia may be better, to mitigate copycat phishing activity. isaacl (talk) 15:20, 1 October 2026 (UTC)

Commons:Permission requests is a related project, set up last year. Regular users post suggestions to reach out to people or sources to licence or request a particular image, and experienced volunteers try to make that happen, via email or a social media message. I don't know what their hit rate has been. Belbury (talk) 16:27, 1 October 2026 (UTC)

Creation of a "factual accuracy" noticeboard (if something like it does not exist)

An article I'm heavily involved in (superpower) has been tagged with "factual accuracy is disputed" since July. I don't believe this is accurate at this point, but believe given the state of the articles talk page, removing it would be blocked and cause a big mess. The page has already been to DRN multiple times, and these have failed. It has also had multiple RfCs in the past several months. I was looking for a noticeboard that would be appropriate to have an articles general factual accuracy reviewed, and don't believe it fits any of the existing ones. The closest I've found is Wikipedia:Peer review, but think that process might be a bit more then this requires. The Wikipedia:Reliable sources/Noticeboard, Wikipedia:No original research/Noticeboard, Wikipedia:Third opinion, and Wikipedia:Neutral point of view/Noticeboard all come close, but don't include the focus of broadly verifying the facts/claims made in an article. Third opinion is limited to disputes between two editors, not multiple. Without something specific to this tag, when a dispute happens, it seems impossible to resolve as long as editors continue to dispute it on the talk page. In cases like this, nothing short of fully capitulating to a specific world view is likely to resolve the dispute. If something already exists that I've never seen before, that's great! Please point me there. If not, I think this could be a useful thing that exists somewhere between RfC/3rd opinion/DRN/Peer review and the reliable source noticeboard. Otherwise, I believe this tag is too broad/general to be useful for anything but undermining the faith in an articles content. GeogSage ^{(⚔Chat?⚔)} 01:20, 3 October 2026 (UTC)

Hi @GeogSage! I hope you’ve been well. I doubt we need additional bureaucracy, but it can’t hurt to try to form a guild of fact checkers like Wikipedia:WikiProject Guild of Copy Editors. As I write that I bet my elders will advise 5 things that have been tried already. In the meantime, I’ll take a look myself. Dw31415 (talk) 02:32, 3 October 2026 (UTC)

I see that there is an open RfC on the page and this post might be considered Wikipedia:Forum shop. Others

Please see Talk:Superpower#RfC on including the DiME index Dw31415 (talk) 02:57, 3 October 2026 (UTC)

This has nothing to do with that particular RfC, the RfC is about if an Index should be included or not and is mostly a question of Wikipedia:No original research/Synthesis. This is about the inability for me to find a way to properly resolve a specific maintenance tag, "factual accuracy is disputed," after noticing the gap in existing noticeboards. When I was not able to find a way to resolve it, I figured one could either be created, or someone could point me in the right direction towards an existing process specific to that template. GeogSage ^{(⚔Chat?⚔)} 03:55, 3 October 2026 (UTC)

Why does there need to be a noticeboard for every issue? Katzrockso (talk) 13:27, 3 October 2026 (UTC)

There doesn't, ideally we could just expand an existing noticeboard to cover this. At this point though, removing the template would be contested simply because the page is not presenting a specific POV, and I've already been accused of "vandalize page without any constraints" and "cunningly" "spreading biased disinformation" today, so I'd rather find an uninvolved editor to check the general factual accuracy of the article and if appropriate remove the template. Having this maintenance template but no place to discuss resolving it seems like a gap. GeogSage ^{(⚔Chat?⚔)} 13:42, 3 October 2026 (UTC)

There doesn't. We probably have too many already. Disputes need to be settled through discussions based around core Wikipedia policy (WP:NPOV, WP:RS etc) and long-running ones very rarely come down to something that can be simplistically labelled 'factual accuracy'. In the case of this dispute, there are few facts involved anyway, since 'superpower' is self-evidently a word of contested meaning, and not a 'fact' at all. It's all opinion, driven by ideology. We can, and should, report opinion, if due. We are under no obligation to pretend it is fact. AndyTheGrump (talk) 13:47, 3 October 2026 (UTC)

I’m willing to help with the template after the current RfC is resolved. Dw31415 (talk) 13:45, 3 October 2026 (UTC)

Thanks. The template has been there longer then the RfC by a few months. I haven't known what to do about it since August, and finally gave up trying to find a venue to discuss it clearly. As for for what Andy said, I 100% agree with what you said about this dispute, but think that if we are going to have a template like this, there should be a clear place to go to request eyes on it. Looking at the Wikipedia:Template index/Disputes, there are probably a few similar gaps. We have plenty of noticeboards/Wikiprojects, as you've said, we could just go down these templates and find an existing noticeboard to take responsibility for them. For example, good luck resolving Template:Disputed map for anything but the most basic issues unless you have someone who understands cartography. Literally all maps are factually inaccurate by their nature, so it is possible to dispute any map if you want to be pedantic. Knowing when factual inaccuracy in maps is an acceptable white lie vs misinformation is not something the average editor could really weigh in on. Maybe Wikiproject Maps could field these arguments, and we could point editors to a talk page there. This is two examples from the list, but if we don't have a central place to get a 3rd party to help check that a template is resolved, then maybe we shouldn't have that template. GeogSage ^{(⚔Chat?⚔)} 14:01, 3 October 2026 (UTC)

Hi Andy, if you’re at a keyboard could you please fix your reply to come after mine and delete this message. Thanks! Dw31415 (talk) 13:52, 3 October 2026 (UTC)

I was replying to Katzrockso. That's how talk page indentation is supposed to be used. AndyTheGrump (talk) 13:56, 3 October 2026 (UTC)

@AndyTheGrump: Looks like you made an error. In Special:Diff/1378206051, Dw31415 wrote a reply to GeogSage's message. When you replied in Special:Diff/1378206496 to Katzrockso's message, yours should have gone (with the same indentation) after Dw31415's reply, while you inserted your edit before. I.e. it should have looked like

::: Katzrockso
:::: GeogSage
::::: Dw31415
:::: AndyTheGrump

but instead you produced

::: Katzrockso
:::: GeogSage
:::: AndyTheGrump
::::: Dw31415

which makes it look like Dw31415 was replying to you instead of GeogSage. The situation is further complicated now because GeogSage wrote a further reply to Dw31415 which also mentions you. Anomie⚔ 14:18, 3 October 2026 (UTC)

We can leave it. Thanks for explaining!! Dw31415 (talk) 14:20, 3 October 2026 (UTC)

We don't need a separate noticeboard for every maintenance tag. If the problems with Superpower are so intractable that every other dispute resolution lever has been pulled to no effect, it is unlikely that a bespoke noticeboard will be any more successful. —Myceteae‍🍄‍🟫 (talk) 15:53, 3 October 2026 (UTC)

Extended confirmed edit requests

Has there been any work to make it easier to manage edit protection? The good requested edits at Talk:Flydubai Flight 1073 are coming in hot. Is there a template that could help? Use a sandbox? A new button? I know it’s a short term issue for this page but a reoccurring one I’m sure. Dw31415 (talk) 13:50, 3 October 2026 (UTC)